Today, the European Parliament al­lowed the sus­pi­cion­less mass scan­ning of pri­vate com­mu­ni­ca­tions (“Chat Control 1.0”) to pass, a mea­sure it had re­jected twice in March. Although a ma­jor­ity of vot­ing Members of the European Parliament (MEPs) ac­tu­ally op­posed the reg­u­la­tion (314 against, 276 in fa­vor, 17 ab­sten­tions), the mo­tion to re­ject it failed to se­cure the re­quired ab­solute ma­jor­ity of 361 votes. As a re­sult, mass scan­ning is now per­mit­ted again un­til 2028.

A sym­bolic ex­emp­tion was adopted for en­crypted com­mu­ni­ca­tions—though in prac­tice, ser­vice providers do not scan these any­way. Furthermore, while a ma­jor­ity of vot­ing MEPs wanted to re­strict the scan­ning of pri­vate com­mu­ni­ca­tions strictly to sus­pects iden­ti­fied by the ju­di­ciary (322 to 255 votes), this amend­ment like­wise fell short of the re­quired ab­solute ma­jor­ity.

Dr. Patrick Breyer, civil rights ac­tivist and for­mer Member of the European Parliament (MEP), warns of the con­se­quences:

“The fact that Chat Control is mov­ing for­ward against the will of the ma­jor­ity of vot­ing MEPs is a farce and dam­ages democ­racy. Our chil­dren are the real losers in this un­de­mo­c­ra­tic process. The pas­sage of a gen­uine, per­ma­nent child pro­tec­tion reg­u­la­tion is now in se­ri­ous jeop­ardy. The Council will never agree to a des­per­ately needed par­a­digm shift as long as they can sim­ply stick to the old ap­proach of sus­pi­cion­less scan­ning at the whim of the tech in­dus­try.”

Despite the leg­isla­tive de­feat, Breyer re­mains de­fi­ant re­gard­ing the up­com­ing ne­go­ti­a­tions:

“Today’s vote on the in­terim reg­u­la­tion was a set­back, but the po­lit­i­cal bat­tle over the per­ma­nent ‘Chat Control 2.0’ is just get­ting started. The re­sis­tance we saw in Parliament to­day was so strong that find­ing a ma­jor­ity for per­ma­nent, sus­pi­cion­less mass scan­ning in fu­ture ne­go­ti­a­tions is a com­plete pipe dream.”

Breyer fun­da­men­tally re­jects the mass sur­veil­lance ap­proach:

“Trying to pro­tect chil­dren with sus­pi­cion­less mass sur­veil­lance is like fran­ti­cally mop­ping the floor while the faucet is still run­ning. Blanket chat con­trol is just as un­ac­cept­able as in­dis­crim­i­nately open­ing every­one’s phys­i­cal mail. For five years, this failed sys­tem has served as a smoke­screen to de­lay real ac­tion, all while over­whelm­ing the po­lice with false alarms. We need more child pro­tec­tion, not less—but we need ef­fec­tive pro­tec­tion, not the il­lu­sion of se­cu­rity.”

What hap­pens next?The in­terim reg­u­la­tion passed to­day will re­main in ef­fect un­til 2028, or un­til an agree­ment on a per­ma­nent reg­u­la­tion is reached. Negotiations for the per­ma­nent law will re­sume in September. The core dis­pute be­tween the EU Parliament, mem­ber state gov­ern­ments, and the EU Commission re­mains the scan­ning of pri­vate chats: should it be in­dis­crim­i­nate, or tar­geted at crim­i­nal sus­pects?

What changes with the re­turn of Chat Control 1.0—and what stays the same:

What is com­ing back: US tech com­pa­nies are once again al­lowed to scan pri­vate mes­sages with­out a war­rant or prior sus­pi­cion. This af­fects di­rect mes­sages on plat­forms like Instagram, Discord, Snapchat, Skype, and Xbox, as well as emails via Google’s Gmail and Apple’s iCloud.

What re­mains un­changed: Public so­cial me­dia posts and files hosted in cloud stor­age could al­ready be scanned with­out this law. Furthermore, pri­vate mes­sages can al­ways be re­ported by users, or mon­i­tored by au­thor­i­ties us­ing tar­geted, court-or­dered wire­tap­ping.

What is still NOT be­ing scanned: End-to-end en­crypted chats, such as those on WhatsApp, have al­ways been ex­empt from these scans. Additionally, European providers of mes­sag­ing and email ser­vices have never im­ple­mented chat con­trol mea­sures.

Why Chat Control is the wrong ap­proach:

Since 2022, the vol­ume of sus­pected abuse re­ports from the US has al­ready dropped by 50 per­cent due to the grow­ing use of mes­sage en­cryp­tion.

According to EU Commission fig­ures, mass scan­ning of pri­vate chats ac­counted for only 36 per­cent of all abuse re­ports in 2024 (the ma­jor­ity came from pub­lic posts and cloud stor­age).

The German Federal Criminal Police Office (BKA) re­ports that 48 per­cent of all in­com­ing alerts are not crim­i­nally rel­e­vant in the first place.

Crime sta­tis­tics re­veal that 40 per­cent of the re­sult­ing in­ves­ti­ga­tions ac­tu­ally tar­get mi­nors them­selves.

Under the chat con­trol sys­tem, an es­ti­mated 99 per­cent of re­ports gen­er­ated by Meta con­sist of pre­vi­ously known ma­te­r­ial, which gen­er­ally does lit­tle to stop on­go­ing, ac­tive abuse.

The EU Commission ad­mits there is no ev­i­dence that sus­pi­cion­less scan­ning of pri­vate com­mu­ni­ca­tions has led to an in­crease in crim­i­nal con­vic­tions or in res­cued chil­dren.

Talk of avert­ing a “protection gap” is there­fore highly mis­lead­ing. The most ef­fec­tive law en­force­ment tools—court-or­dered wire­taps, user re­ports, and the scan­ning of pub­lic plat­forms and cloud stor­age—were never at risk and re­main fully in­tact. The only prac­tice that was tem­porar­ily banned since April was the in­dis­crim­i­nate, war­rant­less search­ing of pri­vate, un­en­crypted mes­sages of in­no­cent peo­ple on a hand­ful of US plat­forms.

Background: The dead­lock over a per­ma­nent so­lu­tionIn par­al­lel, ne­go­ti­a­tions are on­go­ing for a per­ma­nent reg­u­la­tion to pro­tect chil­dren from sex­u­al­ized on­line vi­o­lence (the “CSAM Regulation” or “Chat Control 2.0”). In these talks, the EU Parliament is push­ing for a par­a­digm shift in how we ap­proach on­line child safety, de­mand­ing:

Mandatory, tar­geted de­tec­tion or­ders against ac­tual crim­i­nal sus­pects, rather than blan­ket mass scan­ning left to the tech in­dus­try’s dis­cre­tion.

An EU Child Protection Centre tasked with the sys­tem­atic re­moval of known abuse ma­te­r­ial from the pub­lic in­ter­net.

Strict se­cu­rity stan­dards for mes­sag­ing apps (“Security by Design”) to pre­vent cy­ber groom­ing.

This per­ma­nent leg­is­la­tion has stalled be­cause EU mem­ber states in­sist on main­tain­ing the out­dated ap­proach of vol­un­tary, sus­pi­cion­less scan­ning of pri­vate com­mu­ni­ca­tions. Critics warn that re­peat­edly ex­tend­ing the in­terim rules re­moves the po­lit­i­cal pres­sure needed to reach a vi­able, per­ma­nent agree­ment. Ultimately, cling­ing to the sta­tus quo threat­ens to de­rail real progress on child pro­tec­tion.

Patrick Breyer sums up the prob­lem:“As long as EU gov­ern­ments can use pro­ce­dural loop­holes to con­tin­u­ally ex­tend their com­fort­able sta­tus quo of vol­un­tary, in­dis­crim­i­nate mass scan­ning, they have zero in­cen­tive to en­gage with the Parliament’s tar­geted, legally sound, and far more ef­fec­tive child pro­tec­tion strat­egy.

“The Voices of Survivors: “We need pri­vacy to bring abusers to jus­tice”

Survivors of sex­ual vi­o­lence ex­plic­itly em­pha­size that un­tar­geted Chat Control did not help vic­tims:

Alexander Hanff, sur­vivor of child sex­ual abuse and pri­vacy ad­vo­cate, clar­i­fies:“As a sur­vivor I re­lied on con­fi­den­tial com­mu­ni­ca­tions to tell my story and find jus­tice for 28 school­boys—my­self in­cluded—re­sult­ing in the con­vic­tion of mul­ti­ple of­fend­ers. We sur­vivors need pri­vacy, be­cause with­out it we lose our voice. Chat Control was not cre­ated to pro­tect chil­dren. It was about Big Tech com­pa­nies like Meta or Google want­ing ac­cess to our data for prof­i­teer­ing, and states at­tempt­ing to ex­pand mass sur­veil­lance. The EU Commission has wasted five years and mil­lions of eu­ros on al­go­rithms that can­not pro­tect chil­dren and were never meant to. This money should have been di­verted to real polic­ing, causal re­search, and sup­port for sur­vivors, mil­lions of whom have never re­ceived any sup­port at all.”

Marcel Schneider* (name changed), a sur­vivor who has been su­ing Meta in court over its vol­un­tary Chat Control, adds:“Any­one mourn­ing the end of Chat Control has not un­der­stood what ac­tu­ally helps sur­vivors of sex­ual vi­o­lence. Mass sur­veil­lance by cor­po­ra­tions like Meta does not pre­vent abuse. Genuine pro­tec­tion means: delet­ing ma­te­r­ial at the source, proac­tive po­lice work on the Darknet, and apps that are safe by de­sign for chil­dren from the very start.”

Dorothée Hahne, found­ing mem­ber and vice-chair of the sur­vivors’ ini­tia­tive MOGiS e.V. (A Voice for Survivors), em­pha­sizes the dan­ger mass sur­veil­lance poses to vic­tims them­selves:“As sur­vivors, we see our ‘safe spaces’, our pro­tected ar­eas and com­mu­ni­ca­tion chan­nels, en­dan­gered or de­stroyed by this. For sur­vivors, this need is ex­is­ten­tial.“

Thanks for play­ing! You can send me feed­back or try my other game Zanagrams.

Context: Rewriting Bun in Rust

History

When Jarred joined the Zig com­mu­nity about 5 years ago, I de­scribed him as some­one who had strong “beginner en­ergy”. That is, he moved fast and tried a lot of dif­fer­ent stuff, jump­ing head first into prob­lems that he was not yet equipped to solve, lead­ing to mediocre out­comes in terms of en­gi­neer­ing, but learn­ing a whole heck of a lot in the process. I see it as quite a healthy at­ti­tude, par­tic­u­larly for young peo­ple and stu­dents. This is the best way to level up and learn new things.

As he fo­cused his ef­forts on Bun he be­gan to at­tract at­ten­tion. JavaScript be­ing the most pop­u­lar pro­gram­ming lan­guage in the world, there are a lot of po­ten­tial eye­balls on a promis­ing new tool­chain.

This at­ten­tion could have been har­nessed in a few dif­fer­ent ways. For ex­am­ple, he could have eas­ily achieved a solid liv­ing via crowd­fund­ing, even for San Francisco stan­dards. But hav­ing grad­u­ated from the Thiel Fellowship school of thought rather than uni­ver­sity, he was es­sen­tially groomed from a young age into un­crit­i­cally em­brac­ing the Silicon Valley mind­set, and he took ven­ture cap­i­tal.

From the be­gin­ning, Jarred was ap­pre­cia­tive to­wards the Zig pro­ject. He cred­ited Zig on the Bun web­site for the pro­jec­t’s per­for­mance achieve­ments. He set up a monthly do­na­tion to Zig Software Foundation that amounted to $60,000 per year. He did­n’t have to do ei­ther of those things, but he did, and it was pretty cool of him. Even in his blog post that I’m ref­er­enc­ing, he ex­presses what I per­ceive as sin­cere grat­ti­tude to­wards the Zig pro­ject.

However, once Bun be­came a VC-backed startup, he started rac­ing to­wards the fin­ish line. Now, in­stead of work­ing on a free and open source pro­ject, learn­ing and grow­ing with the com­mu­nity, Jarred was run­ning a busi­ness. It was at this point - when he sud­denly be­came a man­ager - that this “beginner en­ergy” started to hit dif­fer­ently for me. It’s one thing to choose a poor work-life bal­ance for one­self; a dif­fer­ent thing en­tirely to de­mand it of oth­ers:

“Oven is go­ing to be a grind, es­pe­cially the first nine months or so. If work-life bal­ance means a lot of time spent not work­ing, it’s prob­a­bly not a good fit.”

Fun fact: peo­ple talk to each other.

I talked to those who in­ter­viewed for a job at Oven. I talked to peo­ple who worked there. Those peo­ple talked to each other. Everybody talked to every­body. The grapevine was large and healthy and full of juicy grapes, and all those grapes con­tained the juice of the same mes­sage: Jarred was a stinky man­ager. Poor com­mu­ni­ca­tion, un­re­al­is­tic ex­pec­ta­tions, low em­pa­thy, no ex­pe­ri­ence. Just a to­tal shit show, from an em­ploy­ment per­spec­tive.

Consequently, al­though Zig com­mu­nity mem­bers were ea­ger to find work cod­ing in Zig on the clock, most of the tal­ent pool steered clear of Oven and Bun.

At the same time, a rift be­tween Zig and Jarred started widen­ing. His sin­gu­lar fo­cus on pro­duc­tiv­ity and his star­tup’s exit strat­egy was in­creas­ingly at odds with my longer term vi­sion for the Zig pro­ject. I re­mem­ber he kept nag­ging me to drop all my other pri­or­i­ties and work on a Language Server Protocol im­ple­men­ta­tion and VSCode in­te­gra­tion, while I had big­ger plans.

The main prob­lem, how­ever, was code qual­ity.

The Zig team reg­u­larly checks in on our users’ pro­jects. We read source code to find out how the lan­guage is af­fect­ing users, we test changes to see how prob­lem­atic break­age might be, and we check for per­for­mance re­gres­sions.

We be­came in­creas­ingly hor­ri­fied at the pro­gram­ming prac­tices we saw in Bun’s code­base. Hacks on top of hacks. Abuse of as­ser­tions. Most of all, reck­lessly speed­ing past fea­ture af­ter fea­ture with very lit­tle time taken for re­flec­tion and elim­i­na­tion of bugs and tech­ni­cal debt. Jarred was al­ready writ­ing slop well be­fore he had ac­cess to LLMs. Now, it’s not our busi­ness to po­lice what our users do, but you may have no­ticed peo­ple scream­ing in our faces about mem­ory safety con­stantly. You can imag­ine how we might want to put some so­cial dis­tance be­tween our­selves and a pro­ject whose ir­re­spon­si­ble soft­ware en­gi­neer­ing prac­tices in­vite the ex­act kind of crit­i­cism that peo­ple are ea­ger to level.

We made fu­tile at­tempts to guide them to­wards bet­ter pro­gram­ming prac­tices. There were a few ex­cep­tional he­roes who did their very best in a dys­func­tional com­pany. You know who you are. But you can’t stop a ris­ing tide.

By this time, we all felt at ZSF that Bun was a net li­a­bil­ity, and this was be­fore RoboBun be­came the #1 con­trib­u­tor. Along with the dis­com­fort of the pub­licly pre­sumed poster child for Zig pro­gram­ming lan­guage ac­tu­ally be­ing the prime ex­am­ple of How Not To Write Zig Code, at some point they would sell out (let’s be hon­est, their vague “sell some cloud some­thing” busi­ness plan was a farce from the get-go), we would re­ceive some neg­a­tive pub­lic­ity by proxy, and we’d stop get­ting that reg­u­lar do­na­tion.

So, when the Anthropic aqui­si­tion fi­nally hap­pened, we at ZSF breathed a sigh of re­lief. When the do­na­tion silently stopped, our bank ac­count was ready for it. When they nei­ther can­celed their monthly meet­ing with us, nor showed up, we were not sur­prised. The re­la­tion­ship was over.

The (re)writing was on the wall. Even within a cou­ple days, we al­ready sus­pected a Rust rewrite was com­ing. And we were root­ing for it! The ac­qui­si­tion by a large AI com­pany was a bur­den, be­cause even the in­di­rect con­nec­tion of Claude be­ing writ­ten in Bun be­ing writ­ten in Zig caused not only a surge of drive by slop con­tri­bu­tions, but also an in­flux of taste­less AI en­thu­sists into Zig com­mu­ni­ties who had to be in­formed that it’s an­ti­so­cial to paste LLM out­put into fo­rum posts. For a mo­ment, I feared Zig’s iden­tity would be­come known col­lo­qui­ally as a pro­gram­ming lan­guage as­so­ci­ated with AI.

When Jarred an­nounced the Rust rewrite, we were ec­sta­tic. It seemed too good to be true. I have to ad­mit, I did­n’t think the tech­nol­ogy was there, to pull off this stunt. But he did it, and now I’m metaphor­i­cally sip­ping de­li­cious tea from a mug that says “It Tastes Like It’s Not My Problem Anymore”.

Addressing the Blog Post

The blog post is ex­pertly writ­ten. It’s al­most like the mar­ket­ing de­part­ment of a tril­lion dol­lar com­pany has a lot of money rid­ing on this ar­ti­cle.

I do have some bones to pick how­ever.

There’s a di­chotomy be­ing pre­sented here where you have to ei­ther choose a “style guide” or a pro­gram­ming lan­guage fea­ture in or­der to avoid bugs. The sleight of hand mis­di­rects the reader away from the main way bugs are elim­i­nated: by ded­i­cat­ing en­gi­neer­ing re­sources to it. You’re not giv­ing TigerBeetle nearly enough credit. Quite sim­ply they put in the time to find and elim­i­nate the bugs, they make an ef­fort to main­tain a healthy re­la­tion­ship with ZSF, and Bun did nei­ther of those things.

The ar­gu­ment for ship­ping all the mil­lion lines of un­re­viewed code is that the test suite is good enough to catch every­thing. Then why are you say­ing you have so many an­noy­ing bugs in the Zig code? What hap­pened to the test suite be­ing suf­fi­cient to catch every­thing? It’s not suf­fi­cient to catch bugs in Zig code but it is suf­fi­cient to catch bugs in 1 mil­lion lines of un­re­viewed slop?

Performance in­crease is at­trib­uted to LTO, which Zig has sup­ported for all of Bun’s ex­is­tence. It used to be en­abled by de­fault un­til we ran into too many LLVM bugs, all of which also af­fect Rust. We prob­a­bly tried to tell you to try en­abling it and you did­n’t lis­ten. We have good ad­vice, damn it!

The post im­plies you were dili­gently fuzzing your Zig code, while dur­ing our calls the Bun team told us that they were not fuzzing any­thing.

The blog post out­lines a bunch of en­gi­neer­ing work done to re­duce bi­nary size, to bet­ter make the case that “Bun is bet­ter in Rust”. But all that en­gi­neer­ing work had noth­ing to do with the rewrite. I think this (specifically the “binary size” sec­tion of the blog post) is pre­cisely why it took so long for the blog post to come out, you were do­ing the en­gi­neer­ing work that you should have done in the Zig code­base since the be­gin­ning. We’ve been try­ing to warn you about your comp­time abuse for years. We even made this time re­port thing specif­i­cally for pro­jects that need to au­dit their use of comp­time/​in­line us­age and com­pile times.

I no­ticed that you ne­glected to men­tion com­pi­la­tion speed. Zig com­piler pro­ject is about 600,000 lines of code - roughly the same size as Bun be­fore the rewrite, and I’m clock­ing 16s to build from scratch with a clean cache, fol­lowed by 90ms for each sub­se­quent edit with in­cre­men­tal com­pi­la­tion en­abled. What are the cor­re­spond­ing mea­sure­ments of Bun post-rewrite?

What Did We Learn Here Today?

The main is­sue here was the re­la­tion­ship break­down, as I’ve out­lined above, noth­ing to do with pro­gram­ming lan­guage fea­tures. Of course, I don’t ex­pect the blog post to ad­mit that. Really, it was well played.

Zooming out a bit, I want to make a few things clear.

One, I’m gen­uinely grate­ful for the do­na­tions ZSF re­ceived from Bun. We spent that money pay­ing con­trib­u­tors to work on Zig.

Two, I ac­tu­ally don’t have any per­sonal crit­i­cisms of Jarred. He has dif­fer­ent taste than me, he wants dif­fer­ent things out of life than me. But I think he’s ac­tu­ally happy and suc­cess­ful ex­actly where he is. He fig­ured out how to ac­com­plish all the stuff in life that he wants. He gets to live out his pro­duc­tiv­ity fan­tasy fever dream, he’s prob­a­bly al­ready su­per wealthy. He has mi­nor tech celebrity sta­tus.

Honestly, I think he did well for him­self, and I don’t wish him any ill will.

I added this para­graph in an up­date to this blog post be­cause it seems like peo­ple are hav­ing a hard time be­liev­ing me when I say it’s not per­sonal, and that I ac­tu­ally ac­cept Jarred for who he is, and ac­tu­ally per­ceive him as suc­cess­ful by his own stan­dards, and in fact gen­uinely happy for him. It’s the truth though. I ac­cept peo­ple who are wildly dif­fer­ent than me. I don’t hold it against peo­ple to have dif­fer­ent tastes than me. And I don’t even hate my op­po­nents in the world of busi­ness. If any­thing we have some­thing in com­mon, we’re both play­ing the same game, al­beit on op­po­site teams. We both love the game though.

That said I’m happy that our busi­ness in­ter­ests are no longer in­ter­twined! As soon as the Internet stops ar­gu­ing in pub­lic about whether the rewrite was good or bad for Bun based on the lan­guage choice, I be­lieve that con­cludes our in­ter­ac­tions.

¯\_(ツ)_/¯

Thanks for read­ing my blog post.

A Postgres rewrite in Rust.

pgrust tar­gets com­pat­i­bil­ity with Postgres 18.3 and matches Postgres’s ex­pected out­put across more than 46,000 re­gres­sion queries.

pgrust is disk com­pat­i­ble with Postgres and can boot from an ex­ist­ing Postgres 18.3 data di­rec­tory.

The goal is to make Postgres eas­ier to change from the in­side: keep the be­hav­ior Postgres-shaped, keep the real Postgres tests as the or­a­cle, and use Rust plus AI-assisted pro­gram­ming to ex­plore deeper server changes.

Follow pgrust

Get pro­ject up­dates by email, in­clud­ing new re­leases, com­pat­i­bil­ity mile­stones, and ar­chi­tec­ture ex­per­i­ments.

Status

pgrust is not pro­duc­tion-ready yet. It is not per­for­mance op­ti­mized yet.

Existing Postgres ex­ten­sions and pro­ce­dural lan­guage ex­ten­sions such as PL/Python, PL/Perl, and PL/Tcl are not gen­er­ally com­pat­i­ble yet. Some bun­dled con­trib mod­ules are al­ready ported, and more com­pat­i­bil­ity may be pos­si­ble over time.

Roadmap

mul­ti­threaded Postgres in­ter­nals

built-in con­nec­tion pool­ing

bet­ter JSON-heavy work­load sup­port

fast fork­ing and branch­ing work­flows

stor­age ex­per­i­ments, in­clud­ing no-vac­uum de­signs

run­time guardrails for bad queries and AI-generated SQL

fewer sud­den bad plan switches

Try It

Try the WebAssembly demo at https://​pgrust.com.

Docker:

docker run -d –name pgrust -e POSTGRES_PASSWORD=secret mal­isper/​pgrust:v0.1 && un­til docker exec -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U post­gres -c ‘\q’ >/dev/null 2>&1; do sleep 1; done && docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U post­gres; docker rm -f pgrust

This uses the psql client in­side the Docker im­age.

mal­isper/​pgrust:lat­est cur­rently points at the same re­lease, but v0.1 is the pinned launch im­age.

Build From Source

ma­cOS:

brew in­stall icu4c openssl@3 libpq

ex­port LIBRARY_PATH=“$(brew –prefix openssl@3)/​lib:${LI­BRARY_­PATH:-}” ex­port PKG_CONFIG_PATH=“$(brew –prefix openssl@3)/​lib/​pkg­con­fig:$(brew –prefix icu4c)/​lib/​pkg­con­fig:${PKG_­CON­FIG_­PATH:-}” ex­port PATH=“$(brew –prefix libpq)/​bin:$PATH”

Debian/Ubuntu:

sudo apt-get up­date sudo apt-get in­stall -y build-es­sen­tial pkg-con­fig li­bicu-dev lib­ssl-dev li­bldap2-dev lib­pam0g-dev post­gresql-client-18

Build:

PGRUST_PGSHAREDIR=“$PWD/vendor/postgres-18.3/share” \ cargo build –release –locked –bin post­gres

Create a data di­rec­tory:

tar­get/​re­lease/​post­gres –initdb \ -D /tmp/pgrust-data \ -L “$PWD/vendor/postgres-18.3/share” \ –no-locale \ –encoding UTF8 \ -U post­gres

Run pgrust:

ulimit -s 65520

RUST_MIN_STACK=33554432 tar­get/​re­lease/​post­gres \ -D /tmp/pgrust-data \ -F \ -c lis­ten_ad­dresses= \ -k /tmp \ -p 5432 \ -c io_method=sync \ -c max_s­tack­_depth=60000

Connect:

psql -h /tmp -p 5432 -U post­gres -d post­gres \ -c “select ver­sion(), 1 + 1 as two”

Regression Tests

Run the Postgres re­gres­sion tests against pgrust:

PGRUST_BIN=“$PWD/target/release/postgres” \ scripts/​run-re­gres­sion

The run­ner uses pgrust’s own –initdb plus the ven­dored Postgres 18.3 test files in this repos­i­tory. It needs a Postgres 18 psql client on PATH; if psql is some­where else, set PGRUST_PSQL=/path/to/psql.

Verified launch re­sult: pgrust matched Postgres’s ex­pected out­put across more than 46,000 re­gres­sion queries.

History

This repos­i­tory now con­tains the newer pgrust im­ple­men­ta­tion that reached the re­gres­sion-test mile­stone.

The older pub­lic im­ple­men­ta­tion is archived on archive/​pre-fa­bled-2026 – 06-23.

Background:

Original pgrust launch: https://​mal­isper.me/​pgrust-re­build­ing-post­gres-in-rust-with-ai/

67% re­gres­sion up­date: https://​mal­isper.me/​pgrust-up­date-at-67-post­gres-com­pat­i­bil­ity-and-ac­cel­er­at­ing/

Four Horsemen roadmap: https://​mal­isper.me/​the-four-horse­men-be­hind-thou­sands-of-post­gres-out­ages/

Feedback

Please open an is­sue if some­thing breaks, if setup is con­fus­ing, or if there is a Postgres im­prove­ment you want to see first.

Contact

Email: main­tain­ers@pgrust.com

Discord: https://​dis­cord.gg/​FZ­Z4db­d­vwU

Project up­dates: https://​pgrust.com/#​up­dates

License

pgrust is li­censed un­der AGPL-3.0. See LICENSE.

Tiny en­gine, im­mense model. Run GLM-5.2 (744B-parameter MoE) on a con­sumer ma­chine with ~25 GB of RAM — in pure C, with zero de­pen­den­cies, by stream­ing ex­perts from disk.

$ ./coli chat 🐦 col­i­brì v1.0 — GLM-5.2 · 744B MoE · int4 · stream­ing CPU ✓ pronto in 32s · res­i­dente 9.9 GB › ciao! ◆ Ciao! 😊 Come posso aiu­tarti oggi?

The idea

A 744B Mixture-of-Experts model ac­ti­vates only ~40B pa­ra­me­ters per to­ken — and only ~11 GB of those change from to­ken to to­ken (the routed ex­perts). So:

the dense part (attention, shared ex­perts, em­bed­dings — ~17B params) stays res­i­dent in RAM at int4 (~9.9 GB);

the 21,504 routed ex­perts (75 MoE lay­ers × 256 ex­perts + the MTP head, ~19 MB each at int4) live on disk (~370 GB) and are streamed on de­mand, with a per-layer LRU cache, an op­tional pinned hot-store, and the OS page cache as a free L2.

The en­gine is a sin­gle C file (c/glm.c, ~1,300 lines) plus small head­ers. No BLAS, no Python at run­time, no GPU.

What’s im­ple­mented

Faithful GLM-5.2 (glm_moe_dsa) for­ward — val­i­dated to­ken-ex­act against a trans­form­ers or­a­cle (teacher-forcing 32/32, greedy 20/20 on a tiny-ran­dom model with the real ar­chi­tec­ture).

MLA at­ten­tion (q/kv-LoRA, in­ter­leaved par­tial RoPE) with com­pressed KV-cache: 576 floats/​to­ken in­stead of 32,768 (57× smaller — GLM-5.2 has 64 heads and no GQA).

DeepSeek-V3-style sig­moid router (noaux_tc, rout­ed_s­cal­ing_­fac­tor), shared ex­pert, first-3-dense lay­ers.

Native MTP spec­u­la­tive de­cod­ing — GLM-5.2′s own multi-to­ken-pre­dic­tion head (layer 78) drafts to­kens that the main model ver­i­fies in one batched for­ward. The head must be int8 (the con­verter does this by de­fault): at int4 draft ac­cep­tance col­lapses to 0 – 4% and spec­u­la­tion never en­gages; at int8 it’s 39 – 59% ac­cep­tance, 2.2 – 2.8 to­kens/​for­ward (community-measured, #8). Lossless — and stays loss­less un­der sam­pling via re­jec­tion sam­pling. Honest caveat from the same mea­sure­ment: on a cold cache each ver­i­fied draft routes to ex­tra ex­perts (~660 → ~1100 ex­pert-loads/​to­ken), so spec­u­la­tion can be a net time loss un­til the cache/​pin warms up — the adap­tive guard and DRAFT=0 are there for that.

True sam­pling — tem­per­a­ture + nu­cleus, de­faults tuned for int4 re­al­ity (0.7 / 0.90; the of­fi­cial 1.0 / 0.95 sam­ples quan­ti­za­tion noise from the tail).

Integer-dot ker­nels (Q8_0-style int8 ac­ti­va­tions, AVX2 mad­dubs): int8 mat­muls 1.4 – 2.5× faster (119 GFLOP/s mea­sured), int4 1.8× in batch — rout­ing de­cided per shape by mea­sure­ment (int4 sin­gle-row stays f32: it mea­sured slower).

MLA weight ab­sorp­tion (DeepSeek trick) for de­code: no per-to­ken k/​v re­con­struc­tion — the query ab­sorbs kv_b, con­text is pro­jected af­ter at­ten­tion. Validated ex­act: TF 32/32 and gen­er­a­tion 20/20 with ab­sorp­tion forced every­where.

Async ex­pert reada­head: while one block of ex­perts is be­ing mul­ti­plied, the ker­nel is al­ready read­ing the next (WILLNEED).

Quantization ker­nels: int8 / packed int4 / packed int2, per-row scales, AVX2, de­quant-on-use. Packing val­i­dated bit-iden­ti­cal to the int8 con­tainer.

DSA sparse at­ten­tion: in progress — the light­ning-in­dexer weights (a ~108 GB ex­trac­tion from the FP8 repo, –indexer con­verter mode) are down­load­ing; the in­dexer for­ward lands next. Until then at­ten­tion is dense and ex­act for con­texts ≤ 2048 to­kens.

Batch-union MoE: in pre­fill (and MTP ver­i­fi­ca­tion), each unique ex­pert of the batch is read once and ap­plied to every po­si­tion that routes to it.

Byte-level BPE to­k­enizer in C (GPT-2-style with Unicode-property regex, 320k merges).

RAM safety: the ex­pert cache is auto-sized from MemAvailable at startup — an hon­est peak pro­jec­tion (working set, KV, MTP row, re­con­struc­tion buffers) so the ker­nel OOM-killer never fires.

Offline FP8→int4 con­verter (c/convert_fp8_to_int4.py): down­loads one shard at a time (~5 GB), de­quants (128×128 block scales), re­quan­tizes to the en­gine’s con­tainer, deletes the shard — the 756 GB FP8 check­point never needs to ex­ist on disk at once. Resumable.

Honest num­bers (WSL2, 12 cores, 25 GB RAM, NVMe via VHDX)

This is not fast. It is a 744B fron­tier-class model an­swer­ing cor­rectly on a ma­chine that costs less than one H100 fan. Warm cache, pinned hot ex­perts and MTP push the use­ful-re­sponse la­tency down con­sid­er­ably; the physics of the disk does the rest.

SSD note

Cold starts are heavy on ran­dom reads (~11 GB/token), but reads don’t mean­ing­fully wear an SSD — col­i­brì’s stream­ing is read-only. The real con­cerns un­der heavy use are (1) swap traf­fic if the sys­tem runs out of RAM (writes do wear the drive — keep a sane –ram bud­get; col­i­brì’s auto-bud­get is de­signed to stay clear of swap) and (2) sus­tained ther­mals: hours at full read duty cy­cle will heat cheaper dri­ves. Monitor drive tem­per­a­ture and health.

Download the model

A pre-con­verted GLM-5.2 int4 model for col­i­brì is avail­able on Hugging Face:

https://​hug­ging­face.co/​jlnsrk/​GLM-5.2-col­ibri-int4

If the MTP files there are still the int4 head (see #8 — sizes 1765523544/2686077736/536747200 = int4, un­us­able), grab the int8 MTP heads from the com­mu­nity clone by matey-0: https://​hug­ging­face.co/​ma­teogr­gic/​GLM-5.2-col­ibri-int4-with-int8-mtp

Download the repos­i­tory and point COLI_MODEL to its di­rec­tory:

COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat

This skips the FP8 → int4 con­ver­sion step en­tirely.

Thanks DatPat for your help!

Quick start

cd c ./setup.sh # checks gcc/​OpenMP, builds, self-tests

# ONE com­mand does every­thing model-side: down­loads GLM-5.2-FP8 shard by shard # (never needs the full 756 GB at once), con­verts to the int4 con­tainer, then # con­verts the MTP head for spec­u­la­tive de­cod­ing. Resumable at any point. # Conversion (only) needs python with: pip in­stall torch safeten­sors hug­ging­face_hub numpy ./coli con­vert –model /nvme/glm52_i4 # ~400 GB free on a real ext4/​NVMe path

# chat — RAM bud­get, ex­pert cache and MTP are all de­tected au­to­mat­i­cally: COLI_MODEL=/nvme/glm52_i4 ./coli chat

The en­gine at run­time is pure C — python is only used by the one-time con­verter.

Experimental res­i­dent CUDA back­end

col­i­brì in­cludes an opt-in CUDA back­end for model-res­i­dent ten­sors. Streaming ex­perts de­lib­er­ately re­main on the orig­i­nal CPU path for now: copy­ing an ex­pert from NVMe to the GPU on every use would only re­place the disk bot­tle­neck with a PCIe bot­tle­neck. Resident quan­tized ten­sors are up­loaded lazily once and reused.

cd c make cuda-test CUDA=1 # q8/​q4/​q2/​f32 ker­nel cor­rect­ness make CUDA=1 # op­tional dense-path ex­per­i­ment (hot ex­perts are con­fig­ured be­low) COLI_CUDA=1 COLI_GPU=0 CUDA_DENSE=1 SNAP=/nvme/glm52_i4 ./glm 64 4 4

Requirements: Linux, an NVIDIA dri­ver, and a CUDA Toolkit un­der /usr/local/cuda (override with CUDA_HOME=/path/to/cuda). CUDA_ARCH=native builds for the GPU in the cur­rent ma­chine; set an ex­plicit ar­chi­tec­ture when cross-com­pil­ing. Requesting CUDA with a CPU-only bi­nary, an in­valid de­vice, or an un­avail­able run­time fails at startup in­stead of silently falling back.

The nor­mal make build and run­time be­hav­ior are un­changed. CUDA de­faults to an ex­pert-only ac­cel­er­a­tor: res­i­dent dense/​at­ten­tion ten­sors stay on CPU be­cause fix­ture mea­sure­ments show that mov­ing them does not help while ex­pert I/O is the bot­tle­neck. CUDA_DENSE=1 keeps the ear­lier all-res­i­dent ex­per­i­men­tal path. A mea­sured PIN pro­file can pro­mote its hottest ex­perts into the per­sis­tent VRAM tier while keep­ing the rest in RAM:

STATS=stats.txt SNAP=/nvme/glm52_i4 ./glm 64 4 4 # col­lect rout­ing fre­quen­cies first COLI_CUDA=1 COLI_GPU=0 CUDA_EXPERT_GB=16 \ PIN=stats.txt PIN_GB=160 SNAP=/nvme/glm52_i4 ./glm 64 4 4 # multi-GPU ex­pert tier, 96 GB to­tal bud­get across six de­vices COLI_CUDA=1 COLI_GPUS=0,1,2,3,4,5 CUDA_EXPERT_GB=96 \ PIN=stats.txt PIN_GB=160 SNAP=/nvme/glm52_i4 ./glm 64 4 4

Selected ex­perts are up­loaded dur­ing startup, so ca­pac­ity fail­ures oc­cur be­fore in­fer­ence and the log re­ports their ex­act ten­sor foot­print. The bud­get is clamped against free VRAM af­ter re­serv­ing the pro­jected dense res­i­dent set and 2 GB of run­time head­room per se­lected de­vice. With COLI_GPUS, CUDA_EXPERT_GB is a to­tal bud­get across the de­vice set; ex­perts are as­signed whole to the least-loaded de­vice that can hold them. A NUMA-local RAM back­ing store is not im­ple­mented yet.

Current lim­i­ta­tions: de­vices use in­de­pen­dent con­texts and syn­chro­nous host-staged ac­ti­va­tion copies—there is no P2P/NCCL de­pen­dency yet. The ker­nels are cor­rect­ness-first cus­tom ker­nels rather than cuBLAS/​Ten­sor Core ker­nels. This draft in­ten­tion­ally makes no end-to-end speedup claim be­fore the full model is bench­marked.

For a re­pro­ducible back­end A/B with­out the full check­point, gen­er­ate the de­ter­min­is­tic 313M-parameter glm_­moe_dsa fix­ture and run fixed-to­ken re­play:

cd c python make_glm_bench_­model.py –output /nvme/colibri-bench-medium –device cuda python bench­mark_cu­d­a_­fix­ture.py –model /nvme/colibri-bench-medium –gpu 0

The fix­ture has ran­dom weights and is not a lan­guage model. It ex­ists only to pre­serve the real MLA/MoE/streaming shapes and com­pare CPU stream­ing, dense-only CUDA, CPU hot-store, and CUDA hot-ex­pert ex­e­cu­tion with iden­ti­cal re­play to­kens.

Useful knobs (env or flags): –temp T to­ken sam­pling tem­per­a­ture (default 0.7 + nu­cleus 0.90 — tuned for int4; 0 = greedy), –topp 0.7 adap­tive ex­pert top-p (30 – 40% less disk), –ngen N max to­kens per an­swer (:piu in chat con­tin­ues a trun­cated one), AUTOPIN=0 dis­able the learn­ing cache’s auto-pin, THINK=1 en­able GLM-5.2′s rea­son­ing block, DRAFT=n MTP draft depth, TF=1 teacher-forc­ing val­i­da­tion, PILOT=1 router-looka­head disk prefetch (experimental — see be­low), CAP_RAISE=0 don’t auto-grow the ex­pert cache.

The ex­pert cache auto-sizes to your RAM (since 2026 – 07-10): the en­gine now raises the LRU cap to fill your –ram bud­get in­stead of only low­er­ing it. Before this fix a 128 GB ma­chine ran with the same 8-experts/layer cache as a 16 GB one (issue #12) — if you bench­marked col­i­brì be­fore this date, re­run: your num­bers were capped.

Router-lookahead prefetch (PILOT=1, ex­per­i­men­tal): GLM-5.2′s ex­pert rout­ing is mea­sur­ably pre­dictable ahead of time — ap­ply­ing layer L+1′s router to layer L’s post-at­ten­tion state re­calls 71.6% of the true top-8 (vs 41.3% for “same ex­perts as last to­ken”). PILOT=1 uses this to is­sue next-layer ex­pert reada­head from a ded­i­cated I/O thread while the cur­rent layer com­putes. On our dev box the disk is al­ready ~80% sat­u­rated, so it mea­sures neu­tral; on ma­chines where com­pute and disk are bal­anced (like the Ryzen AI 9 in is­sue #12: 43% disk / 46% mat­mul) it should over­lap real work — mea­sure­ments wel­come.

The learn­ing cache: the en­gine records which ex­perts your us­age ac­tu­ally routes to (.coli_usage next to the model, up­dated every turn) and at startup au­to­mat­i­cally pins the hottest ones in spare RAM. col­i­brì lit­er­ally gets faster the more you use it.

Got a bet­ter ma­chine? Try it — here’s what to ex­pect

col­i­brì was built on de­lib­er­ately hum­ble hard­ware (12 cores, 25 GB RAM, NVMe be­hind a WSL2 VHDX that caps ran­dom reads at ~1 GB/s). Every one of those con­straints is a knob your ma­chine can turn up. The en­gine needs: Linux (or WSL2), gcc with OpenMP, AVX2, ≥16 GB RAM, and the ~370 GB int4 model on a lo­cal NVMe (ext4 — never a net­work/​9p mount).

How to test it, in or­der:

cd c && ./setup.sh # build + ar­chi­tec­ture self-test (expects 32/32)

# 1) mea­sure YOUR disk the way the en­gine uses it (parallel 19 MB ran­dom reads): gcc -O2 -fopenmp iobench.c -o iobench ./iobench /path/to/glm52_i4/out-00069.safetensors 19 64 8 0 # buffered, 8 threads ./iobench /path/to/glm52_i4/out-00069.safetensors 19 64 8 1 # O_DIRECT

# 2) chat; watch the per-turn stats line (tok/s, ex­pert hit-rate, RSS): COLI_MODEL=/path/to/glm52_i4 ./coli chat

# 3) record ex­pert us­age, then pin the hottest ex­perts in your spare RAM: STATS=stats.txt ./coli chat PIN=stats.txt PIN_GB=20 ./coli chat # scale PIN_GB to your free RAM

# 4) qual­ity bench­marks (MMLU/HellaSwag/ARC): ./coli bench

Back-of-envelope pre­dic­tions (decode is disk-bound: a cold to­ken costs ~11.4 GB of ex­pert reads; MTP spec­u­la­tion roughly halves the ef­fec­tive cost once the cache is warm; RAM turns cold reads into free cache hits):

These are es­ti­mates, not mea­sure­ments — if you run col­i­brì on se­ri­ous hard­ware, please open an is­sue with your num­bers: real dat­a­points from bet­ter ma­chines are ex­actly what this pro­ject needs next.

Community bench­marks (measured)

Real num­bers from real ma­chines, stock build (setup.sh, gcc 13), greedy de­cod­ing, –ngen 32, MTP ac­tive:

Takeaways: with 24 GB of RAM the en­gine auto-caps the ex­pert cache to 2 slots/​layer, so de­code stays cold even on a disk 2 – 2.7× faster than the dev box — on small-RAM ma­chines the RAM cap, not the disk, is the bind­ing con­straint, ex­actly as the table above pre­dicts; –topp 0.7 alone bought a clean 1.6× end-to-end speedup. The M5 Max dat­a­point lands right on the table’s sec­ond row: ~1 tok/​s of a 744B model on a lap­top SSD — and its 14 GB/s disk shifts the bot­tle­neck back to RAM bud­get and ker­nels. The Framework 13 rows are the cache the­sis proven end-to-end on one ma­chine: 0.29 → 0.37 tok/​s (hit 28% → 66%, spec­u­la­tion fi­nally en­gag­ing at 52% ac­cep­tance) just by giv­ing the cache its RAM — int8 MTP head + a big­ger cap + the learned pin. The cap part is now au­to­matic (cap auto-raise, 2026 – 07-10).

Quality bench­mark — help wanted

We have never mea­sured how much the int4 quan­ti­za­tion costs in ac­cu­racy — the har­ness is built and wired, but scor­ing is one for­ward per an­swer op­tion, and on the dev box’s ~1 GB/s disk a full run takes the bet­ter part of a day. This is the sin­gle most valu­able thing a faster ma­chine can con­tribute. The code is here and ready; one com­mand runs it end to end (it auto-down­loads the datasets on first use):

cd c ./coli bench # hel­laswag, ar­c_chal­lenge, mmlu — 40 ques­tions each ./coli bench hel­laswag –limit 200 # one task, more ques­tions ./coli bench mmlu ar­c_chal­lenge –ram 100 # pick tasks, set a RAM bud­get

It prints per-task ac­cu­racy (log-likelihood scor­ing, EleutherAI-harness style). Published full-pre­ci­sion GLM-5.2 scores on these tasks sit around 85 – 95%; if our int4 con­tainer lands within a few points, the quan­ti­za­tion is val­i­dated — if it does­n’t, we know to in­vest in mixed / grouped-scale quan­ti­za­tion. If you have the hard­ware to run this, please open an is­sue with the num­bers — it’s the mea­sure­ment the pro­ject is miss­ing.

Supporting the pro­ject

col­i­brì is a one-per­son pro­ject, writ­ten and tested en­tirely on a 12-core lap­top with 25 GB of RAM — the num­bers above are the ceil­ing of what I can mea­sure at home. If this pro­ject is use­ful or in­ter­est­ing to you and you’d like to sup­port its de­vel­op­ment (better test hard­ware trans­lates di­rectly into a faster en­gine for every­one: real NVMe scal­ing data, big­ger pinned caches, int2/​int3 qual­ity sweeps on real bench­marks), you can:

⭐ star the repo and share it;

🐛 open is­sues with bench­mark num­bers from your hard­ware;

💬 reach out via GitHub is­sues if you’d like to spon­sor de­vel­op­ment or do­nate hard­ware.

Every con­tri­bu­tion, from a dat­a­point to a disk, moves the ceil­ing.

Repo lay­out

c/​glm.c the en­gine (GLM-5.2 for­ward, stream­ing MoE, MTP, serve mode) c/​st.h safeten­sors reader: pread + fad­vise, no mmap (RSS stays flat) c/​tok.h byte-level BPE to­k­enizer in C c/​coli CLI: chat / run / bench / con­vert / info c/​iobench.c par­al­lel disk mi­crobench­mark (measures what the en­gine feels) c/​con­vert_f­p8_­to_int4.py disk-safe FP8 → int4 con­verter c/​make_glm_o­r­a­cle.py tiny-ran­dom or­a­cle gen­er­a­tor for val­i­da­tion c/​ol­moe.c stage-A en­gine (OLMoE), first val­i­da­tion tar­get

Why “colibrì”

The hum­ming­bird weighs a few grams, hov­ers in place, and vis­its a thou­sand flow­ers a day. This en­gine keeps a 744-billion-parameter gi­ant alive on hum­ming­bird ra­tions: 25 GB of RAM, twelve CPU cores, and a lot of disk pa­tience.

License

Apache 2.0. GLM-5.2 weights are re­leased by Z.ai un­der MIT.

I spent a rather em­bar­rass­ing amount of time try­ing to match up Run­ning Train‘s hy­per-re­al­is­tic train lines and Japanese ter­rain with the real world. And in do­ing so, I paid the game the high­est pos­si­ble com­pli­ment. This ex­tra­or­di­nar­ily re­al­is­tic sim made by one-per­son de­vel­op­ment team Novatetsu Games is in fact set in a fic­tional re­gion of Japan, but is cre­ated so lov­ingly that you’ll be­lieve it’s real life.

I’m not ex­actly a train en­thu­si­ast, nor in­deed par­tic­u­larly au fait with the range of train sim games pre­vi­ously avail­able, but in Running Train I’ve found some­thing ab­solutely cap­ti­vat­ing. And most bizarrely, I’ve found that qual­ity not by ac­tu­ally play­ing it, but rather by let­ting it play it­self. While the game en­cour­ages you to mas­ter the rea­son­ably sim­ple con­trols of its range of per­fectly crafted en­gines, you can also just set it to play it­self and then take over the free cam­era as it does. Doing so has brought me so much plea­sure.

Played prop­erly, Run­ning Train asks you to care­fully con­trol your speed, brak­ing, and prompt, safe ar­rival at train sta­tions, and re­wards or pe­nal­izes you ac­cord­ingly. By turn­ing off in-game guides and even the UI, you can earn higher scores and more credit, con­tribut­ing to your over­all rat­ing for each of the 42 dif­fer­ent routes it cur­rently fea­tures. These routes fea­ture ten 12-minute routes on the fic­tional Fukugawa Line, and a fur­ther 32 of hugely vary­ing length on the equally made up Sankai Main Line. They can be as short as six min­utes, or as long as 44, each set at dif­fer­ent times of day.

And oh my good­ness, it’s so pretty. Vast stretches of imag­ined Japanese towns and coun­try­side have been cre­ated (40 kilo­me­ters of track, ap­par­ently), and it’s not just ran­domly placed as­sets. Jumping into that free cam­era, I could­n’t be­lieve it when I no­ticed that even pow­er­lines are log­i­cally placed, with wires be­gin­ning at sub­sta­tions, then stretch­ing across py­lon net­works. Roads are filled with traf­fic, cars are parked in bays out­side apart­ment build­ings, Shinto tem­ples sit on hill­sides, fer­ries bob on the sea while waves lap onto shores.

The key thing about all these de­tails is that…you don’t see most of them from the train! If you stuck with the dri­ver cam, you’d miss al­most all of it. It’s so much ef­fort that the de­vel­op­ers could eas­ily have got­ten away with­out, but it adds so much by be­ing in­cluded. It’s also pos­si­ble to play any of the routes in dif­fer­ent weather con­di­tions, from sunny days to tor­ren­tial rain, or in­deed in ei­ther spring or win­ter, with op­tional bliz­zards cov­er­ing the en­tire game in snow.

Zoom out far enough—and for some rea­son it will let you—and you see the tiles, the roads that don’t line up, and the var­i­ous tricks and tech­niques that al­low it to look so re­al­is­tic from low down. But don’t do that! That’s silly. This is a train sim, not a plane sim, you’ve no busi­ness in the sky.

From those who know what they’re do­ing, Steam re­views could not be more glow­ing. “Honestly, I re­ally, re­ally do not know what to say,” be­gins one, be­fore adding, “Hands down the most beau­ti­ful train sim that has been re­leased on the mar­ket thus far. The mod­el­ing is top tier. The en­vi­ron­ment de­tails, the clouds, the light­ing, the weather ef­fects all of it is just ab­solutely in­sane!”

Another says, “Best train sim­u­la­tor game so far!” while a third com­pli­ments the solo dev for in­clud­ing sup­port for the Zuiki MASCON, a be­spoke pe­riph­eral for train dri­ving sims.

This is all for the Early Access re­lease, and there are still big plans to make the game far more de­tailed. The de­vel­oper wants to add a pas­sen­ger sys­tem (currently the trains run empty) and a con­duc­tor mode, and the ul­ti­mate goal is up to 100 km of track. The hope is to have that all done by the end of next year.

As it is, you can ab­solutely en­joy it as a top-notch train sim, but for me the ex­pe­ri­ence has been about let­ting the model rail­way run it­self as I swoop about in the cam­era. It’s a rare plea­sure.

Running Train is out now in Early Access on Steam for $18.

Published Jul 8, 2026, 4:00 PM EDT

A tech­nol­ogy en­thu­si­ast, Bobby stud­ied Computer Science at the University of Southampton be­fore work­ing in a num­ber of roles across in­dus­tries, from the pri­vate sec­tor to the char­i­ta­ble one, at multi­na­tion­als and star­tups. He’s helped main­tain back­end Java servers, de­signed data­bases and front-end in­ter­faces, and cre­ated a be­spoke con­tent man­age­ment sys­tem.

Bobby also en­joys video gam­ing, and has writ­ten for sev­eral out­lets, in­clud­ing a stint as Editor-in-Chief at Switch Player Magazine and con­tri­bu­tions to on­line mag­a­zine, SUPERJUMP. Bobby uses a Mac for day-to-day work and an Android phone for dis­trac­tions.

Sign in to your How-To Geek ac­count

By many mea­sures, GitHub is as pop­u­lar as ever. One new user joins every sec­ond, the ser­vice hosts over 600 mil­lion repos­i­to­ries, and nearly one bil­lion com­mits were made in 2025.

But scratch the sur­face, and some­thing else is go­ing on. Some users are con­cerned about a range of is­sues, from tech­ni­cal prob­lems like fre­quent down­time to the ser­vice’s po­lit­i­cal di­rec­tion, es­pe­cially since it was taken over by Microsoft.

A few high-pro­file pro­jects have taken things much fur­ther, aban­don­ing the of­fer­ing al­to­gether, in a move that may rep­re­sent the be­gin­nings of a more wide­spread ex­o­dus.

Some key play­ers have aban­doned GitHub

A slow trickle that may gain mo­men­tum

When you’re search­ing for open-source soft­ware, it can seem like every pro­ject is hosted on GitHub. Even the Linux ker­nel source code has a read-only GitHub mir­ror, al­though its main home has a do­main of its own.

But this is­n’t al­ways the case, and it may be­come less and less so if moves by a hand­ful of pro­jects be­come a wider trend.

Probably the high­est-pro­file de­par­ture so far has been Ghostty, a cross-plat­form ter­mi­nal em­u­la­tor. The pro­jec­t’s main­tainer, Mitchell Hashimoto, an­nounced in April 2026 that Ghostty was leav­ing GitHub, al­though not im­me­di­ately:

It’ll take us time to re­move all of our de­pen­den­cies on GitHub and we have a plan in place to do it as in­cre­men­tally as pos­si­ble. We plan on keep­ing a read-only mir­ror avail­able on GitHub at the cur­rent URL.

It’ll take us time to re­move all of our de­pen­den­cies on GitHub and we have a plan in place to do it as in­cre­men­tally as pos­si­ble. We plan on keep­ing a read-only mir­ror avail­able on GitHub at the cur­rent URL.

Zig, a sys­tem pro­gram­ming lan­guage that’s a spir­i­tual suc­ces­sor to C, also an­nounced its de­par­ture, back in November 2025. The pro­ject made its first com­mit back in 2015, and en­joyed an un­in­ter­rupted run on GitHub, un­til re­cently.

Another sig­nif­i­cant pro­ject that’s made a switch is Tenacity. This cross-plat­form au­dio ed­i­tor an­nounced its move on a Reddit fo­rum in 2023 and now only main­tains a mir­ror pres­ence on GitHub.

Alongside these more promi­nent re­pos, many other pro­jects have mi­grated, such as the Dillo web browser and the Hare pro­gram­ming lan­guage. Even more were never on GitHub in the first place, choos­ing to self-host their repos­i­to­ries, like GNOME or Apache’s vast ar­ray of soft­ware.

Quiz

8 Questions · Test Your Knowledge

GitHub al­ter­na­tives for de­vel­op­er­sTrivia chal­lenge

Think you know your GitLab from your Gitea? Put your source con­trol knowl­edge to the test.

PlatformsOpen SourceHistoryFeaturesDevOps

Begin

01 / 8

Platforms

Which com­pany de­vel­oped GitLab, one of the most pop­u­lar GitHub al­ter­na­tives?

AMicrosoftBAtlassianCGitLab Inc.DJetBrains

That’s right! GitLab Inc. was founded in 2014 by Dmitriy Zaporozhets and Sid Sijbrandij. The plat­form started as an open-source pro­ject and has grown into one of the most fea­ture-rich DevOps plat­forms avail­able to­day.

Not quite — GitLab was cre­ated by GitLab Inc., founded by Dmitriy Zaporozhets and Sid Sijbrandij in 2014. While Microsoft owns GitHub it­self, GitLab is an en­tirely sep­a­rate com­pany and prod­uct.

Continue

02 / 8

Open Source

Which GitHub al­ter­na­tive is a light­weight, self-hosted Git ser­vice writ­ten in Go, known for its low re­source us­age?

AGogsBGiteaCKallitheaDPhabricator

Correct! Gitea is a com­mu­nity-man­aged fork of Gogs, writ­ten in Go, and is cel­e­brated for be­ing in­cred­i­bly light­weight. It can run on a Raspberry Pi and of­fers a GitHub-like in­ter­face with­out heavy server re­quire­ments.

Close, but the an­swer is Gitea. While Gogs is also writ­ten in Go and in­spired Gitea, Gitea is the more ac­tively main­tained fork with a larger com­mu­nity. Both are self-hosted op­tions, but Gitea has sur­passed Gogs in de­vel­op­ment ac­tiv­ity.

Continue

03 / 8

History

Bitbucket, a ma­jor GitHub al­ter­na­tive, was orig­i­nally ac­quired by which com­pany in 2010?

AMicrosoftBSalesforceCAtlassianDIBM

Spot on! Atlassian ac­quired Bitbucket in 2010, in­te­grat­ing it into their suite of de­vel­oper tools along­side Jira and Confluence. This made Bitbucket es­pe­cially pop­u­lar among teams al­ready us­ing the Atlassian ecosys­tem.

Not quite — Bitbucket was ac­quired by Atlassian in 2010, not Microsoft or any of the other op­tions. Atlassian is the com­pany be­hind Jira, Confluence, and Trello, mak­ing Bitbucket a nat­ural fit for its de­vel­oper-fo­cused prod­uct lineup.

Continue

04 / 8

Features

Which GitHub al­ter­na­tive is best known for of­fer­ing a fully in­te­grated DevOps life­cy­cle plat­form, in­clud­ing CI/CD, se­cu­rity scan­ning, and pro­ject man­age­ment in a sin­gle ap­pli­ca­tion?

ABitbucketBSourceForgeCGitLabDLaunchpad

Exactly right! GitLab mar­kets it­self as a com­plete DevOps plat­form, of­fer­ing every­thing from source con­trol and CI/CD pipelines to con­tainer reg­istries and se­cu­rity scan­ning — all within one uni­fied in­ter­face. This all-in-one ap­proach is a key dif­fer­en­tia­tor.

The cor­rect an­swer is GitLab. While Bitbucket also of­fers CI/CD via Pipelines, GitLab is uniquely rec­og­nized for pack­ag­ing the en­tire DevOps life­cy­cle — from plan­ning to mon­i­tor­ing — into a sin­gle co­he­sive plat­form, mak­ing it a fa­vorite for en­ter­prise teams.

Continue

05 / 8

History

SourceForge, one of the ear­li­est code host­ing plat­forms, launched in which year?

A1995B1999C2003D2001

Well done! SourceForge launched in 1999 and was a pi­o­neer in open-source code host­ing be­fore GitHub ex­isted. At its peak it hosted mil­lions of pro­jects, though it later lost ground to GitHub due to con­tro­versy over ad­ware bundling.

Not quite — SourceForge launched in 1999, mak­ing it one of the old­est code host­ing ser­vices on the in­ter­net. It pre­dates GitHub by nearly a decade and was once the go-to plat­form for open-source pro­jects be­fore GitHub dis­rupted the space.

Continue

06 / 8

DevOps

Which self-hosted Git repos­i­tory man­ager, de­vel­oped by Perforce, is widely used in en­ter­prise en­vi­ron­ments and sup­ports both Git and Mercurial?

AGerritBRhodecodeCGitoliteDKallithea

Correct! RhodeCode is an en­ter­prise-grade, self-hosted source code man­age­ment plat­form that sup­ports Git, Mercurial, and SVN. It was ac­quired by Perforce and is used by or­ga­ni­za­tions that need strong ac­cess con­trols and au­dit trails.

The right an­swer is RhodeCode, now part of Perforce. It stands out among self-hosted al­ter­na­tives for sup­port­ing mul­ti­ple ver­sion con­trol sys­tems — Git, Mercurial, and SVN — mak­ing it at­trac­tive for en­ter­prises man­ag­ing legacy code­bases along­side mod­ern re­pos.

Continue

07 / 8

Platforms

Which plat­form, pri­mar­ily used for large-scale open-source pro­jects, is main­tained by Canonical and hosts the de­vel­op­ment of many Ubuntu-related pack­ages?

ASavannahBLaunchpadCCodebergDPhabricator

That’s cor­rect! Launchpad is main­tained by Canonical and serves as the cen­tral hub for Ubuntu de­vel­op­ment. It of­fers bug track­ing, code host­ing via Bazaar and Git, and trans­la­tion tools, mak­ing it a spe­cial­ized but pow­er­ful plat­form for the Ubuntu ecosys­tem.

The an­swer is Launchpad, run by Canonical — the com­pany be­hind Ubuntu. While it’s not as gen­eral-pur­pose as GitHub or GitLab, Launchpad is in­te­gral to Ubuntu’s de­vel­op­ment work­flow and hosts thou­sands of pack­ages and pro­jects tied to the Debian/Ubuntu ecosys­tem.

Continue

08 / 8

Open Source

Codeberg is a non­profit-run GitHub al­ter­na­tive based in Germany. Which open-source soft­ware does it run un­der the hood?

AGitLab CEBGogsCGiteaDKallithea

Exactly! Codeberg is pow­ered by Gitea, the light­weight open-source Git plat­form writ­ten in Go. As a non­profit hosted in the EU, Codeberg ap­peals strongly to pri­vacy-con­scious de­vel­op­ers and those who want an eth­i­cal al­ter­na­tive to com­mer­cial plat­forms.

The cor­rect an­swer is Gitea. Codeberg uses Gitea as its un­der­ly­ing soft­ware and op­er­ates as a reg­is­tered non­profit based in Berlin, Germany. It has be­come a fa­vorite in the open-source and pri­vacy-fo­cused de­vel­oper com­mu­ni­ties as a trans­par­ent al­ter­na­tive to GitHub.

See My Score

Challenge Complete

Your Score

/ 8

Thanks for play­ing!

Try Again

Projects have left for these key rea­sons

Downtime, ar­ti­fi­cial in­tel­li­gence, and pol­i­tics are all con­cerns

Maintainers have given var­i­ous rea­sons for mov­ing away, in­clud­ing these:

Technical qual­ity: prob­a­bly the most com­mon com­plaint is that GitHub suf­fers from fre­quent out­ages. IncidentHub tracked a to­tal down­time of 112 hours across 48 “major out­ages” in the year from May 2025, not­ing that such out­ages were the dri­ver be­hind the mi­gra­tions of Ghostty and Zig.

Politics: Andrew Kelley, cre­ator of Zig, men­tioned GitHub’s re­la­tion­ship with ICE in pass­ing. The com­pa­ny’s $200k deal with the im­mi­gra­tion agency was also crit­i­cized by em­ploy­ees way back in 2019.

AI: Still a di­vi­sive topic, ar­ti­fi­cial in­tel­li­gence has touched al­most every as­pect of our tech lives, in­clud­ing GitHub, where Copilot is be­ing in­creas­ingly in­te­grated. The ser­vice nailed its col­ors firmly to the mast in 2025, when CEO Thomas Dohmke com­mented, “Either you em­brace AI, or get out of this ca­reer.”

Complaints about GitHub are prob­a­bly best sum­ma­rized by an­other quote from Mitchell Hashimoto:

It’s not a fun place for me to be any­more. I want to be there but it does­n’t want me to be there. I want to get work done and it does­n’t want me to get work done. I want to ship soft­ware and it does­n’t want me to ship soft­ware.

It’s not a fun place for me to be any­more. I want to be there but it does­n’t want me to be there. I want to get work done and it does­n’t want me to get work done. I want to ship soft­ware and it does­n’t want me to ship soft­ware.

Aside from these de­par­tures, those pro­jects that have al­ways avoided GitHub have their own rea­sons. The GNU Project, for ex­am­ple, has al­ways been fiercely ide­o­log­i­cal and re­jects GitHub be­cause it re­quires non-free soft­ware (JavaScript) to run. It also notes the host’s en­cour­age­ment of “bad li­cens­ing prac­tice.”

Alternatives to GitHub are do­ing well

From self-host­ing to Codeberg, var­i­ous op­tions are avail­able

Codeberg is prob­a­bly the sin­gu­lar most pop­u­lar com­pet­ing ser­vice that pro­jects like Zig have cho­sen to aban­don GitHub for. It has many of the same fea­tures as GitHub: is­sue track­ing, sta­tic page host­ing, and Continuous Integration/Continuous Delivery (CI/CD), for ex­am­ple.

There are other op­tions, such as GitLab, which has a self-host­ing op­tion, or Bitbucket, GitHub’s most con­tem­po­rary al­ter­na­tive.

Sourcehut is a com­pletely open-source of­fer­ing, with equiv­a­lents of GitHub’s core fea­tures and an em­pha­sis on an email-based work­flow. Others choose to host their own forge, with pop­u­lar op­tions in­clud­ing Gitea and Forgejo, the soft­ware that runs in the back­ground at Codeberg.

There are even whole move­ments en­cour­ag­ing peo­ple to give up GitHub, like the Software Freedom Conservancy’s cam­paign, which has many re­sources to help you make the move.

Today, we’re ex­cited to in­tro­duce Muse Spark 1.1, the lat­est model from Meta Superintelligence Labs and a sig­nif­i­cant up­grade from Muse Spark. Muse Spark 1.1 is a mul­ti­modal rea­son­ing model built for agen­tic tasks, with ma­jor gains in tool and com­puter use, cod­ing, and mul­ti­modal un­der­stand­ing.

With these im­prove­ments, Muse Spark 1.1 ad­vances the per­for­mance-ef­fi­ciency fron­tier. Together with this week’s launch of Muse Image, this re­lease brings us closer to our vi­sion of per­sonal su­per­in­tel­li­gence: mod­els that help you pur­sue your goals, cre­ate what you imag­ine, deepen your re­la­tion­ships, and take ac­tion on what you value most.

Along with this re­lease, we are launch­ing a pub­lic pre­view of the new Meta Model API where de­vel­op­ers can ac­cess Muse Spark 1.1. The model is avail­able now in “Thinking” mode in the Meta AI app and on meta.ai.

Evaluations

Agents

Muse Spark 1.1 de­liv­ers ex­cep­tional per­for­mance in per­sonal agen­tic tasks that re­quire plan­ning and or­ches­tra­tion across a range of ex­ter­nal apps and ser­vices. It zero-shot gen­er­al­izes to new na­tive tools, MCP servers, and cus­tom skills.

It tack­les com­plex pro­jects sig­nif­i­cantly faster than Muse Spark, as it is trained to or­ches­trate multi-agent sys­tems to op­ti­mize end-to-end la­tency. As the main agent, it can gather con­text, make a plan, and del­e­gate ex­e­cu­tion across par­al­lel sub­agents. As a sub­agent, it ad­heres to its job, un­der­stands avail­able tools, and knows when to es­ca­late back to the main agent.

Muse Spark 1.1 can ac­tively man­age its con­text win­dow of 1 mil­lion to­kens. It re­mem­bers ac­tions, re­trieves in­for­ma­tion from much ear­lier work, and com­pacts in a way that keeps the crit­i­cal steps needed for later work.

Computer Use

Muse Spark 1.1 ex­cels at com­puter-use work­flows that un­fold across mul­ti­ple ap­pli­ca­tions with in­for­ma­tion chang­ing on-the-fly. It main­tains con­text across ex­tended ses­sions, adapts to evolv­ing re­quire­ments, and nav­i­gates un­fa­mil­iar in­ter­faces with min­i­mal hu­man in­ter­ven­tion.

Rather than rea­son­ing through every desk­top step one click at a time, Muse Spark 1.1 un­der­stands when to au­to­mate and when to use the in­ter­face di­rectly. We trained the model to write scripts when au­toma­tion is faster, click when di­rect in­ter­ac­tion is sim­pler, and gen­er­ate batches of ac­tions at each step.

Agentic din­ner party or­ga­ni­za­tion: In real-world ap­pli­ca­tions, new con­text arises that changes the task. Muse Spark 1.1 no­tices these changes when plac­ing the din­ner or­der and makes nec­es­sary up­dates with­out user in­ter­ven­tion.

Coding

Coding per­for­mance for Muse Spark 1.1 im­proved sub­stan­tially on real-world tasks in­volv­ing large, com­plex code­bases. It can di­ag­nose and fix com­plex bugs, im­ple­ment new fea­tures in en­ter­prise-grade sys­tems, and ex­e­cute large code mi­gra­tions. In use cases like cre­at­ing web ap­pli­ca­tions and end-to-end ques­tion an­swer­ing, Muse Spark 1.1 shows large gains over our first model.

We trained our model to smoothly adapt to di­verse har­nesses and re­li­ably han­dle com­plex multi-turn dy­nam­ics. Muse Spark 1.1 per­forms well with pop­u­lar agen­tic cod­ing se­tups, sup­port­ing com­mon fea­tures like plan­ning mode, goal con­di­tion­ing, sub­agent del­e­ga­tion, and con­text com­paction.

Debugging demo in OpenCode: Muse Spark 1.1 builds a chat web app, takes au­to­mated screen­shots to iden­tify user-vis­i­ble fail­ures, traces is­sues back to rel­e­vant code to im­ple­ment fixes, and val­i­dates these changes. The model seam­lessly com­bines cod­ing, mul­ti­modal un­der­stand­ing, and tool call­ing.

Across Meta, de­vel­op­ers and re­searchers are us­ing Muse Spark 1.1 daily to build faster and work smarter. On our pri­mary in­ter­nal cod­ing eval­u­a­tion, Meta Internal Coding Bench, Muse Spark 1.1 sig­nif­i­cantly im­proves upon Muse Spark and is com­pet­i­tive with lead­ing al­ter­na­tives.

Researchers are now also au­tomat­ing model de­vel­op­ment and eval­u­a­tion tasks by lever­ag­ing Muse Spark 1.1 in their work­flows.

DeepSWE eval­u­a­tion in OpenCode: Muse Spark 1.1 eval­u­ates it­self on a sub­set of DeepSWE tasks across dif­fer­ent rea­son­ing strengths and pro­duces an analy­sis dash­board based on the re­sults.

Multimodal

Along with cod­ing and agen­tic ca­pa­bil­i­ties, Muse Spark 1.1 ex­cels in per­cep­tion, mul­ti­modal rea­son­ing, and tool use. It can in­ter­act with real en­vi­ron­ments and pro­duce grounded out­puts with strengths in vi­sual-to-code ar­ti­fact gen­er­a­tion, ul­tra-de­scrip­tive im­age and video cap­tion­ing, and agen­tic work­flow ex­e­cu­tion for mul­ti­modal use cases.

Muse Spark 1.1’s mul­ti­modal ca­pa­bil­i­ties are es­pe­cially valu­able when per­cep­tion and ac­tion need to hap­pen to­gether. The model can in­spect vi­sual and au­dio, pre­serve de­tails across a long work­flow, and use those de­tails while op­er­at­ing com­put­ers on the user’s be­half.

Facebook Marketplace agent: Using video shot from a smart­phone, Muse Spark 1.1 ex­tracts use­ful pho­tos and rea­sons about the prod­uct to op­er­ate a user’s browser and make a Facebook Marketplace list­ing on the user’s be­half.

Safety

We con­ducted ex­ten­sive safety eval­u­a­tions be­fore de­ploy­ment, fol­low­ing the Advanced AI Scaling Framework, which de­fines eval­u­a­tions, threat mod­els, and de­ploy­ment thresh­olds for our most ad­vanced mod­els.

Across all fron­tier risk cat­e­gories — Chemical & Biological, Cybersecurity, and Loss of Control — our eval­u­a­tions show Muse Spark 1.1 op­er­ates within safe mar­gins. Muse Spark 1.1 demon­strates strong re­sis­tance to di­rect jail­breaks and in­di­rect at­tacks from un­trusted data, prompt in­jec­tion, and de­vel­oper-prompt at­tacks. Consequently, it shows bet­ter ad­ver­sar­ial ro­bust­ness, lower hal­lu­ci­na­tion rates, and re­duced syco­phancy.

Our full safety pos­ture for 1.1 is doc­u­mented in our Muse Spark 1.1 Evaluation Report.

Availability

For the first time, de­vel­op­ers can be­gin build­ing with Muse Spark 1.1 via the new Meta Model API, now in pub­lic pre­view. Early part­ners of Muse Spark 1.1 praise the model as a com­plete agen­tic foun­da­tion, pair­ing long con­text han­dling with strong cod­ing and rea­son­ing ca­pa­bil­i­ties to han­dle large-scale agen­tic work­loads.

“What’s most im­pres­sive about Muse Spark is how much it packs into one model: mas­sive mil­lion-to­ken con­text, full mul­ti­modal sup­port (images, video, PDFs), built-in search with ci­ta­tions, strong rea­son­ing, top-tier cod­ing abil­i­ties (particularly fron­tend and de­sign), struc­tured out­put, and par­al­lel tool call­ing — all in a clean OpenAI-compatible pack­age. A com­plete agen­tic foun­da­tion.”

— Amjad Masad, CEO of Replit

“Meta is clearly build­ing for se­ri­ous agen­tic cod­ing — strong tool use at a price point that makes it vi­able to run real cod­ing work­loads at scale. That com­bi­na­tion is rare, and it’s ex­actly why we wanted Cline de­vel­op­ers to have ac­cess early.”

— Saoud Rizwan, CEO of Cline

“When tested against Box’s en­ter­prise work eval­u­a­tion set, Muse Spark de­liv­ered en­ter­prise ca­pa­bil­i­ties com­pet­i­tive with to­day’s lead­ing fron­tier mod­els. That level of in­tel­li­gence, com­bined with its strengths in struc­tured, pro­ce­dural work­flows across in­dus­tries such as pro­fes­sional ser­vices, pub­lic sec­tor, and in­dus­trial op­er­a­tions, makes it a com­pelling choice for or­ga­ni­za­tions.”

— Yashodha Bhavnani, VP of AI Products at Box

We’re thrilled to be re­leas­ing Muse Spark 1.1, a tes­ta­ment to our re­search mo­men­tum. We have even more ca­pa­ble mod­els in train­ing and look for­ward to shar­ing what’s to come.

Written by:

Meta Superintelligence Labs

Share: