Vincent Ping (English)

The AI Business Through a Crypto Miner's Eyes

Thu, 25 Jun 2026 22:27:00 GMT

In the last piece, NVIDIA Through a Crypto Miner’s Eyes, I looked at NVIDIA through the lens of my mining years and saw two things. One was its fragility: value is shifting from training to inference, from general-purpose chips to custom silicon, and the segment NVIDIA is counting on most is exactly the one being hollowed out from within — while the company itself has started investing in its own customers, adding leverage to its own demand. The other was more fundamental: even if NVIDIA is the hardest pick-and-shovel play of this AI wave, that doesn’t prove today’s price is rational. Whether a technology is real and whether its stock price makes sense are two different lines on two different charts.

This time I want to look higher up the stack — not just NVIDIA, but the entire AI industry.

The AI business is red-hot right now. The four major tech giants’ combined capital expenditure for 2026 tops $700 billion, up roughly 80% from last year. Bonds, venture rounds, and stock prices are all riding the same wave. The business is “running” — people are paying, the ChatGPTs of the world have real subscription revenue. But revenue is just revenue. I want to ask a simpler question: when does this business actually turn a profit? Meaning: out of all that money pouring in, is there any layer in this stack that can earn enough from end users to sustain itself, justify today’s valuations — and not just create the appearance of prosperity through round after round of investment?

The Base of the Pyramid: Chips

To see where the money actually lands, start with an honest admission: someone in this chain is making real money — right at the bottom, in the chip layer.

NVIDIA, TSMC, and the high-bandwidth memory suppliers like SK Hynix — these are the people genuinely cashing in. Their shared advantage is simple: regardless of whether infrastructure, models, or applications above them ever turn a profit, as long as this arms race keeps going, everyone has to buy their chips, their fab capacity, their memory. The chip layer is the one tier that’s reliably profitable today. NVIDIA’s gross margins are absurdly high. The HBM memory suppliers are minting money on tight supply.

But notice two things.

First, this windfall isn’t as stable as it looks. On the NVIDIA side, I covered this in the last piece: inference — the segment NVIDIA has the biggest hopes for — is being eaten from the inside by custom chips. The bar for building an inference-specific chip isn’t that high, so the largest buyers are designing their own, and new entrants keep piling in. This territory will be hard to monopolize.

On the memory side, it’s a different kind of instability. Memory is a notoriously cyclical industry. The script repeats every few years: supply gets tight, prices spike, capacity floods in, prices crash 50%, margins go negative. It’s played out this way for three decades.

Here’s the interesting part. This round, as memory makers rake in record profits, they’re all saying the same thing: this time is different — AI demand is structural, it has “ended the cycle,” and prices can stay elevated indefinitely. But every time a bubble nears its peak, the loudest chorus is always “this time is different.” Cisco was justified at more than 200x earnings with the same line: “the old rules don’t apply anymore.” An industry that has convinced itself the cycle has been abolished is usually standing right on top of one.

So the memory windfall, as I see it, is riding the cycle — not transcending it. When it turns is hard to say, but the louder “this time is different” gets, the closer the turn usually is.

The second point matters more: the chip layer’s profits don’t appear out of thin air. They’re extracted from the layers above — infrastructure buys its GPUs, models pay infrastructure rent, applications foot the bill for all of it. The harder chips squeeze, the tighter every layer above gets squeezed.

In other words, the chip layer’s profit is everyone else’s cost. So “someone is making money” doesn’t refute “this business isn’t really making money yet” — it is the problem. All the money sinks to the very bottom, and the higher you go — the closer you get to where value is supposed to originate — the worse things look. And don’t forget: trace the chip layer’s revenue all the way up, and most of it isn’t coming from end users willingly paying for an AI product. It’s coming from the tech giants’ own reserves, their venture rounds, their debt — money they’re pouring into the arms race. The one layer that’s reliably profitable is profiting from investment, not revenue.

Infrastructure: A Hole Waiting to Be Fed

One layer up from chips sits infrastructure — compute, data centers. Wall Street’s dominant narrative right now is “sell picks and shovels at the gold mine”: nobody knows which model wins, but everyone needs compute, so investing in infrastructure is a sure thing.

Infrastructure is actually the most worrying layer of all.

I mentioned in the last piece that a mining rig is a cash-burning heavy asset — power bills, depreciation, maintenance, every single day. An AI data center is the same thing, only heavier. It has to buy the most expensive GPUs from the layer below — cards that get outclassed by the next generation in two or three years and get their lifespan cut short by 24/7 full-throttle operation. Then it has to keep buying electricity. Compute’s endgame is power. Every training run and every inference call burns watts. The big players are signing multi-decade, multi-billion-dollar power purchase agreements just to lock in stable supply. GPUs, power, cooling, maintenance — all cash out the door. The GPU bill flows down to the chip layer and becomes its monopoly profit. The rest — power, cooling, maintenance — is operating cost that vanishes the moment it’s spent. Bleeding from both ends.

And infrastructure isn’t the destination. It produces compute, but someone has to use that compute and actually make money from it before infrastructure can break even. Whether it recoups its investment depends entirely on whether the models and applications running on top of it can earn enough to feed it. The problem is right here: the money feeding infrastructure today is still mostly investment from above, not revenue earned from end users.

How hungry is this hole? One number tells the story. Alphabet, Google’s parent company, had over $73 billion in free cash flow in 2025. According to analyst projections, AI infrastructure spending will drain that to roughly $8 billion in 2026. Most of the money went to buying GPUs, feeding this layer. Alphabet even started issuing bonds to fill the gap — a company that prints cash like a mint, forced to borrow because infrastructure is sucking it dry.

And even the profits that show up on infrastructure’s books are inflated. These GPUs become obsolete in two or three years, but they’re often depreciated over five or six on the balance sheet — the gap quietly turns into better-looking profits on the income statement. This isn’t speculation: over the past two years, the major tech companies have been quietly stretching the depreciation schedules for AI chips to five or six years. Did the actual useful life of the hardware change? No. But the reported profits got a boost anyway. Even Michael Burry — “The Big Short” — has publicly questioned this practice: using extended depreciation to make profits look better than they are. In other words, infrastructure isn’t just bleeding cash constantly — even the presentable numbers on its financial statements are dressed up by accounting choices.

Models and Applications: A Layer That Hasn’t Split Yet

One more layer up, we get to the large language models running on all that compute. Will this be the layer that makes sustainable money? Intuitively, it should be — this entire AI breakthrough is a breakthrough in large models.

As things stand, large models will have a hard time earning monopoly profits.

One reason is competition from Chinese models and the progress of open source. Companies like DeepSeek are producing near-frontier performance at a fraction of the cost — and open-sourcing it. Open-source models keep closing the gap on closed ones. You’re ahead this month; open source catches up by next month, and the distance keeps shrinking. When something of comparable quality is available for free, the logic of “my technology is superior, so I can charge a premium” stops working.

Models have another trait: user loyalty is extremely low. Whichever one works better this month gets the traffic. Switching costs are essentially zero. This is nothing like Facebook or social networks — you can’t leave those because everyone you know is on them. Models aren’t sticky. People use whichever is best and jump without a second thought. Anthropic briefly overtaking OpenAI is a case in point.

Look more closely and you find that the model layer isn’t just “not profitable” — it’s bleeding money at scale. Take OpenAI, the front-runner: annualized revenue for 2026 is somewhere north of $20 billion, which sounds impressive, until you see the projected $14 billion loss in the same year. For every dollar coming in, roughly 70 cents is going out the other side. Out of hundreds of millions of users, only a small fraction pay. Over 90% use it for free — and every free API call’s compute cost comes out of OpenAI’s pocket. The hole gets filled by round after round of fundraising. So the model layer works the same way as infrastructure: the money it burns is overwhelmingly investor capital, not revenue earned from end users. What it brings in from customers doesn’t cover the cost.

What about applications? At the very top of the pyramid, there should be a layer where apps make money. But try to isolate that layer today and you’ll find it barely exists. The most usable applications — ChatGPT, Claude — are built by the model companies themselves. Models and applications haven’t separated yet. Beyond those, a wave of smaller players are building image generators, voice tools, video tools — but they’re either burning cash training their own models or relying on the big players’ APIs, and they can’t get costs down. The market looks busy on the surface, but it’s miles from ordinary people’s daily lives. Most people play with it and move on. Watch the media cycle: one model drops a new version, a crowd rushes over to test it; next week another company ships a new feature, and the crowd rushes over there. Any stickiness at all? No must-have use case, no moat, all of them surviving on transfusions.

Truly independent third-party applications — ones not tethered to a big-model company — are still rare. That’s a sign the market is just getting started, nowhere near mature. A revolutionary technology breakthrough, without broad creative participation from society at large, relying on a handful of model companies tinkering by themselves — that’s not how killer apps get born.

The Assumption That Got Priced In as Fact

Connect all these layers and something interesting emerges.

The staggering valuations across the AI industry today — triple-digit P/E ratios, market caps that have priced in years of future expectations — all of them rest on a single assumption: this business will eventually earn long-term, sustainable, monopoly-level profits. Only monopoly profits can justify multiples like these.

But walk through the pyramid layer by layer. The only tier actually earning monopoly profits is chips, at the very bottom — and those profits are extracted from every layer above, while the monopoly itself is likely to be eroded by custom inference chips. One layer up, infrastructure is a hole waiting to be fed. Above that, models can’t hold a monopoly and are hemorrhaging cash. And the topmost layer, where applications are supposed to make money? It hasn’t even emerged yet.

The assumption underpinning every sky-high valuation — “this will produce long-term monopoly profits” — fails at every link. Each one is either already broken or far from proven.

Here’s a simple way to sum up the present: the market has priced in something that is far from certain, as though it were already certain.

Google makes a good illustration. Google designs its own TPUs, builds its own data centers, runs Gemini, and stuffs AI into Search and every product it has — it’s a miniature of the entire AI supply chain in one company. Can that AI supply chain feed itself? No. It still survives on the cash its old search-advertising business earns every day, constantly transfusing it into the new one.

What does that tell you? After all this money poured in, even Google hasn’t grown a single new, self-sustaining, must-have application out of AI. What about everyone else?

The truth is, for this AI business to become self-sustaining at this stage, what’s missing isn’t just money. What’s most missing is time.

For the AI industry to stand on its own, it needs the creative energy of society at large — widespread experimentation, from which a generation of killer apps can emerge and grow into genuine necessities, the kind people truly can’t live without. Only then can we say AI is a business with a future. Until that happens, AI is an infant that needs to be fed constantly.

Growth takes time. Time to bring down the cost of the technology. Time to educate and onboard the public. Time for applications to seep into daily life and habits. You can’t rush it.

But time is the one thing capital has the hardest time giving. Money can be deployed all at once. It can’t sit patiently while something grows for years.

References

Sequoia Capital, David Cahn, “AI’s $600B Question” (sustaining current capex requires ~$600B in annual revenue; December 2025 update notes end-user revenue still “tens of billions per year” while infrastructure investment is “trillions over the next five years”): https://www.sequoiacap.com/article/ais-600b-question/
CNBC: Major cloud companies’ combined 2026 capex ~$700B; Alphabet’s free cash flow projected to plunge ~90% from $73.3B (2025) to ~$8.2B; multiple bond issuances, long-term debt quadrupled in one year to $46.5B (Pivotal Research et al.): https://www.cnbc.com/2026/02/06/google-microsoft-meta-amazon-ai-cash.html
CoinDesk: Public Bitcoin miners pivoting en masse to AI data centers, $70B+ in AI/HPC contracts signed, AI projected to account for ~70% of their revenue by end of 2026: https://www.coindesk.com/markets/2026/03/27/bitcoin-miners-are-becoming-ai-companies-and-selling-their-btc-to-fund-the-transition
On cloud companies extending server/GPU depreciation from 3–4 years to 5–6 years, inflating reported profits (including Michael Burry’s criticism): https://www.cnbc.com/2025/11/14/ai-gpu-depreciation-coreweave-nvidia-michael-burry.html
Goldman Sachs on AI infrastructure spending scale and GPU depreciation schedules (“industry commonly depreciating over 4–6 years, mismatched with NVIDIA’s annual upgrade cadence”): https://www.goldmansachs.com/insights/articles/tracking-trillions-the-assumptions-shaping-scale-of-the-ai-build-out
On Google TPU, Amazon Trainium/Inferentia, Microsoft Maia, Meta MTIA and custom inference chips eroding general-purpose GPU market share: https://www.stanleylaman.com/signals-and-noise/gpus-how-long-do-they-really-last
CNBC: Memory industry’s cyclical boom-bust history (Micron et al. — prices halved, margins turning negative, stocks dropping 50–60%), current “AI has ended the memory cycle” optimism, and peak-risk indicators; top three manufacturers control ~95% of global DRAM capacity: https://www.cnbc.com/2026/05/25/memory-stocks-cyclical-boom-bust-samsung-sk-hynix.html

This article was written in June 2026. All figures are publicly available estimates as of that date; sources and methodologies vary, and numbers will change over time. Please verify against the latest primary disclosures before citing. This is personal observation and analysis, not investment advice.

NVIDIA Through a Crypto Miner's Eyes

Sun, 21 Jun 2026 15:24:00 GMT

For the past two years, watching people scramble for NVIDIA cards and the AI frenzy run hotter every quarter, I keep getting a strange flicker of recognition. I’ve seen this before. Roughly ten years ago, through my own stint as a miner, I lived the whole arc once.

I’m not here to analyze NVIDIA. I want to talk about a few things those mining years left me — and the lens they hand me for looking at the world’s most valuable company.

Up front: this is personal observation, not investment advice.

Let me start with my rigs. I’ll keep it short — it’s only the setup.

The Setup: My Mining Rigs

At the peak of the 2017 ETH mining craze, GPUs weren’t just expensive — they were gone. China was still the world’s crypto mining capital back then, and every mining-capable card got swept up domestically first. I bought over twenty cards, mostly NVIDIA, a few AMD. Some I fought for locally; others I ordered from the UK through Amazon, shipped in batches over weeks. The last batch spent a month on a cargo ship before reaching Shanghai. Once I had them all, I assembled six-card rigs, set them up in my attic, and let them hum. A big standing fan pointed at them. In summer, I ran the air conditioning too. Electricity ran several thousand RMB a month. Sometimes the house circuit couldn’t handle it — tripped the breaker more than once.

I put up with all of it because the money was genuinely good.

I stopped because of the late-2018 ETH crash. As Ethereum’s price kept falling, there came a point where what I mined couldn’t even cover the power bill. Mining rigs aren’t like stocks — if a stock drops, you can hold and wait, it costs you nothing. A mining rig burns real money every single day it’s running. The moment revenue dips below cost, your money-making asset becomes a hole that bleeds cash. So I shut them down.

I never sold a single one of those twenty-plus cards. Anyone in the GPU world knows mining cards are untouchable — running 24/7 destroys the VRAM, and nobody wants them. They sat in my attic for years until I moved house and finally scrapped them. From hunting them down across the globe to disposing of them as junk — about seven years.

That’s the setup. I dwell on it because the GPUs that ate my power bill back then were mostly NVIDIA’s — and the GPUs eating the world’s data-center power today are still NVIDIA’s. Nearly a decade apart, same protagonist; only the label changed, from “gaming” to “AI.” Those years handed me a pair of glasses: with any capital-heavy asset, ask a few questions before anything else. Below, I aim those questions at NVIDIA.

How Much of the Demand Is Real?

NVIDIA’s quarterly earnings are staggering right now — each one better than the last. But impressive earnings and real demand have never been the same thing. The mining boom taught me that.

During that scramble, how many buyers were real gamers, and how many were miners like me? This isn’t hindsight. A big slice of NVIDIA’s revenue in those years was actually mining money — booked under gaming, and counted as genuine growth in gaming demand. In 2022 the SEC found that NVIDIA had failed to tell investors mining was a “significant” reason its gaming revenue surged across several quarters of fiscal 2018, and the company settled with a fine. A class action is still grinding on, alleging more than a billion dollars in mining-related sales were buried inside “gaming.” Then the mining crash hit, that demand evaporated overnight, and the earnings were exposed for what they were: inventory piled up, the stock halved. Demand that looked bottomless had a huge chunk that could vanish in an instant — and at the time almost no one, NVIDIA included, was willing to mark it off on its own.

Today’s AI compute demand is the same setup. How much of it comes from applications that actually make money, and how much is pure arms race — “everyone else is buying, so I can’t afford not to”? On the books, both kinds look identical. You can only tell them apart after the tide goes out. And right now, a hard-to-ignore fact: end-user revenue across the entire AI industry is still in the tens of billions per year, while the big tech companies’ combined capital expenditure is heading toward $700 billion in 2026 and projected to break $1 trillion in 2027. Sequoia Capital did the math back in 2024: to justify spending at that scale, the industry needs $600 billion in annual revenue. Actual revenue is nowhere close. The enormous gap in between is held up by one thing — the not-yet-proven expectation that “AI will change the world.”

Versatility: Moat and Achilles’ Heel

When I was getting into mining, a friend advised me: buy GPUs — they’re insurance. If ETH goes south, you can mine other coins. Worst case, you can game on them. Sounded reasonable. Versatility. If one road closes, there’s always another. That’s the biggest seduction of a general-purpose tool: it makes you feel like you’ve kept a fallback open.

But crypto mining’s history drew a very precise boundary around that “fallback.”

Start with Bitcoin. BTC’s algorithm is extremely friendly to specialized chips (ASICs). Once ASICs arrived, GPUs got crushed — orders of magnitude difference. Same kilowatt-hour, but a dedicated mining machine produced hundreds to thousands of times more hashpower. GPUs were instantly unviable for BTC. Entire fleets got pushed out.

Ethereum was different. ETH’s algorithm was deliberately designed to be memory-hard — specifically to resist ASICs. Result: even when ETH-specific mining machines eventually appeared, the memory bandwidth bottleneck kept their edge over GPUs modest. Not an order-of-magnitude gap. So GPUs survived on the ETH track — barely.

Put the two threads together and you get the real origin of the 2017 ETH boom: GPU miners, driven out of Bitcoin by ASICs, poured into ETH — the one algorithm ASICs couldn’t crack. The refuge I ran into was itself a refugee crisis, made by an earlier round of “specialized crushing general-purpose.” My friend’s “you can always mine something else” did keep GPUs alive for a while — not because versatility is dependable, but because ETH’s algorithm happened to shrug ASICs off. Whether a fallback exists was never my call. It belonged to the other side’s chip, and to the algorithm.

And once specialization is proven viable in a domain, it spreads and iterates terrifyingly fast. The moment an algorithm is shown to be ASIC-able, dedicated machines flood the market. They start on cheap mature process nodes to prove the concept, then sprint toward faster, more power-efficient versions — each generation more ruthless. “It’s not strong enough yet” is never a reason for comfort. It’s weak now precisely because it just started.

Now put that lens on NVIDIA.

NVIDIA’s cards are valuable precisely because they can compute anything. But over the past two years, AI’s center of gravity has been shifting from training to inference. You train a model once; after that, it gets called for inference by hundreds of millions of users, countless times a day. The two demand curves aren’t symmetric: training compute will eventually plateau as models grow and training cadence stabilizes. Inference is different — it scales with users. More users, more calls, no ceiling. Inference will inevitably overtake training as the bulk of AI compute.

Inference is high-volume, repetitive, algorithm-fixed — exactly the scenario where specialized chips excel and general-purpose GPUs are at their weakest. So Google’s TPUs, Amazon, Microsoft, Meta — NVIDIA’s biggest customers — are all building chips purpose-built for inference.

NVIDIA currently holds roughly 85–90% of the AI chip market. But that number hides a structural detail: it’s above 90% in training, only 60–70% in inference. Multiple analysts project its overall share could fall from ~90% to ~70% within two or three years, with inference being where the ground is lost. Custom chip shipment growth this year is nearly 3x that of general-purpose GPUs. Even NVIDIA is alarmed — it recently spent $20 billion acquiring Groq’s technology and team, a company specializing in high-speed inference chips. That move alone tells you: the fattest piece of its territory is being eyed.

So the real question isn’t whether NVIDIA is versatile. It’s whether AI inference turns out to be more like BTC or more like ETH. Can specialized chips beat it by an order of magnitude and shove NVIDIA off the richest ground — or is there something about inference that lets general-purpose GPUs hold on a while longer? I don’t have the answer. What I do know is that every current trend points to custom silicon closing in on inference fast — and the part of NVIDIA’s future that carries the highest hopes is sitting right on top of inference.

The Shovel-Seller Digs for Gold

There’s a business pattern in crypto I know well: mining hardware manufacturers almost always mine themselves. They sell machines and build their own mining farms — taking profit from both sides. And they mine with structural advantages: their machines cost less because they built them; each new chip generation gets run internally first to extract the cream of profits before “last-gen” models go on sale to outside miners. Same industry, vastly different economics — not competition on a level field, but an asymmetric advantage.

NVIDIA is running the same playbook now. Only the scale and complexity dwarf anything those mining hardware companies ever attempted.

Its private equity investments went from roughly $3.4 billion a year ago to over $22 billion at the start of this year — more than a 6x increase. The money flows into AI infrastructure up and down the stack, and a significant portion goes to companies that buy its chips, or buy them indirectly through cloud providers. The loop is simple: NVIDIA invests money so these companies can afford to buy its GPUs. Those companies rent out the compute, earn revenue, service their debt, and their valuations rise — which makes NVIDIA’s equity stakes appreciate. The money goes around in a circle and comes back to NVIDIA’s pocket. Analysts have been blunt about it: these deals “fit squarely within the circular investment theme.” Jensen Huang isn’t hiding it either — at a conference this year he said NVIDIA “has truly become an infrastructure company, not just a GPU company.” The goal is to control the entire stack: networking, compute, software, data centers.

And the data center companies it invests in enjoy the same advantages as those mining hardware manufacturers who ran their own farms: they’re first in the supply queue, they get the latest generation cards, and pricing and allocation decisions sit in NVIDIA’s hands. The shovel-seller doesn’t just want to dig for gold — it digs with better shovels than anyone else can buy.

But the flip side of that advantage is risk. This entire structure is leveraged. Mining hardware companies building farms worked the same way — partnering with local operators in regions with cheap electricity, putting up machines while partners handled site, power, cooling, and connections. At the height of it, many were pledging their existing BTC — or even future BTC — as loan collateral. NVIDIA’s version: its investments lever up downstream companies’ debt, secured against future compute contracts. Add leverage, and the whole operation scales up and up.

When the market rises, leverage makes the wins spectacular — GPU sales profit on one side, equity appreciation on the other. But the other edge of the blade is always there. If those multi-billion-dollar compute contracts can’t be fulfilled on schedule, the chain unwinds bottom-up: the debt-laden companies default first, then the $22 billion in equity on NVIDIA’s books shrinks with them. In good times, leverage amplifies profits. In bad times, it amplifies destruction.

Old Players, New Table

If everything above is just “similar shapes,” there’s one thing where even the people haven’t changed.

Over the past two years, the crypto mining industry has collectively rebranded itself as AI data centers. Core Scientific, IREN, TeraWulf, Hut 8, Riot — these are all old mining names. Listed mining companies sold a record 30,000+ BTC in Q1 2026 — more than during the 2022 crash — liquidating core assets they’d been hoarding, just to fund their pivot into AI. Hut 8 said on its earnings call that Bitcoin is no longer the company’s “long-term strategic focus.”

But look closely at how they pivoted, and not all of them were pushed out by mining. A good number saw it coming early and left on their own terms — selling their crypto while prices were still high, betting that AI was worth more than mining. And their exit, in turn, pushed crypto prices down, squeezing the holdouts into selling at a loss just to survive. The early movers were shrewd. The late movers were desperate. But they all ended up at the same new table.

That rush toward whatever’s hottest — I know it too well. Every boom’s workforce comes from the last boom’s bust. This time, the bust is mining and the boom is AI. The table is new. The players are old. Even the urgency they bring is old.

And full circle: these rebranded old players end up right back in front of NVIDIA. In that circular investment loop I described earlier, the data center companies NVIDIA funds include their names — IREN and others were mining farms just yesterday. NVIDIA sells them cards on one side and invests money so they buy more cards on the other. And they are a crowd that just arrived from the last gold rush, chasing the wave. Every link in this chain radiates the same familiar heat — the same people, rushing toward the hottest thing, again.

A Pair of Glasses

I need to be clear about something, so I’m not misread: I am not bearish on AI.

Quite the opposite. I believe AI is this generation’s Industrial Revolution — call it the Information Revolution if you prefer. But that’s a completely separate matter from everything I’ve said above.

When the dot-com bubble burst in 2001, nobody could say the internet was useless. Email was in use then and is still in use today — never stopped for a single day. The internet genuinely changed the world. That didn’t stop the NASDAQ from collapsing that year, didn’t stop a wave of companies going to zero. The technology can be as real as it gets. The bubble pops anyway.

Within that bubble, one company’s story reads like a mirror today — Cisco. It sold “internet plumbing”: routers, switches, the backbone hardware of the entire internet. The narrative back then was word-for-word identical to today’s: nobody knows who wins at the application layer, but everyone has to buy Cisco. It became the world’s most valuable company then. P/E ratio above 200. Then the bubble burst, and its stock dropped nearly 90%. Note: Cisco wasn’t a fraud. It never went bankrupt. It remained profitable. Networking equipment is still essential today. But even a company that solid — its stock took twenty-five years to climb back to its 2000 peak. Meaning: even if you correctly called “the internet will change the world” and you correctly picked the hardest shovel-seller, buying at a price set by mania meant waiting a quarter century to break even.

Swap “Cisco” for “NVIDIA” and that sentence works almost unchanged. Same ecological niche — one sold network plumbing, the other sells compute. Same “nobody knows who wins, but everyone has to buy it” positioning. Same title of world’s most expensive company. I’m not saying NVIDIA is the next Cisco. History doesn’t repeat that simply. I’m saying: the Cisco mirror tells us that technology being real, the company being good, the product being essential — all three together still can’t prevent a price set by mania from spending two decades paying off.

Some will say that bubble at least left fiber optic cables in the ground, which got used later — a “good bubble.” Fair point, but it may not apply today. Even Morgan Stanley flagged the difference: fiber lasts twenty years. Today’s GPUs are obsolete in two or three. When the fiber bubble burst, the pipes stayed buried, waiting for the next wave. If these GPUs don’t earn back their cost within their lifespan, they leave nothing behind when they’re retired — just like my mining cards, which ended up sold as scrap for 2 RMB per kilogram.

That’s what those mining years really left me: a pair of glasses that lets me hold two things at once — that a thing can be real, useful, even world-changing, and at the same time be inflated by frenzy into an enormous bubble. So “AI is a genuine revolution,” however true, says nothing about whether NVIDIA’s price today makes sense. The truth of a technology and the fate of its price have always run as two separate lines.

The technology line, I can still read a bit. The price line — where it goes from here, I can’t call. I never called coin prices either; I didn’t step off at the top, the power bill pushed me off. Predicting was never my job. Setting down what I saw and what I made of it — that is.

This piece focused on NVIDIA alone. Where the profits actually land when all this money pours into AI — I follow that thread in the next one, The AI Business Through a Crypto Miner’s Eyes.

References

SEC 2022 settlement with NVIDIA for failing to disclose mining’s material impact on gaming revenue ($5.5M): https://www.sec.gov/newsroom/press-releases/2022-79
CNN reporting on the settlement (NVIDIA “omitted material information, was misleading”): https://www.cnn.com/2022/05/06/tech/nvidia-sec-settlement-crypto-mining
Sequoia Capital’s David Cahn, “AI’s $600B Question” (estimating ~$600B annual revenue needed to justify current capex; his Dec 2025 update notes end-user revenue still “tens of billions/year” vs. “trillions in infra investment over five years”): https://www.sequoiacap.com/article/ais-600b-question/
TrendForce data on custom AI chip share erosion vs. general-purpose GPU and shipment growth differential: https://www.spotedcrypto.com/hut-8-cipher-digital-ai-data-center-pivot-2026/
Morgan Stanley comparing this AI capex cycle to the telecom bubble, noting GPU depreciation (2–3 years) vs. fiber (20+ years): https://medium.com/@truthbit.ai/the-2-trillion-question-can-ai-revenue-catch-up-to-capex-df8c5c3c52fb
Ethereum’s Ethash memory-hard anti-ASIC design; BTC ASIC’s orders-of-magnitude advantage over GPUs (Wikipedia): https://en.wikipedia.org/wiki/Ethash
CNBC: NVIDIA’s private equity investments grew from ~$3.39B to ~$22.25B in one year, covering the full AI infrastructure stack including chip customers (analyst: “fits squarely within circular investment theme”; includes IREN 5GW infrastructure deal): https://www.cnbc.com/2026/05/09/nvidia-embraces-ai-investor-topping-40-billion-in-equity-bets-2026.html
Bloomberg: NVIDIA invested another $2B in CoreWeave in Jan 2026 (latest circular financing example): https://www.bloomberg.com/news/articles/2026-01-26/nvidia-invests-another-2-billion-in-coreweave-offers-new-chip
Jensen Huang at Computex 2026: “NVIDIA has truly become an infrastructure company, not just a GPU company,” emphasizing full-stack infrastructure strategy: https://finance.yahoo.com/sectors/technology/articles/nvidia-become-infrastructure-company-jensen-003249580.html

Written in June 2026. All figures are publicly available estimates at the time of writing. Different sources use different methodologies; numbers will change over time. Verify against the latest primary disclosures before citing.

Writing and Code: Same Leverage, Different Story

Fri, 19 Jun 2026 10:30:00 GMT

Naval Ravikant said it in The Almanack of Naval Ravikant: “Fortunes require leverage.” The modern divide isn’t between the rich and the poor. It’s between people who use leverage and people who don’t.

He broke leverage into four types: labor, capital, code, and media. Of these, he singled out code and media as the only two forms of permissionless leverage — the only two that don’t require anyone’s permission to use. Labor needs people willing to work for you. Capital needs you to already have money, or someone willing to give you theirs. But code and media? One person, one laptop. Once it’s built, it works for you while you sleep.

Naval’s “media” covers writing, podcasts, video — all of it. But today I want to focus on just one slice: writing, and how it compares to code as a form of leverage.

I largely agree with Naval’s framework, especially on code. I’ve made my living writing code for a long time now. I understand code leverage well: build something once, copy it at near-zero marginal cost. With web-based software, you don’t even need to distribute — people open a browser and it’s there. Software has direct utility, too. Plenty of people rarely read, but everyone uses software every day: WhatsApp, TikTok, Apple Pay, Amazon. From that angle, code has broader reach — users don’t need to want to read, they just need to use.

But lately I’ve been rethinking the comparison. The more I look at it, the more I think that as two forms of permissionless leverage, writing and code are far more different than they first appear.

What Writing Can Do

First, the nature of influence is different.

Code is a tool. A user opens an app, completes a task, closes it. Who coded it doesn’t matter. The user doesn’t know, doesn’t care, doesn’t need to. Code’s influence is functional — it changes what you can do, but it rarely changes how you think.

Writing is different. A good piece of writing demands reading, sometimes re-reading. It requires understanding, internalization. Writing enters the reader’s mind. It changes how they think.

A good essay might shift how you see something. It might open a window during a moment of confusion. It might make you smile in recognition: “Someone else thinks the way I do.” That kind of influence is cognitive. It’s a real connection between writer and reader.

A software user finishes and moves on. A reader sometimes carries an essay for life.

Second, the independence of distribution is different.

Code must live inside a complete runtime environment — operating system, dependencies, servers, databases. It can’t exist on its own. It needs infrastructure to run. That means code distribution has a high barrier: users need to install, configure, learn, sometimes need specific hardware and systems. This is partly why many developers prefer building standalone apps over web services — fewer dependencies.

Writing is different. An essay is a complete, self-contained unit. One article, one link — it can go anywhere, and anyone who opens it can read it. No screen? Print it out. Carry it in your pocket. It doesn’t need a runtime, an installation, an account, or a manual. That lightness is something code rarely achieves. Naval’s “works for you while you sleep” is purer with writing — it truly exists independently, with no preconditions.

Third, the shelf life is different.

Technology iterates fast. Code written ten years ago often can’t run today — not because anything is wrong with the code itself, but because the environment changed. The things it depends on moved too fast. I’ve seen plenty of projects like this: the code is fine, but a single deprecated dependency kills the whole system. Software has a peculiar kind of rot. It doesn’t change, but the world around it does, and that’s enough to break it.

Writing ages differently. An essay can become outdated — the data, the references, the specific context it discusses may all expire over time. But it doesn’t “break.” An essay you wrote twenty years ago still opens, still reads, still looks the same. No one needs to maintain it for it to continue existing. And the best writing doesn’t go stale at all — explorations of worldview, ways of thinking, observations about the human condition. These sometimes hit harder decades or centuries later, strengthened by the weight of time.

Paul Graham is a good example. Few people remember the software he wrote in the early days. But the essays he wrote in the same period — on startups, on thinking, on programming languages — are still circulating, still cited, still shaping each new generation of founders and engineers.

The half-life of an essay’s influence is something most software products can’t match.

Writing as a Durable Asset

Once an essay is finished, it’s a complete product.

That sounds simple, but think about it — software rarely works this way. Launching an app isn’t the end. It’s just the beginning. Then comes user feedback, bug fixes, feature iterations, version upgrades, security patches. The developer is tied to the product. As long as the product lives, the developer has to keep up. In a real sense, this is a hidden long-term liability.

Writing doesn’t have this problem. Publish it, and it’s done. Readers might comment. You can respond or not. The essay itself doesn’t need your continued investment to continue existing. That “ship it and it’s done” cleanliness is an outright luxury in software development.

There’s another difference. When a user uses an app, they experience the product, not the person. But when someone reads an essay, they experience the writer — how they think, what they’ve seen, where they’ve been. The author’s voice, judgment, even personality live in the words. Writing is a bridge between reader and writer. It builds something code never can: a relationship between people, not just between a person and a tool.

Finally, there’s the meaning of recording.

I once wrote on my About page: what isn’t recorded ceases to exist. In the context of code versus writing, that line takes on a specific meaning.

Code records functionality — a solution to a problem. It’s useful, but it captures “how it was done,” not “who I am.” Writing records the person — my judgment at a particular point in time, the path I walked, what I saw, how I thought, my doubts and realizations. Over time, this accumulates into an archive that belongs only to you. Your own history.

AI Is Changing the Comparison

One more thing has been shifting in the last couple of years: the impact of AI.

AI’s ability to write code is improving fast. Describe a feature clearly, and AI builds it — faster, better, every month. Code as leverage is becoming less scarce. That doesn’t mean code is unimportant. It means “being able to write code,” as a personal competitive edge, is diluting. When AI can produce code faster and better than most of us, where does my leverage as a coder come from?

Writing is different. AI writing capabilities are also advancing rapidly, but there’s a fundamental distinction: AI-generated writing can be mass-produced, but it has no real experience, no authentic voice, no perspective that belongs to one specific person. AI can produce fluent, well-structured articles. But it can’t write “It started around 1999, writing weekly columns on internet marketing for a newspaper. I remember always procrastinating until the last minute” — or capture the texture behind that kind of detail.

In an era flooded with AI-generated content, writing with real experience and an authentic voice is becoming scarcer. Which means it’s becoming more valuable.

That’s roughly everything I can think of right now about how code and writing differ as leverage. I’ve been emphasizing writing’s strengths here, mostly because I come from the code side — I’ve written code for a living for years, and while I’ve occasionally jotted things down along the way, I’d never really stopped to think about how these two forms of leverage actually compare. This is a small summary of that recent reflection.

One thing I want to emphasize: code and writing are absolutely the two forms of permissionless leverage of our era. Whenever possible, we should make full use of both.

And to my fellow developers: whenever you get the chance, write things down. Because one day you’ll realize that your essays outlasted your code.

Notes

Thanks to everyone who read and left a comment — you’ve kept this piece growing. I’ll record some of the discussion that followed here.

2026-06-19, from V2EX user canyue7897 (comment)

He raised an angle I hadn’t considered. With code, he pointed out, you just need the interface defined — whatever happens inside, even if the AI produces garbage, it’ll probably still run. The compiler has your back. Writing has no such safety net. It demands logical coherence from start to finish, and the moment it breaks down or drifts off course, a reader can see it instantly.

That got me to a more fundamental difference. Code chases correctness. It converges — give the same function to a hundred people and they’ll write roughly the same thing, all drifting toward the same optimal solution. So code can be “correct without personality.”

Writing chases the opposite. It diverges — give the same topic to a hundred people and you get a hundred different pieces. The personality and the logic are the value. Strip them out and nothing’s left.

He made another point that hit home: a bad essay, you can spot in a glance. Bad code, as long as it runs, can fake its way through for now. A bad essay can’t — the moment the logic rings hollow or the feeling rings false, the reader feels it. Writing can’t hide how much thought went into it. It can’t bluff.

Code can fall back on being correct without personality. Writing can’t. Which is probably why AI keeps getting smoother at mass-producing code, while writing with a real human behind it only gets harder for AI to replace.

AI Is Killing Jobs — and Creating New Ones

Tue, 16 Jun 2026 20:30:00 GMT

Over the past two years, layoff headlines from Big Tech have been relentless. Meta, Google, Amazon — the reason is always the same: AI. But while AI is eliminating jobs, it’s also generating demand for entirely new roles.

It’s not just coders. Copywriters, translators, image editors, audio engineers, video producers — any information-processing job that can be broken into clear steps is getting automated fast.

The flip side: AI lets one person do the work of an entire team, and that’s causing demand for information products to explode. A promo video that used to take a month now ships in a week — three of them. Output goes up, demand follows. The result is that people who can actually use AI are in short supply.

The shift isn’t “jobs are disappearing.” It’s “jobs are changing shape.” New roles aren’t organized by skill — writer, designer, editor — they’re organized by problem. Can you use AI to take this thing from start to finish?

A few days ago I got an alumni email from Per Scholas about a program called Claude Corps. It caught my attention — this is exactly what these new roles look like in practice.

What Is Claude Corps?

A 12-month, fully paid fellowship that places young people inside nonprofits across the US for a year, helping these organizations actually adopt AI.

The program is backed by Anthropic — the company behind Claude — with $150 million in funding. On the same day the program launched, Anthropic CEO Dario Amodei published Policy on the AI Exponential, acknowledging that AI could cause mass job displacement and calling for AI companies to be taxed to fund universal basic income. Acknowledging the problem and investing real money to create new opportunities at the same time — that’s an interesting combination.

Three organizations run it together: Anthropic provides funding and technology, CodePath (a nonprofit focused on tech education) handles recruiting, training, and employment, and Social Finance manages the program.

The compensation is solid: $85,000/year, full medical, dental, and vision insurance, 401(k), paid time off, and up to $2,500 in Claude API credits. These are full-time employees, not interns.

Who Can Apply?

18 or older
Less than two years of full-time work experience (hard requirement)
US work authorization (no visa sponsorship; F-1 OPT does not qualify)
Already using AI tools day-to-day
Has taken real action for a community or cause
Willing to relocate as needed (relocation assistance provided)

The key point: no coding background required, no college degree required. They’re looking for young people who actually use AI, learn fast, communicate well, and care about social issues.

What Do You Do? What Do You Learn?

Fellows work full-time inside nonprofits for a year, across areas like education, public health, refugee services, food security, community development, and environmental protection. The specific project depends on the organization, but the core mission is the same: use AI to solve real problems — building automation workflows, developing internal tools, creating data dashboards, and helping staff understand and adopt AI.

In short, it’s a joint training program where Anthropic funds and supports young people working on real projects inside real organizations.

Training starts before day one: applicants complete two Anthropic online courses (AI Fluency + Claude 101). The first week is an in-person bootcamp in San Francisco. Throughout the fellowship, there’s about five hours of structured training per week. Fellows have an Anthropic technical contact and a CodePath mentor the entire time.

After a year, you walk away with: hands-on AI project experience, a deliverable you owned end-to-end, Anthropic’s name on your resume, and a nationwide network of fellow alumni.

Application Process

Submit an online application with two short-answer questions
Complete two Anthropic online courses (AI Fluency + Claude 101)
After passing initial review, complete a take-home skills assessment
25-minute team interview
Two final-round interviews
Interview with 2–3 host organizations for mutual matching

Timeline and Locations

Cohort 1 plans to enroll about 100 fellows, starting October 19, 2026. Application deadline: July 17, 2026. The full program will run three cohorts totaling 1,000 fellows, with subsequent cohorts starting in January and August 2027.

Confirmed host organizations span the country: Chicago (Braven), New York (International Rescue Committee), Oakland (Code for America), Boston (Year Up United), and more. Cohort 1 is fully in-person. Later cohorts will offer hybrid and remote options.

Apply here: https://www.anthropic.com/claude-corps

Other Opportunities Like This

Claude Corps isn’t an isolated case. The AI era is producing more programs like it:

Bolder Futures Fellowship: Sponsored by Micron. Fully remote, 12 weeks, paid. Apply AI skills to nonprofit projects. Deadline: June 30, 2026. Learn more
Anthropic Fellows Program: Anthropic’s own 4-month, fully funded research fellowship focused on AI safety, governance, and ML research. For applicants with a research background. Rolling admissions. Learn more
Cambridge ERA:AI Research Fellowship: Based in Cambridge, UK. 10 weeks, fully funded (including housing and meals). Focused on AI safety and governance research. Starts July 6, 2026. Learn more

AI is replacing some jobs, but it’s also creating new demand. People who can put AI to real use will only become more valuable in the years ahead. Claude Corps is a structured starting point with real support and real projects — opportunities like this are rare.

If you qualify, give it a serious look.

Keep learning AI, keep using it on real work — more opportunities like this are coming.

From Smart Cards to AI Agents: Why I Built ASys

Sun, 07 Jun 2026 23:23:00 GMT

ASys (Agentic System Interface) is an open-source system interface protocol designed specifically for AI Agents — binary instructions instead of text commands, persistent connections instead of per-request handshakes, instruction-level permissions instead of broad session-level access. This is where it came from and why it’s built the way it is.

Last year, using Claude to help write code felt like working with an intern with terrible memory. Context would drift as conversations grew longer. Restarting a session meant spending several rounds just getting back to where we were. Interfaces we’d agreed on earlier would be forgotten later.

Early this year I tried again. I used Claude Code to build ReCall — a PySide6 desktop flashcard app with config, UI, database, i18n, a theme system, tests, and Windows packaging. Not huge in scope, but it covered everything a real desktop app needs. The experience was completely different. I was still driving, but Claude could keep up. I’d say what needed doing, and it understood accurately. The code mostly worked. When it went off track, a correction pulled it back fast.

The progress between those two experiences was obvious.

Looking back, the domains where LLMs have actually shipped: text and code. Both share something: they’re tasks with a finish line — write an article, ship a feature, done. Operations is different. Once a system is live, it’s real-time, stateful, and problems arrive without warning. There’s no “done.” It’s a different world entirely.

I was studying for CompTIA A+ Core 2 at the time — reviewing during the day, writing code at night. One question kept turning over in my head: AI assistance for development is maturing fast. What about ops?

When the Operator Becomes an AI

Once AI accelerates development to an exponential pace, the accumulation of running systems accelerates with it. Every new service deployed is something that needs maintaining — indefinitely. Systems don’t disappear. Problems pile up. Complexity compounds. Think of it this way: all running systems together form a large lake; all systems under development are rivers flowing into it. As more rivers flow faster, the lake grows faster than anyone expects.

But human ops scales linearly. One engineer can only maintain so many systems, no matter the tooling. Human ops can’t keep up with exponential accumulation. Looking ahead, only AI ops can take that on.

For AI ops to work, though, one prerequisite needs solving: the interface.

From POSIX to SSH, from Ansible to Kubernetes Operators — these tools are battle-tested, widely deployed, and will keep running for years. But every one of them was designed with a human operator in mind. When the operator becomes an AI Agent, several things are worth rethinking from scratch: text parsing fails whenever output format changes; session-level permissions carry serious risk for Agents that can hallucinate; frequent sampling makes per-connection handshakes a real bottleneck.

Take the cost of “guessing text.” An Agent running ps aux | grep nginx over SSH gets back free-form text — format varies by OS, locale, and tool version. The Agent has to parse it, and every regex that might break is a potential hallucination entry point. Call ASys’s SYS_PROCS instead, and you get a fixed 44-byte binary frame: process count, top-5 PIDs, CPU%, memory%, status flags. Typed, unambiguous, identical on every node. Parsing is one line of struct.unpack. This isn’t just a performance gain. It’s a reliability improvement of a different order. When parsing overhead approaches zero, the Agent can spend nearly all its compute on what actually matters: perception, reasoning, decision.

ASys isn’t trying to replace any of these tools. It’s exploring one question: if you designed an interface specifically for Agents, from first principles, what would it look like? One more option, that’s all.

Open source: github.com/vincentping/asys

Where ASys Came From

From 2010 to 2016, I worked as a developer at a smart card company in Shanghai — SIM cards, bank cards, ID chip cards. The industry had one iron rule: once a card ships, you can’t take it back.

Smart card development meant writing the spec first, implementing against the spec, testing against the spec: functional tests, failure tests, edge case coverage. After internal testing came on-site testing at the telecom operator. Tedious, long-cycle, no shortcuts. Because if you found a bug after mass production, the recall cost was catastrophic. That’s a completely different philosophy from the move-fast-and-iterate approach of internet development. The deepest thing those six years left me wasn’t any particular technology. It was an instinct: thinking it through and writing it down matters more than starting fast.

Those six years also made me fluent in protocols. Especially ISO/IEC 7816 — the APDU system for smart card communication. A card reader sends binary instructions to a smart card and gets back a fixed-format response, never parsed by human eyes. 0x9000 means success. 0x6982 means security status not satisfied. Unchanged for decades. This protocol runs on tens of billions of devices — every bank chip card, every e-passport, every SIM card. Every edge case has been validated in the hardest production conditions possible.

After 2016, I left smart cards and spent the next ten years building web systems of all shapes — frontend JS, backend Python/Go/Java, databases, servers, caches, clouds, various architectures.

The past year I’ve been deep in AI, building projects with Claude. The more I understand it, the more convinced I am: AI will reshape humanity the way the Industrial Revolution did. After finishing ReCall, I kept asking myself what to build next that was actually AI-related.

One night in late February — studying late, just lay down, half-asleep — APDU from 7816 flashed into my head. Those elegantly simple binary instructions, fixed-format responses. I sat straight up. Why not use APDU-style communication between Agents and servers? Why keep human-readable text in the middle at all?

That same night I re-read the 7816 spec, wrote a rough document, got the initial idea down.

Six years in smart cards, ten years in web systems, one-plus years in AI — take away any one of those, and that half-asleep connection doesn’t happen. Most of my old smart card colleagues are still in embedded systems. My web friends rarely have a background in low-level protocol design. Maybe this is what people mean when they say diversity drives emergence. Once the idea showed up, not trying it felt like a waste.

Three Months, Zero to Open Source

Early March — A+ Core 2 still not done — I started anyway.

Old habit from smart card days: write the docs first. Interface design philosophy, instruction set encoding, security model, frame format — think each piece through, write it up, realize mid-writing that I hadn’t thought it through, go back. March 16, v0.1 docs done. Same day, first PoC running between a Windows machine and a RHEL server: SYS_HELLO instruction, response 0x9000 OK.

After the exam, progress accelerated. Docs and code alternated. Write code, find a design problem, go fix the spec, continue. Not throwing things away and starting over — just continuous refinement.

A few decisions in this process each took time to work through.

Transport: Why Not mTLS

Transport layer was the first thing that stopped me. Instinct said mTLS — common, widely used, easy to debug. But the more I thought about it, the more wrong it felt.

asyd is ASys’s server-side daemon. One of its core use cases is staying reachable during OOM events, full disks, exactly the moments you need it most. If it goes silent because a certificate expired or the CA is unreachable at that moment — an interface that fails during emergencies is more dangerous than no interface at all. And OpenSSL is a heavyweight dependency. That directly conflicts with the zero-external-dependencies design goal.

I went with Noise Protocol IK, implemented on Monocypher. Pure cryptographic primitives, no certificate dependencies, roughly 2,000 lines of C, fully auditable, 1-RTT handshake. This choice lets asyd ship as a single static binary. Deploy it on any POSIX environment with no runtime risk.

Permission Model: Making Unauthorized Things Not Exist

The permission model took longer. The intuitive answer was an ACL table — configure which Agent can do what. Simple-looking, but not enough.

Traditional security models (SSH, sudo) were designed for human operators. Human actions are exploratory; intent is hard to declare upfront. “Broad default permissions plus negative interception” fits how humans work. When the operator is an AI Agent, that assumption breaks. Agent behavior is programmatic. Permission boundaries can be declared precisely at deployment time.

So ASys flips it. The system is dark to an Agent by default. Only instructions explicitly lit up in the Capability Map “physically exist.” An unauthorized operation isn’t “you don’t have permission” — it’s “this instruction doesn’t exist in your world.” Unregistered instructions are dropped at the decode stage and never enter any execution path.

Using a bitmap has an additional benefit: side-channel resistance. If you check permissions before checking existence, an attacker can infer which instructions “exist but are disabled” through tiny timing differences in responses. The Capability Map forces existence-check first. All unauthorized operations produce identical response timing. No information leakage surface.

Least privilege isn’t a configuration option. It’s a physical property of the protocol.

Instruction Set: How to Organize 256 Slots

The instruction set structure came together faster, because there was an obvious reference: APDU.

Frame format borrowed directly: [CLA][INS][P1][P2][Lc][Data][Le]. The high nibble of the INS byte serves as a logical page index — 0x00–0x0F is Core ISA, the baseline observation instructions, permanently locked; 0x20–0x8F is Standard ISA, seven functional groups; 0xC0–0xFF is Vendor Extensions, open for domain-specific customization.

Any developer reading an instruction code knows the group at a glance. 0x2x is Process Control, no table lookup needed.

More important is the semantic lock on Core ISA: once a core instruction ships, byte offsets never change. New fields can only be appended at the end. Agent parsing code written today is expected to work on some POSIX-compatible system fifty years from now. APDU covers tens of billions of devices precisely because of this long-termism. That’s what ASys is trying to inherit.

Closing the OODA Loop

Late May, I ran a complete OODA loop demo on RHEL. The RHEL server ran a CPU hog to trigger a load spike. A Python client on Windows called SYS_STATUS to detect the anomaly, SYS_PROCS to locate the process, PROC_THROTTLE to suppress it, then SYS_STATUS again to confirm recovery. All 0x9000 throughout.

That moment didn’t feel like “it works.” It felt like “proof of concept confirmed.”

May 27, v0.3.0 released. Three months from idea to open source.

Where Things Stand

github.com/vincentping/asys is now at v0.3.1.

Stable today: Core ISA’s four observation instructions (SYS_CAPS / SYS_HELLO / SYS_STATUS / SYS_PROCS), the first batch of Standard ISA control instructions (PROC_THROTTLE / SVC_RESTART / TASK_QUERY), a complete Noise IK encrypted channel, public key whitelist authentication, and Epoch_ID replay protection.

The most important next piece is the Python SDK — targeting AI Agent developers, designed to drop into LangChain, AutoGen, and similar frameworks. The core design principle: Agents never touch the byte layer directly. They call structured interfaces (sdk.proc_throttle(pid=1234, action="stop")); the SDK handles parameter validation and binary compilation. LLMs are inherently bad at byte offsets. Having an Agent assemble raw APDU parameters is the wrong abstraction.

Still planned but not yet implemented: per-Agent fine-grained Capability Maps, an audit black box, chained transport. All in the spec. All coming.

Honest Thoughts

Building a protocol solo sounds a little crazy.

Protocols are usually a committee job — they need multi-party consensus, large bodies of real-world input, exhaustive edge case analysis. But the idea showed up. So I tried. Working alone means decisions move fast. It also means no external pressure forces you to think every corner through. My response has been the same as in smart card days: docs before code. White paper, protocol spec, design notes, implementation notes — these took more time than the code itself. Because writing is the best thinking tool I have. If I can’t write it clearly, I don’t actually understand it. If I don’t understand it, the code will collapse eventually.

ASys is an exploratory project. It’s not a replacement for SSH, not a competitor to Ansible. The gap it’s trying to fill: when an Agent needs to manipulate a system at high frequency, low latency, and with full auditability — while staying reachable in extreme conditions — there’s currently no purpose-built standard for that. Wrapping an LLM around SSH and calling it AI ops doesn’t solve the underlying problem.

Whether that’s worth solving is for others to judge. But I think as Agents move further into production systems, the question “what should the interface between an Agent and a system actually look like?” deserves serious attention.

If ASys starts that conversation, that’s enough.

One last note: ASys listens on port 7816 by default. A deliberate tribute to ISO/IEC 7816 — the standard number for smart card communication protocols. Every time I see that number, I’m back in front of a stack of specs from a decade ago: 7816, 14443, EMV, PBOC, UICC, RSA. The years I spent with my face in those pages.

Grant in Lincoln Park

Fri, 05 Jun 2026 22:55:00 GMT

Lincoln Park, Chicago skyline beyond.

There were once more than thirty thousand bodies buried in Lincoln Park.

This is not a metaphor. Before the 1850s, this stretch of lakefront green was Chicago’s municipal cemetery. The city expanded. The government decided to move the dead and return the land to the living. Most of the remains were relocated — but no one could guarantee the job was finished. The lawn where joggers run today, where families spread their blankets, where children chase squirrels — beneath it, some nineteenth-century Chicagoans may still be sleeping. Names unknown. The removal orders never found them.

Lincoln was assassinated in 1865, and the park was renamed in his honor. Death and commemoration. This place never pretended that life was light.

I came today specifically to see the Grant statue. I’d been cooped up for days wrestling with Claude Code — when it’s cooperative, it makes you want to write code forever; when it isn’t, it’s a wall you can’t get through. After enough of that, a statue seemed like a reasonable destination.

General Ulysses Grant — who would become president — died in July 1885. In his final months he raced his throat cancer, driving himself to finish his memoirs, hoping to leave his wife some royalty money. Mark Twain published them, and the contract became one of the most lucrative in American publishing history. Grant didn’t live to see the check. Four days after he died, New York held his funeral. A million people lined the streets.

Chicago decided to build him a monument. Within a month of the announcement, tens of thousands of dollars had come in from every corner of the city, from nearly one hundred thousand donors. When the statue was unveiled in 1891, roughly two hundred thousand people were there. Chicago’s total population was just over a million. One in five.

I stood in front of the statue and looked up at how Grant sat his horse. No triumphant gesture. No arm sweeping toward the horizon. The horse’s front hooves stayed on the ground. He simply sat there, expression composed, like a man who had nothing left to prove.

The year after the statue was completed — 1892 — lightning struck. It hit near the arch at the base. Three people sheltering there were killed instantly. The bronze was untouched.

I don’t know what to do with that detail. But it stays with me.

Grant Statue

There is another structure in the park worth mentioning, though most visitors walk past it without a second glance. The Carlson Cottage, built in 1888, was originally a public restroom — segregated by sex, brick and stone, designed by the architect Joseph Lyman Silsbee. Silsbee’s office once employed a young apprentice named Frank Lloyd Wright, who went on to become one of the most consequential architects of the twentieth century.

A public toilet. From the office that shaped a century of building.

In 2008, the federal government funded the cottage’s restoration through the Save America’s Treasures program. Bureaucracies occasionally do surprising things — they decided to restore an 1888 outhouse because it was history. That logic, I accept.

But once restored, it was no longer used as a restroom. It became an event space, and most days it sits quietly locked. The history was preserved; the function died. It’s a strange outcome — like maintaining a body in perfect condition after removing everything it was ever for.

Carlson Cottage

In 2020, Mayor Lori Lightfoot, amid a nationwide reckoning with public monuments, formed the Chicago Monuments Project. The proximate cause was the Columbus statue — toppled by protesters, or quietly removed by the city before protesters could topple it, depending on which account you read. The committee’s mandate was to review the city’s monuments and public art: what should stay, what should go, whose stories had been left out of the official memory.

There is nothing inherently wrong with this. A city periodically examining what it has chosen to memorialize is ordinary civic practice. Public monuments are not neutral. Each one is a decision, made by a particular group of people in a particular era, telling everyone who passes: this person, this event, deserves to be remembered.

Grant’s statue was on the review list.

The argument against him: he had signed policies that were unjust to Native Americans, and the westward expansion of his presidency brought forced removal and cultural destruction to tribal nations. These are facts.

But Grant was also the Union general who defeated the Confederacy — the man whose military pressure compelled Lee’s surrender at Appomattox, the moment slavery’s military defense collapsed. During Reconstruction, he was among the rare presidents who genuinely tried to protect the civil rights of Black Americans, deploying federal force against the Ku Klux Klan. The memoirs he finished while racing toward death were later called by Hemingway the best account of war he had ever read.

One person can be both of these things at once: an instrument of one justice, and an agent of another injustice.

I have no objection to the Monuments Project’s existence. Scrutinizing history is not the same as erasing it. But I’ve always had a fundamental skepticism toward the logic that removing a bronze statue can repair a historical wound.

The thirty thousand bodies once buried under Lincoln Park did not change their position when the park changed its name. Removing a monument does not remove history. Sometimes it only creates a feeling of cleanliness — the problem seems handled, when really it has simply moved out of sight.

The Grant statue was ultimately not removed. The report recommended keeping it, with an interpretive panel added to provide fuller historical context. That seems like the right call, or close enough to it — not because it satisfies everyone, but because it acknowledges that historical complexity cannot be resolved by a piece of bronze, or by taking a piece of bronze away. For what it’s worth, I walked around the base of that arch today, all the way around, and found no interpretive panel. Perhaps it’s still being made.

I sat near the statue for a long time. Wind off Lake Michigan. A man walking his dog. Kids on bikes. In the distance, by the smaller pond, someone was getting married. Laughter carried over.

Grant sat on his horse, Lake Michigan to his left, facing the city to the south. Some say the orientation is deliberate — the general keeping watch over the former Confederacy, a symbol of union and victory. But the expression I described earlier as composed — I want to change that word now. It’s the tiredness of someone who has seen too much. Not a defeated tiredness, but the kind that no longer needs to explain itself to anyone.

The lightning of 1892 killed three people. It didn’t touch him.

I don’t know what that means. But when something a city built in one month with money from a hundred thousand people is still standing a hundred and thirty years later — I’m willing to sit beside it a while longer.

There may still be some nineteenth-century Chicagoans underfoot who were never moved. That doesn’t seem like a bad arrangement.

The dead and the bronze are more patient than we tend to think.

Plywood Over Bed Slats: A Better Alternative to Bunkie Boards

Mon, 01 Jun 2026 11:40:00 GMT

I needed a new bed after moving.

For the frame, I ordered a King Size solid wood bed frame with storage drawers from Bob’s Discount Furniture.

The mattress came from Wayfair — a Simmons Beautyrest Silver BRS900, Extra Firm, with individually pocketed coil springs. Fun fact: the Simmons brand name is the origin of “席梦思” (Xí Mèng Sī), the generic term Chinese consumers use for spring mattresses.

I like a firm feel — solid, supportive under the back, no sinking when you roll over. Extra Firm was exactly what I was after.

When the delivery crew from Bob’s brought the frame in, both white-glove installers said the same thing unprompted: “This bed is really heavy.” Once it was set up, I could confirm — solid and sturdy.

But the slats on top of the frame were spaced too far apart. I measured: each slat was 2.5 inches wide and 0.6 inches thick, with gaps of nearly 3.5 inches between them.

Putting the mattress directly on that wasn’t going to work. A pocketed coil mattress has each spring individually wrapped in fabric — there’s no interconnecting steel wire forming a grid. Based on the spring count for my model, each coil pocket is roughly 2.1 inches in diameter. With gaps that wide, every spring would be affected:

Springs sitting directly over a gap lose their support entirely, sag downward, and stop doing their job.
Springs partially over a gap bear uneven loads and are prone to twisting out of shape.
Even springs that land squarely on a slat end up carrying disproportionate weight, causing them to wear out and lose tension faster.

This doesn’t just mean an uneven sleeping surface and internal damage over time — Simmons will also void the warranty outright if the gap exceeds 2 inches. Their official Warranty Instructions are explicit: gaps between slats must not exceed 2 inches.

So what to do?

American Beds vs. Chinese Beds

Back in China, mattress support was never something I thought about.

Beds there were simple: a frame with a solid wood board on top, a cotton mattress pad, a sheet, done. I also slept on palm fiber mattresses for a while — rock hard. The elders always said that was good for your bones and spine. These days everyone uses mattresses, but the solid board base is still standard. Support was never a problem; it never crossed anyone’s mind.

Coming to America, I found things work completely differently. The standard American bed has three layers: frame + Box Spring + mattress.

The frame itself is just a border with legs and a few sparse slats running across.

Because that alone can’t support a mattress properly, a Box Spring goes in between. Originally, a box spring was literally a box filled with springs — essentially a simple spring mattress in a box shape, designed to add bounce and raise the overall bed height. Today, nearly all box springs have no springs at all. They’ve been replaced by a layer of closely spaced slats on top of a wooden frame, wrapped in the familiar knit fabric — but still built in the same boxy shape.

That’s why American beds tend to sit so high — raising the height was part of the box spring’s original purpose.

The Options

So what were my choices?

Box Spring — ruled out

My first thought was to just add a box spring. But the slats inside modern box springs are spaced roughly 2–3 inches apart as well, so adding one would accomplish nothing.

Bunkie Board — ruled out

I asked an AI for suggestions, and it recommended a Bunkie Board.

After researching extensively, I could see the idea: it’s designed to go between the frame and mattress to solve exactly this kind of support problem. But after looking at a lot of products on the market, I wasn’t convinced.

Bunkie boards come in two types. The first uses internal slats with a fabric cover — the slats are a bit closer together (1–2 inches), slightly better than the bed frame, but still gapped. The second type uses a solid panel inside with a fabric cover.

The solid panel type sounds right, but on closer inspection the materials are almost universally particleboard or MDF — both prone to off-gassing, moisture warping, and a lifespan of only 5–10 years.

Foundation — ruled out

The AI also suggested a foundation. Looking at what’s actually sold, a foundation is essentially the same thing as a modern springless box spring: same height, fabric-wrapped exterior, wooden frame inside, no springs, slats spaced about 1–2 inches apart — and priced at $200–$400. Pass.

Adding more slats — ruled out

This was the DIY angle: add more slats between the existing ones to bring the spacing down to 1–2 inches. Theoretically workable, but a King Size frame has an interior width of 76 inches, which isn’t a standard dimension, so the slats would need custom cutting. Then each one would have to be installed and spaced evenly. More effort than it’s worth, with too much room for error.

The actual solution: plywood

Cut a few sheets of plywood to the bed’s dimensions, lay them flat on the existing slats, put the mattress on top. Solid, 100% even support. It’s the same logic as the traditional Chinese bed board — just a different material.

At Home Depot — What to Say

I went to the Home Depot on North Ave in Chicago. Weekdays between 10am and 2pm are the best time — the cutting station is least busy and wait times are short.

I picked up two sheets of SANDEPLY 12mm Sande Plywood, 1/2 in. x 4 ft. x 8 ft., sanded surface finish, at $53.73 each. Two sheets for a King Size comes to $107.46. Home Depot cuts for free. I also grabbed a roll of black Duct Tape to hold the panels together.

My frame has 13 slats spaced fairly evenly, and with a 3.5-inch span between them, 1/2-inch plywood is thick enough — no sagging.

Load the sheets onto a flat cart and wheel them to the cutting station. Here’s what to say:

Please cut these TWO 4x8 sheets into FOUR pieces total. Each piece should be 38 inches by 40 inches. Please account for the kerf so the final combined width equals 76 inches. Discard the remaining scraps.

One important detail: always ask them to account for the kerf. The saw blade itself has thickness — each cut removes about 1/8 inch of material. If you ignore this, the two panels won’t quite add up to 76 inches when placed side by side. Let the staff handle the math; they do this all day and will get it right.

A King Size is 76 × 80 inches. Two 4×8 sheets, each cut into two 38×40-inch pieces, gives you four panels total.

Transport and Installation

The reason to cut into four pieces rather than two 38×80-inch panels is simple: my car isn’t big enough for an 80-inch panel. With four pieces, I folded down the rear seats and stacked them flat in the back. Each panel is 38×40 inches — about a meter long — so nothing pushed against the front passenger seat or blocked the right mirror. Perfectly manageable. If you have a pickup truck, two panels are enough.

Pad the edges with an old blanket to avoid scratching the car’s interior trim.

Back home, I rinsed the panels off and left them outside to air out for a bit — plywood does have a smell.

Installation was fast: starting from the headboard, lay all four panels flat, working toward the foot. They’ll naturally leave about a 1-inch gap around the perimeter, which is actually good for airflow. Run Duct Tape over the cross-shaped seam in the center to keep the panels from shifting.

When the mattress arrived, I set it straight on top.

How It Feels

Rock solid.

The Extra Firm feel comes through completely — no localized sinking anywhere. Rolling over, getting up, the entire surface holds. Two people sleeping doesn’t affect the other side at all.

Exactly what I wanted.

On airflow: a solid panel does restrict circulation underneath compared to slats, but the bed frame is open on all four sides, so air can come in from the edges. If you live somewhere humid or tend to sleep hot, drill 1/2-inch holes every 6 inches across the panels — airflow improves dramatically with almost no effect on structural rigidity.

Final Thoughts

Bunkie boards and foundations are, at their core, fabric-wrapped thin panels or slat assemblies. You’re paying for the packaging. Plywood is thicker, stronger, more durable, and costs less than half the price. If your bed is a platform frame that was never designed for a box spring, this is the most practical solution I’ve found.

Cost comparison: Bunkie Board $100–$300, Foundation $200–$400, two sheets of Sande Plywood $108, Home Depot cutting free.

None of this is a new idea. It’s just the logic of the traditional Chinese bed board, applied in America. Went the long way around, and ended up back at a solid surface.

WSL2 Under the Hood: One VM, One File, One IP That Never Stays the Same

Fri, 27 Feb 2026 22:10:00 GMT

The previous article “Install Linux on Windows 11 in 5 Minutes” covered how to install WSL2 and get it running. Once you’ve had it going for a while, the quirks start to show.

You delete a bunch of files inside Linux — Windows disk space doesn’t move. You try to access Windows files from inside WSL2 — painfully slow. A network script that worked fine yesterday stops connecting after a wsl --shutdown.

None of this is a bug. It all comes directly from how WSL2 is designed under the hood. Once you understand the key design decisions, these problems become easy to diagnose.

What Kind of VM Is It, Exactly?

There are two types of hypervisors. Type 1 (Bare Metal) runs directly on hardware and hosts multiple operating systems — no host OS in between. Type 2 runs on top of an existing OS, like VirtualBox or VMware on your Windows desktop.

Type 1 is more efficient, suited for data center servers. Type 2 is more flexible, better for developer workstations.

So where does WSL2 fit?

At first glance, it looks like Type 2 — Linux is running inside Windows, it can’t run standalone, and we’re using it on a client machine. But the performance is surprisingly good, almost like running on bare metal.

The reality is it’s neither. Or rather, it has the efficiency of Type 1 and the flexibility of Type 2.

WSL2 runs a real Linux kernel inside Windows.

But this “VM” isn’t like VirtualBox or VMware. It’s called a Utility VM, running on Microsoft’s own Hyper-V Hypervisor.

A regular VM has to simulate an entire hardware stack: motherboard, BIOS, GPU drivers, storage controllers — all of it. WSL2’s Utility VM skips all of that:

No BIOS emulation
No virtual hardware drivers
No fixed memory reservation

It only exposes what the Linux kernel actually needs: CPU time, memory pages, and I/O channels. The result is fast startup and near-zero memory use when idle.

If we had to put a label on it: Type 1.5 — Hyper-V underneath, but far lighter than a traditional VM.

One thing worth clarifying: Hyper-V actually has two layers. The first is the Hypervisor itself, loaded directly by the Windows 11 bootloader at startup — it runs below the OS at Type 1 level, and it’s always on. That’s the layer WSL2 uses. The second layer is the Hyper-V management services — the “Hyper-V xxx” entries you see in services.msc. Those are for Hyper-V Manager and traditional VM management. WSL2 doesn’t use them at all, so it’s completely normal for those services to be stopped.

From WSL1 to WSL2: Why the Design Changed

Why is WSL2 designed this way? We need to look back at the history — starting with how WSL1 worked and where it broke down.

WSL1, released in August 2016, was built around syscall translation: when you ran ls or make inside it, WSL1 intercepted those Linux kernel calls and translated them into Windows API calls in real time. Clever idea — but it fell apart under real workloads.

Problem 1: Translation itself has a cost. Every syscall — reading a file, spawning a process, checking permissions — goes through three steps: intercept, translate, execute. This isn’t something that happens occasionally. A running program can trigger thousands of syscalls per second. The overhead adds up fast.

Problem 2: The file systems are fundamentally incompatible. Linux uses ext4, built around inodes. Windows uses NTFS, with a completely different permission model. WSL1 had to do real-time mapping between the two — but Linux concepts like symlinks, permission bits, and case-sensitive filenames either have no equivalent in Windows or behave differently. The translation cost was high, and the results weren’t always correct.

Problem 3: Some things simply can’t be translated. This was WSL1’s real breaking point. Containers (Docker) depend deeply on two Linux kernel mechanisms: namespaces, which isolate what a process can see, and cgroups, which limit resource usage. These are native Linux kernel capabilities — Windows has no equivalent. There’s nothing to translate to. So Docker in WSL1 never worked, period.

WSL2’s solution was direct: stop translating. Put a real Linux kernel in there instead.

With that, Linux syscalls go straight into the kernel — no middle layer. The ext4 file system runs natively inside the VM with no NTFS mapping. Namespaces and cgroups actually exist, so Docker just works.

The performance gain wasn’t a tweak. It was a fundamental rethink.

Your Entire Linux Lives in One File

Let’s see what Linux actually looks like inside the Windows file system.

Open File Explorer and navigate to C:\Users\[username]\AppData\Local\wsl\. You’ll find a subfolder with a GUID name (something like {445ca81a-6e98-4e8d-aa7b-da5591a61d49}). Inside it is a file called ext4.vhdx.

(Older versions of WSL2 used the distro name as the folder name, like Ubuntu. Newer versions switched to GUIDs.)

Your entire Linux system is that one file. Every package installed, every repo cloned, every line written to a log — it’s all in there.

Here’s a counterintuitive trap: .vhdx is dynamically expanding, so it grows as you add data. But deleting files inside Linux does not shrink the .vhdx.

Delete 20 GB of dependencies? Windows disk usage won’t budge. After a few months, the .vhdx ballooning to several hundred GB is common — even if the actual Linux content is much smaller.

The fix is Windows’ built-in diskpart. Close all WSL windows, run wsl --shutdown, then:

diskpart
> select vdisk file="C:\Users\[username]\AppData\Local\wsl\{your-GUID}\ext4.vhdx"
> attach vdisk readonly
> compact vdisk
> detach vdisk
> exit

This compresses the empty space inside the virtual disk and gives it back to Windows. Anyone maintaining a WSL environment long-term should run this periodically.

Why Is Cross-System File Access So Slow?

This is WSL2’s most common performance complaint: accessing Windows files from inside Linux (anything under /mnt/c/) is painfully slow. Restarting WSL or switching commands doesn’t help.

What about the other direction? Opening Linux files from Windows Explorer (the penguin icon in the left sidebar) — just as slow.

Same reason: both directions go through the same channel.

WSL2 runs two completely separate file systems:

ext4, inside the Linux Utility VM (paths like ~/projects/)
NTFS, on the Windows side (accessed from Linux as /mnt/c/)

Whichever direction you’re crossing, every request goes through: the Hyper-V virtualization layer → tunneled via the 9P protocol → reaches the other side → data comes all the way back. Every single file operation makes that round trip.

(9P is a network file-sharing protocol. WSL2 runs a 9P server internally — it essentially treats the other side’s file system like a network share on a LAN.)

For anything that reads and writes lots of small files frequently, each operation is a 9P round trip through the virtualization layer — 10 to 50× slower is completely normal.

The rule is simple: keep files where you use them. Files you work on in WSL2 go in the Linux file system (~/). Windows projects stay in NTFS. Don’t make files cross the boundary repeatedly — no configuration can work around this physical constraint.

The IP That Keeps Changing

When WSL2 starts, Windows builds a small internal virtual LAN: Linux gets a virtual network card, the Windows host gets one too, and they talk through this private network using addresses in the 172.x.x.x range.

The problem: every time WSL2 restarts via wsl --shutdown, this virtual LAN gets rebuilt and IPs are reassigned. It might be 172.28.80.1 one time, 172.19.32.1 the next.

This creates two distinct issues — worth separating:

Windows connecting to Linux services: Say you’re running a web server inside Linux and want to open it in a Windows browser — don’t worry about the IP. Just use localhost. Microsoft handles automatic forwarding on the Windows side. Nothing to configure here.

Linux connecting to Windows services: This direction is trickier. If a script needs to call an endpoint on the Windows host, or connect to a database running on Windows, Linux needs to know the current Windows host IP to get there.

And that IP is exactly the one that changes every restart.

The good news: every time WSL2 starts, it automatically writes the current Windows host IP into /etc/resolv.conf on the Linux side:

cat /etc/resolv.conf
# nameserver 172.28.80.1  ← this is the Windows host IP right now

Any script that needs to reach back to Windows should read this value dynamically — never hardcode a specific IP. Hardcode it, and after the next restart it silently stops working. No error, no warning — just mysterious failures that take a long time to trace.

Keeping WSL2 From Eating All Your Memory

Let’s talk about resource limits. By default, WSL2 can use up to 50% of system memory and all CPU cores. On a 32 GB machine running heavy workloads, that noticeably squeezes Windows-side applications.

How do we configure it? Windows now includes a built-in GUI tool called WSL Settings — just search for it and open it. Memory limit, CPU core count, and swap size are all right there. Adjust and save.

If you prefer editing manually, create or edit .wslconfig in C:\Users\[username]\:

[wsl2]
memory=8GB
processors=4
swap=2GB

Both approaches work the same way. Run wsl --shutdown after saving — changes take effect on the next start. Tune the numbers to your machine; there’s no universal right answer.

Why Did Microsoft Build This?

Some people wonder — why would Microsoft go to all this trouble to run Linux inside Windows? Weren’t they worried about it cutting into their business?

There’s a clear business logic behind it. Three reasons, actually.

Reason 1: Win back developers. Between 2010 and 2018, a massive number of developers moved from Windows to MacBooks — because macOS natively supports Unix toolchains, while Windows developers were fighting Cygwin, path escaping, and permission incompatibilities. Microsoft saw the pattern: control the developer experience, control the ecosystem. WSL2 was the counterpunch — make Windows a platform developers actually want to use.

Reason 2: A beachhead for the cloud. Every major cloud platform runs Linux. Developers who use WSL2 locally — learning shell, apt, systemd — build skills that transfer directly to cloud environments. When they’re ready to move workloads up, the path of least resistance leads straight to Azure.

Reason 3: A prerequisite for the container era. Docker and Kubernetes require a real Linux kernel. Without WSL2, Docker Desktop on Windows needed a much heavier standalone VM. WSL2 made containers feel natural on Windows — and comfortable Docker users are one step closer to Azure.

WSL2 isn’t a product. It’s a layer of strategic infrastructure. A company that once called Linux “a cancer” spent years building what is arguably the most polished Linux environment on any platform. Once the business logic clicks, everything makes sense.

Quick Reference: Things That’ll Bite You

wsl --unregister is a hard delete. The .vhdx file disappears instantly — no confirmation, no Recycle Bin, no recovery. Always run wsl --export [distro-name] [backup.tar] before using it.

The .vhdx silently bloats. Disk space freed inside Linux doesn’t return to Windows automatically. On long-running WSL machines, run diskpart compact vdisk periodically — otherwise one day you’ll suddenly find the C drive full.

Where files live affects performance. Files that need frequent access inside WSL2 should live in the Linux file system (~/), not /mnt/c/. Making this clear resolves most “why is WSL2 so slow” complaints.

Kernel errors: update before reinstalling. WSL2’s Linux kernel is maintained by Microsoft separately from your distro. For mysterious crashes, run wsl --update first — reinstalling the distro almost certainly won’t fix a kernel-level issue.

Installing WSL2 is the first step. Understanding how it actually behaves is what makes you comfortable using it.

Install Linux on Windows 11 in 5 Minutes

Thu, 26 Feb 2026 16:10:00 GMT

I recently started training for the CompTIA A+ certification at Per Scholas. Core 2 covers a substantial amount of Linux-specific content.

To get more comfortable with Linux — especially command-line operations — I needed a Linux system to practice on. Since my machine runs Windows 11 Pro, my first instinct was to set up a virtual machine using VirtualBox or VMware. But that approach demands a lot of system resources. After some back-and-forth with AI, I discovered that modern Windows ships with WSL2 (Windows Subsystem for Linux 2) built in. Once installed, you can launch a Linux system directly inside Windows.

Quick Installation

No fluff — let’s get started.

Run CMD as Administrator on Windows, open the command line, and enter the following command:

wsl --install

After pressing Enter, Windows will begin downloading the default Linux distribution — Ubuntu. Once the download finishes, installation starts automatically. You’ll then be prompted to create a user account (the default username matches your current Windows username) and set a password. Note: password input is invisible — just type and press Enter. You’ll be asked to confirm it once more.

Your browser doesn't support HTML5 video playing. You could download the video to watch。

Install Linux with wsl --install command in Windows

Once everything completes successfully, congratulations — you now have a Linux/Ubuntu system inside Windows, natively.

Notes

WSL2 is supported on all Windows 11 editions (Home, Pro, and Enterprise). For Windows 10, make sure your build is 2004 (Build 19041) or later.
WSL2 relies on hardware virtualization. If installation keeps failing, check whether hardware virtualization is enabled. Open Task Manager, click the Performance tab, and select CPU. Look for Virtualization in the lower-right corner to see whether it’s enabled. If Virtualization shows as Disabled, restart your computer and repeatedly press F2 or Del to enter BIOS/UEFI settings. Locate the Intel VT-x or AMD-V option and set it to Enabled.
If nothing happens after installation completes, try restarting Windows.

Basic Usage

Once installation is done and Windows has restarted, open File Explorer. At the very bottom of the left navigation panel, you’ll be pleasantly surprised to find a Linux penguin icon. Click it to see a list of your installed Linux distributions. If you followed the command above, you’ll see an Ubuntu directory.

Click that directory and you’re taken straight to the root of your Ubuntu filesystem. You can drag files from your Windows desktop into it, or pull files out from Ubuntu back to Windows. This drag-and-drop file exchange is more convenient than anything a traditional virtual machine offers.

Another change shows up in the CMD terminal. In the dropdown next to the title bar, you’ll now see an Ubuntu option. Click it and a new tab opens running Ubuntu directly — extremely convenient.

There are other ways to launch Linux/Ubuntu as well — for example, press Ctrl+R, type wsl, and hit Enter. Or simply type wsl in CMD and press Enter.

Launching Linux/Ubuntu this way is fast — nearly as instant as opening any Windows app — and uses very little resources. Traditional virtual machines simply can’t compare.

To exit Linux and return to Windows, just type exit.

Other WSL Commands

We used wsl --install to install Ubuntu, but there are other WSL options worth knowing. (The following commands are run in Windows CMD — not inside Linux.)

wsl --list: Lists all currently installed Linux distributions.

wsl --list --online: Lists all Linux distributions available for download from Microsoft.

To install a different Linux distribution (e.g., Kali Linux): wsl --install --Kali-linux

If you have multiple distributions installed, launch a specific one by name: wsl -d Kali-linux

wsl --status: Displays current WSL status information.

To remove a Linux distribution (e.g., Kali Linux):

wsl --unregister Kali-linux

This is a physical-level wipe! Once executed, the corresponding Linux folder and all its data vanish instantly with no recovery possible. BACKUP your DATA!

Additional Tips

After closing all Linux windows, Linux is still running in the background on standby. To fully release those resources, run: wsl --shutdown
If you get an error on startup one day, don’t rush to uninstall. Try this command first: wsl --update It works like a phone OS update — automatically fetching the latest Linux kernel patches from the cloud.
Desktop Shortcut

To create a desktop shortcut that launches Linux with a single click, right-click the desktop and select New → Shortcut. Set the target to wsl -d Ubuntu.

To use the Ubuntu icon for the shortcut, right-click it → Properties → Change Icon, then navigate to C:\Users\[YourUsername]\AppData\Local\wsl\ and select the native Ubuntu icon.

I Built a Study Tool While Preparing for CompTIA A+ — Now It's Open Source

Sun, 22 Feb 2026 17:30:00 GMT

In December 2025, I enrolled in Per Scholas’ IT Support training program in Chicago, with the goal of earning both the CompTIA A+ and Google IT Support certifications by the end of March 2026.

The schedule is intense — five days a week, 9am to 4pm in class, plus two to three hours of homework every evening. It’s demanding, but the full-time structure keeps me fully immersed, and I can feel myself improving every single day.

The coursework involves a lot of hands-on practice: labs, unit quizzes, cumulative tests, and more. These exercises don’t just reinforce concepts — they simulate real-world IT scenarios that sharpen problem-solving skills.

Of course, mistakes are part of the process. I needed a way to capture the questions I got wrong so I could come back and review them intentionally, not just hope I’d remember.

I started by copying wrong answers into a document. It worked at first, but as the list grew, the limitations became obvious. It was passive — I could only review questions in the order I wrote them down, with no way to quiz myself interactively or filter by topic.

So I built a tool. Using Python and the PySide6 framework, I put together a simple wrong-answer practice app and started entering questions one by one. That gave me the ability to draw random questions, flag ones that needed extra attention, and actually practice rather than just re-read.

The tool made a real difference during my Core 1 exam prep, and I passed.

For Core 2 — which covers even more ground — I kept improving it based on how I was actually using it. Here’s where it stands now:

Multiple exam databases — Core 1 and Core 2 can be managed separately, each with its own modules and chapters
Question management — Add questions manually or batch-import from a Markdown file
Two practice modes — Learning mode gives instant feedback after each question; Exam Simulation is timed and graded at the end, just like the real thing
Progress tracking — The home screen shows overall accuracy, per-module mastery, and automatically flags weak areas
Bilingual interface — English and Chinese, with light and dark themes

I named it ReCall — Know it when it counts. It’s now open source on GitHub, free to download and use:

https://github.com/vincentping/recall

Windows users can download the pre-built executable directly from the Releases page — no Python installation required, just unzip and run.

This project will be further improved in the future, and I hope to add the following features:

Richer analytics — error trends, progress curves across sessions, and a clearer picture of how your mastery improves over time
AI-assisted review — using AI to explain weak areas in depth, or to intelligently recommend what to study next based on your performance

If you’re preparing for an IT certification — or just need a better way to practice what you’re getting wrong — feel free to download and try it out. If you run into any bugs or have ideas for improvement, I’d love to hear from you on GitHub Issues.

Remove Category and Article ID from URL in Joomla 3

Thu, 01 Oct 2015 17:13:00 GMT

This site has moved to a web site static generator to manage the content, and here is just a backup for reference.

Problem

I installed Joomla 3.4.4 on my vincentping.com site.

After created some categories and articles, I just wanna try the “SEO Settings” in the “Global Configuration”.

I set the options to: Search Engine Friendly URLs - Yes, use URL Rewriting - Yes, Adds Suffix to URL - Yes, just as following:

When I viewed the site, the article URL is like this:

http://www.vincentping.com/9-blog/2-remove-category-article-id-from-url-in-joomla-3.html

It’s ok comparing with the original URL like this:

http://www.vincentping.com/index.php?option=com_content&view=article&id=2:remove-category-article-id-from-url-in-joomla-3&catid=9

But the id numbers before the categoriy(here it’s 9) and article(2) are not very nice. Obviously these numbers are some database item number, with them the scripts could fetch data from backend database more efficiently. But to visitors they’re a little strange. So I googled the web and tried lots of suggestions from web, finally here is the solution I used.

The Solution

Open the php file under the Joomla root “components/com_content/router.php“,
Search for the code:

$advanced = $params->get('sef_advanced_link', 0);
Just change the “0” to “1”, the output is as this:

$advanced = $params->get('sef_advanced_link', 1);

There’re two lines of code in the file should be changed.

Find below section of code in the router.php file and comment it out:

 if (strpos($segments[0], ':') === false)
 {
      $vars['view'] = 'article';
      $vars['id'] = (int) $segments[0];

      return $vars;
  }

comment to

 /* if (strpos($segments[0], ':') === false)
  {
      $vars['view'] = 'article';
      $vars['id'] = (int) $segments[0];

      return $vars;
  } */

And all the job is DONE!

After that, the url for the page is now:

http://www.vincentping.com/en/remove-category-article-id-from-url-in-joomla-3.html

Remember: every time you upgrade your Joomla system, you should modify the code again.

Other Suggestions You can Try

From the research online, I know that the id number issues are a problem for Joomla User Groups for near 10 years. And there’s lots of extensions and other methods we could try.

Use SEF extensions such as Sh404SEF, JoomSEF, SEF Advance etc, you can search “SEF” on JED(Joomla! Extensions Directory) and try them, but most of them are paid extensions.
If you’re familar with regex rules, you may try to add some rules to the .htaccess and try to rewrite the URL. But as we know, the .htaccess gets some overhead.
When you just have a very small site, there’s limited articles there, you could create one menu item for each article, and the id issues are solved.

If you want to research more, I recommend the post “Remove article id from url for joomla 3.0” on the Offical Joomla Forum.