Today we’re chang­ing how code en­ters the Ladybird pro­ject.

We will no longer ac­cept pub­lic pull re­quests. From now on, code changes to the Ladybird code­base will only be in­tro­duced by pro­ject main­tain­ers.

Ladybird is mov­ing into a new phase. As we work to­ward our first al­pha re­lease, the pro­ject needs a tighter de­vel­op­ment process, a clearer se­cu­rity model, and a smaller set of peo­ple re­spon­si­ble for the code that en­ters the browser.

This is not a change we make lightly. Many valu­able con­tri­bu­tions have come from out­side the main­tainer group over the years, and we are grate­ful for them. Many of us also came up through open source by send­ing patches to pro­jects we cared about.

For decades, code con­tri­bu­tions have been how open source pro­jects learned who to trust. People would show up, do the work, take re­spon­si­bil­ity for their changes, and stick around. Over time, trust emerged from the work it­self.

AI tools have changed the eco­nom­ics of this very quickly. We use them our­selves every day, but a pull re­quest no longer tells us as much as it used to about the per­son sub­mit­ting it. A sub­stan­tial patch used to im­ply sub­stan­tial ef­fort, and that ef­fort was a rea­son­able proxy for good faith. That as­sump­tion no longer holds.

For a browser, this mat­ters. A browser runs un­trusted in­put from the en­tire in­ter­net on the user’s ma­chine, and one well-dis­guised vul­ner­a­bil­ity is all an at­tacker needs. We have al­ready seen pa­tient, well-re­sourced cam­paigns in open source to earn main­tainer trust and abuse it. What has changed is how much faster and cheaper it has be­come to pro­duce work that looks like a se­ri­ous con­tri­bu­tion.

At the same time, every change that en­ters Ladybird be­comes our re­spon­si­bil­ity. It has to fit the ar­chi­tec­ture, sur­vive fu­ture refac­tor­ing, in­ter­act cor­rectly with the rest of the browser, and be un­der­stood by the peo­ple main­tain­ing it.

Whether code was typed by hand is be­side the point. What mat­ters is who is re­spon­si­ble for it once it en­ters the browser. Ladybird is be­com­ing a browser for real users. The peo­ple in­tro­duc­ing changes to it must be the peo­ple who de­cide those changes be­long in the pro­ject, and who will an­swer for the con­se­quences.

As part of this change, we will close all cur­rently open pub­lic pull re­quests. We are grate­ful for the work peo­ple put into them, but keep­ing the ex­ist­ing queue open would keep that con­tri­bu­tion path open in prac­tice. There is no per­fect time to make this change, so we are mak­ing it now. Going for­ward, pull re­quests will only be avail­able to pro­ject main­tain­ers.

There will not be a sep­a­rate process for sub­mit­ting patches by other means. We do not want to cre­ate a shadow con­tri­bu­tion sys­tem through is­sues, com­ments, email, or forks. External code can of course ex­ist un­der the terms of the li­cense, but we will not treat forks or patch dumps as a re­view queue for up­stream Ladybird.

Ladybird re­mains open source. The source code will con­tinue to be pub­licly avail­able un­der an open source li­cense. Outside in­volve­ment still mat­ters: clear bug re­ports, re­duc­tions, web­site test­ing, stan­dards dis­cus­sion, de­sign dis­cus­sion, se­cu­rity re­ports, and tech­ni­cal feed­back all help move the pro­ject for­ward.

This is the right change for Ladybird now. We are prepar­ing to ship a browser to real users, and our de­vel­op­ment process has to match that re­spon­si­bil­ity.

This site re­quires JavaScript to func­tion prop­erly. Please en­able JavaScript in your browser set­tings.

C++

2026 – 06-042026 – 06-04

2 Minutes

C++: The Documentary pre­miered to­day on YouTube, and it was great to be on the live chat with Bjarne and many other key folks who par­tic­i­pated in C++’s his­tory. I’m hon­ored to have been one of hun­dreds of peo­ple who have played a part in ad­vanc­ing Bjarne’s won­der­ful pro­ject over the years.

If you haven’t watched this yet, make it a week­end goal. What a great syn­op­sis of a 40-year suc­cess story, from hum­ble be­gin­nings to global adop­tion to be­ing cur­rently (as of Q3 2025) the fastest-grow­ing of the top four lan­guages in the world… +90% users in the past 3.5 years.

People who ap­pear in the doc­u­men­tary:

Bjarne Stroustrup: Bell Labs, Designer and orig­i­nal im­ple­menter of C++

Alexander Stepanov: Designer of the Standard Template Library

Anders Hejlsberg: Creator of C#, TypeScript, and Turbo Pascal

Andrei Alexandrescu: Principal Research Scientist, Nvidia & C++ Author

Andrew Koenig: Bell Labs, Founding mem­ber of the C++ Standards Committee, Researcher, C++ Author & Educator

Barbara Moo: Bell Labs, Manager C++ Development Team & C++ Author

Brian Kernighan: Bell Labs, Computer Scientist, Co-author of “The C Programming Language”

Chris Lattner: Creator of Mojo, LLVM, Clang & Swift

Danilo Piparo: Particle Physicist, CERN, ROOT Framework Project Lead

Eric Lubin: Software Developer — Lead, Hudson River Trading

Gabriel Dos Reis: Software Engineer and Architect, Microsoft; C++ tools builder; Mathematician

Herb Sutter: Technical Fellow, Citadel Securities; Chair, Standard C++ Foundation; Chair Emeritus, ISO C++ Committee

John Romero: Video Game Developer, Co-Creator of Doom and Quake, Co-Founder id Software

Nina Ranns: Vice-Convener of the ISO C++ Committee

Chapters

00:00 Intro

01:50 Invention at AT&T Bell Labs

07:30 C with Classes

09:37 Early adop­tion of C with Classes

10:53 From C with Classes to C++ (and CFront)

12:32 Why is it called C++?

13:24 AT&T starts sell­ing soft­ware / Another team tries to take over C++

16:08 Early de­vel­op­ment of C++ at AT&T Bell Labs

19:10 “It was a buggy prod­uct” / Release 2.0.0

21:55 C++ spread­ing be­yond AT&T

24:50 Too many ver­sions of C++

26:03 Need for stan­dard­iza­tion

29:38 The STL by Alexander Stepanov

37:19 The first stan­dard: C++98

39:21 C++ at CERN in the 90s

40:34 C++ spread­ing to games and trad­ing

43:00 C++ win­ter of the early 2000s

45:34 Programming lan­guage wars (C#)

49:25 There’s a need for an ef­fi­cient pro­gram­ming lan­guage again

52:29 Modern C++ (C++11)

56:29 Is the stan­dards com­mit­tee mak­ing C++ too com­pli­cated?

1:00:45 C++ is ever­where

01:05:00 The fu­ture and chal­lenges for C++

01:08:31 Bjarne’s im­pact

Published by Herb Sutter

Herb Sutter is an au­thor and speaker, and a tech­ni­cal fel­low at Citadel Securities. He serves as chair of the Standard C++ Foundation and its con­fer­ence CppCon, and served as chair of the ISO C++ stan­dards com­mit­tee from 2002 to 2025. View all posts by Herb Sutter

Published 2026 – 06-042026 – 06-04

Post nav­i­ga­tion

pub­lic sec­tor

Means res­i­dents can skip the credit card and use ‘pay by bank’ for lo­cal au­thor­i­ties and ser­vices

The UK’s Government Digital Service (GDS) has re­placed Stripe with Dutch provider Adyen as its proces­sor for many pay­ments made through its GOV.UK Pay ser­vice.

Adyen will take over GOV.UK Pay card pay­ments for lo­cal au­thor­i­ties, po­lice forces and armed forces units from Stripe, as well as pay by bank ser­vices, un­der a three-year con­tract worth up to £25.3 mil­lion.

According to the ten­der no­tice pub­lished in February 2025, the con­tract cov­ers around 17 per­cent of pay­ments made through GOV.UK Pay but more than 70 percent of its or­ga­ni­za­tions and in­cludes the only op­tion al­low­ing users to start tak­ing pay­ments within one work­ing day. At that point the con­tract had an es­ti­mated max­i­mum value of £49 mil­lion, al­though with no guar­an­tees over vol­ume.

REG AD

In a blog­post about the con­tract award on 2 June, GDS said it will mi­grate around 1,000 ser­vices to the new sup­plier. “We will make mi­gra­tion as straight­for­ward as pos­si­ble while com­ply­ing with Know Your Customer leg­is­la­tion that pro­tects every­one from fraud,” wrote Alan Maddrell, se­nior con­tent de­signer for the ser­vice. “Most im­por­tantly, there will be no dis­cernible dif­fer­ence for pay­ing users and no loss in func­tion­al­ity.”

REG AD

He added that the change of sup­plier will help in­tro­duce new op­tions in­clud­ing pay by bank, which trans­fers money di­rectly be­tween bank ac­counts us­ing open bank­ing ser­vices and avoids the need to type in card de­tails. GDS will con­tinue to use WorldPay to process pay­ments for cen­tral gov­ern­ment, linked or­ga­ni­za­tions and NHS bod­ies.

GDS es­tab­lished GOV.UK Pay to save pub­lic ser­vices the ef­fort and cost of set­ting up on­line pay­ments them­selves. It does­n’t charge or­ga­ni­za­tions for the ser­vice be­yond pass­ing on trans­ac­tion fees.

According to its per­for­mance data page, GOV.UK Pay has processed 137.5 mil­lion trans­ac­tions since it was set up in 2016, worth around £9.2 bil­lion. It cur­rently pro­vides 1,718 ser­vices, in­clud­ing 662 for lo­cal gov­ern­ment and 256 for po­lice forces, to 608 or­gan­i­sa­tions rang­ing from 1079 (Tiverton) Squadron RAF Air Cadets to Yeovil Town Council. ®

The seven men and women aboard the ISSpublished at 16:35 BST 5 June

Pallab GhoshScience cor­re­spon­dent

Image source, Anadolu via Getty Images

Crew-12 mis­sion as­tro­nauts Jack Hathaway, Andrey Fedyaev, Jessica Meir and Sophie Adenot prepar­ing to launch to the ISS from Florida

The seven crew mem­bers cur­rently aboard the International Space Station rep­re­sent five coun­tries and a re­mark­able range of back­grounds.

Jessica Meir, 48, com­mands the Crew-12 mis­sion. Born in Caribou, Maine, to Israeli and Swedish im­mi­grant par­ents, she holds a doc­tor­ate in ma­rine bi­ol­ogy and once stud­ied how em­peror pen­guins hold their breath in Antarctica. She made his­tory in 2019 as part of the first all-fe­male space­walk. She is a mother and a pri­vate pi­lot, and is con­ver­sa­tional in both Swedish and Russian.

Jack Hathaway, 44, is Crew-12′s pi­lot and a US Navy Commander from South Windsor, Connecticut. He trained as a test pi­lot at the Empire Test Pilots’ School in the UK be­fore be­ing se­lected by NASA in 2021.

Sophie Adenot, 43, is a French colonel, he­li­copter test pi­lot and the sec­ond French woman ever to reach space, in­spired as a teenager by watch­ing Claudie Haigneré launch to the Mir space sta­tion. She speaks four lan­guages, is a cer­ti­fied yoga teacher and a trained sky­diver.

Chris Williams, 42, is a Nasa physi­cist and for­mer can­cer re­searcher at Harvard Medical School and Brigham and Women’s Hospital who piv­oted from study­ing the early uni­verse for his MIT doc­tor­ate to treat­ing tu­mours be­fore be­com­ing an as­tro­naut. He also vol­un­teered as a fire­fighter and EMT.

Sergey Kud-Sverchkov, 42, the sta­tion com­man­der, is a rocket en­gi­neer born in Baikonur — the very city from which so many space mis­sions have launched. He grad­u­ated with ho­n­ours from Moscow State Technical University and worked as an en­gi­neer at RSC Energia be­fore be­ing se­lected as a cos­mo­naut in 2010. He was awarded the Hero of the Russian Federation af­ter his first ISS mis­sion in 2020. He has also trained in un­der­ground cave sys­tems in Sardinia and stud­ied plan­e­tary ge­ol­ogy in the Dolomites as part of ESA’s as­tro­naut prepa­ra­tion pro­grammes.

Sergei Mikaev, 39, is on his first space­flight. Born in Irkutsk in Siberia, he rose to Major and com­man­der of a mil­i­tary avi­a­tion unit in Primorsky Territory — Russia’s re­mote far east, bor­der­ing China — be­fore be­ing se­lected as a cos­mo­naut in 2018. He is mar­ried with two chil­dren.

Andrey Fedyaev, 45, is a Russian cos­mo­naut and for­mer Air Force ma­jor from Serov in the Ural moun­tains, on his sec­ond space­flight. When he flew on Crew-6 in 2023, he be­came only the sec­ond Russian cos­mo­naut ever to launch aboard an American com­mer­cial space­craft. He is now on his sec­ond mis­sion, again fly­ing along­side Nasa col­leagues aboard Dragon.

Long-running, fault-tol­er­ant SQL func­tions for teams that al­ready keep their state in Postgres and want to stop stitch­ing to­gether cron jobs, work­ers, queues, and sta­tus ta­bles to make back­ground work re­li­able. Define the work­flow in SQL, let pg_­durable check­point each step, and re­sume af­ter crashes, restarts, or failed steps.

Durable ex­e­cu­tion is now a stan­dard in­dus­try pat­tern, and pg_­durable brings it in­side Postgres with no ex­tra ser­vice in­fra­struc­ture re­quired. Part of our mis­sion to bring com­pute close to data.

Try pg_­durable now in Azure HorizonDB, Microsoft’s new PostgreSQL cloud ser­vice en­gi­neered for per­for­mance and built with pg_­durable in­side

Try pg_­durable now in Azure HorizonDB, Microsoft’s new PostgreSQL cloud ser­vice en­gi­neered for per­for­mance and built with pg_­durable in­side

Is this for me?

Who it’s for

Backend and data en­gi­neers who want work­flows to live next to the data they touch.

DBAs and SREs au­tomat­ing run­books that must sur­vive restarts and be au­ditable in SQL.

Teams build­ing data or AI pipelines that need durable ex­e­cu­tion per row, doc­u­ment, or batch.

The core idea

A pg_­durable func­tion is a graph of SQL steps that PostgreSQL ex­e­cutes and check­points as it goes. If the data­base crashes, restarts, or a step fails, ex­e­cu­tion re­sumes from the last durable check­point in­stead of mak­ing you re­con­struct state by hand.

Workloads this is use­ful for

Vector em­bed­ding pipelines: chunk, call an em­bed­ding API, and up­sert into pgvec­tor.

Ingest pipelines: stage, dedu­pli­cate, trans­form, and pub­lish large batches.

Scheduled main­te­nance: de­tect bloat, no­tify, wait for ap­proval, then run the next ac­tion.

Fan-out ag­gre­ga­tion: run in­de­pen­dent queries in par­al­lel, then join the re­sults.

External API work­flows: en­rich­ment, clas­si­fi­ca­tion, and web­hook-style calls from SQL.

What you’re prob­a­bly do­ing to­day in­stead

pg_cron plus a jobs table, sta­tus columns, retry coun­ters, and a polling worker.

An ex­ter­nal or­ches­tra­tor such as Airflow, Temporal, Step Functions, or Argo call­ing back into Postgres.

A queue plus work­ers plus a sep­a­rate state table to co­or­di­nate re­tries and par­tial com­ple­tion.

A plpgsql pro­ce­dure that works un­til a crash or long-run­ning trans­ac­tion forces you to start over.

Pain points it ad­dresses

A restart in the mid­dle of a long job means re­run­ning work that al­ready suc­ceeded.

One failed row or one failed API call turns into man­ual cleanup and un­cer­tain re­play.

Long trans­ac­tions hold locks, grow WAL, and make batch jobs frag­ile at larger scale.

Parallel work in the app tier cre­ates more places for par­tial-fail­ure bugs and drift.

The work­flow logic ends up spread across SQL, work­ers, queues, dash­boards, and sta­tus ta­bles.

What changes in your ar­chi­tec­ture

The work­flow de­f­i­n­i­tion moves into SQL and starts with df.start(…).

Retry state, progress track­ing, and check­point­ing move into Postgres in­stead of be­spoke app code.

Some app-tier work­ers, queue con­sumers, or sched­uler glue can dis­ap­pear en­tirely.

Operational vis­i­bil­ity comes from Postgres ta­bles such as df.in­stances, us­ing the same auth and backup model as your data.

When not to use it

The job is al­ready a sin­gle INSERT … SELECT or one or­di­nary SQL state­ment.

You need sub-mil­lisec­ond syn­chro­nous re­quest han­dling rather than durable back­ground ex­e­cu­tion.

You can­not in­stall ex­ten­sions or run a back­ground worker in your Postgres en­vi­ron­ment.

The work­flow mostly lives out­side Postgres and spans many het­ero­ge­neous sys­tems.

You need ar­bi­trary ap­pli­ca­tion logic that does not map cleanly to SQL steps, branch­ing, loops, or HTTP calls.

How it works

Define a work­flow in SQL us­ing com­pos­able op­er­a­tors such as ~> and |=>.

Start it with df.start() and get back an in­stance ID.

Let the run­time ex­e­cute each step durably with check­point­ing be­tween steps.

Query sta­tus and re­sults from PostgreSQL while the work­flow runs or af­ter it com­pletes.

Limitations

The model is in­ten­tion­ally SQL-shaped. If a step needs ar­bi­trary code, a non-HTTP SDK, or rich in-mem­ory con­trol flow, you may need to wrap that logic in a SQL func­tion, ex­pose it be­hind an HTTP end­point for df.http(), or use a gen­eral-pur­pose or­ches­tra­tor for that part of the sys­tem.

Features

Durable — Function state per­sists to PostgreSQL. Survives crashes, restarts, and failovers.

SQL-native — Define func­tions in SQL us­ing com­pos­able op­er­a­tors.

Database-aware — First-class prim­i­tives for sched­ul­ing, con­di­tions, and par­al­lel ex­e­cu­tion.

Zero in­fra­struc­ture — Runs as a PostgreSQL ex­ten­sion. No Redis, no Temporal, no ex­ter­nal ser­vices.

Quick Example

– A durable func­tion that processes data in steps SELECT df.start( ‘SELECT id FROM doc­u­ments WHERE processed = false LIMIT 100’ |=> ‘batch’ ~> ‘UPDATE doc­u­ments SET processed = true WHERE id = ANY($batch)’ );

Packages

Tagged re­leases pub­lish Debian pack­ages for PostgreSQL 17 and 18 on amd64 from the GitHub re­lease as­sets. Packages are named pg-durable-post­gresql-<PG ma­jor>_<pg_­durable ver­sion>-1_<arch>.deb and in­stall the ex­ten­sion li­brary, con­trol file, and SQL up­grade files into the match­ing PostgreSQL in­stal­la­tion di­rec­to­ries.

After in­stalling a pack­age, add pg_­durable to shared_pre­load­_li­braries, restart PostgreSQL, and cre­ate the ex­ten­sion in the con­fig­ured pg_­durable data­base:

CREATE EXTENSION pg_­durable;

The de­fault pg_­durable data­base is post­gres; see User Guide for back­ground worker con­fig­u­ra­tion and priv­i­lege setup.

Release as­sets also in­clude source archives for build­ing from source.

Development Installation

Prerequisites

PostgreSQL 17 or 18

Rust (nightly)

cargo-pgrx 0.16.1

GitHub Codespace

The main branch pre­build in­stalls PostgreSQL 17, builds pg_­durable, and pre­pares a lo­cal clus­ter un­der ~/.pgrx with the ex­ten­sion ready. PostgreSQL is not left run­ning, so start it when you be­gin work­ing.

# Start PostgreSQL ./scripts/pg-start.sh

# Connect ~/.pgrx/17.*/pgrx-install/bin/psql -h lo­cal­host -p 28817 -d post­gres

On a branch with­out a ready pre­build, run pg-start.sh — it will build and in­stall the ex­ten­sion on first run (expect a few min­utes):

./scripts/pg-start.sh

Other en­vi­ron­ments

Local and Dev Container

A VS Code Dev Container (.devcontainer/) pro­vides Rust, cargo-pgrx, and PostgreSQL 17 pre-in­stalled. For a bare lo­cal ma­chine, in­stall the tool­chain first by fol­low­ing the steps in .devcontainer/onCreateCommand.sh.

# Build, ini­tial­ize PostgreSQL, and in­stall the ex­ten­sion # This takes a while - go do some­thing else ./scripts/pg-start.sh

# Connect to the lo­cal pgrx PostgreSQL in­stance ~/.pgrx/17.*/pgrx-install/bin/psql -h lo­cal­host -p 28817 -d post­gres

pg-start.sh boot­straps new lo­cal data di­rec­to­ries with a post­gres su­pe­ruser and also cre­ates a match­ing su­pe­ruser role for the cur­rent OS user, so de­fault lo­cal psql us­age con­tin­ues to work. Use -U post­gres if you want to force the canon­i­cal boot­strap role ex­plic­itly.

Docker

# Build and test ./scripts/test-e2e-docker.sh –rebuild

# Optional: Deploy to ACR (for cus­tom PG17 im­age with pg_­durable baked-in) ./scripts/deploy-acr.sh

Multi-User Setup

CREATE EXTENSION pg_­durable does not grant any priv­i­leges to PUBLIC. After in­stalling the ex­ten­sion, the ad­min must ex­plic­itly grant ac­cess to ap­pli­ca­tion roles. Row-level se­cu­rity (RLS) en­sures each user can only see and man­age their own durable func­tion in­stances and nodes.

Grant priv­i­leges to an ap­pli­ca­tion role:

– Grant to spe­cific roles af­ter CREATE EXTENSION SELECT df.grant_us­age(‘ap­p_role’);

Alternatively, cre­ate an in­di­rec­tion role and grant mem­ber­ship to ap­pli­ca­tion roles:

– Create a shared role for pg_­durable ac­cess CREATE ROLE pg_­durable_user NOLOGIN; SELECT df.grant_us­age(‘pg_­durable_user’);

– Grant mem­ber­ship to ap­pli­ca­tion roles GRANT pg_­durable_user TO ap­p_back­end, etl_ser­vice;

See the User Guide — Privilege Grants sec­tion for the full list of in­di­vid­ual grants, re­vok­ing ac­cess, and hard­en­ing up­graded in­stalls.

See the User Guide — Privilege Grants sec­tion for the full list of in­di­vid­ual grants, re­vok­ing ac­cess, and hard­en­ing up­graded in­stalls.

Note: GRANT EXECUTE ON ALL FUNCTIONS only ap­plies to func­tions that ex­ist when the grant runs. After up­grad­ing pg_­durable with ALTER EXTENSION pg_­durable UPDATE, re-run df.grant_us­age(‘role’) (or re-is­sue the man­ual grants) so new func­tions are ac­ces­si­ble.

Note: GRANT EXECUTE ON ALL FUNCTIONS only ap­plies to func­tions that ex­ist when the grant runs. After up­grad­ing pg_­durable with ALTER EXTENSION pg_­durable UPDATE, re-run df.grant_us­age(‘role’) (or re-is­sue the man­ual grants) so new func­tions are ac­ces­si­ble.

Key points:

The back­ground worker role (pg_durable.worker_role GUC, de­fault: post­gres) must be a su­pe­ruser — it by­passes RLS to man­age all users’ in­stances

Users get SELECT + INSERT on df.in­stances / df.nodes, col­umn-level UPDATE (status, up­dat­ed_at) on in­stances for df.can­cel()

Identity col­umn (submitted_by) can­not be mod­i­fied by users

df.vars uses per-user scop­ing — each user has their own vari­able name­space via an owner col­umn and RLS. Superusers by­pass RLS but DSL func­tions still scope to the call­ing user via ex­plicit fil­ters. Avoid stor­ing se­crets in plain text

Continuous Integration

All pull re­quests must pass the fol­low­ing checks be­fore merg­ing:

Format Check — cargo fmt –check

Clippy & Tests — cargo clippy, unit tests (cargo pgrx test pg17), pg_regress tests, and E2E tests

The CI work­flow is de­fined in .github/workflows/ci.yml. It uses pgrx to down­load and man­age PostgreSQL.

Data Analysis · June 2026

A sim­ple dis­tri­b­u­tional analy­sis of every rsync re­lease with bug data. Nothing com­pli­cated, an­swers only one ques­tion: are the Claude-assisted re­leases un­usu­ally buggy?

Repository: RsyncProject/rsync Method: sever­ity-weighted bugs per 10 com­mits, ex­act per­mu­ta­tion test

0 · Disclaimer: How AI Assistance Was Used

In or­der to avoid ac­cuas­tions of this “just be­ing Claude de­fend­ing Claude,” “AI slop,” “probably all hal­lu­ci­na­tions,” etc., I’ve de­cided it’s prob­a­bly worth ex­plain­ing a few key points about how this re­port was cre­ated:

All met­rics, method­ol­ogy, and data sources were ex­clu­sively cho­sen by me, in con­sul­ta­tion with my wife, who has a Master’s Degree in Statistics from Penn State University.

The method­ol­ogy is di­rectly based on my wife’s in­put: she was the one that pointed out that try­ing to just com­pare bugs per ten lines of code be­fore and af­ter would likely be too ef­fected by noise be­cause of the low num­ber of post-Claude sam­ples, and that, for sim­i­lar rea­sons, try­ing to build some kind of lin­ear re­gres­sion model to as­cer­tain the rel­a­tive ef­fects of dif­fer­ent vari­ables would prob­a­bly also not work. She specif­i­cally told me that look­ing at where the post-Claude re­leases fall into the his­tor­i­cal dis­tri­b­u­tion, and how likely from the his­tor­i­cal dis­tri­b­u­tion we would be to get re­leases as “bad” or worse than the post-Claude re­leases, was prob­a­bly the best that could be done.

I spent sev­eral days on this, two be­fore even cre­at­ing the GitHub repo and had at least one ma­jor to­tal rewrite of the re­port to use a bet­ter method­ol­ogy (given the feed­back from my wife men­tioned above). This was a lot of man­ual, cog­ni­tive ef­fort on my end.

The scripts used to fetch the data, col­late it into a DuckDB data­base file, con­struct the views on that DB, and then do the sta­tis­ti­cal analy­sis on that data, were in­deed writ­ten by GLM 5.1, as was the HTML and much of the orig­i­nal prose for the fi­nal re­port web­page you’re look­ing at right now.

Crucially, how­ever, all num­bers, sta­tis­tics, cards, and graphs in this re­port are au­to­mat­i­cally tem­plated in di­rectly by the Python script that ran the sta­tis­ti­cal analy­sis, thus avoid­ing any pos­si­bil­ity of hal­lu­ci­na­tions or in­con­sis­ten­cies in the num­bers.

After post­ing this on Hacker News and re­ciev­ing al­most no sub­stan­tive in­put, dis­cus­sion, or re­sponse on the ac­tual con­tent of the ar­ti­cle, I de­cided to rewrite all of the prose in my own voice. If any­one com­plains about my ver­bosity or sen­tence struc­ture — as they usu­ally do, which is the rea­son I orig­i­nally let the AI write the prose, among other rea­sons ob­so­leted by tem­plat­ing — they can go fuck them­selves.

If you want to repli­cate the data and re­sults here, and in­spect ex­actly how they were cal­cu­lated, you can find the repos­i­tory here. I have pur­pose­fully made it so that the pipeline can be run end to end com­pletely from scratch, so you can see the en­tire pipeline end-to end, with no mys­te­ri­ous DB blobs forc­ing you to trust that I did­n’t doc­tor or screw up the data. If you want to be mad about the num­bers, look there first.

1 · Background: The rsync Outrage

In late May 2026, rsync blew up. First, an ev­i­dence-free Mastodon post was made point­ing to a spu­ri­ous cor­re­la­tion be­tween a re­gres­sion that par­tic­u­lar user ex­pe­ri­enced upon up­grad­ing to a re­lease, and that re­lease hav­ing Claude com­mits in it. It was viewed an un­known num­ber of times, but even likes and boosts passed the thou­sands mark hand­ily, and it gained sig­nif­i­cant trac­tion — as all spu­ri­ous anti-AI hate does —, see­ing 58 replies from 32 unique users. Someone rages about “cognitive sur­ren­der” with no ev­i­dence; an­other sug­gests adding rsync to the fa­mous open-slop­ware black­list. From there, it spread to Hacker News, with 81 com­ments, full of mixed dread, anger, and crow­ing about how this fi­nally proves once and for all no one can use LLMs safely. Among all that was one par­tic­u­lar com­ment which spurred fur­ther the view that the re­gres­sions and bugs were caused by Claude.

This On May 30, 2026, this bur­geon­ing out­rage emer­gently co­a­lesced into a sin­gle fo­cal point: a GitHub is­sue ti­tled “Please Do Not Vibe Fuck Up This Software”, opened against the rsync repos­i­tory. It at­tached a screen­shot of the Mastodon post crit­i­ciz­ing the pro­jec­t’s use of Claude. That’s it. No bug re­port, no tech­ni­cal con­tent, no at­tempt to ac­tu­ally as­cer­tain if the con­cern was real or jus­ti­fied; just 350+ com­ments rang­ing from thought­ful con­cern to out­right ha­rass­ment (most of the most egre­gious, un­rea­son­able, and out­right vi­o­lent com­ments have since been deleted; few thought to pre­serve them).

The thread did not stop at words. It even­tu­ally es­ca­lated to, at one point, vi­sual de­pic­tions of fan­tasies of vi­o­lence, when one user posted a now deleted com­ment in­clud­ing My Little Pony draw­ings of them­selves stran­gling the “project jan­i­tor that pushed vibecoded com­mits”:

Completing the in­ter­net out­rage cy­cle, this is­sue in turn spread to Hacker News, gen­er­at­ing hun­dreds more com­ments. Some at­tempted to point at the num­ber of re­gres­sions af­ter the in­tro­duc­tion of Claude — “The Linux Mint Timeshift tool has an is­sue open doc­u­ment­ing a num­ber of re­gres­sions that are cur­rently open on the rsync is­sues page, that were only in­tro­duced post-vibecod­ing” — as ev­i­dence that it was worse. Others pointed out that those re­gres­sions were not caused by Claude, and in re­sponse, the goal­posts were moved again. Over and over, the core theme was one cen­tral claim, re­peated every­where: Claude-assisted de­vel­op­ment in­tro­duced bugs into a pre­vi­ously sta­ble tool. AI is cog­ni­tive sur­ren­der, is co­caine, is loss of craft, and the users are right to be an­gry as a re­sult:

People are very jus­ti­fi­ably an­gry that a very sta­ble, well trusted tool, has started to im­me­di­ately go down­hill… all be­cause the main dev is vibecod­ing that soft­ware. — fao_ on Hacker News

People are very jus­ti­fi­ably an­gry that a very sta­ble, well trusted tool, has started to im­me­di­ately go down­hill… all be­cause the main dev is vibecod­ing that soft­ware.

However, this is­n’t does­n’t have to be a ques­tion solved only on the ba­sis of — iron­i­cally — vibes. This is some­thing that could be, at least to a de­gree, em­pir­i­cally tested. Some even pointed that out:

On Lobste.rs, in re­sponse to the Medium es­say Tridge him­self posted in re­sponse, fi­nally some users like bo­ra­malper be­gin to ac­tu­ally ask for ev­i­dence one way or an­other:

It’d be in­ter­est­ing if some­one ac­tu­ally did a timechart of re­gres­sions af­ter each re­lease (if at all pos­si­ble) to see if the num­ber ac­tu­ally went up re­cently or not. — bo­ra­malper on Lobsters

It’d be in­ter­est­ing if some­one ac­tu­ally did a timechart of re­gres­sions af­ter each re­lease (if at all pos­si­ble) to see if the num­ber ac­tu­ally went up re­cently or not.

User bit­shift replied: “I would also love to see such a chart. It would­n’t be com­pletely in­for­ma­tive… But at least it would be some­thing ob­jec­tive we could mea­sure.”

This analy­sis is that chart. Or, well, as best as it can be made, given the lim­i­ta­tions of the data (see the pre­vi­ous sec­tion).

2 · Executive Summary

36 re­leases with bug data, span­ning v2.4.6 to v3.4.3

2 re­leases have Claude com­mits: v3.4.2 (9 Claude, 0.00 sev/​10c) and v3.4.3 (28 Claude, 3.29 sev/​10c)

The Claude re­leases bracket the IQR in op­po­site di­rec­tions: v3.4.2 is be­low the IQR, v3.4.3 is above it. Neither is an out­lier.

Exact per­mu­ta­tion test p-value = 46%: pick any 2 re­leases at ran­dom, you’d score as bad or worse 46% of the time. This is the strongest avail­able test and it finds noth­ing.

Fisher’s ex­act test p-value = 74%: Claude re­leases are no more likely to fall above the his­tor­i­cal me­dian than any other re­leases (odds ra­tio 1.06).

The his­tor­i­cal mean is 1.8× the Claude mean (2.95 vs 1.65 sev/​10c)

v3.4.1 (59 bugs / 9 com­mits, no Claude) is an out­lier but be­longs in the base­line — it is a re­lease, and the dis­tri­b­u­tion al­ready cap­tures it

3 · The Metric

The analy­sis uses a sin­gle met­ric: sever­ity-weighted bugs per 10 com­mits (sev/10c). Each bug is nor­mal­ized to a 0 – 1 sever­ity score (its LLM-assigned sever­ity di­vided by 100), and those scores are summed per re­lease in­stead of sim­ply count­ing bugs. The raw bug count is also shown in the table for ref­er­ence, but sev/​10c dri­ves all sta­tis­ti­cal tests.

sev/​10c = (Σ sever­ity/​100 ÷ to­tal_­com­mits) × 10

How com­mits are as­signed to re­leases

Every com­mit on the de­fault branch was or­dered by com­mit­ter date to pro­duce a se­quen­tial time­line. Each git tag points to a spe­cific com­mit in this time­line. A re­lease’s range is all com­mits be­tween the pre­vi­ous tag and its own tag. Pre-release tags (“pre”, “rc”) are skipped as bound­aries and ab­sorbed into their fi­nal re­lease. Every com­mit be­longs to ex­actly one re­lease.

How bugs are found and as­signed to re­leases

Bug re­ports come from three sources:

GitHub is­sues in the rsync repos­i­tory (collated via the GitHub REST API),

the rsync Bugzilla in­stance (collected via the API),

and the rsync mail­ing list.

GitHub is­sues and mail­ing-list bugs are at­trib­uted to the most re­cent re­lease that shipped be­fore the bug was re­ported. For Bugzilla, each en­try has a “Version” field that ex­plic­itly states which re­lease the bug was re­ported against, and bugs are at­trib­uted to that re­lease.

Severity scor­ing

To con­trol for bug sever­ity — so that, as some­one on HN said, a typo in a but­ton and a CVE aren’t rated equally — every bug re­port was scored for sever­ity on a 0 – 100 scale. The scorer is Qwen 3 35B, a small open-weight lan­guage model, prompted as a se­nior re­li­a­bil­ity en­gi­neer as­sess­ing real-world im­pact. Each bug re­port was given to the model as its ti­tle and body text (truncated to 3,000 char­ac­ters), along with the fol­low­ing rubric:

All three bug sources — GitHub is­sues, Bugzilla, and the rsync mail­ing list — were scored. Bugzilla and mail­ing list re­ports had only a ti­tle (no body), so the model scored those from the ti­tle alone. The model was in­structed to fall back on the ti­tle and lean to­ward the mid­dle of the range (40 – 60) when the body did­n’t pro­vide enough in­for­ma­tion. The model was also told to out­put only a sever­ity in­te­ger via struc­tured out­put (JSON schema), so there were no free-text re­sponses to parse. Scoring was done at tem­per­a­ture 0 for de­ter­min­ism — the same in­put al­ways pro­duces the same score.

Issues scored sever­ity 0 — fea­ture re­quests, spam, off-topic rants about AI, empty sub­mis­sions — are ex­cluded from bug counts by de­fault. This mat­ters be­cause some re­leases at­tracted a lot of noise on GitHub. v3.4.2 had four is­sues filed; the model scored all four at sever­ity 0 (a fea­ture-re­quest op­tion, a miss­ing tar­ball ques­tion, and two more fea­ture re­quests).

Example scores from the data­base, one per tier:

Why the re­lease is the unit of analy­sis

Why group com­mits by re­lease, bugs by re­lease, and then as­cer­tain the cor­re­la­tion — or lack thereof — be­tween Claude com­mits and bugs through the in­ter­me­di­ary of re­leases? This is for two rea­sons.

First, be­cause the claim that the crit­ics are mak­ing is also, it­self, made in terms of re­leases: that hav­ing any Claude com­mits in a re­lease makes the whole re­lease more buggy as a whole in a no­tice­able way, not just that Claude-authored com­mits may in­tro­duce more bugs; the lat­ter is a dif­fer­ent met­ric, be­cause later Claude- or hu­man-au­thored com­mits could cor­rect for those bugs within the same re­lease, and no­body would then no­tice as part of the re­lease, and over­all it would­n’t mat­ter to users; ad­di­tion­ally, it’s sim­ply im­por­tant, as stated else­where, to meet the claim of the crit­ics where it’s at. If this forces them to make their claims more nu­anced — or oth­er­wise move the goal­posts — then mis­sion ac­com­plished.

Second, it’s a prob­lem of at­tri­bu­tion: the vast, vast ma­jor­ity of bugs do not state ex­actly which com­mit caused them, be­cause do­ing so would re­quire ex­ten­sive re­search and analy­sis that is of­ten not worth it in fa­vor of sim­ply fix­ing-for­ward, and even if that analy­sis was done — via some­thing like git bi­sect — it would­n’t nec­es­sar­ily re­sult in any­thing use­ful, or any­thing at all. Many bugs can re­sult from a com­bi­na­tion of mul­ti­ple com­mits, of­ten sep­a­rated sig­nif­i­cantly over time, where it’s un­clear whether one com­mit or the other re­ally in­tro­duced the bug. Or, one com­mit can re­veal sev­eral la­tent bugs in­tro­duced by other com­mits at once, and so on.

Why bugs and com­mits?

The crit­ics’ claim is sim­plis­tic, ab­solute, and uni­ver­sal­is­tic: the rate of bugs in the Claude-exposed re­leases went up. Therefore, the sim­plest hon­est re­sponse is to ana­ly­ize pre­cisely what is be­ing claimed: bugs, com­mits, re­leases, and Claude-exposed com­mits. If the Claude re­leases sit in the mid­dle of the his­tor­i­cal dis­tri­b­u­tion, the bur­den shifts to the crit­ics to ex­plain why this par­tic­u­lar mid­dle is some­how worse than all the other mid­dles that came be­fore it. Even by weight­ing by sever­ity, I feel that I am giv­ing ex­ten­sive gen­eros­ity to the anti-AI point in all this, but enough of the more in­tel­li­gent crit­ics brought it up that I found it worth it.

Even if that re­sults in is shift­ing the con­ver­sa­tion to­ward a more nu­anced dis­cus­sion of the qual­ity and type and user im­pact of the bugs in the re­leases, it will al­ready have been a ma­jor win for the pro-AI crowd, and a shift­ing of the goal­posts for the anti-AI crowd, and then we can do fur­ther analy­sis based on that. And the bal­l’s in the anti-AI court for that game.

What this ap­proach does not do

I’m aware that this met­ric does not con­trol for com­mit com­plex­ity or se­cu­rity in­ten­sity. It is a blunt in­stru­ment. But the crit­ics’ ac­cu­sa­tion is also blunt: “Claude is mak­ing things worse.” A blunt in­stru­ment is what is re­quired in re­sponse. Blood begets blood.

4 · Results

Claude Releases

Before we jump into deeper analy­sis, let’s just look at the two Claude re­leases them­selves, to get a sense for them:

v3.4.2

0.00 sev/​10c

0 bugs · 50 com­mits · 9 Claude

0th per­centile (rank 0 of 35)

v3.4.3

3.29 sev/​10c

17 bugs · 34 com­mits · 28 Claude

77th per­centile (rank 27 of 35)

If that does­n’t look like a red flag to you, you’d be right.

Exact Permutation Test

So the ques­tion is: are the Claude re­leases un­usu­ally buggy, or could you eas­ily pull a group just as bad out of the his­tor­i­cal dis­tri­b­u­tion by dumb luck? The way you an­swer that ques­tion sta­tis­ti­cally is an ex­act per­mu­ta­tion test, which just enu­mer­ates all pairs of two re­leases and asks: what frac­tion have a mean bug rate as bad or worse than the one we ac­tu­ally ob­served? That frac­tion is the p-value of the hy­poth­e­sis un­der test.

46%

ex­act per­mu­ta­tion test p-value (one-sided, H₁: Claude mean > his­tor­i­cal)

272 of 595 pos­si­ble groups of 2 his­tor­i­cal re­leases have mean sev/​10c ≥ 1.65. Nearly half. The Claude re­leases sit right in the mid­dle of the per­mu­ta­tion dis­tri­b­u­tion — there is noth­ing ex­treme about them.

Test sta­tis­tic: mean sev/​10c per group · Claude group mean: 1.65 · Historical mean: 2.95

What this p-value tells us is that the hy­poth­e­sis that Claude makes re­leases worse has, at least so far, about as much pre­dic­tive power as a coin flip: if you closed your eyes and picked 2 re­leases at ran­dom, you’d do as bad or worse nearly half the time. There’s noth­ing un­usual about the Claude group.

Fisher’s Exact Test

The per­mu­ta­tion test asks: how likely is it that a ran­dom group of re­leases scores as badly as the Claude group? But there’s an­other way to pose the ques­tion: are Claude re­leases more likely than non-Claude re­leases to fall above the his­tor­i­cal me­dian? That’s a text­book 2×2 con­tin­gency table, and the stan­dard test for it is Fisher’s ex­act test.

74%

one-sided p-value (H₁: Claude more likely above me­dian)

Fisher’s ex­act test asks: if we split all re­leases at the his­tor­i­cal me­dian (0.74 sev/​10c), are these Claude re­leases sig­nif­i­cantly buggy than pre­vi­ous re­leases (more likely to land above the me­dian)? With a p-value of 74%, the an­swer is a de­ci­sive no. The odds ra­tio is 1.06 — es­sen­tially 1:1. Claude re­leases are no more likely to be above the me­dian than any other re­leases.

Odds ra­tio: 1.06 · Median: 0.74 sev/​10c

To em­pha­size, this does not mean that all Claude re­leases in the fu­ture will not be more buggy. We don’t have nearly enough data to build a model and ex­trap­o­late out like that, and that’s not what a Fisher’s ex­act test is for. The point that’s be­ing made here is that these spe­cific re­leases are not at all no­table; if no one had known they were AI, no one would have cared or no­ticed any­thing out of the or­di­nary, and there is no ev­i­dence with which to con­clude that Claude made any­thing worse yet, un­like the ob­jec­tive, ab­so­lutist, uni­ver­sal claims made by crit­ics.

The Distribution

In case you’re not con­vinced, here’s a vi­sual aid, show­ing where these re­leases fall in the dis­tri­b­u­tion of all prior re­leases:

mid­dle 50%

v3.4.2

v3.4.3

0.010.1110100

Historical Claude

Middle 50% (IQR)

Outside IQR

How to read this graph: Each dot is a re­lease. The shaded green band is the in­terquar­tile range — the mid­dle 50% of his­tor­i­cal re­leases, from 0.29 to 2.59 sev/​10c. The darker re­gions on ei­ther side are the lower and up­per quar­ters.

This is an­other way of say­ing the same thing the pre­vi­ous two tests said, but more in­tu­itively: the Claude re­leases (green dots) bracket the IQR in op­po­site di­rec­tions. v3.4.2, with zero real bugs, sits just be­low the IQR; v3.4.3 sits just above it. They bracket the mid­dle of the dis­tri­b­u­tion in op­po­site di­rec­tions. Neither is a neg­a­tive out­lier, and since they’re on ei­ther side of the IQR, there’s no ev­i­dence Claude us­age bends re­leases in ei­ther di­rec­tion.

Commit Rate

One pos­si­ble ob­jec­tion I’ve seen is that while per­haps the de­fect rate of Claude-authored com­mits is not worse than hu­man-au­thored ones, Claude sped up de­vel­op­mend so much — due to “vibe cod­ing” per­haps — that the to­tal num­ber of bugs in each re­lease got too high for com­fort any­way, in which case it does­n’t mat­ter that the de­fect rate per com­mit is­n’t so bad, be­cause that’s not what down­stream users ex­pe­ri­ence. We can check this, though:

p=88%

ex­act per­mu­ta­tion test: do Claude re­leases have more com­mits?

Claude re­leases av­er­aged 42 com­mits; non-Claude re­leases av­er­aged 185. If you pick any 2 re­leases at ran­dom, you’d see as many or more com­mits 88% of the time.

Your browser does not sup­port the au­dio el­e­ment.

Listen to ar­ti­cle

This con­tent is gen­er­ated by Google AI. Generative AI is ex­per­i­men­tal

[[duration]] min­utes

Since re­leas­ing Gemma 4 two months ago, we’ve been con­tin­u­ously work­ing to ex­pand its ca­pa­bil­i­ties. First, we in­tro­duced Multi-Token Prediction (MTP) to ac­cel­er­ate in­fer­ence, and just a cou­ple of days ago, we re­leased a 12B model to bridge the gap be­tween our E4B and 26B MOE mod­els.

Today, we are re­leas­ing new check­points op­ti­mized with Quantization-Aware Training (QAT) to make Gemma 4 even more ef­fi­cient, so you can run mod­els lo­cally on every­day edge de­vices and con­sumer GPUs.

By sim­u­lat­ing quan­ti­za­tion dur­ing train­ing, QAT min­i­mizes qual­ity loss when the model is com­pressed. This re­lease in­cludes QAT check­points for the pop­u­lar Q4_0 quan­ti­za­tion for­mat as well as a novel quan­ti­za­tion for­mat spe­cial­ized for mo­bile use cases. Using this mo­bile for­mat, we’ve re­duced the mem­ory foot­print of Gemma 4 E2B to 1GB. Together, these dra­mat­i­cally re­duce mem­ory re­quire­ments while pre­serv­ing the ca­pa­bil­i­ties and qual­ity you ex­pect from Gemma 4.

Keeping model qual­ity while mak­ing them smaller

Quantization is a key tech­nol­ogy to run mod­els on con­sumer hard­ware by re­duc­ing their mem­ory foot­print while also ac­cel­er­at­ing de­code speed. However, stan­dard Post-Training Quantization (PTQ) of­ten leads to per­for­mance degra­da­tion. Instead of sim­ply quan­tiz­ing the model af­ter train­ing, QAT in­te­grates the quan­ti­za­tion process di­rectly into train­ing. While PTQ is al­ready ef­fec­tive at pre­serv­ing qual­ity, our QAT re­sults yield even higher over­all qual­ity com­pared to stan­dard PTQ base­lines.

We ap­plied this QAT recipe to the pop­u­lar Q4_0 for­mat to max­i­mize per­for­mance for all the mod­els. For the edge mod­els (E2B and E4B), we rethought how we ap­proach quan­ti­za­tion with a spe­cial mo­bile-spe­cial­ized quan­ti­za­tion schema.

Saving on VRAM and Storage

Below are the ap­prox­i­mate mem­ory re­quire­ments in­di­cat­ing how much VRAM is re­quired to load the mod­els:

Optimizing for mo­bile de­vices un­der the hood

Standard com­pres­sion for­mats are of­ten hard for mo­bile proces­sors to run ef­fi­ciently. To en­sure Gemma 4 per­forms smoothly on mo­bile, we en­gi­neered a cus­tom mo­bile-quan­ti­za­tion schema de­signed for edge hard­ware:

Static ac­ti­va­tions: Normally, mod­els waste pro­cess­ing power cal­cu­lat­ing how to scale data on the fly. We pre-cal­cu­late these set­tings dur­ing train­ing, which re­duces work­load on mo­bile chips and makes re­sponses faster.

Channel-wise quan­ti­za­tion: We struc­tured the com­pressed data to fit the de­sign of mo­bile ac­cel­er­a­tors. This al­lows the phone to run cal­cu­la­tions na­tively with­out need­ing slow workarounds.

Targeted 2-bit quan­ti­za­tion: We heav­ily com­pressed (to 2-bit) the spe­cific parts of the model that gen­er­ate to­kens, while keep­ing the core rea­son­ing lay­ers at higher pre­ci­sion. This saves stor­age with­out mak­ing the model less smart.

Embedding and KV cache op­ti­miza­tion: We fo­cused com­pres­sion on the mod­el’s vo­cab­u­lary list and its short-term mem­ory. This dras­ti­cally re­duces the ac­tive mem­ory foot­print, let­ting you have long chats with­out run­ning out of space.

Because our au­dio and vi­sion en­coders are not needed in many use cases, you can op­ti­mize your mem­ory foot­print even fur­ther by de­ploy­ing only the modal­i­ties you need. For ex­am­ple, the Gemma 4 E2B text-only model (without Per-Layer Embeddings) re­quires less than 1 GB of mem­ory.

Get started to­day

To make those mod­els eas­ily us­able with your pre­ferred work­flow, we’ve part­nered with pop­u­lar de­vel­oper tools across the ecosys­tem to seam­lessly sup­port the Gemma 4 QAT check­points start­ing to­day:

Download the weights: Access the Q4_0 and mo­bile model weights right now on Hugging Face. We’ve tai­lored the for­mats to fit your work­flow: GGUF for­mats are ready for use with llama.cpp, and com­pressed ten­sors are pro­vided for vLLM. For every­thing else, we share un­quan­tized check­points that can be con­verted and quan­tized into for­mats sup­port­ing Q4_0.

Integrate & learn: Explore our doc­u­men­ta­tion to learn how to best de­ploy the QAT check­points.

Try on your desk­top: Easily down­load, man­age, and run Gemma 4 QAT mod­els lo­cally on your desk­top us­ing user-friendly in­ter­faces like llama.cpp, Ollama and LM Studio.

Deploy on-de­vice: Use Google’s light­weight LiteRT-LM run­time for op­ti­mized edge de­ploy­ment or run the mod­els di­rectly on the web with Transformers.js

Use your fa­vorite de­vel­op­ment tools: Serve larger mod­els ef­fi­ciently with SGLang and vLLM, op­ti­mize for Apple Silicon with MLX. Use the MTP QAT check­points to pre­serve the speedup of MTP while quan­tiz­ing the mod­els. Fine-tune weights di­rectly us­ing Hugging Face Transformers and Unsloth.

We can’t wait to see what you build with Gemma 4 run­ning lo­cally!

The en­ergy-ef­fi­cient de­sali­na­tion sys­tem pro­duces fresh wa­ter with­out chem­i­cal ad­di­tives and trans­forms left­over salts into use­ful ma­te­ri­als.

The United Nations es­ti­mates that 2.2 bil­lion peo­ple lack safely man­aged drink­ing wa­ter, and com­mu­ni­ties from California to the Middle East rely on de­sali­na­tion plants to con­vert ocean wa­ter to fresh wa­ter. Common de­sali­na­tion tech­niques, such as re­verse os­mo­sis and ther­mal dis­til­la­tion, are en­ergy-in­ten­sive, re­quire pre- and post-wa­ter treat­ment, and leave be­hind a con­cen­trated salt­wa­ter byprod­uct called brine. The brine byprod­uct wreaks havoc on sea life when it’s de­posited back into the ocean by rais­ing the salt level and low­er­ing oxy­gen in the wa­ter.

But a novel ap­proach de­vel­oped at the University of Rochester of­fers a way to over­come these draw­backs. Researchers at URochester’s Institute of Optics de­vel­oped a new so­lar-ther­mal de­sali­na­tion process to pro­duce fresh wa­ter in an en­ergy-ef­fi­cient way that does not leave be­hind brine and re­quires no chem­i­cal ad­di­tives to pre-treat the wa­ter. A team led by Chunlei Guo, a pro­fes­sor of op­tics and of physics and a se­nior sci­en­tist at URochester’s Laboratory for Laser Energetics, de­scribes their method in a pa­per pub­lished in Light: Science & Applications.

The tech­nol­ogy uses so­lar pan­els made of black metal etched with fem­tosec­ond lasers to make the sur­face su­per light-ab­sorb­ing and su­per­wick­ing—or ex­tremely at­trac­tive to wa­ter. The pan­els have a laser-treated ac­tive re­gion that pulls a thin layer of wa­ter across the sur­face, ab­sorbs nearly all so­lar ra­di­a­tion, dis­tills the wa­ter, and de­posits the left­over salts and min­er­als into the pan­el’s un­treated sides or “passive” re­gion so that the salt does not clog the ac­tive re­gion and dis­rupt con­tin­u­ous de­sali­na­tion.

Leveraging the ‘coffee ring’ ef­fect

Guo says other re­searchers have de­vel­oped so­lar-ther­mal de­sali­na­tion tech­niques that work well in lab ex­per­i­ments us­ing sim­u­lated sea­wa­ter made of only wa­ter and sodium chlo­ride. As the wa­ter evap­o­rates, the sodium chlo­ride crys­tal­lizes in a grainy and porous fash­ion al­low­ing wa­ter to pass through to dis­solve the salt. The so­lar pan­els, mean­while, can be eas­ily cleaned.

But real ocean has a much more com­plex com­po­si­tion, and these sys­tems tend to en­counter is­sues when tested in the field. Unlike sodium chlo­ride, many other com­po­nents in sea­wa­ter, such as mag­ne­sium- and cal­cium-based ma­te­ri­als, crys­tal­lize in a crusty and non-porous fash­ion on the so­lar pan­el’s sur­face, clog­ging it. Eventually, wa­ter can no longer seep through. This is the same phe­nom­e­non as your shower head clog­ging over time or your teapot lined with scales, ex­cept that sea­wa­ter con­tains hun­dreds of times more salts than your tap wa­ter.

“Mining lithium from the earth has proven to be very tax­ing from an en­ergy and en­vi­ron­men­tal stand­point, so pulling lithium di­rectly from salt­wa­ter could be a very im­por­tant fu­ture route.”

“Mining lithium from the earth has proven to be very tax­ing from an en­ergy and en­vi­ron­men­tal stand­point, so pulling lithium di­rectly from salt­wa­ter could be a very im­por­tant fu­ture route.”

To keep their so­lar panel sur­face from gum­ming up sim­i­larly, Guo’s team pre­cisely etched the black met­al’s grooves so the var­i­ous salts and min­er­als in ocean wa­ter would sim­ply slough off. They also lever­aged a phys­i­cal phe­nom­e­non that has plagued clumsy javaphiles for cen­turies: the cof­fee ring ef­fect.

“If you drop cof­fee on a sur­face, even­tu­ally the wa­ter evap­o­rates, and there’s a ring left at the outer edge that is the con­cen­trated cof­fee par­ti­cles,” says Guo. “We use that same prin­ci­ple to ad­vance the salts to the pas­sive re­gion.”

Testing their so­lar-ther­mal de­sali­na­tion tech­nique us­ing sam­ples of wa­ter from the Pacific, Atlantic, and Indian Oceans, Guo and his team were able to make the sur­face self-clean­ing. In other words, it ex­tracted fresh­wa­ter and di­rected the re­main­ing salts to the pas­sive re­gion where they could be later col­lected with­out re­duc­ing the pan­el’s ef­fi­ciency.

Turning waste into re­sources

One of the new de­sali­na­tion method’s dis­tinct ad­van­tages is that in­stead of leav­ing be­hind brine that must be dis­posed of or processed, it ex­tracts nearly 100 per­cent of the salts in solid form. This could not only pro­duce an abun­dant sup­ply of table salt, but it could also be used to ex­tract more pre­cious min­er­als, in­clud­ing lithium, which is used in the lithium-ion bat­ter­ies that power elec­tric ve­hi­cles and other elec­tron­ics.

In a re­lated pa­per in the Journal of Materials Chemistry A, Guo and his col­leagues show how they can use the same su­per­wick­ing so­lar pan­els to sep­a­rate lithium from the rest of other salts in de­sali­na­tion. Embedding nanopar­ti­cles made of hy­dro­gen ti­tanate in the tiny grooves of the black metal sur­face iso­lates the lithium from other salts and min­er­als.

“Mining lithium from the earth has proven to be very tax­ing from an en­ergy and en­vi­ron­men­tal stand­point, so pulling lithium di­rectly from salt­wa­ter could be a very im­por­tant fu­ture route,” says Guo.

Using wa­ter sam­ples from Great Salt Lake, the re­searchers ex­tracted about 50 per­cent of the lithium from the salts left be­hind by the de­sali­na­tion process.

Guo says now that the su­per­wick­ing de­sali­na­tion tech­nol­ogy has been demon­strated in proofs of con­cept on small-scale de­vices, he sees the tech­nol­ogy in­her­ently scal­able, ca­pa­ble of im­prov­ing global ac­cess to drink­ing wa­ter and build­ing more sus­tain­able sup­ply chains for pre­cious min­er­als.

The National Science Foundation, the Bill & Melinda Gates Foundation, and Worldwide Universities Network sup­ported this re­search. Guo’s col­leagues from the Institute of Optics who con­tributed to the re­search in­clude Senior Scientist Subash Singh, alum­nus Ran Wei ’24 (PhD), PhD stu­dents Luheng Tang and Tainshu Xu, and Mingjiang Ma.