uv in­stalls pack­ages faster than pip by an or­der of mag­ni­tude. The usual ex­pla­na­tion is “it’s writ­ten in Rust.” That’s true, but it does­n’t ex­plain much. Plenty of tools are writ­ten in Rust with­out be­ing no­tably fast. The in­ter­est­ing ques­tion is what de­sign de­ci­sions made the dif­fer­ence.

Charlie Marsh’s Jane Street talk and a Xebia en­gi­neer­ing deep-dive cover the tech­ni­cal de­tails well. The in­ter­est­ing parts are the de­sign de­ci­sions: stan­dards that en­able fast paths, things uv drops that pip sup­ports, and op­ti­miza­tions that don’t re­quire Rust at all.

pip’s slow­ness is­n’t a fail­ure of im­ple­men­ta­tion. For years, Python pack­ag­ing re­quired ex­e­cut­ing code to find out what a pack­age needed.

The prob­lem was setup.py. You could­n’t know a pack­age’s de­pen­den­cies with­out run­ning its setup script. But you could­n’t run its setup script with­out in­stalling its build de­pen­den­cies. PEP 518 in 2016 called this out ex­plic­itly: “You can’t ex­e­cute a setup.py file with­out know­ing its de­pen­den­cies, but cur­rently there is no stan­dard way to know what those de­pen­den­cies are in an au­to­mated fash­ion with­out ex­e­cut­ing the setup.py file.”

This chicken-and-egg prob­lem forced pip to down­load pack­ages, ex­e­cute un­trusted code, fail, in­stall miss­ing build tools, and try again. Every in­stall was po­ten­tially a cas­cade of sub­process spawns and ar­bi­trary code ex­e­cu­tion. Installing a source dis­tri­b­u­tion was es­sen­tially curl | bash with ex­tra steps.

The fix came in stages:

* PEP 518 (2016) cre­ated pypro­ject.toml, giv­ing pack­ages a place to de­clare build de­pen­den­cies with­out code ex­e­cu­tion. The TOML for­mat was bor­rowed from Rust’s Cargo, which makes a Rust tool re­turn­ing to fix Python pack­ag­ing feel less like co­in­ci­dence.

* PEP 517 (2017) sep­a­rated build fron­tends from back­ends, so pip did­n’t need to un­der­stand se­tup­tools in­ter­nals.

* PEP 621 (2020) stan­dard­ized the [project] table, so de­pen­den­cies could be read by pars­ing TOML rather than run­ning Python.

* PEP 658 (2022) put pack­age meta­data di­rectly in the Simple Repository API, so re­solvers could fetch de­pen­dency in­for­ma­tion with­out down­load­ing wheels at all.

PEP 658 went live on PyPI in May 2023. uv launched in February 2024. uv could be fast be­cause the ecosys­tem fi­nally had the in­fra­struc­ture to sup­port it. A tool like uv could­n’t have shipped in 2020. The stan­dards weren’t there yet.

Other ecosys­tems fig­ured this out ear­lier. Cargo has had sta­tic meta­data from the start. npm’s pack­age.json is de­clar­a­tive. Python’s pack­ag­ing stan­dards fi­nally bring it to par­ity.

Speed comes from elim­i­na­tion. Every code path you don’t have is a code path you don’t wait for.

uv’s com­pat­i­bil­ity doc­u­men­ta­tion is a list of things it does­n’t do:

No .egg sup­port. Eggs were the pre-wheel bi­nary for­mat. pip still han­dles them; uv does­n’t even try. The for­mat has been ob­so­lete for over a decade.

No pip.conf. uv ig­nores pip’s con­fig­u­ra­tion files en­tirely. No pars­ing, no en­vi­ron­ment vari­able lookups, no in­her­i­tance from sys­tem-wide and per-user lo­ca­tions.

No byte­code com­pi­la­tion by de­fault. pip com­piles .py files to .pyc dur­ing in­stal­la­tion. uv skips this step, shav­ing time off every in­stall. You can opt in if you want it.

Virtual en­vi­ron­ments re­quired. pip lets you in­stall into sys­tem Python by de­fault. uv in­verts this, re­fus­ing to touch sys­tem Python with­out ex­plicit flags. This re­moves a whole cat­e­gory of per­mis­sion checks and safety code.

Stricter spec en­force­ment. pip ac­cepts mal­formed pack­ages that tech­ni­cally vi­o­late pack­ag­ing specs. uv re­jects them. Less tol­er­ance means less fall­back logic.

Ignoring re­quires-python up­per bounds. When a pack­age says it re­quires python, uv ig­nores the up­per bound and only checks the lower. This re­duces re­solver back­track­ing dra­mat­i­cally since up­per bounds are al­most al­ways wrong. Packages de­clare python be­cause they haven’t tested on Python 4, not be­cause they’ll ac­tu­ally break. The con­straint is de­fen­sive, not pre­dic­tive.

First-index wins by de­fault. When mul­ti­ple pack­age in­dexes are con­fig­ured, pip checks all of them. uv picks from the first in­dex that has the pack­age, stop­ping there. This pre­vents de­pen­dency con­fu­sion at­tacks and avoids ex­tra net­work re­quests.

Each of these is a code path pip has to ex­e­cute and uv does­n’t.

Some of uv’s speed comes from Rust. But not as much as you’d think. Several key op­ti­miza­tions could be im­ple­mented in pip to­day:

HTTP range re­quests for meta­data. Wheel files are zip archives, and zip archives put their file list­ing at the end. uv tries PEP 658 meta­data first, falls back to HTTP range re­quests for the zip cen­tral di­rec­tory, then full wheel down­load, then build­ing from source. Each step is slower and riskier. The de­sign makes the fast path cover 99% of cases. None of this re­quires Rust.

Parallel down­loads. pip down­loads pack­ages one at a time. uv down­loads many at once. Any lan­guage can do this.

Global cache with hardlinks. pip copies pack­ages into each vir­tual en­vi­ron­ment. uv keeps one copy glob­ally and uses hardlinks (or copy-on-write on filesys­tems that sup­port it). Installing the same pack­age into ten venvs takes the same disk space as one. Any lan­guage with filesys­tem ac­cess can do this.

Python-free res­o­lu­tion. pip needs Python run­ning to do any­thing, and in­vokes build back­ends as sub­processes to get meta­data from legacy pack­ages. uv parses TOML and wheel meta­data na­tively, only spawn­ing Python when it hits a setup.py-only pack­age that has no other op­tion.

PubGrub re­solver. uv uses the PubGrub al­go­rithm, orig­i­nally from Dart’s pub pack­age man­ager. Both pip and PubGrub use back­track­ing, but PubGrub ap­plies con­flict-dri­ven clause learn­ing from SAT solvers: when it hits a dead end, it an­a­lyzes why and skips sim­i­lar dead ends later. This makes it faster on com­plex de­pen­dency graphs and bet­ter at ex­plain­ing fail­ures. pip could adopt PubGrub with­out rewrit­ing in Rust.

Zero-copy de­se­ri­al­iza­tion. uv uses rkyv to de­se­ri­al­ize cached data with­out copy­ing it. The data for­mat is the in-mem­ory for­mat. Libraries like FlatBuffers achieve this in other lan­guages, but rkyv in­te­grates tightly with Rust’s type sys­tem.

Thread-level par­al­lelism. Python’s GIL forces par­al­lel work into sep­a­rate processes, with IPC over­head and data copy­ing. Rust can par­al­lelize across threads na­tively, shar­ing mem­ory with­out se­ri­al­iza­tion bound­aries. This mat­ters most for res­o­lu­tion, where the solver ex­plores many ver­sion com­bi­na­tions.

No in­ter­preter startup. Every time pip spawns a sub­process, it pays Python’s startup cost. uv is a sin­gle sta­tic bi­nary with no run­time to ini­tial­ize.

Compact ver­sion rep­re­sen­ta­tion. uv packs ver­sions into u64 in­te­gers where pos­si­ble, mak­ing com­par­i­son and hash­ing fast. Over 90% of ver­sions fit in one u64. This is mi­cro-op­ti­miza­tion that com­pounds across mil­lions of com­par­isons.

These are real ad­van­tages. But they’re smaller than the ar­chi­tec­tural wins from drop­ping legacy sup­port and ex­ploit­ing mod­ern stan­dards.

uv is fast be­cause of what it does­n’t do, not be­cause of what lan­guage it’s writ­ten in. The stan­dards work of PEP 518, 517, 621, and 658 made fast pack­age man­age­ment pos­si­ble. Dropping eggs, pip.conf, and per­mis­sive pars­ing made it achiev­able. Rust makes it a bit faster still.

pip could im­ple­ment par­al­lel down­loads, global caching, and meta­data-only res­o­lu­tion to­mor­row. It does­n’t, largely be­cause back­wards com­pat­i­bil­ity with fif­teen years of edge cases takes prece­dence. But it means pip will al­ways be slower than a tool that starts fresh with mod­ern as­sump­tions.

Other pack­age man­agers could learn from this: sta­tic meta­data, no code ex­e­cu­tion to dis­cover de­pen­den­cies, and the abil­ity to re­solve every­thing up­front be­fore down­load­ing. Cargo and npm have op­er­ated this way for years. If your ecosys­tem re­quires run­ning ar­bi­trary code to find out what a pack­age needs, you’ve al­ready lost.

When some­thing is run­ning on a sys­tem—whether it is a process, a ser­vice, or some­thing bound to a port—there is al­ways a cause. That cause is of­ten in­di­rect, non-ob­vi­ous, or spread across mul­ti­ple lay­ers such as su­per­vi­sors, con­tain­ers, ser­vices, or shells.

Existing tools (ps, top, lsof, ss, sys­tem­ctl, docker ps) ex­pose state and meta­data. They show what is run­ning, but leave the user to in­fer why by man­u­ally cor­re­lat­ing out­puts across tools.

It ex­plains where a run­ning thing came from, how it was started, and what chain of sys­tems is re­spon­si­ble for it ex­ist­ing right now, in a sin­gle, hu­man-read­able out­put.

* Explain why a process ex­ists, not just that it ex­ists

Ports, ser­vices, con­tain­ers, and com­mands all even­tu­ally map to PIDs. Once a PID is iden­ti­fied, witr builds a causal chain ex­plain­ing why that PID ex­ists.

How did it start?

What is keep­ing it run­ning?

What con­text does it be­long to?

witr node

witr ng­inx

A sin­gle po­si­tional ar­gu­ment (without flags) is treated as a process or ser­vice name. If mul­ti­ple matches are found, witr will prompt for dis­am­bigua­tion by PID.

witr –pid 14233

witr –port 5000

What the user asked about.

A causal an­ces­try chain show­ing how the process came to ex­ist. This is the core value of witr.

The pri­mary sys­tem re­spon­si­ble for start­ing or su­per­vis­ing the process (best ef­fort).

Only one pri­mary source is se­lected.

* Restarted mul­ti­ple times (warning only if above thresh­old)

* Process has been run­ning for over 90 days

A sin­gle po­si­tional ar­gu­ment (without flags) is treated as a process or ser­vice name.

witr node

witr –port 5000 –short

witr –pid 1482060 –tree

witr node

witr ng­inx

The eas­i­est way to in­stall witr is via the in­stall script.

curl -fsSL https://​raw.githubuser­con­tent.com/​pran­shu­par­mar/​witr/​main/​in­stall.sh | bash

curl -fsSL https://​raw.githubuser­con­tent.com/​pran­shu­par­mar/​witr/​main/​in­stall.sh -o in­stall.sh

cat in­stall.sh

chmod +x in­stall.sh

./install.sh

You may be prompted for your pass­word to write to sys­tem di­rec­to­ries.

If you pre­fer man­ual in­stal­la­tion, fol­low these sim­ple steps for your ar­chi­tec­ture:

# Download the bi­nary

curl -fsSL https://​github.com/​pran­shu­par­mar/​witr/​re­leases/​lat­est/​down­load/​witr-linux-amd64 -o witr-linux-amd64

# Verify check­sum (Optional, should print OK)

curl -fsSL https://​github.com/​pran­shu­par­mar/​witr/​re­leases/​lat­est/​down­load/​SHA256­SUMS -o SHA256SUMS

grep witr-linux-amd64 SHA256SUMS | sha256­sum -c -

# Rename and in­stall

mv witr-linux-amd64 witr && chmod +x witr

sudo mv witr /usr/local/bin/witr

# Install the man page (Optional)

sudo curl -fsSL https://​github.com/​pran­shu­par­mar/​witr/​re­leases/​lat­est/​down­load/​witr.1 -o /usr/local/share/man/man1/witr.1

sudo mandb >/dev/null 2>&1 || true

# Download the bi­nary

curl -fsSL https://​github.com/​pran­shu­par­mar/​witr/​re­leases/​lat­est/​down­load/​witr-linux-ar­m64 -o witr-linux-ar­m64

# Verify check­sum (Optional, should print OK)

curl -fsSL https://​github.com/​pran­shu­par­mar/​witr/​re­leases/​lat­est/​down­load/​SHA256­SUMS -o SHA256SUMS

grep witr-linux-ar­m64 SHA256SUMS | sha256­sum -c -

# Rename and in­stall

mv witr-linux-ar­m64 witr && chmod +x witr

sudo mv witr /usr/local/bin/witr

# Install the man page (Optional)

sudo curl -fsSL https://​github.com/​pran­shu­par­mar/​witr/​re­leases/​lat­est/​down­load/​witr.1 -o /usr/local/share/man/man1/witr.1

sudo mandb >/dev/null 2>&1 || true

* Download only the bi­nary for your ar­chi­tec­ture and the SHA256SUMS file.

* Verify the check­sum for your bi­nary only (prints OK if valid).

* Rename to witr, make it ex­e­cutable, and move to your PATH.

witr –version

man witr

sudo rm -f /usr/local/bin/witr

sudo rm -f /usr/local/share/man/man1/witr.1

If you use Nix, you can build witr from source and run with­out in­stal­la­tion:

nix run github:pran­shu­par­mar/​witr — –port 5000

witr in­spects /proc and may re­quire el­e­vated per­mis­sions to ex­plain cer­tain processes.

If you are not see­ing the ex­pected in­for­ma­tion (e.g., miss­ing process an­ces­try, user, work­ing di­rec­tory or en­vi­ron­ment de­tails), try run­ning witr with sudo for el­e­vated per­mis­sions:

sudo witr [your ar­gu­ments]

* A user can an­swer “why is this run­ning?” within sec­onds

This pro­ject was de­vel­oped with as­sis­tance from AI/LLMs (including GitHub Copilot, ChatGPT, and re­lated tools), su­per­vised by a hu­man who oc­ca­sion­ally knew what he was do­ing.

The disk per­sists. You have sudo.

Great things and peo­ple that I dis­cov­ered, learned, read, met, etc. in 2025. No par­tic­u­lar or­der­ing is im­plied. Not every­thing is new.

also: see the lists from 2024,

2023,

2022,

2021,

2020,

2019,

2018,

2017,

2016,

2015,

2014,

2013,

2012,

2011

and 2010

While I’ve posted a few tech­ni­cal post on my per­sonal blog, I’ve taken a lot of time to guest-post on the Wormwoodania

blog about weird, macabre, and sar­donic fic­tion and other re­lated, non-tech­ni­cal top­ics. I hope to con­tinue this trend into next year. Also, my most as­sid­u­ous read­ers will have no­ticed that I’ve writ­ten more about games. I’ve de­cided to keep those posts on this blog since my in­tent for the site has al­ways been about sys­tems and sys­tems-think­ing and games are a great way to study and model sys­tems.

* Mouse, a Language

for Microcomputers by Peter Grogono - Mouse is

ba­si­cally an es­olang with barely any ab­strac­tion fa­cil­i­ties, but the

book was well-writ­ten and the lan­guage com­pelling enough to ex­plore

fur­ther.

* Notes on

Distance Dialing (pdf) by AT&T - Described the

tele­phone sys­tems of the USA and Canada in the mid-1950s. The read­ing is

a dry as it gets, but it was a fas­ci­nat­ing dive into a vastly com­plex

sys­tem solv­ing ex­tremely hard prob­lems. This is a must-read for folks

in­ter­ested in sys­tems-think­ing. That said, I am ac­tively look­ing for

rec­om­men­da­tions for books about the process of de­sign­ing and build­ing

the un­be­liev­ably com­plex tele­phony sys­tem over the rudi­ments of the

ear­lier sys­tems. Recommendations wel­comed!

The vast ma­jor­ity of my read­ing this year was fic­tion, and I dis­cov­ered some real gems.

* The Eye of

Osiris by R. Austin Freeman - This is the first book

that I’ve read from Freeman and I sus­pect that I will read many more in

the fu­ture. The story fol­lows the dis­ap­pear­ance of John Bellingham,

Egyptologist and the sub­se­quent in­ves­ti­ga­tion. As the in­ves­ti­ga­tion

stalls, the em­i­nent Dr. Thorndyke digs into the case. The story sets up

the mys­tery nicely and in­deed pro­vides enough in­for­ma­tion to the reader

to in­fer how the dis­ap­pear­ance oc­curred and who or what fa­cil­i­tated it.

The book is one of the best who­dunits that I’ve ever read.

* The Mystery

of Edwin Drood by Charles Dickens - His fi­nal work

re­mains un­fin­ished as he passed away be­fore he could com­plete it.

Further com­pli­cat­ing the meta-story is that he also did­n’t out­line the

end­ing nor even put to pa­per the “villain” of the story. The

meta-mys­tery of the end­ing has mo­ti­vated a moun­tain of spec­u­la­tion

around the end­ing in­clud­ing dozens of con­tin­u­a­tions of the story from

other au­thors, all de­riv­ing their pet end­ings from tex­tual hints,

ac­counts from Dickens’ friends, il­lus­tra­tion notes, and even in some

cases seances sup­pos­edly ac­com­pa­nied by the spirit of Dickens him­self.

What was writ­ten by Dickens is spec­tac­u­lar and a com­pelling mys­tery and

al­though it would be great to know the res­o­lu­tion, in some ways the

“Droodiana” that has cropped up over the past 150+ years is rea­son

enough for it to re­main a mys­tery. The whole lore around Edwin Drood is

a worth­while hobby in it­self and well-worth ex­plor­ing. The Chiltern

Library edi­tion of the book con­tains the story and a good bit of the

lore around the writ­ing and the meta-works avail­able at the time of its

pub­li­ca­tion.

* The

Shadow People by Margaret St. Clair - Sadly out of

print and dif­fi­cult to find, but I’ve had it on my shelves for decades

and fi­nally got around to read­ing it. The book came onto my radar in the

1980s when I learned about it in the ap­pen­dix-n of the

1st edi­tion Advanced D&D Dungeon Masters Guide. I en­joyed many of

the books at the time and have slowly swung around to re-read­ing them

over the past few years. Sadly, most on the list do not stand the test

of time for me, but St. Clair’s mix­ture of 60s counter-cul­tural lean­ings

in a fan­tasy/​sf world still works. The cul­tural touch-points in the book

feel quite dated, but de­spite the oc­ca­sional awk­ward­ness, the story is

unique even to­day.

* Lolly

Willowes by Sylvia Townsend Warner - The book started

as a pass­able novel of man­ners fo­cused on a turn of the cen­tury British

mid­dle-class fam­ily. The tit­u­lar char­ac­ter was mostly back­ground

dec­o­ra­tion for the first third of the novel and AFAIR was talked about

only in the third-per­son. It’s only when she made the choice to move out

on her own to the coun­try in her mid­dle age does she gain a

cen­tral role in the nar­ra­tive and her in­ner thoughts re­vealed. This is

where things re­ally pick up be­cause I was shocked to learn that this

unas­sum­ing wom­an’s in­ner thoughts had a de­li­cious dark­ness to them. I

don’t want to give away too much, but I’ll just say that you will not

ex­pect how the story ends.

* Patience

by Daniel Clowes - A pro­found graphic novel us­ing time-travel to

ex­plore the idea of en­dur­ing love with a story that pro­ceed through

time, fol­low­ing Jack as he tries to al­ter the past and save the woman he

loves. This well-known sci­ence fic­tion mo­tif is el­e­vated by Clowes’

sig­na­ture psy­cho­log­i­cal com­plex­ity.

* Narcissus

and Goldmund by Herman Hesse - I’ve read most of the

books by Hermann Hesse but this one es­caped my at­ten­tion un­til this

year. The story fol­lows the par­al­lel lives of a monk Narcissus and his

pas­sion­ate friend Goldmund as they re­spec­tively search for mean­ing in

life through spir­i­tual means and through plea­sures of the

flesh.

* We

Who Are About To… by Joanna Russ - A small group of

as­tro­nauts crash land on a hos­tile alien world and quickly re­al­ize that

This soft­ware pro­ject ac­com­pa­nies the re­search pa­per: Sharp Monocular View Synthesis in Less Than a Second

by Lars Mescheder, Wei Dong, Shiwei Li, Xuyang Bai, Marcel Santos, Peiyun Hu, Bruno Lecouat, Mingmin Zhen, Amaël Delaunoy, Tian Fang, Yanghai Tsin, Stephan Richter and Vladlen Koltun.

We pre­sent SHARP, an ap­proach to pho­to­re­al­is­tic view syn­the­sis from a sin­gle im­age. Given a sin­gle pho­to­graph, SHARP re­gresses the pa­ra­me­ters of a 3D Gaussian rep­re­sen­ta­tion of the de­picted scene. This is done in less than a sec­ond on a stan­dard GPU via a sin­gle feed­for­ward pass through a neural net­work. The 3D Gaussian rep­re­sen­ta­tion pro­duced by SHARP can then be ren­dered in real time, yield­ing high-res­o­lu­tion pho­to­re­al­is­tic im­ages for nearby views. The rep­re­sen­ta­tion is met­ric, with ab­solute scale, sup­port­ing met­ric cam­era move­ments. Experimental re­sults demon­strate that SHARP de­liv­ers ro­bust zero-shot gen­er­al­iza­tion across datasets. It sets a new state of the art on mul­ti­ple datasets, re­duc­ing LPIPS by 25–34% and DISTS by 21–43% ver­sus the best prior model, while low­er­ing the syn­the­sis time by three or­ders of mag­ni­tude.

We rec­om­mend to first cre­ate a python en­vi­ron­ment:

Afterwards, you can in­stall the pro­ject us­ing

The model check­point will be down­loaded au­to­mat­i­cally on first run and cached lo­cally at ~/.cache/torch/hub/checkpoints/.

Alternatively, you can down­load the model di­rectly:

To use a man­u­ally down­loaded check­point, spec­ify it with the -c flag:

The re­sults will be 3D gauss­ian splats (3DGS) in the out­put folder. The 3DGS .ply files are com­pat­i­ble to var­i­ous pub­lic 3DGS ren­der­ers. We fol­low the OpenCV co­or­di­nate con­ven­tion (x right, y down, z for­ward). The 3DGS scene cen­ter is roughly at (0, 0, +z). When deal­ing with 3rdparty ren­der­ers, please scale and ro­tate to re-cen­ter the scene ac­cord­ingly.

Additionally you can ren­der videos with a cam­era tra­jec­tory. While the gaus­sians pre­dic­tion works for all CPU, CUDA, and MPS, ren­der­ing videos via the –render op­tion cur­rently re­quires a CUDA GPU. The gsplat ren­derer takes a while to ini­tial­ize at the first launch.

Please re­fer to the pa­per for both quan­ti­ta­tive and qual­i­ta­tive eval­u­a­tions. Additionally, please check out this qual­i­ta­tive ex­am­ples page con­tain­ing sev­eral video com­par­isons against re­lated work.

If you find our work use­ful, please cite the fol­low­ing pa­per:

@inproceedings{Sharp2025:arxiv,

ti­tle = {Sharp Monocular View Synthesis in Less Than a Second},

au­thor = {Lars Mescheder and Wei Dong and Shiwei Li and Xuyang Bai and Marcel Santos and Peiyun Hu and Bruno Lecouat and Mingmin Zhen and Ama"{e}l Delaunoy and Tian Fang and Yanghai Tsin and Stephan R. Richter and Vladlen Koltun},

jour­nal = {arXiv preprint arXiv:2512.10685},

year = {2025},

url = {https://​arxiv.org/​abs/​2512.10685},

Our code­base is built us­ing mul­ti­ple open­source con­tri­bu­tions, please see ACKNOWLEDGEMENTS for more de­tails.

Please check out the repos­i­tory LICENSE be­fore us­ing the pro­vided code and

LICENSE_MODEL for the re­leased mod­els.

Try out the ini­tial re­lease of the QNX Developer Desktop — a self-hosted de­vel­op­ment en­vi­ron­ment for QNX. No more cross-com­pi­la­tion!

Try out the ini­tial re­lease of the QNX Developer Desktop — a self-hosted de­vel­op­ment en­vi­ron­ment for QNX. No more cross-com­pi­la­tion!

The team and I are be­yond ex­cited to share what we’ve been cook­ing up over the last lit­tle while: a full desk­top en­vi­ron­ment run­ning on QNX 8.0, with sup­port for self-hosted com­pi­la­tion! This en­vi­ron­ment both makes it eas­ier for newly-minted QNX de­vel­op­ers to get started with build­ing for QNX, but it also vastly sim­pli­fies the process of port­ing Linux ap­pli­ca­tions and li­braries to QNX 8.0.

This self-hosted tar­get en­vi­ron­ment is pre-loaded with many of the ports you’ll find on the QNX Open-source Dashboard. (The por­tal cur­rently in­cludes over 1,400 ports across var­i­ous tar­gets, QNX ver­sions, and ar­chi­tec­tures, of which more than 600 are unique ports!)

In this ini­tial re­lease, you can grab a copy of the QEMU im­age and give it a try for your­self. There’s still so much more to add, but it’s in a great place to­day for this first re­lease. The team is re­ally pas­sion­ate about this one, and we’re ea­gerly look­ing for­ward to your feed­back!

For the ini­tial re­lease of Desktop, we tried to cover all the ba­sics: win­dow­ing, ter­mi­nal, IDEs, browser, file man­age­ment, and sam­ples. To that end, here’s what makes up the QNX Developer Desktop:

* The tools you need to com­pile and/​or run your code (clang, gcc, clang++, Python, make, cmake, git, etc)

* A web browser (can you join the QNX Discord from the QNX Desktop? 🏅👀)

* Ports of pop­u­lar IDEs/editors, like Geany, Emacs, Neovim, and vim

* Preloaded sam­ples, like Hello World in C, C++, and Python, and GTK demos OpenGL ES demos

* … and of course, a ter­mi­nal.

This en­vi­ron­ment runs as a vir­tual ma­chine, us­ing QEMU on Ubuntu. To try the im­age, you’ll need:

With a free QNX li­cense, you can find this re­lease in QNX Software Center. On the Available tab of the Manage Installation pane, search for “quick start” and in­stall the “QNX SDP 8.0 Quick Start Target Image for QEMU”.

You’ll find the im­age in your QNX in­stal­la­tion di­rec­tory, usu­ally ~/qnx800/images by de­fault. Follow the README.md file in the qemu di­rec­tory to ex­tract & com­bine the mul­ti­ple QNX pack­ages down­loaded un­der the hood.

Next, fol­low the PDF in­struc­tions found in the new ./qemu_qsti/docs/ di­rec­tory to in­stall the re­quired de­pen­den­cies and boot up.

This is just the very first re­lease! Over the next few months and be­yond, we’ll drop more up­dates of Desktop. You can look for­ward to:

* QEMU im­ages for Windows & ma­cOS, and na­tive im­ages for x86

* Features to help use this self-hosted en­vi­ron­ment in CI jobs

* … and more! Have sug­ges­tions? Let us know.

Lastly, if you want some help with your QNX jour­ney, you can find the QNX team and com­mu­nity:

In 2024, EFF wrote our ini­tial blog about what could go wrong when po­lice let AI write po­lice re­ports. Since then, the tech­nol­ogy has pro­lif­er­ated at a dis­turb­ing rate. Why? The most pop­u­lar gen­er­a­tive AI tool for writ­ing po­lice re­ports is Axon’s Draft One, and Axon also hap­pens to be the largest provider of body-worn cam­eras to po­lice de­part­ments in the United States. As we’ve writ­ten, com­pa­nies are in­creas­ingly bundling their prod­ucts to make it eas­ier for po­lice to buy more tech­nol­ogy than they may need or that the pub­lic feels com­fort­able with.

We have good news and bad news.

Here’s the bad news: AI writ­ten po­lice re­ports are still un­proven, un­trans­par­ent, and down­right ir­re­spon­si­ble–es­pe­cially when the crim­i­nal jus­tice sys­tem, in­formed by po­lice re­ports, is de­cid­ing peo­ple’s free­dom. The King County pros­e­cut­ing at­tor­ney’s of­fice in Washington state barred po­lice from us­ing AI to write po­lice re­ports. As their memo read, “We do not fear ad­vances in tech­nol­ogy — but we do have le­git­i­mate con­cerns about some of the prod­ucts on the mar­ket now… AI con­tin­ues to de­velop and we are hope­ful that we will reach a point in the near fu­ture where these re­ports can be re­lied on. For now, our of­fice has made the de­ci­sion not to ac­cept any po­lice nar­ra­tives that were pro­duced with the as­sis­tance of AI.”

In July of this year, EFF pub­lished a two-part re­port on how Axon de­signed Draft One to defy trans­parency. Police up­load their body-worn cam­er­a’s au­dio into the sys­tem, the sys­tem gen­er­ates a re­port that the of­fi­cer is ex­pected to edit, and then the of­fi­cer ex­ports the re­port. But when they do that, Draft One erases the ini­tial draft, and with it any ev­i­dence of what por­tions of the re­port were writ­ten by AI and what por­tions were writ­ten by an of­fi­cer. That means that if an of­fi­cer is caught ly­ing on the stand — as shown by a con­tra­dic­tion be­tween their court­room tes­ti­mony and their ear­lier po­lice re­port — they could point to the con­tra­dic­tory parts of their re­port and say, “the AI wrote that.” Draft One is de­signed to make it hard to dis­prove that.

In this video of a round­table dis­cus­sion about Draft One, Axon’s se­nior prin­ci­pal prod­uct man­ager for gen­er­a­tive AI is asked (at the 49:47 mark) whether or not it’s pos­si­ble to see af­ter-the-fact which parts of the re­port were sug­gested by the AI and which were edited by the of­fi­cer. His re­sponse (bold and de­f­i­n­i­tion of RMS added):

“So we don’t store the orig­i­nal draft and that’s by de­sign and that’s re­ally be­cause the last thing we want to do is cre­ate more dis­clo­sure headaches for our cus­tomers and our at­tor­ney’s of­fices—so ba­si­cally the of­fi­cer gen­er­ates that draft, they make their ed­its, if they sub­mit it into our Axon records sys­tem then that’s the only place we store it, if they copy and paste it into their third-party RMS [records man­age­ment sys­tem] sys­tem as soon as they’re done with that and close their browser tab, it’s gone. It’s ac­tu­ally never stored in the cloud at all so you don’t have to worry about ex­tra copies float­ing around.”

All of this ob­fus­ca­tion also makes it in­cred­i­bly hard for peo­ple out­side po­lice de­part­ments to fig­ure out if their city’s of­fi­cers are us­ing AI to write re­ports–and even harder to use pub­lic records re­quests to au­dit just those re­ports. That’s why this year EFF also put out a com­pre­hen­sive guide to help the pub­lic make their records re­quests as tai­lored as pos­si­ble to learn about AI-generated re­ports.

Ok, now here’s the good news: Peo­ple who be­lieve AI-written po­lice re­ports are ir­re­spon­si­ble and po­ten­tially harm­ful to the pub­lic are fight­ing back.

This year, two states have passed bills that are an im­por­tant first step in reign­ing in AI po­lice re­ports. Utah’s SB 180 man­dates that po­lice re­ports cre­ated in whole or in part by gen­er­a­tive AI have a dis­claimer that the re­port con­tains con­tent gen­er­ated by AI. It also re­quires of­fi­cers to cer­tify that they checked the re­port for ac­cu­racy. California’s SB 524 went even fur­ther. It re­quires po­lice to dis­close, on the re­port, if it was used to fully or in part au­thor a po­lice re­port. Further, it bans ven­dors from sell­ing or shar­ing the in­for­ma­tion a po­lice agency pro­vided to the AI. The bill also re­quires de­part­ments to re­tain the first draft of the re­port so that judges, de­fense at­tor­neys, or au­di­tors could read­ily see which por­tions of the fi­nal re­port were writ­ten by the of­fi­cer and which por­tions were writ­ten by the com­puter.

In the com­ing year, an­tic­i­pate many more states join­ing California and Utah in reg­u­lat­ing, or per­haps even ban­ning, po­lice from us­ing AI to write their re­ports.

This ar­ti­cle is part of our Year in Review se­ries. Read other ar­ti­cles about the fight for dig­i­tal rights in 2025.

T-Ruby is an open source pro­ject. Your con­tri­bu­tion makes a dif­fer­ence.

It’s still ex­per­i­men­tal. The core com­piler works, but there’s much to im­prove.

Feedback and sug­ges­tions are al­ways wel­come!

If you’ve heard “Grok” thrown around lately, you’re prob­a­bly think­ing of Elon’s chat­bot from xAI. We’re not talk­ing about that one. That model is­n’t par­tic­u­larly good, but its whole value prop is be­ing po­lit­i­cally in­cor­rect so you can get it to say edgy things.

The com­pany Nvidia bought is Groq (with a Q). Totally dif­fer­ent beast.

If you’ve used any high qual­ity LLM, you’ve no­ticed it takes a while to gen­er­ate a re­sponse. Especially for some­thing rapid fire like a con­ver­sa­tion, you want high qual­ity AND speed. But speed is of­ten what gets sac­ri­ficed. There’s al­ways that “thinking… gath­er­ing my notes… tak­ing some time to form the best re­sponse” de­lay.

Groq spe­cial­ized in hard­ware and soft­ware that makes this way faster. They cre­ated a new type of chip called an LPU (Language Processing Unit). It’s based on an ASIC, an ap­pli­ca­tion spe­cific in­te­grated cir­cuit. If that’s con­fus­ing, don’t worry about it. It’s just a proces­sor that does a spe­cific type of task re­ally well.

So imag­ine you’re talk­ing to Gemini and it takes a cou­ple sec­onds to re­spond. Now imag­ine it re­sponded in­stantly, like 10 or 100 times faster. That’s the prob­lem Groq was solv­ing.

To go one level deeper on LPUs ver­sus GPUs (the proces­sors most LLMs run on, typ­i­cally Nvidia cards): those GPU cal­cu­la­tions have to ac­cess a lot of things in mem­ory. Nvidia’s chips de­pend on HBM, high band­width mem­ory. But LPUs use some­thing called SRAM that’s much faster to ref­er­ence.

Think about it like this. Your wife has a gro­cery list for you. You go to the store but for­get the list. Every time you’re in an aisle, you have to call her on the phone: “Hey, do I need any­thing from the bread aisle?” Get the bread. Put the phone down. Go to the next aisle. “Hey, do I need any­thing from canned goods?” And so on through pro­duce, meat, pick up the beer, check out, get home. Very in­ef­fi­cient.

Groq’s ap­proach is like you just took the list to the store. Get to a new aisle, look at the list. Next aisle, look at the list. Much faster than a phone call.

That’s the key dif­fer­ence. Nvidia GPUs are phon­ing out every time they hit a new aisle. Groq’s LPUs mean the shop­per has the list in their pocket.

Groq’s main of­fer­ing is GroqCloud. An en­gi­neer like me is­n’t go­ing to go out and buy an LPU (I don’t even know if they’re com­mer­cially avail­able). What I’m go­ing to do is, if I need light­ning fast re­sponse in an ap­pli­ca­tion I’m build­ing, I’ll use GroqCloud. That in­fer­ence hap­pens at an ex­tremely fast rate, run­ning on LPUs in a data cen­ter some­where.

Their value prop is: fast, cheap, low en­ergy.

Where they’ve been falling short is they mostly use open source mod­els. Llama, Mistral, GPT-OSS (OpenAI’s open source of­fer­ing). These are de­cent mod­els, but nowhere near the qual­ity of some­thing like Anthropic’s Opus 4.5 or Gemini 3 Pro.

Groq po­si­tioned them­selves for hard­core use cases where mil­lisec­onds mat­ter. One of their big in­dus­try fits is real time data analy­sis for Formula 1. When your dri­ver’s out there on the track, you don’t have time to send a query to Gemini and wait 20 to 30 sec­onds to fig­ure out if you should pit this guy for new tires this lap. You want some­thing like Groq which does pretty good analy­sis, re­ally re­ally re­ally fast.

This is in­sider base­ball you’re go­ing to miss from main­stream news head­lines. The me­dia is pay­ing at­ten­tion to Grok (Elon’s chat­bot), not Groq (the chip com­pany). This is­n’t a con­spir­acy, it’s just that the only peo­ple aware of Groq are soft­ware de­vel­op­ers and tech nuts like me.

This is a ca­nary in the coal mine for worse things to come in 2026.

About a year ago, Groq an­nounced a $1.5 bil­lion in­fra­struc­ture in­vest­ment deal with Saudi Arabia. They also se­cured a $750 mil­lion Series D fund­ing round. These are crazy mul­ti­ples even for a soft­ware com­pany that’s some­what lever­aged in hard­ware. Bubble level pro­jec­tions.

To vi­su­al­ize $1.5 bil­lion: if you cashed that check out in $100 bills and stacked them one on top of an­other, it would reach a five story build­ing. For or­di­nary ple­beians like us, at the av­er­age US salary of around $75K, you’d need to work 20,000 years to earn that.

At that time, the com­pany was val­ued at $2 bil­lion. Hello bub­ble.

Then in maybe one of the best rug pulls of all time, in July they qui­etly changed their rev­enue pro­jec­tions to $500 mil­lion. A 75% cut in four months. I’ve never seen any­thing like that since the 2008 fi­nan­cial cri­sis.

This was a com­pany val­ued at $2 bil­lion, enough that the gov­ern­ment of Saudi Arabia was in­vest­ing at that val­u­a­tion. Then they took a 75% hair­cut four months later with­out any­thing ma­jor hap­pen­ing.

If it can hap­pen to Groq, who else can it hap­pen to? Nvidia? Intel?

The ru­mors started fly­ing on Christmas Eve. Confirmed the 26th: Nvidia will be buy­ing Groq, their key prod­uct line, and key per­son­nel in­clud­ing the CEO, for $20 bil­lion.

Let’s walk through that again:

* December: Nvidia buys them for $20 bil­lion af­ter they took a 75% hair­cut

What is go­ing on? This is a bub­ble.

The only ex­pla­na­tion is this is a fear pur­chase. Groq was promis­ing faster, cheaper, more ef­fi­cient, less elec­tric­ity use for their chips. But they could­n’t scale fast enough to com­pete with the ven­dor lock in and buddy sys­tem Nvidia has go­ing.

Nvidia’s buy­ing them with their in­sanely in­flated war chest. They don’t want a chunk taken out of their mar­ket share. They can’t af­ford to take that chance. So it’s like they’re just say­ing: “Shut up, take the $20 bil­lion, walk away from this pro­ject.”

This is a sign that in or­der to suc­ceed, Nvidia needs a mo­nop­oly on the mar­ket. Otherwise they would not pay ten times the com­pa­ny’s val­u­a­tion that was then de­creased by 75%. This is a des­per­ate move to con­sol­i­date the mar­ket into “you have to go with us.”

Saudi Arabia did­n’t keep that $1.5 bil­lion sit­ting around. They redi­rected it to Nvidia and AMD in­stead. Nvidia still gets paid ofc.

Smaller com­peti­tors like Cerebras and Inflection, do­ing things in Groq’s space or ex­plor­ing dif­fer­ent ar­chi­tec­tures for AI in­fer­ence, are can­cel­ing IPOs, drop­ping like flies, seek­ing emer­gency fund­ing. The chat­ter I’m hear­ing from VCs and friends in that world? Ain’t no­body buy­ing it right now.

Google made their own chip. Microsoft and Amazon are rac­ing to make com­pe­ti­tion chips that run on less elec­tric­ity, are more ef­fi­cient, faster. But no mat­ter what any­body does, the mar­ket is con­sol­i­dat­ing around the Nvidia mo­nop­oly for AI hard­ware. Engineers like me and ar­chi­tects at large en­ter­prises are try­ing to es­cape this. Once they con­sol­i­date enough of the mar­ket, they can set their price for chips and us­age. If you don’t own them, you go through Oracle or some cloud com­put­ing ser­vice, and they can charge what­ever they want be­cause there will be no com­peti­tors. Even a com­peti­tor hav­ing a rough time but get­ting some trac­tion? They just buy them out for $20 bil­lion be­cause with this mo­nop­oly go­ing, that’s pocket change.

The AI in­fra­struc­ture boom ran on one large er­rant as­sump­tion: that power is cheap and plen­ti­ful. That as­sump­tion was very, very wrong.

We’ve seen parts of the power grid fail, go un­main­tained. There’s a great ar­ti­cle on Palladium called “The Competency Crisis” that ex­plains some of what’s go­ing on in the US right now. Electricity is now the bot­tle­neck. It’s the con­straint. Too ex­pen­sive or you can’t get enough of it. Who’s pay­ing these costs? The tech com­pa­nies aren’t. Trump is meet­ing with Jensen Huang, with Sam Altman. He has­n’t been over my place lately. He has­n’t in­vited you to the White House to talk about how you can’t af­ford gro­ceries and eggs cost three times what they did a few years ago.

You and I are go­ing to pay to sub­si­dize the elec­tric­ity con­straints.

US data cen­ters are us­ing about 4% of all elec­tric­ity right now. If growth con­tin­ues at the same rate, in ten years they’ll use 9%. Almost one tenth of all elec­tric­ity gen­er­ated in the US.

I’m not much of an en­vi­ron­men­tal­ist. But even some­one like me, pretty jaded to some amount of waste be­cause of in­dus­tri­al­iza­tion, some­thing like this ac­tu­ally makes my stom­ach turn. In places with lots of data cen­ters, AI heavy re­gions, they’re ex­pe­ri­enc­ing about a 250% in­crease in en­ergy costs com­pared to just five years ago. That’s huge. Even com­pared to gro­cery costs, which are out of con­trol. At least with food you have al­ter­na­tives. Red meat too ex­pen­sive? Buy chicken. Chicken too ex­pen­sive? Buy eggs. But elec­tric­ity? You have to run elec­tric­ity. It’s a pub­lic util­ity. You can’t just “use a lot less” when your bill goes up 2.5x.

Let me walk you through what hap­pens. Some busi­ness de­vel­op­ment guy from Oracle wants to build a new data cen­ter in Rural America. A year be­fore it’s even built, they meet with city of­fi­cials, maybe the gov­er­nor. They grease the right peo­ple. Get leg­is­la­tion passed with the util­ity com­pa­nies that says they’ll pay a pref­er­en­tial rate for elec­tric­ity be­cause they’re go­ing to use a shit ton.

They’re Oracle or Nvidia, they’re good for it. They pay five years up­front. Then the util­ity de­cides what to do with the rest of the elec­tric­ity. The grid is strained. They want every­one else to use less. They can’t just tell them to use less, so they keep rais­ing the price un­til nat­u­rally you just can’t af­ford to use more.

You turn the lights off. Turn the TV off. Get those LED bulbs that dis­rupt your sleep. Do every­thing to keep elec­tric­ity costs down. But you and I are left hold­ing the bag. The data cen­ter folks aren’t pay­ing for that, they paid up­front at a pref­er­en­tial rate.

Senate Democrats are al­legedly in­ves­ti­gat­ing this. I’ll be­lieve it when I see it. These tech com­pa­nies have their hooks so far into in­flu­en­tial politi­cians. It’s a vote grab. I’d be happy to be wrong about that, but I know I’m not go­ing to be.

I talked about this in my last piece on the AI bub­ble. This com­puter com­mu­nism that’s go­ing on, pric­ing you out of per­sonal com­put­ing, keep­ing it all in the fam­ily of these tech com­pa­nies. But with the Groq deal con­firmed, it’s gone one step fur­ther. Nvidia is not just sell­ing chips any­more. They are lend­ing money to cus­tomers who buy the chips. They are ar­ti­fi­cially in­flat­ing de­mand.

It’s like if I run a small gro­cery store and I need to show good sig­nal to in­vestors that I’m bring­ing cash in the door. So I go down­town dur­ing farmer’s mar­ket and give every­body a $20 voucher to use at my store. I take a whole­sale hit when they come in and buy stuff. But what I can show is: “Hey, peo­ple are com­ing in and spend­ing money. Look at the rev­enue. Give me more ven­ture cap­i­tal money.”

This can’t work in­fi­nitely, for the same rea­son any per­pet­ual mo­tion ma­chine can’t work.

Back in September, Nvidia an­nounced a $100 bil­lion in­vest­ment in OpenAI. Coming through in $10 bil­lion tranches over time. And it’s not eq­uity, it’s lease agree­ments for Nvidia’s chips. Literally pay­ing them to pay them­selves. There’s prob­a­bly some tax shenani­gans go­ing on there since they’re typ­i­cally of­fer­ing $xxx in leases of their chips to the com­pany they’re “lending” to. Assuming they do this in part be­cause the de­pre­ci­a­tion on the phys­i­cal as­set (the chips) can be writ­ten off on their taxes some­how. They’re es­sen­tially in­cen­tiviz­ing an­other per­son to use them with money. Even OpenAI’s CFO has ad­mit­ted, quote: “Most of the money will go back to Nvidia.”

They’re play­ing both sides. In the OpenAI case, they’re fi­nanc­ing soft­ware that uses their chips. But they’re also get­ting their hooks into data cen­ters.

CoreWeave: they have some­thing like 7% share in the com­pany. Worth $3 bil­lion. That’s funded by GPU rev­enue from CoreWeave.

Lambda: an­other data cen­ter op­er­a­tor. That’s a $1.3 bil­lion spend­ing deal. Renting Nvidia’s own chips back from them.

They’ve pledged to in­vest £2 bil­lion across British star­tups, which of course are go­ing to go back to Nvidia chips one way or an­other.

In 2024, they in­vested about $1 bil­lion across star­tups and saw a $24 bil­lion re­turn in chip spend. They 24x’d their bil­lion dol­lar in­vest­ment in one year. Nvidia has more power than the Fed right now. More power than the pres­i­dent over the econ­omy. They have their hand on the knob of the econ­omy. They can choose how fast or slow they want it to go. If the Nvidia cash ma­chine stops print­ing, if they stop fund­ing star­tups, data cen­ters, hard­ware com­pa­nies, soft­ware com­pa­nies, that whole part of the econ­omy slows way down and maybe crashes if in­vestors get spooked.

I’m wait­ing for some­body to blow the whis­tle on this. I’m not a fi­nance guy, so it’s strange I’m even talk­ing about it. But their en­tire suc­cess story for the next cou­ple years hinges on their $100 bil­lion in­vest­ment in OpenAI, which they’re ex­pect­ing to bring back about $300 bil­lion in chip pur­chases.

It’s ven­dor fi­nanc­ing. It’s sweet­en­ing the pot on your own deals. I can­not be­lieve more peo­ple are not talk­ing about this.

OpenAI, the leader of this space, the com­pany whose CEO Sam Altman is in­vited to the White House nu­mer­ous times, prob­a­bly has a di­rect line to Trump, a lot of the econ­omy hinges on this guy’s strat­egy, opin­ions, and pub­lic state­ments.

And he runs a com­pany that is not prof­itable. Actually in­sane if you think about it. All he’s done with that com­pany, from an eco­nom­ics point of view, is rack up debt. Spent more than he’s earned.

By that met­ric, I’m richer than Sam Altman. Not in net worth. But if I con­sider my­self a busi­ness and the fact that I bring in any salary at all, even a dol­lar a year, that would make me earn more than Sam Altman, who has only lost money. In the next few years, they’re ex­pected to burn some­thing like $75 bil­lion a year. Just set that money on fire. I have a credit card with no pre­set spend­ing limit, but I as­sume if I run up a $75 bil­lion charge it’s go­ing to get de­nied. By their pro­jec­tions, they think they’ll be­come prof­itable around 2029/2030, and they need $200 bil­lion in an­nual rev­enue to off­set their debts and losses.

To vi­su­al­ize $200 bil­lion: if you cashed that out in $100 bills and stacked them, it would reach halfway to the International Space Station. That’s how much they’d have to make every sin­gle year to just be prof­itable. Not be a mas­sively suc­cess­ful com­pany. Just to not spend more than they earn.

* 2028 (projected): Will lose $74 bil­lion that year. Just lose it.

They’d need to make $200 bil­lion in a year to off­set that. Are they in­clud­ing in­ter­est? I have no idea how these things work, but in sim­ple terms: they’re spend­ing a lot more money than they make.

Groq was kind of a one off be­cause Nvidia panic bought the com­pe­ti­tion. But they also need to fig­ure out how to get prices down or they can’t keep this money ma­chine mov­ing.

Groq is prob­a­bly one of the last com­pa­nies that caught a good lifeboat off a sink­ing ship.

What we’re go­ing to see this year: it’ll start small, but get ma­jor. A com­pany first, then mul­ti­ple larger ones, that had a 2025 val­u­a­tion, will go to raise. They’ll do a 409A eval­u­a­tion. A bunch of smart an­a­lysts will say what it’s worth to in­vestors. And you’re go­ing to see the val­u­a­tion drop. They won’t be able to raise money.

Then the shit is re­ally go­ing to start to hit the fan.

The domi­noes will start falling. That’s prob­a­bly what kicks off the ac­tual pop, and it’s im­mi­nent. Any day now.

Part of the big gam­ble they’ve sold in­vestors is: we’ve got to re­place you. The worker. That’s why we need to spend so much money, go into debt. It’ll all be worth it be­cause then we won’t have to pay peo­ple to do these jobs any­more.

We’re go­ing to con­tinue to see mas­sive la­bor dis­place­ment. To a de­gree this is a shell game, an in­vestor il­lu­sion. What these larger en­ter­prise com­pa­nies are hop­ing to do: cut a lot of folks, have big lay­offs, say it’s be­cause AI is re­plac­ing the jobs.

In some cases they’re right. Data en­try, for ex­am­ple. I don’t mean to be mean if you do data en­try for a liv­ing, but there are mod­els very good at that now. You need some­one to man­age the work, spot check it. But it’s kind of a job AI can do.

Like how gro­cery stores have au­to­matic check­out lines now with one per­son mon­i­tor­ing six or eight of them. So some of that’s real. A lot of it is­n’t though.

They cut a bunch of American work­ers un­der the guise that AI’s re­plac­ing work­ers. A lot of these mega­corp ex­ecs are ac­tu­ally con­vinced of it. Americans are ex­pen­sive, es­pe­cially tech work­ers.

Then they see: damn, maybe we could have cut some, but not as many. We got greedy. Now our ser­vices are fail­ing in pro­duc­tion. AWS in Northern Virginia is flaky, go­ing down again. That just hap­pened, by the way, di­rect re­sult of these lay­offs.

So in­stead they think, “We’ll look glob­ally! Spin up a cam­pus in Hyderabad!” Pay them way less. The cost of liv­ing is less there, they ex­pect less. Bring them over on H-1B when needed. I’ve writ­ten about the H-1B pro­gram. This is noth­ing against the in­di­vid­u­als on that pro­gram. I’ve worked with very tal­ented H-1Bs, and some very in­fe­rior ones, just like American cit­i­zens.

But the cor­po­rate sleight of hand is some­thing like this, we can get those H-1B visas, and they’re not go­ing to ask for pesky stuff like Sunday off for church. We can put them on call 24/7 and they can’t say no be­cause if they do, we kick them back to their coun­try. Same thing that’s hap­pened with mi­grant la­bor in farm­ing over the past cen­tury. Even if it does­n’t look like it on the sur­face, cor­po­ra­tions know that they can pay H-1B em­ploy­ees less than American cit­i­zens. If a US cit­i­zen and H-1B re­cip­i­ent both make $120k but the H-1B works dou­ble the hours be­cause they have no room to push back and are un­der threat of be­ing sent home, they are mak­ing 50% less than the American per-hour.

Salesforce: My fa­vorite one. 4,000 cus­tomer sup­port roles cut. And the CEO is gloat­ing about it in in­ter­views. So great that he can re­place work­ers!

Now Salesforce is ad­mit­ting that they fucked up. They cut too many peo­ple.

I’ve been on the other side of this when I was an en­gi­neer­ing di­rec­tor at a Fortune 500 com­pany. They were neu­rotic about track­ing AI use. Spending an ex­or­bi­tant amount of money on shitty AI tools. Like tools from a year ago. GPT-4o in the GPT-5 era, in the Anthropic dom­i­nance era. More or less use­less.

Not only would they mon­i­tor all us­age across em­ploy­ees, specif­i­cally who’s us­ing it how much, they could see every sin­gle mes­sage be­ing sent to the AI. So the­o­ret­i­cally you could check some­body’s queries and do a per­for­mance eval­u­a­tion based on where you per­ceive them to be.

They’re us­ing yes­ter­day’s tools be­cause of reg­u­la­tion and com­pli­ance, blow­ing an ab­surd amount of money. The CEO just sees a lot go­ing out the door: “I thought these were sup­posed to save money, what’s go­ing on here?” So his lieu­tenants have to get a grip on it, mon­i­tor every­thing. Even at Amazon this is be­ing in­cluded in per­for­mance re­views, how much they’re us­ing AI.

That’s why if you’re a soft­ware de­vel­oper won­der­ing why your boss is on you about us­ing AI tools. They’re prob­a­bly get­ting pres­sure from their bosses. I want my en­gi­neers to be as pro­duc­tive as pos­si­ble. I think AI is prob­a­bly part of that tool belt for every­one at this point. But is track­ing it re­ally the best way? I’m go­ing to gauge per­for­mance on met­rics, how you in­ter­acted with the team, what you shipped. It puts the cart be­fore the horse to say you’re paid by how much you use these AI tools. If I’m a de­vel­oper, I’m just spin­ning up a script to send lorem ip­sum text 24 hours a day, get max­i­mum rat­ings be­cause I used GPT-3.5 the most.

MIT did a study in sum­mer 2025. They’re say­ing 95% of com­pa­nies re­port zero mea­sur­able ROI on AI prod­ucts.

Actually not that crazy if you con­sider that a lot of them did lay­offs and subbed in AI. That’s just go­ing ac­cord­ing to plan in my es­ti­ma­tion.

They es­ti­mate about $30 to $40 bil­lion has been spent on en­ter­prise AI. That’s the money your JPMorgan Chase is spend­ing for their en­gi­neers to use Claude Code or what­ever dated tool they have ac­cess to.

The mar­ket heard that sig­nal. When that study came out:

That last one is­n’t en­cour­ag­ing for an AI bub­ble pop be­cause it in­di­cates this is a big part of the econ­omy.

January through February: Maybe down val­u­a­tions, just a very flat mar­ket with­out much growth.

Q1 to Q2: We’ll start to see a cou­ple busi­nesses, or maybe one ma­jor one at first like a domino start­ing to fall, not able to raise cap­i­tal at their 2025 val­u­a­tion. We’ll see val­u­a­tions go down. VCs will be like: “Not touch­ing it, not giv­ing them more money, cut­ting our losses.”

Then tim­ing a lit­tle more in­de­ter­mi­nate but these things will hap­pen quickly in suc­ces­sion:

* Debt re­fi­nanc­ing pres­sure builds up in the sys­tem

* Nvidia re­vises its rev­enue guid­ance to some­thing at least vaguely linked to re­al­ity

And that’s when the big reck­on­ing be­gins.

I want to be clear. AI is not go­ing any­where. It’s go­ing to con­tinue be­ing a main­stream part of the world. I like a lot of these tools, I think they’re very help­ful.

But the talk­ing heads have re­ally promised us the world. It’s clear the tech­nol­ogy can­not de­liver above and be­yond what it’s do­ing now.

We’ve seen progress of these mod­els slow at an ex­po­nen­tial rate of slow­ing over the past few re­leases. Each re­lease is bet­ter, but the gap be­tween the cur­rent re­lease and the last re­lease is much smaller than it used to be.

Because of that, a lot of these AI com­pa­nies are go­ing to sur­vive, but their val­u­a­tions are go­ing to get giga slashed.

Valuations of $500 bil­lion for OpenAI, $42 bil­lion for Anthropic are un­sus­tain­able. We’re go­ing to ac­tu­ally see them be­come un­sus­tain­able in 2026 as they’re even­tu­ally cut. Smaller com­pa­nies will face those slashes first. But it’s com­ing for the ma­jor AI labs as well.

This is good news, hon­estly. This AI hype has re­ally turned tech into some­thing dif­fer­ent these days, dif­fer­ent than it used to be. While I don’t feel AI is go­ing any­where, I do feel we’ll get a lit­tle more back to nor­mal once this bub­ble pops and re­solves.

What do you think? Drop a com­ment be­low. Subscribe if you found this in­ter­est­ing.

Last month I came across one­mil­lion­screen­shots.com and was pleas­antly sur­prised at how well it worked as a tool for dis­cov­ery. We all know the adage about judg­ing book cov­ers, but here, …it just kinda works. Skip over the sites with bright flashy col­ors beg­ging for at­ten­tion and in­stead, seek out the neg­a­tive space in be­tween.

The one nit­pick I have though is in how they sourced the web­sites. They used the most pop­u­lar web­sites from Common Crawl which is fine, but not re­ally what I’m in­ter­ested in…

There are of course ex­cep­tions, but the re­la­tion­ship be­tween pop­u­lar­ity and qual­ity is loose. McDonald’s is­n’t pop­u­lar be­cause it serves the best cheese­burger, it’s pop­u­lar be­cause it serves a cheese­burger that meets the min­i­mum level of sat­is­fac­tion for the max­i­mum num­ber of peo­ple. It’s a profit max­i­miz­ing lo­cal min­ima on the cheese­burger land­scape.

This is­n’t lim­ited to just food ei­ther, the NYT Best Sellers list, Spotify Top 50, and Amazon re­view vol­ume are other good ex­am­ples. For me, what’s “popular” has be­come a fil­ter for what to avoid. Lucky for us though, there’s a cor­ner of the in­ter­net where sub­stance still out­weighs click-through rates. A place that’s largely im­mune to the cor­ro­sive in­flu­ence of mon­e­ti­za­tion. It’s called the small web and it’s a beau­ti­ful place.

The tim­ing of this could­n’t have been bet­ter. I’m cur­rently work­ing on a cou­ple of tools specif­i­cally fo­cused on small web dis­cov­ery/​rec­om­men­da­tion and hap­pen to al­ready have most of the data re­quired to pull this off. I just needed to take some screen­shots, sooo… you’re wel­come arm­chairhacker!

Because I plan on dis­cussing how I gath­ered the do­mains in the near fu­ture, I’ll skip it for now (it’s pretty in­ter­est­ing). Suffice it to say though, once the do­mains are avail­able, cap­tur­ing the screen­shots is triv­ial. And once those are ready, we have a fairly well worn path to fol­low:

I find the last two steps par­tic­u­larly repet­i­tive so I de­cided to com­bine them this time via self-or­ga­niz­ing maps (SOMs). I tried us­ing SOMs a few years ago to help solve a TSP prob­lem (well, ac­tu­ally the ex­act op­po­site…) but ended up go­ing in a dif­fer­ent di­rec­tion. Anyway, de­spite their triv­ial im­ple­men­ta­tion they can be ex­tremely use­ful. A bare bones SOM clocks in at about 10 lines with torch.

At their core, most SOMs have two el­e­ments: a mo­not­o­n­i­cally de­creas­ing learn­ing rate and a neigh­bor­hood func­tion with an in­flu­ence (radius) that is also mo­not­o­n­i­cally de­creas­ing. During train­ing, each step con­sists of the fol­low­ing:

There are nu­mer­ous mod­i­fi­ca­tions that can be made, but that’s ba­si­cally it! If I’ve piqued your in­ter­est, I highly rec­om­mend the book Self-Organizing Maps by Teuvo Kohonen, it’s a fairly quick read and cov­ers the core as­pects of SOMs.

With di­men­sion­al­ity re­duc­tion and as­sign­ment re­solved, we just need the vi­sual em­bed­dings now. I started with the brand new DinoV3 model, but was left rather dis­ap­pointed. The pro­gres­sion of Meta’s self-su­per­vised vi­sion trans­form­ers has been truly in­cred­i­ble, but the la­tent space cap­tures waaay more in­for­ma­tion than what I ac­tu­ally need. I just want to en­code the high level aes­thetic de­tails of web­page screen­shots. Because of this, I fell back on an old friend: the triplet loss on top of a small en­coder. The re­sult­ing out­put di­men­sion of 64 af­forded am­ple room for de­scrib­ing the vi­sual range while main­tain­ing a con­sid­er­ably smaller foot­print.

This got me 90% of the way there, but it was still lack­ing the vi­sual lay­out I had en­vi­sioned. I wanted a stronger cor­re­la­tion with color at the ex­pense of vi­sual sim­i­lar­ity. To achieve this, I had to man­u­ally en­force this bias by train­ing two SOMs in par­al­lel. One SOM op­er­ated on the en­coder out­put (visual), the sec­ond SOM on the color dis­tri­b­u­tion and were linked us­ing the fol­low­ing:

When the quan­ti­za­tion er­ror is low, the BMU pulling force is dom­i­nated by the vi­sual sim­i­lar­ity. As quan­ti­za­tion er­ror in­creases, the pulling force due to vi­sual sim­i­lar­ity wanes and is slowly over­pow­ered by the pulling force from the color dis­tri­b­u­tion. In essence, the color dis­tri­b­u­tion con­trols the macro place­ment while the vi­sual sim­i­lar­ity con­trols the mi­cro place­ment. The only con­trol­lable hy­per­pa­ra­me­ter with this ap­proach is se­lect­ing a thresh­old for where the crossover point oc­curs.

I did­n’t spend much time try­ing to find the op­ti­mal point, it’s cur­rently peak fall and well, I’d much rather be out­side. A quick look at the over­all quan­ti­za­tion er­ror (below left) and the U-matrix (below right) was suf­fi­cient.

There’s still a lot of cruft that slipped in (substack, medium.com, linkedin, etc…) but over­all, I’d say it’s not too bad for a first pass. In the time since gen­er­at­ing this ini­tial map I’ve al­ready crawled an ad­di­tional ~250k new do­mains so I sup­pose this means I’ll be do­ing an up­date. What I do know for cer­tain though is that self-or­ga­niz­ing maps have earned a cov­eted spot in my heart for things that are sim­ple to the point of be­ing el­e­gant and yet, de­cep­tively pow­er­ful (the oth­ers of course be­ing panel meth­ods, LBM, Metropolis-Hastings, and the bi­cy­cle).