I wanted an e-ink monitor. There is no such thing.
The tool I built instead of buying a MacBook ended by telling me to upgrade *on my next machine*. The thing hurting me was a disk at 95%, not the processor. So I closed the tab and bought nothing.
A few days later I spent $443 on an e-ink tablet from Pine64 that arrived not working.
This is the other half of the same month, and it is not a contradiction. The audit answered the question I asked it. It has no opinion at all about the question I was actually carrying around.
The device I wanted does not exist
It started as *I want to play with an e-ink display*. The motive was eyes — no blue light, reflective, the calm of paper. The obvious shape was an external monitor: keep working on the Mac, put the text on e-ink.
That shape is impossible twice over.
macOS has no concept of a wireless external display, so the tablet would have to be wired. And the tablet's USB-C is not a video input — you cannot point a computer at it, because nothing on the other end is listening for pixels. The only way to "use it as a screen" is to run a minimal system on it that boots straight into a full-screen SSH session.
Which is not a monitor. That is a **standalone terminal** that happens to be showing you another machine.
So the want collapsed into something buyable: a self-contained e-ink terminal I SSH out from, driven by the tri-mode Bluetooth keyboard I already own. It took a while to get there, and the reframing did more work than any of the comparisons that followed.
Five candidates, five different kinds of no
The useful part of the shortlist is not the winner. It is that each option failed for a **different class** of reason.
**Build it myself — a Pi and an e-ink panel.** Kept as a fallback. The cheap panels refresh too slowly to type on, and the good open panel is expensive and only 150ppi. This one is only correct if the building *is* the point, and it wasn't.
**A jailbroken Kindle or Scribe.** Dead on a spec, not an opinion: those devices only speak Bluetooth *audio*. There is no HID profile, so there is no keyboard, so there is no terminal. A wonderful hacking toy; not this.
**reMarkable Paper Pro.** Has colour, official SSH, a developer mode, and will pair a Bluetooth keyboard. And colour is the *wrong technology* for an interactive terminal: the panel has no black pigment, so the background sits grey and contrast suffers, and every colour change flashes the whole screen. It is a world-class notebook that would be a poor terminal.
**Daylight DC-1.** A 60fps reflective display, genuinely smooth. But 190dpi makes text soft, contrast is thin, and under its amber frontlight black reads as chocolate brown. Reviews converge on the same shape: the longer people use it, the more disappointed they get. Also closed Android.
**Boox — the best one.** The most mature e-ink computing device by a distance: Termux, an editor, split screen, the best refresh in the industry. It would have worked on day one.
I vetoed it. Onyx devices phone home with IMEI and MAC to servers in China and ship no device-level privacy policy, the platform is closed, and it wears a vendor logo. Every purchase is a vote for the world you want to exist, and I was not casting that one.
The sentence most of these posts never write
Here is what I think is actually worth publishing:
**There was no perfect option because my own rules removed it.**
Open, non-surveilling, unbranded — those three constraints happen to exclude precisely the one polished mainstream product in the category. That is not bad luck. It is arithmetic. Either I loosen a rule and get the polish, or I keep the rules and pay for it in inconvenience.
Naming that honestly matters, because the alternative is the story people usually tell — *I chose the open one and it turned out to be great!* — which quietly hides the trade and leaves the reader thinking they can have both.
I chose the rules. The bill for that arrived eleven days later.
The rule that actually decided it
Between the remaining options, one question did all the work:
**Which pain can I fix?**
The PineNote's problems are software. Software I can read, patch, and only have to fix once. Daylight's problem is 190dpi. reMarkable's problem is that its display has no black pigment. **There is no patch for a screen that renders black as brown.** One of those is a project; the others are permanent.
And one more thing, decided before ordering rather than after: expect the tinkering. The cure for *what if it isn't good* is not optimism, it is a correct expectation. If you go in expecting turnkey, the first bad evening feels like a betrayal. If you go in expecting to work for it, the same evening is a footnote on a ticket you already bought.
$399 plus $44 shipping, PayPal, Hong Kong to Kyoto. Pine64 sells close to cost and doesn't do discount codes — their forum's word for asking is "no begging" — so paying full price felt like the point rather than the cost.
Then it arrived broken
The first night it crashed at random, crashed mid-use, booted fine, crashed again, and at one point stopped responding to a twelve-second press on the power button.
The important thing I did that night was not debugging. It was refusing to let one bad evening rewrite a decision made two weeks earlier — while also refusing to let the decision excuse a defect:
Tonight, what exceeded expectations was not tinkering. It was a machine that might be broken. Those are two different things.
I had pre-agreed to pay the tinkering tax. **A defective unit is not in the tax.** And open hardware does not get a pass here either: Pine64 charged $443 and preloaded an operating system, and at that moment it stopped being a community toy and became a product. *Community-driven* is not a disclaimer once you have taken the money and shipped a system.
So the plan was a deadline, not a mood. Survive one full package upgrade and keep going. Still crashing afterwards and it's hardware — open a ticket and ask for a replacement, at full price, without apology.
It was software. Once the package base was repaired and one desktop version was held back, four consecutive boots came up clean — including runs of 40 and 47 hours with real work on them. The hardware was innocent. No ticket.
What the open bet actually bought, on the worst night
This is the part I did not expect to be the payoff.
On the night it would not boot, I could tell that the bootloader had succeeded, and the kernel, and the initrd — because I recognised which of the two boot screens I was looking at, and the second one belongs to the Linux userland. So the failure was *after* the kernel and *before* the desktop. I could read the partition table. I could learn what the panel's calibration voltage is, where it lives, and that it is unique per unit and unrecoverable if lost. I could find the upstream bug report whose symptoms matched.
With the polished closed device I would have been mailing a black brick back to a factory.
**The open bet does not pay off on the good days. It pays off on the night the thing is broken**, which is exactly the night you would otherwise have no move at all.
The tuning, and a trick borrowed from Kindle
Typing on e-ink normally looks terrible: the entire screen inverts to clean itself, over and over, while you are mid-sentence. The cause turned out to be mundane — the default display waveform is the flashy one, and it is applied on every keystroke.
Switch to the fast black-and-white waveform and typing becomes calm. And then ghosting accumulates forever, because that waveform touches so little of the screen that the automatic "time to clean up" trigger never fires. Clean the ghosting and you are back to flashing.
The way out was not technical. A Kindle flashes too, and nobody minds, **because it hides the flash inside a page turn**. The clear is not invisible. It is *timed*.
So: never clean while you are typing. Clean eight seconds after you stop. A full clear has to drive every pixel and will always be conspicuous — so the goal was never to remove it, only to move it to a moment when nobody is looking. That is now three small configuration layers and a script, and it is the single change that turned this device from a curiosity into something I write on.
And it didn't work for three days
The clean-on-idle half was broken from the day it was installed, in two independent ways.
A background service was losing a race at boot and crashing, so the thing that performs the refresh was never on the bus. And the script that decides whether you have gone idle was reading the reply `(uint64 342896,)` with a pattern that matched **every** number in it — including the `64` in `uint64` — so every comparison failed. One boot logged 173,975 error lines. Idle was never once detected.
Neither made a sound, because the line that called the missing service ended in `2>/dev/null`. It shouted into the void for three days and reported success every time.
**A component whose job is to be quiet has to be loud when it breaks.**
The evidence was sitting in the journal the whole time. Nothing ever claimed there was a problem, so nobody had a reason to look — which is the same failure, from a different angle, as 149 rounds of review that missed five broken languages.
One more finding worth having: this machine cannot be rebooted remotely. Not "it's fiddly" — three mechanically unrelated paths (the standard reset, an RTC wake alarm, a hardware watchdog burning through) all end in the power rail dropping and only a human finger bringing it back. That is a board-level property, not a bug, and it permanently changed how I work on it: everything gets designed so it can be verified *without* a restart, because cold boots are expensive now.
The waveform fix went upstream as a one-line change so the good mode is reachable from the menu at all. It is still open, untouched, nine days on. That is what contributing to a small open project usually looks like — and it is the difference between being a party that open-sources and a party that contributes.
What no auditor can tell you
So: I did not buy the laptop that would have worked perfectly, and I did buy the tablet that did not work at all, cannot be restarted without me in the room, and needed a fortnight before it earned its place on the desk.
`sheerstatus` can tell you whether your machine is the thing holding you back. That is a real question and it deserved a real tool. But the reason this one is on my desk is not on any dashboard, and the day the tool starts pretending otherwise is the day it stops being honest.
Buying nothing was the right answer to the question I asked it. Buying this was the answer to a question I never gave it.
The boring footnote
The configuration is a public repo — CVERInc/pinenote, MIT — including the typing mode above, reproducible on a fresh flash with one command. The auditor from the first post is sheerstatus. Neither of them would have approved this purchase.
Keep reading
-
Your best reviewer is the one who has never heard your reasoning
A bug survived five releases because everyone who read that line already knew what it was supposed to do. The fix was not reading harder — it was pointing a reader with no memory at the diff, and paying the tax that comes with one.\"
-
Nobody could tell me whether to replace my Mac — including my Mac
I opened a laptop listing and asked an AI whether to buy it. Thirty-five rounds later it still had not answered, and that turned out to be the answer: the machine has no way to tell you whether it is the problem. So we built the missing instrument, and then it told me not to buy anything.
-
What 149 rounds of review still missed
I reviewed a tool line by line for three and a half hours and caught a hardcoded threshold twice, a punctuation inconsistency, and a terminal alignment bug. It shipped claiming nine languages, with five of them broken. Everything I looked at was excellent; everything I did not look at was never built.