DEV Community: CacheLine

Phones on shelves got 15% pricier in 2026: how memory chips broke the price curve

CacheLine — Thu, 15 Oct 2026 20:52:55 +0000

Phones that were already on shelves went up in price by 15% on average in 2026, and some models nearly doubled. That is from Counterpoint Research's Global Smartphone Price Increase Tracker, published on 3 September 2026, and the cause it names is memory: prices for the chips that hold your apps and photos have risen fourfold since Q4 2025.

If you have spent years watching last year's flagship get cheaper every month, this breaks the rule you learned. Here is how a part you never see ends up on the price tag.

The usual curve, and why it bent

Normally a phone launches at its highest price and drifts down. The parts inside it get cheaper as factories improve, and the maker can cut the price and still keep its margin.

That only works while the bill of materials goes down. In a phone, two big lines on that bill are DRAM (the working memory) and NAND flash (the storage). When those two jump, the maker of a phone that is already on sale has three options: eat the cost, raise the price, or quietly ship less memory in the next batch.

According to Counterpoint, they did all three. Over 40% of smartphone models had a price increase so far in 2026, which the firm calls a first for the industry. New launches were 25% more expensive than the models they replaced a year earlier. And makers started trimming specs: "lower storage capacities, reduced camera configurations and the reintroduction of 4G models in select price segments."

The warning signs were there in January. Counterpoint's Q4 2025 market report said the average selling price had passed $400 in a single quarter for the first time, up 8% year on year, with "higher Bill of Materials (BOM) costs" and "the ongoing memory shortages" in the mix. Research Director Tarun Pathak expected a "continued rise in ASPs supported by ... DRAM/NAND price hikes." That was the forecast. The September tracker is what it looked like in shops.

We made a short, dramatized version of this as a story about a man who keeps telling his wife to wait for a cheaper phone (the people are invented, the numbers are Counterpoint's):

Where it hurts most

The rise is not the same everywhere. From the same tracker:

Market	Rise in existing phone prices, 2026
India	21%
Asia Pacific	19%
Middle East and Africa	18%
China	10%
Europe	7%
US	5%
Global average	15%

The pattern makes sense once you think about margins. A cheap phone has very little room between what its parts cost and what it sells for, so a memory spike has to go straight to the price or the spec sheet. Price-sensitive markets, where most phones sold are budget and mid-range, took the biggest hits. In the US and Europe, more phones are premium or sold through carriers, and Counterpoint says financing, trade-in deals and instalment plans are softening the blow there.

One exception stands out: Counterpoint says Apple has kept iPhone prices steady so far. That may not last. Senior Analyst Karn Chauhan: "Prices for new smartphones are expected to keep rising over the coming quarters, including for the upcoming iPhone 18 series. Memory shortages and elevated component costs are expected to persist in the near term."

What the memory side looks like

The other end of this story is the companies that sell the memory. Samsung makes DRAM, including the LPDDR type used in phones. Its Q3 2026 earnings guidance (8 October 2026) puts consolidated operating profit at about 107.40 trillion won, against 12.17 trillion won in the same quarter of 2025.

Be careful with that number. It is company-wide, and the guidance gives no breakdown and no reason for the jump. It sits next to the memory price rise; this release alone does not prove one caused the other.

What I would take from it

Counterpoint says buyers are already reacting: delaying upgrades, picking lower-storage models and turning to refurbished phones. For you, the practical points are:

"Wait and it gets cheaper" assumes falling part costs. While memory stays expensive, waiting can cost you more, not less.
Check the storage on the new model before you compare prices. Some phones now come with less of it for the same money.
If your current phone works, keeping it is the one option the memory market cannot reprice.

What I would like to track next is how fast the curve flips back once memory supply catches up: do phone prices fall as quickly as they rose, or does the higher price stay? If you have watched a past memory cycle play out in phone or laptop prices, I would like to hear how long the way down took.

A little girl crashed a NASA computer

CacheLine — Thu, 15 Oct 2026 11:27:37 +0000

A four-year-old crashed the Apollo command module simulator by starting the prelaunch program, P01, in the middle of a simulated flight. NASA turned down the fix her mother proposed, and on Apollo 8, in December 1968, an astronaut made the same mistake in real space.

Her mother was Margaret Hamilton, who led the software engineering team at MIT's Instrumentation Lab during Apollo. She died on Sep. 30 at 90, and the MIT News obituary retells the story that became known as "the Lauren error". Below is how that error works, step by step, using the minute-by-minute NASA transcript in the Apollo Flight Journal.

The simulator crash and the "no"

Per MIT News, Lauren was playing with the simulator at the Instrumentation Lab and somehow started P01 while the simulated spacecraft was in flight. The simulator crashed.

Hamilton did two things. She added a warning to the documentation: do not start P01 during flight. And she proposed a change to the software so the error could not happen on a real mission. She was overruled. The reason given was that highly trained astronauts would never make that mistake.

So the fix was a sentence in a document, not a check in the code. The person typing was expected to remember it.

The short version, as a video:

How one keypress became "program 01"

You talked to the Apollo Guidance Computer through a keypad called the DSKY, with verbs (what to do) and nouns (what to do it to). Verb 37 means "change program to...", and the next number you type is the program.

On day 5 of Apollo 8, on the coast home from the Moon, Jim Lovell was about to measure the angle between star 01 (Alpheratz) and the lunar horizon. The Flight Journal lays out the correct sequence:

VERB 37  ENTER  23  ENTER     -> start P23 (star sightings)
VERB 5          01  ENTER     -> star code 01 (Alpheratz)

What he actually keyed, per the Journal, skipped the program number and the second verb:

VERB 37  ENTER  01  ENTER     -> start P01

The computer did exactly what it was told. P01's stated job is "to initialise the platform for the prelaunch programs". The platform is the gyroscope-stabilised unit that holds a fixed direction in space, so the computer always knows which way the ship points. Starting P01 moved it away from its current alignment. A "No Attitude" light came on.

At 106:27:28 mission time Lovell reported: "For some reason, we suddenly got a Program 01 and a 'No Attitude' light on our computer." Three minutes later, at 106:30:21: "We have star 01 coming up, now that might have been the reason."

The Journal's own verdict on the machine: "astonishing" for its time, but its interface was "unsophisticated, even clunky, and very unforgiving of errors", and the crew were sleep-deprived. Both errors had the same root cause. One input was valid in two very different contexts, and nothing asked "are you sure?" before running the program meant for the launch pad.

Fixing it with two stars

The ship was not lost. Apollo 8 was on a long coast with no time-critical burns just ahead, and the Journal calls that fortunate. Houston's procedure: select P00, run P51 to align the platform again by sighting stars, then receive a new reference orientation (the REFSMMAT) from the ground and fine-tune with P52.

At 106:49:50 Frank Borman said: "Jim had to use Rigel and Sirius, and they're pretty close together." Two known stars give the computer enough to rebuild its sense of direction. That is the same job a navigator's sextant did at sea.

Houston later checked the memory. At 115:17:22 Ken Mattingly told the crew their P01 "didn't have any effect" on the erasable memory, apart from one display that might now be unreliable. The crew did not let it go: at 115:21:17 Borman called Lovell "the same guy that tried to launch us this afternoon" (Apollo Flight Journal, the next part of day 5).

What changed after

According to MIT News, Hamilton and her team were called in to solve the error, and after that her proposed changes went into the program. MIT News calls this an early example of "defensive" programming: software that expects mistakes and handles them instead of trusting the operator.

The pattern is still everywhere. A documented "never do X" is a bug report waiting for a date. If an input can destroy state in one mode, the code, not the manual, has to check the mode.

An open question I could not answer from these sources: what exactly did her final check look like in the flight software? If you have read the Apollo flight software listings, I would like to know how it decided P01 was not allowed.

You bought Apple's new $299 screen. You can't even set it up without an iPhone.

CacheLine — Thu, 15 Oct 2026 05:59:14 +0000

Story dramatized. Facts from the sources below.

Apple's new HomeView screen costs $299 in the U.S., and you cannot set it up on its own. Apple's own footnote says setup needs a compatible iPhone or iPad running the latest software, so if your phone is a Samsung, the screen on your wall is a very nice black rectangle.

The story

My coworker forgot his tenth wedding anniversary. His wife cooked dinner and lit candles. He came home with a bag of chips.

So he did what we all do when we feel guilty. He spent money. He ordered the new Apple HomeView for the kitchen wall, so all their wedding photos could live in one place. He drilled holes all morning. He paid extra for the mount. He paid extra for the cable.

That night he covered her eyes, turned it on, and the screen asked for an iPhone. His phone is a Samsung.

Her review was short: it is beautiful, and it does nothing on its own. Same as him on the anniversary.

The 60-second version:

Where Apple tells you (if you look)

None of this is a secret. It is just not where a guilty husband looks. Here is where each fact lives:

What	Where Apple says it
Price: $299 (U.S.), both models	Apple Newsroom, 13 Oct 2026, main text
"Setup and multiuser support require a compatible iPhone or iPad running the latest software"	Same Newsroom post, in the footnotes at the bottom
iPhone with iOS 27.2 or later, or iPad with iPadOS 27.2 or later	HomeView tech specs, "System Requirements"
Wall Mounted model: wall mount, USB-C cable and power adapter (minimum 20W) each sold separately	Same specs page

The main HomeView product page is the page most people actually read. It has no system requirements section. The iPhone rule shows up there only inside the small notes and the FAQ.

So the order of discovery for a normal buyer is: see the price, see the photos, buy it, drill the wall, read the footnote. The last step should be the first one.

Why a screen needs a phone to wake up

From the outside this looks like pure lock-in, and partly it is. Apple does not explain the reason, so this part is our guess. A screen on a kitchen wall has no good keyboard, and typing a Wi-Fi password and an Apple Account password on a wall is painful. Letting a phone that is already signed in do the work is the easy way out.

The product page also says you need to be added as a member of the shared home in the Home app for the full, personal experience. That "home" lives in Apple's Home app, which lives on Apple devices. Android is not in that loop. So the phone is not just a setup tool. It is the key to the house the screen belongs to.

To be fair to Apple, the same page says guests and people it does not recognize can still use the screen for some things. But someone has to set it up first, and that someone needs an iPhone or an iPad.

What the gift really cost

Let us add it up the way the story does:

the $299 screen
the wall mount, sold separately
the USB-C cable, sold separately
the power adapter, sold separately
one brand-new iPhone, just to set up the gift
one week on the couch

The screen works great now. Every morning it shows their wedding photo. He can see it from the couch.

The real lesson for anyone buying tech as a gift

Read the "System Requirements" section on the specs page before you pay, not the footnotes after you drill. For a gift, check what phone the other person (and you) actually use.

An open question for you: if a device needs another device to set up, should that be on the front of the product page, next to the price? Or is "it is in the specs" enough?

Chrome kept the same fingerprint ID on 5 of 5 cookie-free visits. Brave got 5 different ones.

CacheLine — Wed, 14 Oct 2026 00:02:59 +0000

Our home-made test page gave Chrome the same ID, e08e953c, on 5 of 5 visits, and every visit started with a brand new empty profile and zero cookies. Brave, with its default settings, got 5 different IDs in 5 visits on the same Mac.

So clearing cookies changes nothing about what this page sees. We ran this ourselves; below is the method, the reason the two browsers differ, and the limits.

How we measured it

The page reads 7 things from the browser, joins them, and hashes them with SHA-256. The first 8 hex characters are the ID. Two bytes of the ID pick a two-word nickname from two lists of 32 words, so it is easy to read on screen. Chrome was "Bold Llama".

// inside an async function; c is a <canvas> we drew shapes, text and an emoji on
const hex = async s => [...new Uint8Array(await crypto.subtle.digest('SHA-256',
  new TextEncoder().encode(s)))].map(b => b.toString(16).padStart(2, '0')).join('');

const canvas = await hex(c.toDataURL());

const ac = new OfflineAudioContext(1, 44100, 44100);
const o = ac.createOscillator(), comp = ac.createDynamicsCompressor();
o.type = 'triangle'; o.frequency.value = 10000;
o.connect(comp); comp.connect(ac.destination); o.start(0);
const buf = (await ac.startRendering()).getChannelData(0);
let sum = 0; for (let i = 4500; i < 5000; i++) sum += Math.abs(buf[i]);

const gl = document.createElement('canvas').getContext('webgl');
const e = gl.getExtension('WEBGL_debug_renderer_info');
const webgl = e ? gl.getParameter(e.UNMASKED_RENDERER_WEBGL) : gl.getParameter(gl.RENDERER);

const parts = {
  canvas, audio: String(sum),
  screen: `${screen.width}x${screen.height}x${screen.colorDepth}@${devicePixelRatio}`,
  timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
  languages: navigator.languages.join(','),
  cpu_cores: String(navigator.hardwareConcurrency),
  webgl
};
const id = (await hex(JSON.stringify(parts))).slice(0, 8);

A small Playwright script (run.js) opens the page with chromium.launchPersistentContext(profile, { executablePath, headless: true }). The profile is a fresh fs.mkdtempSync folder on every visit, deleted afterwards.

python3 -m http.server 60309 --bind 127.0.0.1
node run.js chrome http://127.0.0.1:60309/fp.html 6   # 1 warm-up + 5 measured
node run.js brave  http://127.0.0.1:60309/fp.html 6
KEEP=1 node run.js brave http://127.0.0.1:60309/fp.html 6   # one kept profile, restart + one reload per visit

Machine: Apple M1 Pro, 16 GB, macOS 26.6.2. Chrome 155.0.8059.40, Brave 155.1.97.56, Playwright 1.64.0, Node v26.8.1. Both browsers ran headless.

The 60-second version:

The numbers

Run	Different IDs in 5 visits	Names
Chrome, new empty profile each visit	1	Bold Llama, 5 times
Brave, new empty profile each visit	5	Zippy Llama, Mighty Mole, Zippy Wombat, Chilly Ferret, Fancy Lobster
Brave, same profile, browser restarted each visit	5	Mellow Panda, Fuzzy Owl, Jolly Owl, Shiny Yak, Cranky Pigeon

In Chrome all 7 parts had one value across the 5 visits. In Brave only 3 parts moved: the canvas hash (5 different values), the audio sum (5), and the CPU core count, which came back as 7, 4, 8, 7, 7. The other 4 stayed the same.

We also opened brave://settings/shields in a new empty profile. "Block fingerprinting" was already on.

Why the two browsers differ

None of the 7 parts is stored in the profile. They describe the hardware and the system, so a new profile reads them the same way. A cookie is something the site puts on your disk, a fingerprint is something the site asks your machine. Mozilla's Tom Ritter wrote in the Firefox fingerprinting post (10 Nov 2025) that the technique "lets websites identify you even when cookies are blocked or you're in private browsing".

Brave does not block the reads. Per the Brave fingerprinting wiki, it adds small random changes to some API values, from "a seed that changes per session, per site (eTLD+1) and per storage area". A hash over many parts breaks as soon as one part moves, and here three of them moved.

There is also a consent angle. The UK regulator ICO noted on 19 Dec 2024 that from 16 February 2025 Google no longer prohibits fingerprinting in its advertising products, and that Google itself had earlier said users "cannot easily consent to it as they would cookies".

Limits you should know

One machine, one test, 5 measured visits per run.
Both browsers ran headless through Playwright with default launch flags. Chrome reported the 1080x1920 viewport as its screen and Brave reported 3840x2160, neither being the real display.
The page was served from 127.0.0.1. It is a 7-part toy, not an ad tracker. Real trackers can use more signals, including your IP address, which Brave does not hide.
We showed the Chrome ID is stable. We did not measure how unique it is: two identical Macs could get the same one.
In Brave the ID changed on every browser start. A reload inside one session kept the same ID, 5 of 5 times, which matches the per-session seed. It is not a new name on every page load.
Firefox with Strict protection was not tested.
Our first full run was thrown away: the nickname list had the word "Brave" in it, so Chrome was named "Brave Llama". We changed it to "Bold" and ran everything again; the pattern was the same.

Next we want to run the page in a normal visible window, and on a second identical Mac to see if the IDs collide. If you run it, which of the 7 parts changes on your setup?

The "Hi Mom" text scam is an authentication bug, and the fix is a shared secret

CacheLine — Tue, 13 Oct 2026 23:27:04 +0000

A text arrives from a number you have never seen: "Hi mom. I lost my phone. This is my new number." A few friendly messages later it asks for money for a bill, today. Nothing in that chat ever proved who was typing.

This is not a coding post. But if you build login flows, you already know this bug, and you are probably the person your family will ask about it. So here it is, written the way we would write up an auth failure.

The attack, message by message

For our short video I rebuilt the chat on screen as a phone conversation. To be clear: it is a re-creation that we wrote, not a real victim's chat. The steps follow the pattern the Australian regulator ACCC described in its media release of 23 August 2022 (the live page answered our requests with a 403, so I read it through a Wayback Machine copy).

[Unknown number]  Hi mom. I lost my phone. This is my new number.
[You]             Oh no! Are you ok?
[Unknown number]  ...friendly small talk...
[Unknown number]  Mom, I need money for a bill. Today.

The replies in the middle are ours, the opening and the ask are the pattern. The ACCC puts it like this: the scammer "will claim they have lost or damaged their phone and are making contact from a new number", and then, "once they have developed a rapport", asks for money "to help urgently pay a bill". It adds a detail that closes the last exit: the story is that they cannot reach their online banking for now, which is why the money has to come from you.

The ACCC counted more than 1,150 victims and A$2.6 million in reported losses in Australia in the first seven months of 2022. Those numbers are old and from one country; they show the pattern is real, not how big it is today.

The short version:

Why it works: every signal is one the attacker controls

Look at what you are asked to trust.

Signal	Who controls it	Proves identity?
The name "Mom" or "it's me" in the text	The sender	No
The new number	The sender	No
A voice on a call	The sender, per the FBI	Not any more
A word you agreed on face to face	Only your family	Yes
A call you place to the saved number	You	Yes

The first message does the real work. "This is my new number" is an account recovery request: please move your trust from the old channel to this one. And you approve it by replying, with no check at all.

The usual answer is "I would know my own kid's voice." The FBI's Internet Crime Complaint Center says that is no longer a safe check. Its alert I-120324-PSA of 3 December 2024 states: "Criminals generate short audio clips containing a loved one's voice to impersonate a close relative in a crisis situation, asking for immediate financial assistance or demanding a ransom." The alert does not say how much audio a copy needs, so I will not guess.

The fix is two things you already ship

A shared secret. The same FBI alert gives the tip in one line: "Create a secret word or phrase with your family to verify their identity." It works for the reason a pre-shared key works: it was agreed outside the channel under attack, so the person on the new number cannot look it up.

[Unknown number]  Mom, I need money for a bill. Today.
[You]             What is our code word?
[Unknown number]  ...

No code word, no money.

An out-of-band check. The ACCC's advice is to "start by calling them on the number already stored in your phone". You start the call, on a channel you already trusted before the message came. If they pick up, you know the text was a scam.

Both checks cost about a minute. A real family member can wait one minute. The whole scam depends on you not waiting, which is why the bill is always due today.

Limits

I did not test this against a real scammer, and I did not clone a voice. The chat is a re-creation and the claims come from the two public sources above.
A code word only helps if you set it before you need it, and if nobody types it into the same chat they are trying to check.
The ACCC also covers the case where the old number does not answer: try a second contact method, then ask a personal question a scammer could not know.

What I have not solved: how do you rotate a family code word after someone says it out loud in the wrong place, without the new one leaking the same way? If your family already does this, I would like to hear how.

Your Zipper Has a Hidden Brake You've Been Fighting for Years

CacheLine — Mon, 28 Sep 2026 16:24:49 +0000

Every jacket zipper does two jobs, and most people have only ever noticed one of them. Closing the gap is the obvious part. The second job is stiffness: two floppy sheets of fabric become one rigid panel the moment the teeth interlock, because the slider forces them into a continuous mechanical spine.

A zipper that makes a rod, not a seam

Researchers pushed that same idea into a shape nobody had building code for: a Y-shaped zipper that joins three flexible straps instead of two flat panels (source). Pull the slider closed, and three straps that flop around on their own suddenly lock into a rigid triangular rod, roughly 160 times stiffer than any one strap was by itself, with no glue, no fasteners, and no extra parts. The stiffness comes entirely from geometry: three flat, floppy things become one triangular cross-section, and a triangle resists bending in a way a flat strip cannot.

That's the same trick your own jacket has been doing quietly for a century, scaled up into something you could use to build a temporary support beam, a splint, or a structural piece that ships flat and only locks rigid when you need it.

Here's the 60-second version:

The part of a normal zipper nobody notices

Look inside the slider on your own coat and there's a second mechanism most people never learn about: a small spring-loaded pin sits inside the body of the slider and drops down between the teeth the instant the pull tab lies flat against the fabric. That pin is what stops a zipper creeping open on its own while you're wearing it — the teeth alone wouldn't hold it shut.

It's also the real reason a "jammed" zipper won't move half the time. You aren't fighting the teeth, you're fighting that pin, which is doing exactly what it was built to do: lock the slider in place. Lift the tab up to roughly ninety degrees from the fabric and the pin retracts out of the teeth, and the slider that felt welded shut usually slides free in one motion.

An idea that lost, forty years too early

The locking-pin mechanism traces back further than you'd expect. A 3D-printable version of it was proposed decades before desktop 3D printers existed for ordinary people to own, and the design lost the competition it was entered into, because there was no cheap way to actually manufacture one at the time. The idea was right; the hardware to build it cheaply just didn't exist yet.

That gap is gone now. Anyone with a $200 desktop printer can print that exact mechanism today, and the Y-zipper project shows the same underlying principle still has more to give: a fastener whose real value isn't sealing a gap, but switching a flexible material into a rigid one on demand.

What to look at next

If "the mechanism was hiding in something ordinary" is your kind of story, the natural next step is to pull apart an old broken zipper slider and actually look at that locking pin — it's a two-minute teardown and it makes the ninety-degree trick obvious the first time you see it. Next time a zipper on your bag or jacket sticks, you'll know exactly which part is catching, and it isn't the teeth.

I was wrong about the RTX 5090 — here's what changed my mind

CacheLine — Mon, 28 Sep 2026 12:17:56 +0000

At launch, the RTX 5090 looked like an easy pass: $2,000 for roughly 30% more performance than the previous flagship, a 25% price hike, and over 500 watts of power draw. Every reviewer ran the price-to-performance math and called it a bad deal. They weren't wrong about the math — they were arguing about the wrong number.

The spec sheet was never the story

Performance-per-dollar assumes a card is being bought to play games. That assumption broke somewhere between the launch reviews and today. While gamers were measuring frame rates, AI infrastructure buyers were pricing VRAM, and the RTX 5090's 32GB of GDDR7 put it in a category almost nobody expected a consumer card to compete in.

Why 32GB at $2,000 became a bargain

Nvidia's professional AI cards didn't just get more expensive — they roughly doubled, going from around $8,000 to $16,000 as demand for training and inference hardware outpaced supply. Next to that, a 32GB consumer card selling for $2,000 wasn't a bad deal for gamers, it was the cheapest way to get that much memory into a rack, sticker price included. Buyers noticed, and started buying them by the pallet.

That's the detail the day-one reviews couldn't have caught. At launch, this was still a graphics card being judged as a graphics card. A few months of AI-side demand later, it turned into an industrial input for anyone who needed memory bandwidth and didn't care about ray-tracing benchmarks.

The resale market is the proof

You can watch this play out in real time. Listings for the RTX 5090 now start around $6,000, and some sellers are asking well past $10,000, for a card that launched at $1,999. Nvidia's own response tells you everything about supply: if you want one at the original price, the company's answer is to show up at events like QuakeCon and enter a raffle. A mainstream gaming product turned into a rationed commodity, handed out by luck instead of sold off a shelf.

That's a strange spot for the world's largest chip company to be in with its own flagship consumer part. Nvidia can make plenty of RTX 5090s. The problem is that every unit gets bid up by two very different buyers chasing the same 32GB of memory, and only one of them is using it to play games.

Here's the 60-second version:

What I'd actually watch next

If a GPU launches to lukewarm reviews and then becomes impossible to find at MSRP months later, that gap is worth investigating before you write the card off, and worth investigating again before you buy one secondhand. Track the actual sale price over time instead of the number from the launch-day press release, and ask who else might want the same hardware for reasons that have nothing to do with gaming.

The RTX 5090's real price was never $1,999. That number just hadn't caught up yet, and by the time it did, the gaming market it was originally priced for wasn't the market that ended up buying it.

That's the part I got wrong the first time around: I judged the card against the wrong buyer. A launch-day price only tells you what a company hoped the market would look like, not what it will look like once a second, better-funded buyer shows up for the same silicon.

Source: the original price breakdown

Colin Furze Built a Magnet Suspension Bike. Physics Made It a Pogo Stick.

CacheLine — Sun, 27 Sep 2026 08:17:21 +0000

Two pairs of neodymium magnets, each rated to hold 500 kilograms, face each other across the frame of a bicycle. No springs. No oil. No air. That's the whole suspension system Colin Furze just built — and it works, right up until the bike hits a real bump and turns into a pogo stick that won't stop bouncing.

A spring that never gets tired

Push two magnets together with the same poles facing and they push back. That's the entire trick behind the bike: one magnet array on the frame, another on the fork and swingarm, all oriented to repel. Compress the "suspension" by hitting a bump, and the magnetic field pushes the wheel back down just like a coil spring would. No moving fluid, no seals to leak, no oil to change.

For small, gentle bumps, this works beautifully. The magnets store the energy of the bump and hand it straight back, exactly the way a spring is supposed to.

The half of suspension that magnets can't do

Here's the problem: a spring is only half a suspension system. Every real fork or shock has two components — a spring that absorbs the bump, and a damper that bleeds off the energy afterward as heat. Springs alone don't stop oscillating; they just keep converting kinetic energy back into potential energy and back again until something else, friction or air resistance, finally kills the motion.

A hydraulic damper does that job by forcing oil through a small orifice, turning the bump's energy into heat and getting rid of it. A magnetic field can't do that. There's no orifice, no friction, no way for the field itself to dissipate energy. Whatever energy goes into compressing the magnets comes right back out, at close to full strength.

Here's the 60-second version of what that looks like on the road.

Why it turns into a pogo stick

Without a damper, any bump big enough to meaningfully compress the magnets doesn't just get absorbed, it gets returned, and the return overshoots, and that overshoot gets returned again. The bike keeps bouncing until ordinary friction in the frame, bearings, and tires slowly bleeds the energy away, which takes a lot longer than a damper would. Small road texture feels smooth. A pothole turns the whole bike into a pogo stick.

This is close to what killed magnetic and air-only suspension concepts in the automotive world decades ago: a spring without damping isn't a suspension, it's an oscillator.

The failure mode nobody wants

There's a sharper problem hiding underneath the physics one. The whole system depends on the magnets never actually touching. If the suspension ever bottoms out hard enough for the repelling faces to get past each other, two magnets rated to hold 500 kilograms apiece will snap together at speed, with the rider's leg sitting somewhere in between. A spring that fails just goes soft. A magnet array that fails inverts from repulsion to violent attraction.

What an actual fix would need

None of this is unfixable, it's just missing a part. Add a hydraulic or friction damper alongside the magnets and you'd get a genuinely novel spring-by-magnetism suspension with normal ride characteristics. Rare-earth magnet springs have been explored seriously for years, mostly in vibration isolation for industrial machinery, always paired with some separate damping mechanism. Furze's build is a fun demonstration of the spring half of that idea in isolation, which is exactly why it bounces the way it does.

The interesting part was never really the magnets. It's the reminder that "suspension" is two different jobs bolted together, and building a viral demo of just one of them is a great way to find out, in public, why the other one exists.

Apple Mocked Foldables for Black Bars. Its Own iPhone Duo Has the Same One.

CacheLine — Sun, 27 Sep 2026 02:36:55 +0000

Apple spent years mocking Android foldables for wasting screen space on video. Its own iPhone Duo just shipped with the identical problem: run a standard 16:9 video on the fully updated app, and about a fifth of the $1,999 display still goes black.

A screen shaped for paper, not video

The iPhone Duo's inner display is 7.6 inches, unfolded into a shape close to a sheet of A4 paper. That aspect ratio is genuinely good for documents, spreadsheets, and web pages — the things Apple leaned on in every demo. It's a poor fit for the 16:9 video most people actually watch, which is exactly the flaw Apple's own executives called out in Android foldables for years.

Do the math on the panel and a 16:9 video maxes out at roughly 80% of the available screen, even once an app is built correctly for the shape. The other ~20% just sits unused. On a phone that costs two grand, that's not a rounding error — it's visible in Apple's own launch coverage of the device.

The order things happened in

The real story isn't the aspect ratio by itself — it's the sequence. Apple locked in the screen's physical shape long before it handed developers the tools to design around it. The SDK that lets an app detect the Duo's panel and lay out content to fill it properly only became available after the phone was already announced to the public.

That leaves developers with a matter of weeks, not months, to rework layouts for an entirely new form factor. Most teams building a phone app never had to think about an A4-shaped canvas before. Retrofitting that in a few weeks, across thousands of apps, is not realistic.

What that means on launch day

Without the update, an app doesn't know the Duo's screen exists — it just renders like a regular phone. On the Duo's inner display, that shows up as a normal phone-sized window floating in the middle of a much bigger panel, with black space filling the rest. Even Apple's own marketing video for the Duo shows this: a 16:9 clip playing inside letterboxing on all sides, using about 80% of the screen it's supposedly designed for.

So the same complaint Apple made about Samsung and other Android foldables — awkward black bars, apps that don't understand the fold — is exactly what ships on day one of its own device, just because of a scheduling problem rather than a hardware one. iOS 27.1 is the update that's supposed to fix this on the software side, and it's the version most apps need before they can even try to fill the screen correctly.

Why this keeps happening with foldables

This isn't really an Apple-specific failure. Every foldable maker has hit the same wall: the physical screen ships on a hardware timeline, while the software that makes content look right on that screen ships on a much slower ecosystem timeline. Samsung dealt with this for years with Android apps that didn't know what to do with a square unfolded display. Google faced it with the Pixel Fold. Now Apple, despite having full control of both its hardware and software stack and years of advance warning about the exact problem it was walking into, shipped the SDK too late to matter for launch day.

The lesson is less about foldables specifically and more about dependency ordering: if the thing your ecosystem needs to look correct ships after the thing it needs to look correct on, you get a launch full of black bars no matter how good the hardware is.

Here's the 60-second breakdown of the aspect ratio, the missing fifth of the screen, and why the timeline made it unavoidable:

Worth watching next: how Samsung's own foldable app-continuity guidelines evolved over five generations of the Galaxy Fold, since that's the closest real precedent for what iPhone Duo developers are about to go through in the coming months.

The Sonar Found a Plane. The Internet Found the Wrong Story.

CacheLine — Sat, 26 Sep 2026 05:23:55 +0000

In 2021, a California drought drained Folsom Lake low enough to expose the outline of a sunken plane, 160 feet down. Within days, newsrooms had matched it to a 56-year-old missing-persons case. The plane sitting on that lake bed was never the one everyone said it was.

A drought, a sonar hit, and a name that stuck

Two people testing sonar gear on Folsom Lake picked up a clear shape on the bottom: a full-size aircraft, sitting upright in shallow water that a historic drought had pulled back. The obvious story was sitting right there. On New Year's Day, 1965, a Piper Comanche vanished from the same lake carrying three people who were never found. A sonar return, a matching location, a decades-old cold case — the story was reported as the discovery that finally closed it.

That's the problem with a sonar image: it gives you a shape and a depth, nothing else. It can't tell you a tail number, a registration, or a date. Every other detail in that headline — the names, the year, the fact that anyone had died at all — got bolted on afterward by people who wanted the story to be true.

The dive that didn't match the headline

When dive teams actually went down to the wreck, the plane wasn't the 1965 Comanche. It was the remains of a completely different aircraft, from a crash in 1986. Nobody on board that 1986 flight died. Everyone walked away from it. The plane had just been sitting in the lake for over three decades, waiting for a drought to lower the water far enough to find it.

So the "56-year mystery" wasn't solved. It's still open. The three people who disappeared in 1965 are still missing, and the plane that was supposed to be the answer belongs to an entirely unrelated accident that had a happy ending.

Here's the short version of how it actually played out:

Why the mix-up is more interesting than the mystery

The failure here isn't the sonar equipment — it did exactly what sonar is supposed to do: return a shape and a depth from underwater. The failure is everywhere else in the chain. A location that roughly matched. A shape that looked plane-sized. A decades-old cold case that was already sitting in everyone's memory, ready to be reattached to the first plausible wreck that surfaced.

Nobody waited for divers before writing the ending. Families who had no connection to either crash got a story implying their case was closed. Families whose actual missing plane is still on the bottom of a lake somewhere got nothing. And the story ran everywhere anyway, because a sonar blip that "matches" a famous mystery is a much better headline than "unidentified aircraft found, cause and identity unknown, please wait for confirmation."

The actual lesson for anyone reading sensor data

If you work anywhere near sensors, imaging, or any pipeline that turns raw signal into a claim a human will act on, this is a familiar shape of mistake. A sonar return, a satellite pixel, a log line, a fingerprint match — the instrument gives you a narrow, literal fact. Everything past that fact is inference, and inference is where confidence quietly outruns evidence.

The fix isn't more skepticism about sonar. It's separating "here is what the sensor measured" from "here is what we're claiming it means" before either one gets published. Folsom Lake had one of those steps skipped for about a week, and the two lakebed wrecks got their identities swapped in front of a national audience before anyone actually confirmed either one.

If you want to go deeper on how identification actually works underwater, dive registries and wreck-identification case studies from maritime archaeology groups are a much better rabbit hole than the next viral sonar headline — they spend paragraphs on exactly the kind of confirmation this story skipped.

What 10 years of writing code actually changes (it's not the code)

CacheLine — Sat, 26 Sep 2026 03:17:16 +0000

Ask sixteen experienced open-source developers how much faster AI tools would make them, and they'll say about 24%. Ask them again right after they finish the task, and they'll still swear they were roughly 20% faster. The stopwatch says otherwise: they were actually 19% slower.

That gap is the headline result from a 2025 randomized controlled trial run by METR, a group that studies how AI systems actually perform in the wild rather than on benchmarks. Instead of testing beginners on toy problems, the study put experienced developers to work on real, mature codebases they already knew well — their own open-source repositories, with years of accumulated context already living in their heads.

The 39-point gap

Here's the setup: developers picked real issues from their own projects, then were randomly assigned to either use AI tools or not for each task. Before starting, they predicted AI would cut their completion time by about 24%. After finishing, they still believed they had come out roughly 20% ahead.

The actual clock time told a different story. Tasks done with AI assistance took about 19% longer than tasks done without it. That's a 39 percentage-point gap between what these developers believed happened and what a stopwatch recorded — in professionals who write code for a living.

Why the most experienced developers lost the most time

The slowdown wasn't evenly spread. It was strongest on exactly the codebases the developers knew best. That's the counterintuitive part: you'd expect deep familiarity to make AI assistance additive, a second pair of hands on a system you already understand. Instead, the tool mostly added overhead — prompting, reviewing suggestions, and correcting output — layered on top of work the developer could already do quickly from memory.

Ten years of shipping code builds a fast, private, mental model of a system: which functions are safe to touch, which abstractions leak, where the real bugs hide. That model runs in the background and is basically free. An AI assistant doesn't have it, so every suggestion has to be checked against it, and checking takes time the raw "assistance" never shows up as.

The same illusion shows up in floating point

There's a smaller, more mechanical version of this mismatch that any developer runs into on day one:

>>> 0.1 + 0.2
0.30000000000000004

Nothing is broken. Binary floating point can't represent 0.1 or 0.2 exactly, so the addition is off by a sliver too small to notice by eye but large enough to break an equality check. The computer isn't wrong — your intuition about what "0.1 + 0.2" means is just miscalibrated against how the machine actually stores numbers.

That's the same shape as the METR result. Your internal sense of speed, like your internal sense of what 0.1 plus 0.2 equals, is a model — usually good enough, occasionally confidently wrong, and only correctable by actually checking the value against a ground truth instead of trusting the feeling.

What actually worked

The METR study also found the developers who avoided the slowdown weren't the ones who resisted AI tools altogether. They were the ones who stopped guessing and started timing themselves — treating "does this actually help me" as a measurable question instead of a vibe.

The other habit that held up: writing down why the code looks the way it does, before that reasoning quietly leaves with whoever holds it in their head. A decade of experience is mostly an unwritten, unmeasured model of a system. AI tools are good at producing plausible-looking code fast; they are not a substitute for that model, and treating them as one is exactly how an experienced developer ends up slower while feeling faster.

If you want to know whether a tool is actually helping you, the fix is unglamorous: time it, on your own real tasks, more than once.

Here's the 60-second version of this story:

If you've caught yourself feeling faster while a task actually dragged on, that's the whole study in miniature — worth checking with a clock next time before you trust the feeling.

Boston Cancelled Its License Plate Cameras. The Cameras Didn't Leave.

CacheLine — Fri, 25 Sep 2026 21:49:20 +0000

Boston's mayor announced in September 2026 that the city had cut ties with Flock Safety, the license-plate-reading camera vendor behind its automated surveillance network. The trigger wasn't a hack — it was a configuration setting that left Boston's plate-reader data searchable by police departments across the country, for purposes the city never approved.

What actually happened

Flock's cameras photograph every car that passes a fixed point and log the plate, timestamp, and location. Departments that buy into the network can share that data with other agencies, and by default, Boston's data was shared far more widely than city officials realized. Once the configuration was flagged, Flock closed the hole. But there was no audit trail showing who had already run searches against Boston's plates, and the underlying records had already rolled off after their standard 30-day retention window. Boston residents didn't learn any of this until roughly seventeen months after the exposure happened.

Automated plate readers are attractive to departments precisely because they're cheap and passive: no officer has to run a plate manually, the system just logs everything and lets anyone with access search it later. That convenience is also the entire privacy problem — the system doesn't know the difference between "investigating a stolen vehicle" and "checking where an ex-partner parks."

Cancelling the vendor didn't turn the cameras off

This is the part that got buried under the "city bans surveillance cameras" headline: the Boston Police Department had already installed 75 license-plate cameras from other vendors, Motorola and Axon, before the Flock cancellation was even announced. The plate reading didn't stop. The logo on the camera changed.

Public records showed around 11,000 searches against the plate database in five months. About half of them carried no case number at all, meaning there's no record of what investigation, if any, justified the lookup.

The real risk was never the vendor

Swapping Flock for Motorola doesn't fix the actual failure mode: a plate-reader network is only as trustworthy as every individual officer who has a login. Nationally, hundreds of officers have been formally accused of running plate or database searches for personal reasons — checking on an ex, a neighbor, a family member — with no case attached. A vendor swap doesn't touch that. Neither does a press release announcing the old contract is gone.

Here's the 60-second version:

What to actually watch for

If your city announces it's "ending" a surveillance camera contract, the headline question isn't which vendor got fired. It's:

Did the hardware actually come down, or just get relabeled under a new vendor?
Is there an audit log tied to every search, with a mandatory case number?
How long is data retained, and who can still pull it before it expires?
Is oversight independent of the department running the cameras?

Boston's story is a clean case study because the paper trail is public: a Flock misconfiguration, a fix with no accountability for prior access, a 30-day retention window that erased the evidence before anyone could audit it, and a quiet buildout of a replacement network using different hardware from the same playbook. None of the incentives changed. Only the branding did.

If you want to go deeper, UFD Tech's coverage is what originally surfaced the Boston details referenced above: https://www.youtube.com/watch?v=BXDzO9YWGbI. Worth checking next: how your own city handles public-records requests for plate-reader search logs. Some departments publish them by default; most don't, and that gap is where accountability quietly dies.