Hacker News Top 30 — 2026-04-25

April 24, 2026 at 3:50 PM UTC

Google will invest $10 billion in Anthropic PBC, with another $30 billion potentially to follow, strengthening the relationship between two companies that are at once partners and rivals in the race to build artificial intelligence.

Anthropic said that Google is committing to invest $10 billion now in cash at a $350 billion valuation, the same amount it was valued at in a funding round in February, not including the recent money raised. The Alphabet Inc.-owned company will invest another $30 billion if Anthropic hits performance targets, the startup said Friday, and support a significant expansion of Anthropic’s computing capacity.

From Wikipedia, the free encyclopedia

Paraloid B-72

Names
Other names B-72 Acryloid B-72 (obsolete)
Identifiers
ChemSpider	none
Properties
Density	9.6 lb gal−1 (1.15 g cm−3)
Hazards
Safety data sheet (SDS)	MSDS
Except where otherwise noted, data are given for materials in their standard state (at 25 °C [77 °F], 100 kPa). Infobox references

Paraloid B-72 or B-72 is a thermoplastic resin that was created by Rohm and Haas for use as a surface coating and as a vehicle for flexographic ink. Subsequently, it has found popular use as an adhesive by conservator-restorers, specifically in the conservation and restoration of ceramic objects, glass objects,^[1] the preparation of fossils, the hardening of piano hammers,^[2][3] and can also be used for labeling museum objects.^[4]

B-72 is a durable and non-yellowing acrylic resin, which can be described chemically as an ethyl methacrylate–methyl acrylate copolymer. It is soluble in acetone, ethanol, toluene, and xylenes, among other solvents and solvent mixtures.^[5]

One of the major advantages of B-72 as a consolidant is that it is stronger and harder than polyvinyl acetate without being extremely brittle. This adhesive is more flexible than many of the other typically used adhesives and tolerates more stress and strain on a join than most others. The major drawbacks to using B-72 are related to its handling properties: as in the case of other acrylic resins it is difficult to apply as an adhesive and to manipulate with precision.^[6]

The most suitable solvent for B-72 is acetone. However, solvent mixtures with various proportions of acetone, ethanol, and toluene are frequently used to alter the working time of the resin and to produce slightly different properties (hardness and flexibility, e.g.) in the set resin. Unlike cellulose nitrate, B-72 does not need additives like plasticizers to stabilize its durability. Fumed colloidal silica can be added to help with the workability of the resin. Research shows that the silica better distributes the stress and strain that occurs during evaporation of a solvent and during the setting of the adhesive film.^[6]: p.9

Because of its transparency and versatility, conservators, led by Stephen Koob of the Corning Museum of Glass, have recently begun to use cast sheets of B-72 as a fill material in glass objects.^[7]

last year i bought a Rodecaster Duo to solve some audio woes to allow myself and my girlfriend to have microphones to our respective computers when gaming together and talking on discord in the same room without any echo, and to be able to swap that to my work pc easily. the rodecaster is really nice, it's pretty effortless to use and works great for our home. I would gladly recommend it to anyone looking for a similar solution.

as is usual for any device in my house, i try to ensure when it's time to update the firmware I have enough tooling in place to capture how firmware updates work, or to at a minimum capture a firmware blob to try and reverse engineer it and poke around for fun and/or to see the often horrific reality that is the industry we work in.

fw update

I was feeling pretty lazy and assumed that rode would dump the firmware somewhere on my computer before flashing the device, so i set up Instruments on macos to capture disk activity, and found where the fw was dumped, and surprisingly it was just a gzipped tarball. The device I did this update on happened to have the ability to write to USB disks disabled, so the update actually failed.

Poking around a bit, i found the binaries of the stuff that actually runs on the device, as well as a shell script that handles the updates themselves. there are two partitions on the disk, so that if you brick one it boots from the other. It also doesn't have any signature checks or anything on the incoming firmware. I'm used to many vendors of this style of device requiring signed firmwares or something nowadays, kind of nice to actually own a device I can modify. I also noticed that ssh seemed to be enabled by default, and plugged in an ethernet cable and saw that ssh indeed is enabled w/ pubkey auth only. Here are the keys that are added by default:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCX/bCFTDgViuPvdFL/VMMVRrw9b5S8HcDQk17qoCEYwmI+IIG8rEAsLiaeCOwyhf9IN+8/LRaN0Z5ZfU3WMbmsKEg8zd1Yvqq74nFbhO47vbtzmCi9S4ucIKkBEVOyvyN5lt9hWf5t5nZSmlfldZK3Pem5y8wHM5A+K/gSnzp4gwQ1QYfFb068uQ+ciIdOhb8SkUs8CwzotglIbp19I6ZmXmsNj/TmpbUf5rMfUAf1gysZ5j1UdRWrvWVh5daqvZRsBBPbXEeJfDU3Nr3HR14XYt9mgexrz/5oyKSj/lQYLmh9cDfsxvkGNIQ8fF9l+n2L1KZM4lLgiGk4KFBjQHaIBZx9OebCiiZCO4NTJUBDk9a+SZpiDiipADV07s7vTInYyFA6GrmKtnq3M6upT4WJBvVuL/BMnK5yY1RZtoqox2/pcCg2rH5S1GIy0v0HFJisl7kWInlaG2mdsaCx19wAjCFe/qT9LyxjQ6+0rArI55/JJFDkNeMjrewRQwNdASjCox8vqXCBfjvsR9qv70/ywcymgsnLAnq2LuYg5FYwMMDYOvVnhACC+BYTdNDTn5oeMIjQCUenY/DPCHpJkf4YOf3YCMUTEU9tExhtwW/X+m21hS3+STLtTfqbUeg9CeuPQZgfl9vc65n3tMxAdlEGEDoTaNMAgr2TzJv92Ka9iQ==
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDaNyzPfIcEeQsfzyQs/wyX6mX52kiS+4eNHfCaxFlgj

since our update failed, i swapped to a windows pc and set up wireshark with USBPcap and then ran the update thru the rodecaster app. I roughly glanced at the pcap file and looked at where the update started, since it was a lot of traffic as I was also using it for audio on another computer. I wrote down the packet numbers I thought were interesting and threw them to claude code to dig thru the pcap while I was doing other stuff.

A bit later (cc only took 10 minutes or so but I was busy for a while) I came back to a breakdown of the structure, and a python script to manually update a device. The RODECaster App sends some HID control stuff to the device, one command to enter the update mode (the 'M' command), and then another (the U command) to trigger the update. Both are just single ASCII characters sent over HID report 1.

I am but a yaml-writing slave and sometimes a below-average ghidra user, and don't often interact with hardware devices, so getting some help from CC in discovery was useful, as well as pointing me to resources to actually learn more about hid devices.

The structure was pretty simple, you send the m command, and then copy archive.tar.gz and archive.md5 (obviously just with md5sum of the archive) onto the newly exposed disk. then you send the U command to trigger the flashing itself.

so the flow is:

1. plug in the rodecaster and power it on (or vice versa)
2. send the 'M' command
3. mount the disk and copy archive.tar.gz and archive.md5 to it
4. chmod 777 both of them because i dont care to figure out how to do it properly
5. unmount the disk
6. send the 'U' command
7. wait for the thing to reboot into your new firmware

custom firmware

I was still working from my mac, and wanted to create some cfw to be able to ssh into the device, so i just used a container to enable password authentication for ssh (don't shoot me) as well as add my own pubkey to the authorized keys, and dump out an archive for me to flash. you don't really need much to actually flash the device, see here (example of the functions its not really much to add the rest.)

run your script to flash the thing and bingo bongo you can ssh to it

conclusion

I was really surprised that I could actually flash firmware so easily to this, and it is really nice to own a device. It's a really nice piece of kit and just kinda blends into the background and I never have to think about it. I don't really know why ssh was enabled, or why it had this key added by default, but I submitted a ticket to RODE for this as I could not find an obvious security email to report to. I did not hear back, but I will watch to see if future firmware updates change anything.

It's been a few months since i've done anything with this, and I am trying to just dump out my thoughts into a notepad and only very lightly edit it and then just poast. I really love all of the RODE stuff I have, and yet again just want to buy more gear.

if you want to ask me questions about this or have any questions, you can reach me with the primary letter of this domain, at this domain.

thanks computer, until next time

Hi friends,

I’ll be attending Babashka Conf on May 8 and Dutch Clojure Days on May 9. If you’re attending either (or just visiting Amsterdam), drop me a line!

When I have an idea for a project, it tends to go in one of these two directions:

1. I just do it. Maybe I make a few minor revisions, but often it turns out exactly how I’d imagined and I’m happy.

2. I think, “I should look for prior art”. There’s a lot of prior art, dealing with a much broader scope than I’d originally imagined. I start to wonder if I should incorporate that scope. Or perhaps try to build my thing on top of the existing sorta-nearby-solutions. Or maybe I should just use the popular thing. Although I could do a better job than that thing, if I put a bunch of time into it. But actually, I don’t want to maintain a big popular project, nor do I want to put that much time into this project. Uh oh, now I’ve spent a bunch of time, having neither addressed the original issue nor experienced the joy of creating something.

I prefer the first outcome, and I think the pivotal factor is how well I’ve internalized my own success criteria.

For example, last weekend I hosted my friend Marcin and we decided it’d be fun to do some woodworking, so we threw together this shelf and 3d-printed hangers for my kitchen:

Absolute banger of a project:

• brainstormed the design over coffee
• did a few 3d-print iterations for the Ikea bin hangers (OnShape CAD, if you want to print your own)
• used material leftover from my workbench
• rounded the corner by eye with a palm sander
• sealed the raw plywood edge with some leftover paint from a friend
• done in a weekend

The main success criteria was to jam on woodworking with a friend, and that helped me not overthink the object-level success criteria: Just make a shelf for my exact kitchen!

In contrast, this past Friday I noticed difftastic did a poor job, so I decided to shop around for structural/semantic diff tools and related workflows (a topic I’ve never studied, that I’m increasingly interested in as I’m reviewing more and more LLM-generated code).

I spent 4 hours over the weekend researching existing tools (see my notes below), going through dark periods of both “semantic tree diffing is a PhD-level complex problem” and “why do all of these have MCP servers? I don’t want an MCP server”, before I came to my senses and remembered my original success criteria: I just want a nicer diffing workflow for myself in Emacs, I should just build it myself — should take about 4 hours.

I’m cautiously optimistic that, having had this realization and committing myself to a minimal scope, I’ll be able to knock out a prototype before running out of motivation.

However, other long-running interests of mine:

• interfaces for prototyping hardware (discussed September 2023)
• a programming language that fuses what I like about Clojure and Rust (November 2023)
• a programming language for CAD (constraints, bidirectional editing, other dubious ideas)

seem to be deep in the well of outcome #2.

That is, I’ve spent hundreds of hours on background research and little prototypes, but haven’t yet synthesized anything that addresses the original motivating issue.

It’s not quite that I regret that time — I do love learning by reading — but I have a nagging sense of unease that my inner critic (fear of failure?) is silencing my generative tendencies, keeping me from the much more enjoyable (and productive!) learning by doing.

I think in these cases the success criteria has been much fuzzier: Am I trying to replace my own usage of Rust/Clojure? Only for some subset of problems? Or is it that I actually just need a playground to learn about language design/implementation, and it’s fine if I don’t end up using it?

Ditto for CAD: Am I trying to replace my commercial CAD tool in favor of my own? Only for some subset of simple or particularly parametric parts? Do I care if it’s useful for others? Does my tool need to be legibly different from existing open-source tools?

It’s worth considering these questions, sure. But at the end of the day, I’d much rather have done a lot than have only considered a lot.

So I’m trying to embrace my inner clueless 20-year-old and just do things — even if some turn out to be “obviously bad” in hindsight, I’ll still be coming out ahead on net =D

Conservation of scope creep

Of course, there’s only so much time to “just do things”, and there’s a balance to be had. I’m not sure how many times I’ll re-learn YAGNI (“you ain’t gonna need it”) in my career, but I was reminded of it again after writing a bunch of code with an LLM agent, then eventually coming to my senses and throwing it all out.

I wanted a Finda-style filesystem-wide fuzzy path search for Emacs. Since I’ve built (by hand, typing the code myself!) this exact functionality before (walk filesystem to collect paths, index them by trigram, do fast fuzzy queries via bitmap intersections), I figured it’d only take a few hours to supervise an LLM to write all the code.

I started with a “plan mode” chat, and the LLM suggested a library, Nucleo, which turned up since I wrote Finda (10 years ago, eek!). I read through it, found it quite well-designed and documented, and decided to use it so I’d get its smart case and Unicode normalization functionality. (E.g., query foo matches Foo and foo, whereas query Foo won’t match foo; similarly for cafe and café.)

Finding a great library wasn’t the problem, the problem was that Nucleo also supported some extra functionality: anchors (^foo only matches at the beginning of a line).

This got me thinking about what that might mean in a corpus that consists entirely of file paths. Anchoring to the beginning of a line isn’t useful (everything starts with /), so I decided to try and interpret the anchors with respect to the path segments. E.g., ^foo would match /root/foobar/ but not /root/barfoo/.

But to do this efficiently, the index needs to keep track of segment boundaries so that the query can be checked against each segment quickly.

But then we also need to handle a slash occurring in an anchored query (e.g., ^foo/bar) since that wouldn’t get matched when only looking at segments individually (root, foo, bar, and baz of a matching path /root/foo/bar/baz/).

Working through this took several hours: first throwing around design ideas with an LLM, having it write code to wrap Nucleo’s types, then realizing its code was bloated and didn’t spark joy, so finally writing my own (smaller) wrapper.

Then, after a break, I realized:

1. I can’t think of a situation where I’d ever wished Finda had anchor functionality
2. In a corpus of paths, I can anchor by just adding / to the start or end of a query (this works for everything except anchoring to the end of a filename).

So I tossed all of the anchoring code.

I’m pretty sure I still came out ahead compared to if I’d tried to write everything myself sans LLM or discussion with others, but I’m not certain.

Perhaps there’s some kind of conservation law here: Any increases in programming speed will be offset by a corresponding increase in unnecessary features, rabbit holes, and diversions.

Structural diffing

Speaking of unnecessary diversions, let me tell you everything I’ve learned about structural diffing recently — if you have thoughts/feelings/references in this space, I’d love to hear about ‘em!

When we’re talking about code, a “diff” usually means a summary of the line-by-line changes between two versions of a file. This might be rendered as a “unified” view, where changed lines are prefixed with + or - to indicate whether they’re additions or deletions. For example:

We’ve removed coffee and added apple.

The same diff might also be rendered in a side-by-side view, which can be easier to read when there are more complex changes:

The problem with these line-by-line diffs is that they’re not aware of higher-level structure like functions, types, etc. — if some braces match up somehow between versions, they might not be shown at all, even if the braces “belong” to different functions.

There’s a wonderful tool, difftastic, which tries to address this by calculating diffs using treesitter-provided concrete syntax trees. It’s a huge improvement over line-based diffs, but unfortunately it doesn’t always do a great job matching entities between versions.

Here’s the diff that motivated this entire foray:

Note that it doesn’t match up struct PendingClick, it shows it deleted on the left and added on the right.

I haven’t dug into why difftastic fails to match here, but I do feel like it’s wrong — even if the overall diff would be longer, I’d still rather see PendingClickRequest and PendingClick matched up between both sides.

Here’s a summary of tools / references in the space:

• The most “baked” and thoughtful semantic diff tool I found is, perhaps unsurprisingly, semanticdiff.com, a small German company with a free VSCode plugin and web app that shows diffs for github PRs. Unfortunately they don’t have any code libraries I can use as a foundation for the workflow I want.

  • this semanticdiff vs. difftastic blog post covers a lot of great details (including that difftastic doesn’t even show semantically meaningful indentation changes in python !!!)
  • one of the authors has great HN comments with hard-won background knowledge. E.g., they moved away from treesitter because it’s unreliable for semantics:

  Context-sensitive keywords in particular were a constant source of annoyance. The grammar looks correct, but it will fail to parse because of the way the lexer works. You don’t want your tool to abort just because someone named their parameter “async”.

• diffsitter

  • built on treesitter, has MCP server. README includes list of similar projects.
  • lots of github stars, but doesn’t seem particularly well-documented; I couldn’t find an explanation of how it works, but the difftastic wiki says it “runs longest-common-subsequence on the leaves of the tree”

• gumtree

  • research / academic origin in 2014
  • requires Java, so no-go for my use case of a quick tool I can use via Emacs

• mergiraf: treesitter-based merge-driver written in rust

  • very nice architecture overview; tool uses Gumtree algorithm
  • docs and adorable illustrations indicate this project was clearly written by a thoughtful human
  • semanticdiff.com author in HN comments: > GumTree is good at returning a result quickly, but there are quite a few cases where it always returned bad matches for us, no matter how many follow-up papers with improvements we tried to implement. In the end we switched over to a dijkstra based approach that tries to minimize the cost of the mapping

• weave: also a treesitter-based merge-driver written in Rust

  • feels a bit “HN-optimized” (flashy landing pages, lots of github stars, MCP server, etc.)
  • I looked into their entity extraction crate, sem
  • core diffing code is OK but pretty wordy
  • greedy entity matching algorithm
  • data model can’t detect intra-file moves, even though those might be significant
  • includes a lot of heuristic “impact” analysis, which feels like overreaching-scope to me since it’d require much tighter language integration before I’d trust it
    • ran into buggy output when running sem diff --verbose HEAD~4; it showed lines as having changed that…didn’t change at all.
  • Too much 80%-done, hypothetically useful functionality for me to use as a foundation, but props for sure to the undergrad/student(?) who’s built all this in just three months.

• diffast: tree edit-distance of ASTs based on an algorithm from a 2008 academic paper.

  • supports “Python, Java, Verilog, Fortran, and C/C++ via dedicated parsers”
  • has a nice gallery of example AST differences
  • can export info in tuples for datalog

• autochrome: Clojure-specific diffs based on dynamic programming

  • excellent visual explanation and example walkthrough

• Tristan Hume has a great article on Designing a Tree Diff Algorithm Using Dynamic Programming and A*

My primary use case is reviewing LLM output turn-by-turn — I’m very much in-the-loop, and I’m not letting my agent (or dozens of them, lol) run wild generating 10k+ lines of code at a time.

Rather, I give an agent a scoped task, then come back in a few minutes and want to see an overview of what it did and then either revise/tweak it manually in Emacs or throw the whole thing out and try again (or just write it myself).

The workflow I want, then, is to

• see a high-level overview of the diff: what entities (types/functions/methods) were added/removed/changed?
• quickly see textual diffs on an entity-by-entity basis (“expanding” parts of the above summary)
• quickly edit any changes, without having to navigate elsewhere (i.e., do it inline, rather than having to switch from “diff” to “file)

Basically, I want something like Magit’s workflow for reviewing and staging changes, but on an entity level rather than file/line level.

In light of the "minimal scope, just get your project done” lesson I’ve just re-learned for the nth time, my plan is to:

• throw together my own treesitter-based entity extraction framework (just Rust for now)
• do some simple greedy matching for now
• render the diff to the command line

Once that seems reasonable (i.e., it does a better job than difftastic did on that specific commit), I’ll:

• wire into a more interactive Magit-like Emacs workflow (maybe I can reuse Magit itself!?!)
• add support for new languages, as I need them
• potentially explore more sophisticated score-based global matching rather than simple greedy matching

Mayyybe if I’m happy with it I’ll end up releasing something. But I’m not trying to collect Github stars or HN karma, so I might just happily use it in the privacy of my own home without trying to “commercialize it”.

After all, sometimes I just want a shelf.

Misc. stuff

• I’m in the market for a few square meters of Tyvek or other translucent, non-woven material suitable for building a light diffuser — let me know if you have any favorite vendors that can ship to the EU.

• How They Made This - Coinbase Commercial Breakdown. Crypto is a negative-sum parasite on productive economic activity, but has the silver lining of funneling a lot of capital to weird creative folks.

• A tail-call interpreter in (nightly) Rust

• The Easiest Way To Design Furniture…. Laura Kampf on getting off the computer and designing physical spaces with tape, lil’ wood sticks, and cardboard.

• Hotel California - Reimagined on the Traditional Chinese Guzheng

• C is not a low-level language: Your computer is not a fast PDP-11.

• I Taught My Dog to Vibe Code Games - Caleb Leak

• Loon is a Lisp. Thrilled to discover I’m not the only one who wants to mash together Clojure and Rust. The current implementation seems to have been manically vibe-coded and I quickly ran into some terrible bugs, but on the other hand it exists so I’m not going to be a hater.

• Made a print in place box so I can easily hand out printed bees🐝. “Im quite content with the result, the bees fit snugly and the box opens and closes nicely”

• Yeast-based vaccines are a big deal for biosecurity

• “There isn’t a lot of reliable information out there about how to buy a gas mask, especially for the specific purpose of living under state repression. But hopefully after reading this guide you’ll feel equipped to make an educated decision.”

• “This zoomable map shows every page of every issue of BYTE starting from the front cover of the first issue (top left) to the last page of the final edition (bottom right). The search bar runs RE2 regex over the full text of all 100k pages.” A lovely reminder that user-interfaces can be extremely fast and information dense.

• How Every* Milk Product Is Made

• In Favour of Trying New Things – Daniel Frank

• Staring into the abyss as a core life skill

“The end then of Learning,” wrote John Milton in 1644, “is to repair the ruines of our first Parents.” The image is hard to improve: education as repair, as recovery, as the restoration of capacities diminished by sin and neglect. 

Four centuries later, in the age of generative artificial intelligence (AI), that image has become urgent again — because we are now surrounded by a technology that offers to perform, on demand, much of what we had long assumed education required us to do ourselves.

I came across Milton’s passage by chance while browsing a collection of the English writer’s works and opening it to his 1644 tract Of Education. Milton was not writing about algorithms. Yet he saw with unusual clarity the educational error that AI now magnifies: the confusion of language with learning. 

Language, he wrote, is “but the instrument conveying to us things useful to be known.” He warned against mistaking command of words for possession of the solid things those words are meant to disclose. He joined language to substance, sequence to maturation, and study to direct contact with reality — principles that four centuries have not made less urgent.

No technology in recent memory has so enlarged the instrument. Large language models such as ChatGPT can summarize books, draft essays, organize research notes, translate passages, generate code, and imitate the prose that schools and universities have long taken as evidence of education. 

Used with discipline, they can be genuinely useful. A professor may use them to prepare discussion questions. A researcher may use them to survey literature more quickly. An administrator may use them to accelerate routine writing. It would be foolish to deny their utility.

But utility is not the same as education, and AI magnifies an older weakness. It tempts us to mistake verbal fluency for understanding itself. A student can submit polished prose without having really grappled with the question. A researcher can produce a competent summary without having seen the problem clearly. A professional can sound informed without having formed a judgment. The danger is not only dishonesty — it is substitution. 

For Catholic education, that substitution matters because learning is not the production of acceptable performances but the formation of a person capable of truth, judgment and responsibility.

Milton saw a version of this in his own day. He criticized the practice of demanding “Themes, Verses and Orations” from young students before their minds had been formed by “long reading and observing.” He objected to asking for finished performances before the underlying powers had matured. 

Generative AI industrializes exactly that pedagogical mistake. It supplies finished language before the student has undergone the reading, questioning, hesitation and revision that make language meaningful. What Milton regarded as a mistake of sequence, AI turns into a system.

This matters because education is not built from answers alone. Every answer worth teaching was once a response to a question someone genuinely asked. 

Students do not assimilate knowledge merely by receiving conclusions — they must be brought into the question. That is why the principal agent of education is the student. No one can learn in another’s place. A tool may assist instruction; it cannot do the learning for the student.

The teacher’s role accordingly becomes more important in the age of AI, not less. A real teacher is not merely a distributor of content. A real teacher is an experienced guide in inquiry: someone who knows what the student has not yet seen, what distinctions must be made, what confusion needs exposing, and what question should come next. The best classroom is not a transfer of information from one container to another. It is a living act of thought. That is why seminar, disputation, laboratory, tutorial and serious conversation retain their force even when information itself becomes cheap.

We tend to celebrate knowledge: facts accumulated, results confirmed, information stored. But as the biologist Stuart Firestein has argued, discovery begins not only with what we know but with a disciplined sense of what we do not yet understand. That frontier is where large language models reach their limit. They can reorganize the archive with astonishing fluency, but they cannot inhabit uncertainty, pose a genuinely new question, or take responsibility for truth.

This clarifies why certain acts cannot be delegated to machines without ceasing to occur at all. Attending carefully to a text, weighing conflicting evidence, judging whether a conclusion is warranted, taking responsibility for what one claims — these are not ancillary tasks. They are the work by which a mind is formed. 

No machine can perform them in our place — not because machines lack processing power, but because these acts have no effect unless a person performs them. Their purpose is not to produce an output. It is to form the one who does them.

Education worthy of the name has always understood this. Its end is not the delivery of content, however accurate. It is the formation of persons capable of judgment, attention and intellectual honesty. That formation requires a genuine encounter with difficulty — the friction of a hard text, the resistance of a problem that does not yield quickly, the discomfort of revising what one believed. It requires embodiment as much as intellect: reading slowly, speaking in one’s own voice, accepting the cost of standing behind one’s words. A person does not become capable of truth by managing information alone. Wisdom is formed in contact with reality, not in its simulation.

The deepest challenge of AI in education is therefore not academic integrity, though that problem is real. It is whether we will allow our schools and universities to define learning as the production of acceptable outputs. If that is our standard, outsourcing will always look like efficiency. But if education is the formation of judgment, substitution becomes self-defeating.

What should institutions do? The answer is neither panic nor blanket prohibition. It is pedagogical redesign. More writing done in class. More oral defense of arguments. More seminars organized around live questions rather than passive downloads of information. More laboratory and studio work in which students must explain not only what a result shows but what it does not. 

When students use AI, one reasonable requirement is transparency: disclose what was asked, what the system produced, what was kept, what was rejected, and why. The point is not surveillance. It is intellectual ownership — the habit of standing behind one’s own thinking. Institutions should also reinvest in the teacher-scholar whose presence, judgment and intellectual seriousness cannot be automated.

The same commitment belongs at home. A dinner table free of devices, conversation across generations, reading aloud together, and the habit of asking children not only what they think but why — these are small schools of freedom. They teach that education is not the production of impressive sentences. It is the formation of honest minds.

The moment we are living through is, in this light, less a crisis than a clarification. AI has not created new educational problems; it has made old ones impossible to ignore. The habit of rewarding performance over understanding, fluency over depth, and polish over genuine engagement was already present in our institutions before the first language model was trained. AI simply industrializes and accelerates those habits until their emptiness becomes undeniable.

That may be its most unexpected gift. If this disruption forces us to recover what education was always for — the formation of minds capable of real questions, careful judgment, and responsibility for truth — then the age of AI may prove, paradoxically, to be an age of educational renewal. 

Milton’s deeper claim presses further. The end of learning is not merely competence or civic virtue, but to “know God aright, to love Him, to imitate Him, to be like Him.” Education, in that view, participates in the restoration of what sin has obscured.

No machine will ever repair those ruins. That restoration is finally God’s work before it is ours; yet, aided by grace, we must still undertake the human labor of attention, judgment and love.

Santiago Schnell is provost and professor of mathematics at Dartmouth, with adjunct appointments in biochemistry and cell biology, and biomedical data science at the Geisel School of Medicine. A mathematical biologist by training, he also writes on the Catholic intellectual tradition, the philosophy of science, and the mission of Catholic higher education. 

View PDF HTML (experimental)

Abstract:In this paper, we make the case that a scientific theory of deep learning is emerging. By this we mean a theory which characterizes important properties and statistics of the training process, hidden representations, final weights, and performance of neural networks. We pull together major strands of ongoing research in deep learning theory and identify five growing bodies of work that point toward such a theory: (a) solvable idealized settings that provide intuition for learning dynamics in realistic systems; (b) tractable limits that reveal insights into fundamental learning phenomena; (c) simple mathematical laws that capture important macroscopic observables; (d) theories of hyperparameters that disentangle them from the rest of the training process, leaving simpler systems behind; and (e) universal behaviors shared across systems and settings which clarify which phenomena call for explanation.
Taken together, these bodies of work share certain broad traits: they are concerned with the dynamics of the training process; they primarily seek to describe coarse aggregate statistics; and they emphasize falsifiable quantitative predictions. We argue that the emerging theory is best thought of as a mechanics of the learning process, and suggest the name learning mechanics. We discuss the relationship between this mechanics perspective and other approaches for building a theory of deep learning, including the statistical and information-theoretic perspectives. In particular, we anticipate a symbiotic relationship between learning mechanics and mechanistic interpretability.
We also review and address common arguments that fundamental theory will not be possible or is not important. We conclude with a portrait of important open directions in learning mechanics and advice for beginners. We host further introductory materials, perspectives, and open questions at this http URL.

Submission history

From: Daniel Kunin [view email]
[v1] Thu, 23 Apr 2026 13:58:12 UTC (3,519 KB)

One of my favorite ways that creative people communicate is by “working with their garage door up,” to riff on a passage from Robin Sloan (below). This is the opposite of the Twitter account which mostly posts announcements of finished work: it’s Screenshot Saturday; it’s giving a lecture about the problems you’re pondering in the shower; it’s thinking out loud about the ways in which your project doesn’t work at all. It’s so much of Twitch. I want to see the process. I want to see you trim the artichoke. I want to see you choose the color palette. Anti-marketing, after Michael Nielsen.

I love this kind of communication personally, but I suspect it also creates more invested, interesting followings over the long term. That effect’s probably related to Working on niche, personally-meaningful projects brings weirder, more serendipitous inbounds.

It’s also a way to avoid the problems described in Pitching out corrupts within. You’re not pitching. You’re just showing your work, day over day.

Maggie Appleton argues:

If you ever needed another reason to learn in public by digital gardening or podcasting or streaming or whathaveyou, add on that people will assume you're more competent than you are. This will get you invites to very cool exclusive events filled with high-achieving, interesting people, even though you have no right to be there. A+ side benefit.
This matches my experience.

References

The inspiration from Robin’s original newsletter:
☄️ Week 43, popular, wide-ranging, functional (link broken as of 2024-12-17)

I wish starting physical businesses was easier; I wish the path wasn’t so steep, especially in places like the Bay Area; because I think it’s one of the absolute best things a person can do. Among many other things, a physical business enlivens public space, by making the simple, eloquent statement: I am here, working.

There’s a scientific glassblowing studio north of us; I walk past it on the sidewalk often. By simply existing, and having a nice sign that faces the street, they are doing a small public service every day. We are here, working.

In the same light industrial complex as the Murray Street Media Lab, there’s a woodworking shop, and the man who runs it always keeps his door propped open. Simple as that. What a delight, every damn day, to ride my bike past that door and peek inside and see all his tools, the boards stacked up for whatever commission he’s undertaking. I am here, working.

Part of the problem of social media is that there is no equivalent to the scientific glassblowers’ sign, or the woodworker’s open door, or Dafna and Jesse’s sandwich boards. On the internet, if you stop speaking: you disappear. And, by corollary: on the internet, you only notice the people who are speaking nonstop.

If you could put on magic internet goggles that enabled you to see through this gnarly selection bias and view the composition of reality fairly, correctly—well, just come walk around Emeryville and West Berkeley. It would look like that! All the tumult of Twitter would shrink into a single weird cafe—just a speck, in an enormous city made up entirely of people quietly working.

Interesting to note that in a way, Robin’s looking for Peripheral vision in this aspiration.

About the author

Sourav Rudra

A nerd with a passion for open source software, custom PC builds, motorsports, and exploring the endless possibilities of this world.

• if someone is confusing or upsetting you, assume they have no sane reason for doing or saying what they are doing or saying

• when ambiguous, assume intent is malicious, ignorant, or amoral. interpret others' actions in the context of your fears

• do not challenge or acknowledge the existence or influence of your assumptions, wholly trust your intuition and feelings

• pivot conversations when someone challenges your assumptions or cites reasoning outside your wheelhouse. avoid displaying a lack of knowledge in any domain – this is seen as weakness

• if you must ask questions, imply the correctness of your originally held position by wording your question suggestively

• dig in your heels when confronted with overwhelming dissent

• exploit your immediate network; when the obvious merits of your narrative are exhausted, present like-minded people with tastefully curated details of your interactions with detractors, to provide a more appropriate account that your supporters can rally around to crush any lingering threats to your narrative

• do not research or consider the record, acumen or credentials of those with whom you speak, unless you agree with them

• do not grant grace to those who make mistakes¹, especially those that you have never met or otherwise spoken to

• when all hope is lost in conversation, retreat into your self

• do not seek to understand those you do not already understand

The iPad should be radically (though obviously) touch-only. No keyboards. No pointers. No mice. No trackpads. Just your disgusting fingers flopping over the screen and mooshing into icons. It should not have any window’d modes. Each app should fill the whole screen and only the whole screen.

iPad apps should be weird as hell, unlike anything you find on a desktop operating system. PushPopPress began to illuminate this path fifteen years ago, and then they got slurped up — like so many other promising, young, talented designers and companies around that time — by Facebook, only to disappear into the wake of Mark Zuckerberg’s electric hydrofoil surfboard. Using an iPad should feel like a finger ballet. Your hands should be swooping and swiping and the whole OS should feel like skipping across a taut slackline, a bit bouncy and pleasing and physical but also precise and quick and focused taking you where you need to go, across some creative gulf. There should be no “hard edges” anywhere. iPadOS shouldn’t be anything like Windows or macOS or Linux, it shouldn’t be iOS made big, it should be only like iPadOS — a singular thing of finger-poking joy. When you pick up one of those magic slabs (and truly, the amount of engineering and power in those thin-as-heck slabs is something else) you should feel giddy, like you’re about to enter a whole ’nother computer-ing universe, one that is all about elegant multitouch tactility, worlds apart from your phone or your laptop.

The MacBook Neo is about six years late. Back in 2020, when the iPad Pro’s 4th generation model — the one with trackpad support — was released, there was a group of us who slapped the new Magic Keyboard with trackpad on it and thought, immediately: Give me this machine with macOS. This feeling had been brewing for a while. iPad Pros had been around since 2015, and it was clear they were more capable than our space-heater, butterfly-cursed, hackneyed singular-port MacBooks. Back then, MacBooks were uninspiring. Used with reluctance and a heaviness of heart. Intel’s laptop processors were at best miserly bridge trolls that enacted a fee of heat and fan noise for not much power. Meanwhile, the iPad Pro was fanless, silent, fast, and had a great screen.

But iPads stank from a software perspective. You couldn’t really do anything “Pro” on them, no matter how much Apple tried to bend the definition. It felt like Apple had bolted a Ferrari engine onto a Honda Super Cub. The Cub was useful and cute for basic tasks, but you weren’t going to haul a ton of wood with it to build a beautiful home, even though the engine could theoretically shoot it to the moon. You could feel that latent power thrumming under the glass each time you woke your iPad to watch YouTube or read the news or play Slay the Spire or whatever else entertainment-focused, low-stakes thing most people out there did (and do) with their iPads. It was a machine with an engine desperately wanting to get out, but hamstrung by the OS and applications. Lightroom on iPad was fun for doing edits and development with a Pencil, but you were encumbered by Adobe’s cloud, by the lack of other basic features like making a duplicate of an image (arguably one of the most fundamental features for people making edits on photographs). These kinds of workflow paper cuts are everywhere on the iPad. In terms of power, that original iPad Pro is still pretty much all the iPad you could ever want or need. I’m sure there are a few of you doing more with your iPads than the original Pro could deliver, but I’m not sure there’re many. Almost anything that doesn’t involve the Apple Pencil (Procreate being one of the true killer apps, the app that may have sold more iPads to creative professionals than anything else) could be done better on a MacBook. Even email feels better on a MacBook.

That lament of MacBooks being left tragically behind didn’t last long. While Apple didn’t give us the iPad Pro with macOS, they did give us an M1 MacBook Pro in November 2020, the same year that the iPad Pro with trackpad support came out. The M1 — here it was! And it was as glorious as we had all assumed it would have been. macOS rocking Apple Silicon. Unburdened from Intel purgatory. Did that machine have anything other than USB-C ports? No, but the ports would come, soon. (Glorious ports in 2021.) For many of us, this marked the moment from which the iPads went from collecting a little dust to collecting all the dust, and we gave up on ever trying to get the machine to live up to its “Pro” title. Today, they sit in the corner. iPadOS simply isn’t an environment for most “serious” work.

This sense of iPad “not working” has only grown in the past two years with the explosion of LLMs and tools like Claude Code. macOS is the place to run the things because macOS is malleable and its constituent parts fungible, it’s able to embody the role of tool by trusting the user to be an adult.

You’d think that Apple would have seen the launch of the M1 as a clear moment to maximally delineate between MacBooks and iPad. But no, Apple got weird. Some kind of internal velocity set in motion perhaps years ago by an errant project manager continued to push the company into fuzzy software spaces. For instead of making iPadOS more iPad-focused — a touch-only wonderland of touch-computing joy — they began to make it more like fake macOS. Adding multitasking that didn’t ever work as fluidly as multitasking on macOS, and windowing that was bizarre at best and infuriating at worst. Ever since the release of M Macs (a real oxygen-at-the-top-of-Mount-Everest-moment, I have to say), I suspect most of us haven’t cared what was happening to iPads or iPadOS. Apple was taking it in the wrong direction — that’s all we intuited from afar, or when we went to watch YouTube on them (though watching YouTube was better on desktop in a browser, more keyboard shortcuts, the ability to hide Shorts, etc.). And each time we’d peek — a few times a year or so — our hearts fell a little in dismay to see how far they’d strayed, how utterly uninteresting it all was, how much it was trying to be “macOS lite” but somehow, mostly, worse.

Slowly, then quickly, those of us on macOS felt squeezed in the opposite direction. First, Settings changed in a worse-for-wear way in Ventura (2022). macOS became ever-so-slightly ever-more locked down. Popups became more and more onerous. And with Tahoe, the direction is clear: in a move straight out of a horror film, Apple is trying to merge macOS and iPadOS (or visionOS, if that’s your angle).

Oh, how far the heart falls when considering this misguided strategy, a strategy clearly devised by someone who doesn’t use iPads or MacBooks, who lives only in the realm of theory, ignoring the terrible praxis of melding these two worlds that so desperately do not want to be melded.

I’m typing this on a MacBook Neo. I’ve been using it daily for two weeks. It’s an outstanding little machine. Cheaper than an iPad with a keyboard. Far, far more capable in almost every way. Bursting with potential, this little machine. It’s the machine we all wanted, in a way, back when the iPad Pro was attempting to be a professional tool. A good keyboard, a fine screen, a solid little processor, and most importantly, an operating system that lets you work and work well, and work well with the coming wave of LLM-related tools. This machine has become what I always wished my iPad could be — a compact, light writing machine that stays out of the way, feels fluid and fluent, integrates easily with services like Dropbox, and syncs with my true Pro machine effortlessly. (I’ve lost untold documents attempting to rely on iCloud Drive and syncing between desktop and mobile versions of apps.)

Rumors have it that touch screens are coming to MacBooks, to macOS. I do not wish to touch my MacBook’s screen. One of the great joys of a MacBook is not touching the screen, is keeping the fingers on the keyboard in a ballet of delightful fluency, flitting between apps, opening apps and documents and assorted files, running tools, doing so at the speed of thought, encumbered only by increasingly slower animations or boneheaded notifications or apps stealing focus as they spin themselves up. Keys are fast, touch is slow, and with all the usability issues appearing in macOS, adding touch seems like one more level of complexity the software teams aren’t yet primed to handle.

Tim Cook is on the way out. John Ternus begins this fall. We know by the numbers that Apple sells a lot of iPads. And they sell an OK number of MacBooks. When Cook came in he streamlined supply chains, but over time, the lineup of devices has grown fat and strange. Perhaps Ternus can streamline once again, on both axes of hardware and software.

Here is the insane business plan of what I would do, the thoughts of some fool on a hill halfway across the world:

No more keyboards or mouse support for iPads. Touch only. Nix half the iPad lineup, simplify simplify simplify. Gut iPadOS and rebuild it around touch fluidity and fluency and focus. Work with Procreate to expand their offerings. What is the Procreate equivalent of every creative tool? Look back to the playfulness of PushPopPress. Now, make a 12" MacBook Air. Get rid of the other Airs. For the MacBook lineup, offer a cheap Neo, an ultra-portable high-spec Air, and powerful, portful Pros. And macOS? No touch. Good god, do not succumb to the siren call of touching MacBook screens. Instead, go into a three year period of major OS refactoring. Speed above all. Mythos harden the OS but increase malleability. What does an LLM-first macOS look like? One you can plug into and automate with ease. Make that. (Plot twist: It turns out it’s the same thing as a user-first OS.) Think about keyboard fluency. Bicycle for the mind the hell out of the thing. Make it absolutely clear about how iPads are used and how MacBooks are used. Think about them as true companions, but with no overlap. Maybe Ternus will usher in parts of this.

I just love the idea that the specificity of our tools should be radically clear. The iPad should be a highly-focused touch playground. Weird as hell, one-of-a-kind apps. And MacBooks should be for multitasking, moving information and data around, building evermore powerful tools (tools within tools within tools), all bounded by a keyboard-first universe. Keep the iPad screen covered in the goop of happy fingers and the MacBook keyboards slathered in the smudge of thought. The more separate they are, the more powerful they become.

Apr 24, 2026 21:44:00

https://www.diatec.co.jp/index.html

Diatec was a company that sold keyboards under its own brand, 'FILCO.' The FILCO Majestouch series was characterized by its stable and robust casing and was popular among mechanical keyboard enthusiasts.

The Majestouch Convertible3, released in 2022, is a keyboard that supports both wired and wireless connections, and allows users to choose between Japanese and English layouts, with or without a numeric keypad, and select from brown, blue, red, and silent red key switches.

In 2023, they also released the split-type 'Majestouch Xacro M10SP,' an ambitious product featuring mechanical switches, a split design, and 10 macro keys.

As of the time of writing this article, accessing Diatec's website displays a notice that the company has ceased operations.

Thank you for your continued patronage of Diatec Co., Ltd. and our products.
We apologize for this sudden announcement, but as of April 22, 2026, our company has ceased operations (closed down).

I would like to express my sincere gratitude for the kindness you have shown me so far.

Diatec Co., Ltd.

🚀 DeepSeek-V4 Preview is officially live & open-sourced! Welcome to the era of cost-effective 1M context length.

🔹 DeepSeek-V4-Pro: 1.6T total / 49B active params. Performance rivaling the world's top closed-source models.

🔹 DeepSeek-V4-Flash: 284B total / 13B active params. Your fast, efficient, and economical choice.

Try it now at chat.deepseek.com via Expert Mode / Instant Mode. API is updated & available today!

📄 Tech Report: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf

🤗 Open Weights: https://huggingface.co/collections/deepseek-ai/deepseek-v4

DeepSeek-V4-Pro​

🔹 Enhanced Agentic Capabilities: Open-source SOTA in Agentic Coding benchmarks.
🔹 Rich World Knowledge: Leads all current open models, trailing only Gemini-3.1-Pro.
🔹 World-Class Reasoning: Beats all current open models in Math/STEM/Coding, rivaling top closed-source models.

DeepSeek-V4-Flash​

🔹 Reasoning capabilities closely approach V4-Pro.
🔹 Performs on par with V4-Pro on simple Agent tasks.
🔹 Smaller parameter size, faster response times, and highly cost-effective API pricing.

Structural Innovation & Ultra-High Context Efficiency​

🔹 Novel Attention: Token-wise compression + DSA (DeepSeek Sparse Attention).
🔹 Peak Efficiency: World-leading long context with drastically reduced compute & memory costs.
🔹 1M Standard: 1M context is now the default across all official DeepSeek services.

Dedicated Optimizations for Agent Capabilities​

🔹 DeepSeek-V4 is seamlessly integrated with leading AI agents like Claude Code, OpenClaw & OpenCode.
🔹 Already driving our in-house agentic coding at DeepSeek.

The figure below showcases a sample PDF generated by DeepSeek-V4-Pro.

API is Available Today!​

🔹 Keep base_url, just update model to deepseek-v4-pro or deepseek-v4-flash.
🔹 Supports OpenAI ChatCompletions & Anthropic APIs.
🔹 Both models support 1M context & dual modes (Thinking / Non-Thinking): https://api-docs.deepseek.com/guides/thinking_mode

⚠️ Note: deepseek-chat & deepseek-reasoner will be fully retired and inaccessible after Jul 24th, 2026, 15:59 (UTC Time). (Currently routing to deepseek-v4-flash non-thinking/thinking).

🔹 Amid recent attention, a quick reminder: please rely only on our official accounts for DeepSeek news. Statements from other channels do not reflect our views.
🔹 Thank you for your continued trust. We remain committed to longtermism, advancing steadily toward our ultimate goal of AGI.

Reverse-engineering infrared-based electronic shelf labels

• Why ?
• Brands and technologies
• Infrastructure
• Infrared MAC
• Infrared PHY
• Image format
• Tag electronics
• Transmitter electronics

For concrete code examples check out PrecIR on Github.
For a compatible USB IR interface check out ESL Blaster.

Why they exist

To consumers, Electronic Shelf Label (ESL) manufacturers list a few pretexts for their existence, often phrased as benefits:

• ESLs are ecological: they can be updated and they last for years, it saves paper and ink !
  This is utter bullshit. Prices and products don't change that often, and the necessary ressources to make the electronics, batteries, and plastic enclosures that constitute the tags largely outweigh what they would replace in terms of paper and ink.
• ESLs provide better price accuracy, what you see is what you'll pay !
  Partially true. In practice, most of the time updates are done store-wide at night. Also, the store database is still maintained manually so an important human factor remains.
• The store staff spends less time changing paper labels, allowing them to dedicate more time to the customer !
  I wouldn't be surprised if that was already used as an excuse to cut jobs.
• Some ESLs are NFC enabled. You can tap your phone to get more infos on a product !
  Seriously, of the few who know about this, who uses it ? Important infos such as allergens are mentionned on the product itself.

On the other hand, the selling points given to store chains make much more sense:

• Instant price updates. Hot day ? Raise bottled water by 20% in one click !
• A single person can manage everything. No maintenance outside of replacing the ESLs every 5 to 10 years.
• Some ESLs have LEDs to attract attention. Brands can pay to make their product more visible.
• Staff on the store floor can interrogate ESLs to see stock info. Less empty shelves !
• Get a significant advantage over smaller stores who can't afford the system.
• The whole thing pays for itself in the first few years.

Why mess with them ?

Sometimes you don't need a reason to do things. But if you really need one in this case, here are a few:

Because it's fun. Because you want a cool name tag. Because you may learn something. Because the vast majority of the tags don't have embedded anti-theft devices. Because multi-billion store chains believing in new ways to earn more but not in preserving the environment deserve it.

Mischievous acts proven to be possible:

• Change displayed prices
• Change displayed images
• Lock tags up for hours without any communication possible

Mischievous acts one could dream of:

• Drain tag batteries very quickly
• Change tag address or access keys, making the store unable to use it
• Remotely update a tag's firmware
• Remotely update all in-range tags firmware

Brands and technologies

There are many brands of ESL systems, each with their own proprietary infrastructure and software.
Free and accurate market share information is hard to come by, there's some geographical segmentation (some brands are more common in some countries) but overall there's only a few leaders. This makes it rather easy to identify brands just by memorizing how their ESLs look.

Even if it doesn't seem like a big concern, some systems are said to implement security measures.
It is not known if these are effectively in place, nor what they're supposed to prevent (unauthorized updates ? Price spying ? Both ?).

Bidirectional communication trades battery life against information reliability. ESLs that can answer allow the system to perform retries on failed updates, retrieve battery status, and even do coarse geolocation. Early systems which weren't energy efficient enough couldn't do that.

Brand	Communication technology	Bidirectionnal communication	Security	Characteristics	Most common in	Tags appearence
Pricer	Proprietary high-speed infrared	Yes	No encryption whatsoever, 16-bit key with default value	Dish-like transmitters scattered across store ceiling. Segment and e-paper based tags. Black IR sensor visible on the front.	Europe, US
SES Imagotag	Proprietary 2.4GHz radio Texas Instruments CC2510 chip	Yes	Mentionned in brochures. Chip has hardware AES-128.	Modern ESL system called "Vusion". RGB LED.	Europe, US
Altierre	Proprietary 2.4GHz radio	Unknown	Unknown	Rather old system. Tags use distinctive graphic monochrome LCDs.	Europe, US
Samsung	Zigbee 2.4GHz Radio	Yes	Unknown	-	Asia	TODO
Digi (Teraoka Seiko)	Radio	Yes	Unknown	-	Europe, Asia	TODO
NCR	Proprietary UHF radio	Unknown	Unknown	Very old, one of the first ESL systems. Rarely found nowadays.	US	TODO
Hanshow	Proprietary 2.4GHz radio	Unknown	Unknown	Seems to be used in smaller installations such as convenience stores and pharmacies.	Europe, Asia, US
ZKong	Radio	Unknown	Unknown	-	Asia
DisplayData	Proprietary 920MHz radio	Unknown	Unknown	ID barcode on the left, round edges.	US
SES / Store Electronic Systems	Proprietary LF 38kHz radio	No	None. Nothing. Really.	Radiating cable hung across store ceiling. Very slow updates. Wonky protocol. Phased out since SES bought Imagotag.	Europe
Countless noname systems from Alibaba	Probably generic 2.4GHz radio or BLE	Unknown	Unknown	More chances of being used in independent stores which don't need any uniformity in ESL systems.		-

The following infos will focus on the only infrared system currently in existence, which is believed to occupy at least a 15% market share worldwide.

Infrastructure

The main selling point of the infrared based system is its speed and its immunity to radio interference in the cluttered 2.4GHz band.
Some years ago the two-way communication scheme was also put forward, but today the rest of the industry caught up and the feature became the norm.

Here's a funny quote from a store manager, boasting about the unique infrared technology:

“There is absolutely no way the system can be hacked or suffer interference from any other wireless devices which are powerful and mobile today. It’s the same, secure technology that was developed specifically for heat-seeking missiles fired from fighter jets.”

The infrastructure is made of a management server, one or more base stations (BS), transceivers (TRX), and of course ESLs.

The server is on the store's premises but out of sight of the public. It's hooked up via ethernet to one or more base stations, which are also generally hidden somewhere. These in turn control up to 32 infrared transceivers via RS-485, which are suspended from the store's ceiling and very recognizable.

Even with powerful infrared transmitters and sensitive receivers, optical communication can't rely much on reflections and ends up being mostly line-of-sight.
Because of this, care must be taken during setup to properly place enough TRXes to avoid any dark zones where ESLs couldn't be reached by the system.

Radio systems in the 2.4GHz band suffer to a lesser extent from the same problem.
One notable story one employee told me was about bags of dog food being great RF absorbers.

When individual tags are associated with products by store employees during setup, the data takes a long path from their handheld barcode scanner, to the WiFi acces point, to the store's network, to the ESL server, to the BS, to the TRX, to finally reach the tag.

If first learned about that thanks to an old promotional video. The employee uses a standard handheld Metrologic device to scan product barcodes and tag barcodes in pair, in order for the management server to register the association. The tags infrared replies made visible by the camera are seen transmitted with a significant delay.

Infrared PHY

Data is transmitted from the TRXes to the ESLs by bursts of 940nm infrared light.
The modulation used is Pulse Position Modulation (PPM) with proprietary parameters.
PPM codes the data in the time between pulses. Therefore, for a given number of symbols n, there's always n+1 bursts.

The bursts are fixed periods of the high frequency "carrier", which is always a 1.25MHz square signal. ESLs have a narrow passband filter which makes them blind to any signal outside approx. +/-10kHz of this frequency.
Carrier is put in quotes here because the bursts don't actually carry the data, unlike the bursts in many standard IR remote protocols do.

Because the data is encoded with time, the total transmission time obviously depends on the actual data.

It may be possible to hack around limitations of IrDA transceivers to form valid pulses, but I'm not aware of any semi-intelligent part capable of producing the required carrier frequency. Phone infrared transmitters that I've tested are limited to hundreds of kHz.

There are two known symbol sets used: a legacy, slower one, and a more recent faster one certainly created to support the higher data rates needed to update graphic ESLs in a reasonable time.

Data is always sent in bytes from first to last.

PP4

As the name implies, this set uses 4 symbols.
Each span between bursts therefore represents 2 bits.

Segment-based ESLs run off a 32768Hz crystal. To allow simple decoding and to keep power consumption low, the timing of PP4 symbols is based on that period, t = 30.52us.

Symbol durations are ordered in a way to form a 2-bit Gray code.

• Symbol 00: 2t = 61.04us
• Symbol 01: 4t = 122.07us
• Symbol 11: 6t = 183.11us
• Symbol 10: 8t = 244.14us

Bursts last a bit more than a period. 1.3t = 40us works well (50 periods of 1.25MHz).

The least significant bit pair of each byte is transmitted first.
E.g.: 0x84 (binary 1000 0100) is sent as 00, 01, 00, 10.

Public documentation mentions that PP4 can achieve bitrates of 10kbps.

Transmitting only 00's: (61.04us + 40us) / 2 = 50.5us per bit = 19.3kbps.
Transmitting only 10's: (244.14us + 40us) / 2 = 142.1us per bit = 6.9kbps.
Average: 13.1kbps.

PP16

Same idea but with 16 symbols instead of 4, encoding 4 bits per symbol.
Thanks to higher frequency crystal or the use of PLLs in graphic ESLs, the base period was also made shorter to further increase speed.
Symbol order seems random. Base period is t = 4us (-1 for each symbol ?).
The burst lasts 21us.

• Symbol 0000: 27us
• Symbol 0001: 51us
• Symbol 0010: 35us
• Symbol 0011: 43us
• Symbol 0100: 147us
• Symbol 0101: 123us
• Symbol 0110: 139us
• Symbol 0111: 131us
• Symbol 1000: 83us
• Symbol 1001: 59us
• Symbol 1010: 75us
• Symbol 1011: 67us
• Symbol 1100: 91us
• Symbol 1101: 115us
• Symbol 1110: 99us
• Symbol 1111: 107us

A special 4-byte header must precede frames transmitted in PP16: hex 00 00 00 40.

Public documentation mentions that PP16 can achieve bitrates of 38kbps.

Transmitting only 0000's: (27us + 21us) / 4 = 12us per bit = 81.4kbps.
Transmitting only 0100's: (147us + 21us) / 4 = 42us per bit = 23.3kbps.
Average: 52.35kbps.

Infrared MAC

Data is packed in frames including a header, an address, a command, one or more parameters, and a CRC.

Each tag has a unique 32-bit low level address called "PLID" (probably for Price Label ID).
Most commands require it, a few allow the use of the broadcast value of 0.

The PLID is pre-programmed in each tag and can't be modified*.

The store infrastructure is made aware of the presence of a given ESL by entering its unique ID barcode in a database.
This barcode is found on a sticker on the backside of the tag, or lasered on the front next to the display.

It is unknown if there's a broadcast command to ask a tag to return its ID barcode data, in case the barcode can't be read.

The barcode uses Code128 symbology, and is made of 17 alphanumeric characters.

Several criteria must be met for the data to be valid:

• The second character must be a '4'
• Manufacturing unit must be under 64
• Manufacturing week must be under 54
• The serial number must be under 65535 (must fit in 16 bits)
• The checksum is the sum of the ASCII values of the previous 16 characters, modulo 10 (the last digit).

For example, G4591371776312423 decodes to:
Tag made by unit 59 in the 37th week of 2001, serial number 17763, tag model code (1)1242, checksum 3 (valid).

The tag's PLID is derived from the ID barcode data. It's divided in two 16-bit words.
The upper one corresponds to the MMYWW fields, the lower one to the SSSSS field.
The example above shows 59137 and 17763, giving a PLID of hex 0xE7014563.

From now on, byte values will be given in hex.

The basic structure of a frame is:

[VER] [PLID] [COMMAND] [PARAMETERS] [KEY] [CRC]

• VER is a byte indicating the protocol version code. Segment ESLs understand code 0x84, graphic ESLs 0x85.
  
• PLID: The 32-bit PLID described above, least significant byte first. The above example would give 63 45 01 E7.
• COMMAND: A 7-bit command code and an acknowledge request flag. The ack flag is bit 7.
• PARAMETERS: One or several parameters, depending on the command.
• KEY: The 16-bit store key, which has very high chances of being 0.
• CRC: A 16-bit CRC computed over all the previous bytes starting from the protocol version code.
  Both the initial value and the polynomial are 0x8408.

Frames with invalid lengths or CRCs are ignored.

Segment page change command

84 [PLID] AB xx [KEY] [CRC16]

Protocol code 4, ack request enabled. 0x80 + 0x04 = 0x84.
The page change command is broadcast, so the PLID is set to 0.
AB is the change page command.
The xx parameter byte is formed as follows:

SPPPPTTT

S: If set, makes the page become the default one.
P: Page number, 0 to 15. Pages 0 to 7 can be customized. Pages 8 and above are used to report ESL internal infos.
T: Duration of display.If S is set, this is ignored. Durations are 4s, 8s, 30s, 480s (8min), 1800s (30min), 3600s (1 hour), 5400s (1h30).

Example: 84 00 00 00 00 AB 11 00 00 A5 E4
Asks tags to show their page 2 during 4 seconds.

Graphic ESL ping / wake up command

85 [PLID] 17 01 [KEY] [PAYLOAD] [CRC16]

ESL spend most of their time asleep, only checking periodically if they're receiving infrared data.
It may be necessary to send wake up frames in loop for up to 4 seconds in order to get the ESL's full attention.

The purpose of the parameter byte is unknown.

It seems that the payload of this type of frame can be anything as long as it's 23 bytes long and starts with a 0 byte.

Segment update command

84 [PLID] 3A xx [KEY] [DATA] [CRC] 00 00 09 00 yy 00 00 [CRC16]

This is an addressed command. Broadcast doesn't work (unfortunately).

The segment data [DATA] is 23 bytes long, meaning that a maximum of 23 * 8 bits = 184 segments can be controlled.
The mapping of bits to segments varies depending on the ESL's model, which is kind of a pain in the ass. A set bit turns the segment on.

xx: Page number to udpate (0 to 7 << 3)
CRC: CRC16 of the [DATA] only (might be ignored ?)
00 00 09 00: Unknown (can be all 0 ?)
yy: Flash page number << 4

Segment blink update command

84 [PLID] 3A xx [KEY] [DATA] [CRC] cc cc 00 00 yz 00 00 [CRC16]

This is an addressed command.
A subcommand of the "segment update" command used to set a mask to define which segments must blink.

As above, the segment data [DATA] is 23 bytes long.
xx: Page number to udpate (0 to 7 << 3) OR 80
CRC: CRC16 of the [DATA] only (might be ignored ?)
y: Blink on time (4 bits. 0 is fast, F is slow)
z: Blink off time (same as above)

Image update command

Updating a graphic ESL's display requires many frames transmitted in a precise order, it's quite an involved process.
If any of the frames is invalid or not received properly, or if the image doesn't fit on the display, the update will fail.

The ESL must first be waken up with the above wake up frame transmitted for a few seconds.

First is a parameter frame describing the image and the format of the data to come next:

85 [PLID] 34 00 00 00 05 [LENGTH] 00 [TYPE] [PAGE] [WIDTH] [HEIGHT] [XPOS] [YPOS] [KEY] 88 00 00 00 00 00 00 [CRC16]

LENGTH: Word. Length of the image data in bytes
TYPE: Byte. Image data compression type. 0 is no compression, 2 is bitwise RLE (see below).
WIDTH, HEIGHT: Words. Size of the image in pixels.
XPOS, YPOS: Words. Position of the image in pixels from the top left corner of the display.

One or more data frames follow:

85 [PLID] 34 00 00 00 20 [INDEX] [DATA] [CRC16]

INDEX: The data frame's index. Starts from 0 and increments every frame.
DATA: Image data. Maximum 20 bytes per frame. Format depends on the TYPE parameter above. See below for encoding.

After the last data frame, a final update frame is sent:

85 [PLID] 34 00 00 00 01 [PAYLOAD] [CRC16]

PAYLOAD: 22 zero bytes. Value may not matter.

After this last frame, the ESL may take a few seconds to react and update its display. I have a few tired ones that take up to 10 seconds.

Image format

There are two known image formats: raw and RLE compressed.

Black and white ESLs use a single block of binary data. 0 means black, 1 means white.
Black, white and red ESLs use two blocks of data. The first one represents black and white pixels, the second forms a mask with 0 meaning red.
Newer 4-color ESLs may use two blocks as real bitplanes, but this is not confirmed.

Image encoding is always done from the top left corner to the bottom right

The raw format is type 0. Each pixel is encoded in a bit. If necessary, padding is done with zeroes.

The RLE format is type 2. Instead of dedicating one bit for each pixel, the length of continuous runs of identical pixels are encoded.
To further reduce the data size, the length of the counts is variable and unary coded.

The first bit of an RLE bitstream represents the very first pixel's color.
Then follows a list of lengths coded as such:

[n-1 * 0 bits] [length coded in n bits]

For example, if the image starts with 13 white pixels, then 59 black pixels, the bitstream would be:

1 000 1101 00000 111011

• 1: First pixel is white
• 000: Next length value will be 4 bits long
• 1100: 12 white pixels
• 00000: Next length value will be 6 bits long
• 111011: 59 black pixels
• And so on...

It's enterily possible that an image compressed with this scheme will end up larger than if it wasn't compressed.
This will often happen with heavily dithered images, because of the many changes in pixel colors causing lots of length coding overhead.

Tag electronics

TODO: Translate

Il existe deux types principaux:

• Les ESL à segments. Économes en énergie, moins chères, mais seulement capables d'afficher quelques caractères.
• Les ESL graphiques. Basées sur des écrans e-paper, bien plus chères, mais permettent d'afficher tout et n'importe quoi.

Ces deux types partagent une base commune: un ASIC mixed-signal (analogique et numérique) propriétaire qui s'occupe de la communication infrarouge au plus bas niveau, et qui abrite également un microcontroleur et de la RAM.

Grâce à Deus Ex Silicium, il a été possible d'observer de près cet ASIC. Il a d'ailleurs publié une vidéo à ce sujet:

Il m'a également fourni plusieurs photos du die, qui ont pu être fusionnées pour produire une photo plus grande.

La finesse de gravure et la complexité du microcontroleur, même sur un circuit conçu pour être le moins cher possible, ne permet pas de discerner individuellement les transistors. Cependant on peut très bien voir les différents blocs:

Il y a deux zones de RAM distinctes, la plus petite sert de RAM de travail pour le MCU. Si on se réfère aux lignes et aux colonnes, celle-ci ne ferait que 32 ou 64 octets. L'architecture du microcontroleur est inconnue. Vu la surface utilisee, je suspecte du 8 bits plutot que du 4.

La logique pour le pilotage des sorties LCD semble être mélangée avec celle du MCU, il n'y a pas de bloc distinct à part les 4 rails d'alimentation qui suivent le bord.

Le bloc PM (Power Management) / Analogique contient de nombreux condensateurs, qui apparaissent comme de gros rectangles de couleur unie. Ce bloc s'occupe de la génération des tensions pour le LCD ainsi que l'amplification et le filtrage du signal provenant de la photodiode.

Le point remarquable est qu'il n'y a pas l'ombre d'un bloc de mémoire flash. Je vois trois raisons possibles à cela:

• Il faut relativement beaucoup de courant pour effacer et programmer de la flash
• Il faut un process special pour avoir de la flash sur un die, qui dit process special dit plus cher
• Le fait que la RAM soit volatile est peut être un avantage financier

Comme il n'y a pas d'autre bloc de mémoire, le firmware est forcément dans le gros bloc de RAM.
Si l'ESL perd son alimentation, non seulement les données affichées s'envolent mais le firmware aussi.
En clair, quand les piles sont mortes ou retirées pendant trop longtemps, il n'y a aucun moyen de ressusciter l'ESL.

Le chargement initial du firmware se fait certainement en usine via des contacts qui se trouvent au dos de la carte. Ils sont ensuite masques par une etiquette mais ils toujours accessibles à travers le boitier si on la retire (voir plus bas).

Restriction pour contrôler le recyclage et garder la main sur les étiquettes ? Simple dommage collatéral lié à l'utilisation de RAM pour faire des économies de quantité ? A vous d'en juger.

Basés à Hong Kong, Solomon-Systech sont relativement connus pour leurs très courants controleurs LCD (SSDxxxx). Ils proposent un service de design d'ASIC et ont leur propre ligne de microcontroleurs (dont ils ne parlent plus sur leur site aujourd'hui).

Les premieres etiquettes graphique de la marque couplaient un ASIC avec un MCU ATMega168 et une EEPROM série pour stocker les images des différentes pages. Cet ASIC joue simplement le role de recepteur/emetteur IR puis passe les donnees au MCU externe qui fait le gros du travail.

J'ai aussi ouvert l'ASIC d'une des étiquettes graphiques (avec des degats). La zone en damier semble être une couche de distribution d'alimentation ou d'égalisation de surface au dessus de la logique. Une partie des blocs analogiques est toujours visible.

En comparant avec le die de l'ESL à segments, on peut remarquer de nettes ressemblances.

On peut aussi voir le gros transistor pour la LED infrarouge.

Derrière un autocollant se trouvent deux petits trous dans la coque de l'ESL donnant sur des pastilles du PCB. L'une va au plan de masse, l'autre à l'ASIC. Des impacts de pointes sont visibles, indiquant que ce sont soit des points tests pour vérifier que l'ESL est vivante en sortie d'usine, soit une interface série pour charger le firmware et leur code unique.

Le fait que des trous aient été prévus dans la coque laisse penser que le chargement du firmware peut se faire à nouveau.

Note: C'est pas du 1-wire, c'est vérifié. Ca aurait été surprenant: il aurait fallu qu'ils paient pour utiliser la technologie. C'est probablement un protocole unidirectionnel très simple, pour éviter d'utiliser trop de surface dans l'ASIC. J'imagine bien un gros registre à décalage. Je ne crois pas en l'existence d'un bootloader puisqu'il s'effacerait avec le firmware.

Balancer une horloge sur un contact et du bruit binaire sur l'autre brique l'ESL !

Le quartz est taillé pour 32768Hz, et sert dès la mise sous tension de l'étiquette (>2.2V).
A droite on trouve la photodiode D1 wire-bondée directement sur la carte, la LED infrarouge de réponse D2 au dessus, ainsi que son condensateur réservoir C4.
Une charge pump intégrée dans l'ASIC génère du 6V sur TP9, probablement pour l'afficheur.
Un procédé nomme "precharge" géré par l'infrastructure permet a l'étiquette de recharger C4 entre plusieurs réponses (allant jusqu'a 2 secondes) afin d'obtenir une réponse puissante malgré le peu de courant disponible instantanément avec les piles CR2032.
TP13: Tension piles (3V).
TP18: Masse.
A noter: 3 fins de pistes sans vernis sont visibles à gauche de R2, possiblement une interface de programmation ou de debug propriétaire.

Todo...

Toujours les trous pour la programmation en usine (étiquette retirée). Fixme: le trou à gauche est utilisé.

Tiroir contenant les deux piles CR2032. Il est soudé !

Surprise à l'ouverture: un autocollant sans contact collé derrière l'écran. C'est clairement du NFC, pas un bête antivol 8.2MHz.
Le fait qu'il n'y ait pas de connection electrique entre l'autocollant et la carte indique qu'il n'est pas possible de mettre à jour son contenu par infrarouge.

TP12_B: Prog ?
TP21_B: VBatt
TP18_B: GND

More recents tags have a single QFN asic - TODO: Picture.

Transmitter electronics

TODO: Add more details, translate.

Uses a Hitachi H8/3687 MCU to decode RS-485 messages and a Lattice 4064V CPLD to generate the IR signal with precise timings.
A fast enough microcontroller and careful programming would work but they might have chosen a CPLD to future proof eventual protocol updates.
It is unknown if the CPLD can be reprogrammed by the MCU.

Given the very low amount of logic blocks in the CPLD, it probably just acts as a dual presettable timer to generate the IR symbols from burst and pause durations provided via a parallel bus by the MCU. It should also form a prescaler to do 10MHz / 8 = 1.25MHz.

Patent: WO0209322

These can be daisy-chained up to a certain number. RJ45 connectors but not Ethernet. Unsure why they didn't use PoE.
RS-485 and 48V power supply. MCU runs at 20MHz and feeds the CPLD with 10MHz.

The uplink circuit is interesting. It has to be extremely sensitive to detect the short and potentially weak IR blinks from the ESLs.
They actually used components made for FM radio !

SA636 FM IF chip. An AD9833 is used to generate the LO at ?? MHz. A 455kHz discriminator is used.
La porteuse de reponse est a 1.245MHz. Decalage de seulement 5kHz du 1.25MHz du downlink ?

Filtre ceramique, logo Murata marquage XH:

On trouve une connexion UART 38400bps sur l'µC, qui semble etre unidirectionelle:

***** TRX INIT *****
Firmware:
Compile date: Feb  4 2007
Compile time: 20:39:15
PON Counter:0001
TCSRWD:AA
WOKE UP FROM POWER ON
WATCHDOG INITIATION STARTED!
WATCHDOG INITIATION COMPLETED!
irrxSetup:
 Intg. Time:02E1
 Noise Time:02C2
 PreFB Time:0DD8
 RIM Time  :1F95
CABLE: TxError
CABLE: RxError
CABLE: 48V Error
FELIF: Closed (HW error)
Hello: 0000632F
Hello: 0000C651
Hello: 00012BCD

L'µC detecte la presence du 48V avec un pont diviseur directement sur l'alimentation (avant la diode): 100k et 4.7k, donnant 2.15V sur une broche ADC (ref interne + comparateur certainement). En ajoutant 100k en parallele sur la resistance de 100k deja presente (=50k), et en alimentant en 30V seulement, l'erreur disparait.

TxError et RxError semblent etre liees a une mesure electrique, et pas un echange de donnees (rien sur la liaison RS485 au demarrage).
FELIF closed ? J'espere que c'est lie a l'absence de 48V...

There's LED chain fault detection.

Breaking up has always been difficult for me.  I tend to fall in love with being in love, and continue a relationship well past the point of futility.  And so it is with my oldest love, writing desktop software.

I’m sorry, desktop apps.  We just don’t have a future together anymore.  Its not you, its me.

A bit of background: for the last three years I’ve sold Bingo Card Creator, a desktop app which pretty much does what it says on the tin.  It has gone from being a passing fancy to a rather lucrative hobby to, well, a bit more than that over the years.  As I gradually became more invested in the business of writing desktop software, I got more and more snippy about the periodic desktop versus webapp flamewars, and defended the ascendancy of desktop software.

What Changed My Mind

Over roughly the same period my day job has changed and transitioned me from writing thick clients in Swing to big freaking enterprise web apps.  I’ve learned SQL, Rails, etc and used them to fairly decent effect in selling Bingo Card Creator, which is a Swing app (if all you have is a hammer…).  This summer, I decided to try stepping my web programming skills up a notch, and released a web version of Bingo Card Creator.  It has exceeded all my expectations: in ease of writing, in features, in sales, in support burden, in marketability, etc.  In game theory terms, it strictly dominates the desktop version, when seen from the eyes of the developer at any rate.

If I were starting out today, I would, without a shadow of a doubt, write a web app instead of a desktop app, for these reasons:

I have never used the word “shareware” to describe Bingo Card Creator, because I think that it is an anacronism that my customers do not understand, but among fellow technically inclined people it describes the business model succinctly.  Someone visits your website, downloads your trial, and hopefully purchases your program.  That process is called a funnel, and if you break it down into concrete steps, the shareware funnel is long and arduous for the consumer:

1. Start your web session on Google, like everyone does these days.
2. Google your pain point.
3. Click on the search result to the shareware site.
4. Read a little, realize they have software that solves your problem.
5. Mentally evaluate whether the software works on your system.
6. Click on the download button.
7. Wait while it downloads.
8. Close your browser.
9. Try to find the file on your hard disk.
10. Execute the installer.
11. Click through six screens that no one in the history of man has ever read.
12. Execute the program.
13. Get dumped at the main screen.
14. Play around, fall in love.
15. Potentially weeks pass.
16. Find your way back to the shareware site.  Check out price.
17. Type in your credit card details.  Hit Checkout.

I could go into more detail if I wanted, but that is seventeen different opportunities for the shareware developer to fail.  If you don’t catch the download in the 30 seconds people give your website, no sale.  If your customer can’t find the file after they download it, no sale.  If it requires a JRE upgrade and after restarting their computer they’ve forgotten what they were working on, no sale.  If they play around with it, close it, and can’t remember how to open it again, no sale.  If they get to the sales page and can’t operate your shopping cart, no sale.

Is it any wonder why shareware has typical conversion ratios of 1% or less?

Web Applications Convert Better

A web application doesn’t have to be downloaded or installed, never requires a restart, and never requires a contextual change just to open up a purchasing page.  As a result, the conversion ratio is higher.  Much higher.  Here are the actual stats from Bingo Card Creator.  I’m looking at conversions from my best performing AdWords campaign only, because that minimizes sources of variation like, e.g., the different types of traffic I’ve gotten in the last 2 months (while the webapp was available) versus in the last three years.

Visitor to Free Trial:

• Downloaded: 18 ~ 22%
• Web App: 22% ~ 26%

Trial to Purchase:

• Downloaded: 1.35%
• Web App: 2.32%

This is essentially the same application.  If anything, the online version has less features, and it has 2 months of development whereas the downloadable application has had 3 years of improvements made to it.  Yet the online version outsells my desktop application almost two to one.

Your AdWords Strategy Is Very Sensitive To Conversion Rates

A portion the numerical disparity is because I have started to react to, e.g., the difference in conversion rates of advertising and promote accordingly.  A sale of either nets me the same amount of money, about $28.  However, if you break out the math on how much AdWords costs per sale (cost per click divided by conversion rate to trial divided by conversion rate to purchase):

• Downloadable version: $20 AdWords CPA
• Web App: $9 AdWords CPA

(You’re welcome, Google.)

This doesn’t just save me money, it helps me trounce my competitors.  For example, if my competitors are selling downloadable software, and they are equally as skilled as I am about writing AdWords ads and optimizing their websites, then it should also cost them about $20 a sale to advertise on AdWords.  (This explains why I never see ads for the competitors who try to gain volume by undercutting my price — if you’re going to price at $23.95, you’d better be a crackerjack SEO because you simply cannot afford to outbid me in AdWords.)

Decreasing my cost of customer acquisition by over half lets me bid more for my AdWords to gain additional volume.  For example, for the longest time my AdWords strategy was more or less monetizing traffic other people couldn’t be bothered with, while larger brands producing e.g. printed bingo supplies went after the head terms like [bingo cards].  With vastly improved conversion rates, I might be able to advertise profitably on those terms, increasing my volume and making me very, very happy.  As it is, I have walked up bids a bit and am getting 25% more inventory than I usually do.

Web Applications Are Easier To Support

Many desktop developers hate customer support with a burning passion in their soul.  I actually enjoy it, but I enjoy making it unnecessary even more, as there is no customer support experience so good as avoiding the problem in the first place.

Support requests from last 50 customers:

• Desktop Application: 15
• Web Application: 3

I’ve had three years to streamline the website, purchasing process, and application for my desktop app, and that has helped me greatly reduce the number of inquiries I get.  Even after all that work, the main culprits are pretty much the same as ever: installation issues, lost registration keys, and bugs present in old versions of the software that are still floating around download sites.

Web apps, by comparison:

• Have no installation issues, because there is no installation.
• Do not require registration keys.  (Technically, because I allow users to use both the desktop and web application, I issue them one — but it is immediately applied to their account via creative abuse of e-junkie and cookies.  Most customers get to use their software immediately without actually reading the bit in the email sent to them — or failing to read it, as happens quite often.)
• Never have an accessible version of the software older than the most recent one.  By comparison, if you were to Google [bingo card creator version 1.04] (which hasn’t been distributed in, hmm, two years or so), you’d find it on hundreds of download sites.

The Age Of The Pirates Is Coming An End, Jack

I’m famously lackadaisical about software piracy, preferring to concentrate on satisfying paying customers rather than harming their experience with anti-piracy methods.  However, the existence of pirates is a stitch in my craw, particularly when any schoolmarm typing the name of my software into Google is prompted to try stealing it instead:

You want to take a quick stab at how many pirates have circumvented the copy protection on the online version?  Bwa.  Hah.  Hah.

I once remarked to Paul Graham that the future of software was with pervasive integration with the server simply because that means that downloading the client doesn’t let you pirate the software any more than downloading Firefox lets you pirate Basecamp.  (Ironically, I made that point in a defense of desktop software as a business model.  Mea maxima culpa!  Theoretical utility of desktop software is one thing, but I can’t ignore what my numbers are telling me.)

Phone Home vs. Google Analytics

One of the curious traits among software developers is that, speaking as a group, we feel something like “I own what happens on my machine and nothing should happen without my say-so”.  This generally leads to a severe reluctance to “phone home” from the application to the developer’s server — even reports on very innocuous data like “Did I steal this software or not?” is often tarred with the label spyware.

On the Internet, privacy expectations have evolved a bit in the last few years.  The overwhelming majority of the public has been told that they’re being tracked via cookies and could not care less.  If you write a privacy policy, they won’t even bother reading it.  Which means that you can disclose in your privacy policy that you track non-personally identifying information, which is very valuable as a software developer.

• What features of your software are being used?
• What features of your software are being ignored?
• What features are used by people who go on to pay?
• What combination of settings is most common?
• What separates the power users from the one-try-and-quit users?

Tracking all of these is very possible with modern analytics software like, e.g., Mixpanel.  You can even wrestle the information out of Google Analytics if you’re prepared to do some extra work.  You can do it in a way which respects your users’ privacy while still maximizing your ability to give them what they want.

Some people may be under the impression that users will tell you what they want.  Nope — most of them will assume you are like every other business they have ever dealt with, where their opinion doesn’t matter, and the software is offered take-it-or-leave-it.  And they just left it!

Things I learned about Bingo Card Creator customers which I never knew before I had an online app:

• The most common word used in bingo cards is — ready for it — “baby”.  I completely underestimated the demand for Baby Shower bingo cards, and avoided making an official set for years.  As soon as I had the top ten word list (which was all baby shower words) I fixed that.
• The more features I add to the software, the worse it sells.  (This is, needless to say, highly unintuitive to most software developers.)
• Most customers purchase within two hours of signup, so it is absolutely imperative that their first use of the software exceed all their expectations.

Web Apps Can Be Customized Per User

Downloadable software pretty much has to treat every user identically by default.  There are very limited ways to segment users, and no way to report the results of experiments.  For web apps, however, if you have a halfway decent A/B testing library (like, say, the free one I wrote for Rails developers), you can experiment with having multiple versions of the application available concurrently, and see which one performs best.

The data collected by A/B testing has helped me:

• simplify my options screens to avoid confusing users
• improve the first-run experience
• write instructions such that they’re easier to follow

In addition to changing program behavior randomly, you can segment your users.  I have only scratched the surface of how powerful this is, and it is already producing solid results for me:

Don’t treat your newbies like you treat your power-users. You have a database.  It records all their actions since the dawn of time.  Use it.  I have a couple very simple heuristics for “is probably still getting used to the software” and, if you are, the software treats you with kid gloves.  For example, it hides complex, seldom used options by default.  It gives you instructions to a degree that a power-user might find insulting.  (I don’t have the artistic skills to draw a little animated paperclip but I would if I could!  It looks like you’re trying to make a bingo card.  Need help?)

Give your customers a “credit” score.  I have a particular heuristic which segments users into four buckets.  It isn’t exactly FICO, but it does successfully predict conversion rates: they range from 10% in bucket A to 0.01% in bucket D.  Bucket C is interesting, though — they convert some of the time, but don’t seem to be getting quite the value out of Bingo Card Creator that Bucket A does.

I wonder if Bucket C would feel differently if they got a $5 coupon in the email.

Meanwhile, it looks like Bucket D isn’t very interested in paying me money under any circumstances, but if I had a scratch-my-back-to-get-it-free option, I could place it prominently on their dashboards.

Long Cycles Mean Low Innovation.  Short Cycles Mean Fast Innovation.

This sort of thing is very difficult to do with desktop apps, because you can’t reliably collect data on what approaches work, and you have the build/test/deploy/distribute cycle to worry about.  It takes months for a new version of the desktop application to hit more than half of my users, and I give out upgrades for free.

By comparison, I can literally have an A/B test coded, tested, and deployed globally in under a minute, for ones which are fairly low impact.  Relocating a button, for example, requires two lines of code, a SVN commit, and a quick server restart.  I start getting data immediately.  By comparison, doing that on my desktop app would require 15 minutes of building, then waiting weeks while the new trials percolated from my website to the various download sites, and probably unforseen issues on Mac OS X 10.4 because apparently in a past life I must have stepped on Pharaoh Jobs’ cat.

Recently, a desktop developer’s mailing list that I’m on commented that a release weekly development cycle is unsustainable, bordering on suicide.  As a desktop developer, I agree, it would break me.  As a web application developer — I have released 67 updates to Bingo Card Creator in the past 7 weeks, and this isn’t even my day job.  A button here, some textual edits there, seven A/B tests, etc etc, and pretty soon you’re looking at the magic of compounding 1% improvements.

Speaking of Magic

I love desktop applications.  I prefer them to web apps almost any chance I get. You can keep your Google Docs, Excel is superior in almost every way.

As a developer, I love getting permanent presence right in front of the user (on their desktop, naturally).

My customers love desktop applications.  They love the “physicality”.  They love the perceived security (the number of people who purchased backup CDs and then proceeded to only use the webapp is downright distressing to me).  They love that the application has first-class OS support, feels native, copies and pastes right, works with double clicking files, etc etc.

But at the end of the day, I’m an engineer.  I follow the numbers where they lead me.  The numbers say that sales in this August were 60% over those of last August, despite a major blowup with Google that should have cost me dearly.  All of my attempts to distill wisdom from the statistics have lead to one conclusion: the cumulative advantages of the web application, in my advertising, in my on-site experience, within the application, within my development process, and within my purchase funnel are just stupendously superior to the desktop app.

I’m sorry, desktop apps.  We had good times together, but we’re through.

[Edit to add: I’m going to continue supporting all customers of Bingo Card Creator, regardless of how they choose to get it. The next major release will almost certainly be its last. The webapp, and my future webapps, seem to be much better investments.]

Long-lived keys are liabilities that, broadly, compound over time:

• As people leave the company, the risk of someone outside of your organization having potential knowledge of the key grows.
• If you assume that someone is constantly trying to guess a key or password, the likelihood that they guess correctly grows over time.
• Cryptographic keys have usage limits before their security guarantees start to degrade¹.

You can manage this risk in two ways. The first is to reduce the scope of what a given key can do. This is ideal but not always possible: a key may just need to be inherently powerful in order to do its job. The more general risk reduction is rotating keys. Key rotation is, also, an incredible pain. I suspect many readers have had an experience like:

• A rotation that needed to be expedited because the key was leaked.
• A key that was generated years ago by an ex-employee with inaccurate (or no) documentation on how the key was generated.
• An outage during rotation because the rollout was rushed or because the documentation was too stale to follow.
• An outage that had significant blast radius because a botched key rotation doesn't gracefully degrade.

Systems built around ephemeral keys (i.e., keys that are valid for roughly 1 day or less) sidestep a lot of this pain as "rotation" is a built-in feature. Replacing long-lived keys with ephemeral keys is, for my money, one of the best uses of security engineering effort. Some specific examples:

• Long-lived production SSH keys may be copied around, hardcoded into configuration files, and potentially forgotten about until there is an incident. If you replace long-lived SSH keys with a pattern like EC2 instance connect, SSH keys become temporary credentials that require a recent authentication and authorization check.

• Instead of relying on a static PyPI token that somehow ended up in the CTO's personal 1Password and, less accidentally, re-used across several release pipelines of varying quality, you can use trusted publishers. This allows you to use specific GitHub Actions workflows (which you might already be using for releases) to generate temporary credentials for package releases. When you go to revoke that static PyPI token, you may even find that it made its way into some one-off release pipeline that you forgot about until you broke it just now.

• A big reason why SSO is useful is that you can replace a user-selected long-lived password at each application with a short-lived authentication assertion from a trusted identity provider (IdP). An attacker can guess a poorly selected password. They can't really guess a signed XML document in the same way.²

Okay but you may still need a long-lived key

Your inner security nerd might be annoyed. Surely it's not plausible to get rid of all long-lived keys? That SSO example above is glossing over the fact that while each authentication assertion is ephemeral, the key that signed the assertion is not.

This is true. You may not be able to eliminate every single long-lived key. However, there is still significant upside in reducing long-lived keys.

First, reducing the number of long-lived keys means you can concentrate your security efforts. It is much harder to reason about, say, the security of an arbitrary Engineer's laptop than it is an EC2 instance that exists exclusively to tell KMS to sign something. By reducing the number of long-lived keys, you also tend to create smaller and more focused pieces of infrastructure that are easier to harden and reason about.

Another upside is that security-sensitive infrastructure tends to require more rigor than most tools. Being rigorous often means taking things a bit slow. You don't always need rigor. You also want to be deliberate about where you sacrifice speed. The cryptographic key limits I mentioned before? You don't want that to be a tertiary concern for an arbitrary engineering team, eating up time spent on feature work. It is more likely to be forgotten, de-prioritized, or done incorrectly. You can, instead, make it part of someone's (or some group's) core focus and solve this once for everyone else.

Proper maintenance of long-term keys takes work. My general advice for long-lived keys is something like:

• Limit the scope of what a given key or credential can do. You might, for example, want to scope a data encryption key to a specific shard of customer data.

• Reason through the limits of the maximum lifetime of a given key. The typical security model for cryptographic keys is something like "It would take a supercomputer billions of years to guess the key." You want your limits to have similarly strong and confident assertions.

• Aim to rotate long-lived keys at least quarterly. From an operational perspective, rotating a key is like exercising a muscle. If you do it regularly you'll likely have more accurate and useful tooling or documentation. Good tooling and docs means you are less likely to pull a muscle miss an SLA.

This setup is, admittedly, toilsome. Don't distribute that toil to everyone. You can concentrate that effort into a group that is incentivized to be rigorous and solve it once, for everyone. Reducing toil and consolidating rigor is a major advantage of robust security infrastructure.