It looks like John Deere own­ers can soon feel free to fix their own ma­chines.

The Federal Trade Commission and at­tor­neys gen­eral from sev­eral states se­cured a right-to-re­pair set­tle­ment Wednesday with agri­cul­ture equip­ment gi­ant Deere & Co. — com­monly known as John Deere — that re­quires the com­pany to let farm­ers and in­de­pen­dent shops fix their own equip­ment.

The Illinois-based man­u­fac­turer has faced com­plaints for years for with­hold­ing the soft­ware needed for re­pairs and forc­ing cus­tomers to use au­tho­rized deal­ers in­stead of in­de­pen­dent ones.

This marks the sec­ond right-to-re­pair set­tle­ment Deere has reached this year, fol­low­ing a sep­a­rate $99 mil­lion class-ac­tion set­tle­ment with farm­ers in April. Though the class-ac­tion com­pen­sated con­sumers, the FTC’s set­tle­ment in­stead re­quires Deere to make its re­pair ser­vices avail­able to equip­ment own­ers and in­de­pen­dent shops.

The FTC and at­tor­neys gen­eral from Arizona, Illinois, Michigan, Minnesota and Wisconsin brought the an­titrust law­suit in January 2025, ar­gu­ing that Deere had il­le­gally re­stricted farm­ers and in­de­pen­dent shops that might oth­er­wise ser­vice them from re­pair­ing farm equip­ment such as trac­tors. Deere also makes en­gines and equip­ment for forestry, land­scap­ing and con­struc­tion.

Under the or­der filed in Illinois, Deere will now be re­quired to make di­ag­nos­tic and re­pair tools avail­able to equip­ment own­ers and in­de­pen­dent re­pair shops, not only its own net­work of au­tho­rized deal­ers. It also pre­vents Deere deal­ers from re­tal­i­at­ing against equip­ment own­ers or re­pair shops who choose to fix their own equip­ment in­stead of pay­ing for Deere’s ser­vices. The or­der is headed to Judge Iain D. Johnston for his ap­proval.

“For too long, Arizona farm­ers and in­de­pen­dent me­chan­ics have been at the mercy of Deere’s mo­nop­oly over re­pair tools, forced to wait — and pay — for au­tho­rized deal­ers just to fix bro­ken trac­tors and other equip­ment,” Arizona Attorney General Kris Mayes said in a state­ment Wednesday.

Deere must pay $1 mil­lion col­lec­tively to the five states for an­titrust en­force­ment costs and will be sub­ject to strict com­pli­ance over­sight for the next 10 years.

In the com­plaint, the FTC ar­gued that Deere pro­vides a ser­vice soft­ware tool to au­tho­rized deal­ers but does not pro­vide the full ver­sion to equip­ment own­ers or in­de­pen­dent shops. Deere had said the law­suit was base­less, de­nied that its dis­tri­b­u­tion of ser­vice tools was an­ti­com­pet­i­tive and ar­gued that it could not mo­nop­o­lize ser­vices since it does not di­rectly pro­vide them.

Sign up for Morning Wire: Our flag­ship newslet­ter breaks down the biggest head­lines of the day.

Deere main­tained its com­mit­ment to in­de­pen­dent re­pair in a state­ment Wednesday, adding that the agree­ment with the FTC re­in­forces its in­no­va­tion of more flex­i­ble re­pair op­tions.

“This is good news for our cus­tomers and for the fu­ture of how Deere equip­ment is sup­ported,” said Denver Caldwell, vice pres­i­dent of af­ter­mar­ket and cus­tomer sup­port.

Right-to-repair has be­come an in­creas­ingly com­mon is­sue over the years, es­pe­cially for tech prod­ucts, with con­sumers com­plain­ing that even sim­ple re­pairs can only be done by com­pany-au­tho­rized deal­ers.

Disclosure: Bun was ac­quired by Anthropic in December 2025. I and oth­ers on the Bun team work at Anthropic. I used a pre-re­lease ver­sion of Claude Fable 5 for much of the Rust rewrite.

Bun started as a line-for-line port of es­build’s JavaScript & TypeScript tran­spiler from Go to Zig. I wrote my first line of Zig on April 16, 2021. I bet on Zig af­ter see­ing the sin­gle-page Zig Language Reference on Hacker News and get­ting re­ally ex­cited about the low-level con­trol and care for per­for­mance.

From the start, Bun’s scope was mas­sive:

JavaScript, TypeScript, and CSS tran­spiler, mini­fier, and bundler

npm-com­pat­i­ble pack­age man­ager

Jest-like test run­ner

Node.js & TypeScript-compatible mod­ule res­o­lu­tion

HTTP/1.1 & WebSocket client

Node.js API im­ple­men­ta­tions like fs, net, tls, and dozens of other mod­ules

The ini­tial ver­sion of Bun was writ­ten by me in 1 year, in a cramped Oakland apart­ment, pre-LLM, in Zig. The de­fault out­come for am­bi­tiously-scoped pro­jects like Bun is join­ing the grave­yard of dead side pro­jects on a GitHub pro­file page. Zig made Bun pos­si­ble. I would never have been able to build this much in 1 year if it was­n’t for Zig.

Nowadays, Bun’s CLI gets over 22 mil­lion monthly down­loads. Popular tools like Claude Code and OpenCode bet on Bun as their run­time. Vercel, Railway, DigitalOcean and more have 1st-party sup­port for Bun.

Bun’s scope has also been a chal­lenge for sta­bil­ity. Here’s a small sam­ple of bugs we fixed in Bun v1.3.14:

heap-use-af­ter-free crash in node:zlib when call­ing .reset() on a zlib, Brotli, or Zstd stream while an async .write() is still in progress on the thread­pool

use-af­ter-free crash in node:zlib when an on­error call­back is­sued a re-en­trant write() fol­lowed by close() on na­tive han­dles

use-af­ter-free crashes in node:http2 when re-en­trant JS call­backs (e.g. ses­sion.re­quest() in­side a time­out lis­tener, an op­tions get­ter, or a write call­back) trig­gered a hashmap re­hash, in­val­i­dat­ing in­ter­nal stream point­ers

use-af­ter-free in UDPSocket.send() and send­Many() where user code in val­ueOf() or toString() call­backs could de­tach an ArrayBuffer be­tween pay­load cap­ture and the ac­tual send

crash and out-of-bounds read in Buffer#copy and Buffer#fill when a val­ueOf call­back de­taches or re­sizes the un­der­ly­ing ArrayBuffer dur­ing ar­gu­ment co­er­cion

heap out-of-bounds write in UDPSocket.sendMany() when the sock­et’s con­nec­tion state changed mid-it­er­a­tion via user JS call­backs

mem­ory leak in crypto.scrypt where the call­back and pro­tected pass­word/​salt buffers were never re­leased when the out­put buffer al­lo­ca­tion failed

SSLWrapper.init leaked the strdup’d passphrase on er­ror paths

mem­ory leak in tlsSocket.set­Ses­sion() where each call leaked one SSL_SESSION (~6.5 KB per call) due to a miss­ing SSL_SESSION_free af­ter d2i_SS­L_SES­SION

mem­ory leak where fs.watch() watch­ers were never garbage col­lected af­ter .close(), caused by a ref­er­ence count un­der­flow that per­ma­nently pinned each watcher as a GC root

dou­ble-free crash in the CSS parser when back­ground-clip had ven­dor pre­fixes and multi-layer back­grounds

DuplexUpgradeContext was never freed — a full leak per tls.con­nect({ socket: du­plex })

race con­di­tion crash in MessageEvent where the GC marker thread could ob­serve a torn vari­ant in m_­data dur­ing con­cur­rent ac­cess from a BroadcastChannel or MessagePort

We could have kept fix­ing these kinds of bugs one-off in per­pe­tu­ity, but we owe it to our users count­ing on us to do bet­ter than that, and sys­tem­at­i­cally pre­vent these kinds of bugs from re­cur­ring.

What we were al­ready do­ing

We patched the Zig com­piler to add Address Sanitizer sup­port. We run our test suite with ASAN on every com­mit.

We ship Zig safety-checked ReleaseSafe builds on Windows

We fuzz Bun’s run­time APIs 24/7 us­ing Fuzzilli, the JavaScript en­gine fuzzer used by V8 & JavaScriptCore

We have a whole lot of end-to-end mem­ory leak tests

This is more than many pro­jects do.

Just be re­ally smart and don’t make mis­takes?

Our bug­fix list felt bad and I was tired of go­ing to sleep wor­ry­ing about crashes in Bun. I don’t blame Zig for that - other users of Zig don’t have the bugs we had, and mix­ing GC with man­u­ally-man­aged mem­ory is an un­com­mon enough thing for soft­ware to need that no lan­guage re­ally de­signs for it. We would­n’t have got­ten this far if not for Zig, and I’ll al­ways be grate­ful. Until very re­cently, pro­gram­ming lan­guage choice was a one-way de­ci­sion for a pro­ject like Bun.

JavaScript is a garbage-col­lected lan­guage and mod­ern JavaScript en­gines like JavaScriptCore (and V8) have strict rules around ex­cep­tion han­dling and the garbage col­lec­tor. Zig, like C, does­n’t man­age mem­ory for you and this is a trade­off that for many pro­jects is a great rea­son to use Zig. Zig does not have con­struc­tors/​de­struc­tors, and most cleanup is ex­pected to be writ­ten out ex­plic­itly at each call site with de­fer.

For Bun, cor­rectly han­dling the life­times of garbage-col­lected val­ues and man­u­ally-man­aged val­ues has been a ma­jor source of sta­bil­ity is­sues - most of­ten small mem­ory leaks and oc­ca­sion­ally, crashes. Every mem­ory al­lo­ca­tion has to be metic­u­lously re­viewed. Where do these bytes get freed? How do we en­sure it only gets freed once? Did we check for JavaScript ex­cep­tions prop­erly? Is this garbage-col­lected pointer vis­i­ble to the con­ser­v­a­tive stack scan­ner? Is this garbage col­lected mem­ory or man­u­ally man­aged mem­ory?

For sta­bil­ity is­sues, know­ing as early as pos­si­ble is best. Fuzzing hap­pens af­ter code is merged. CI hap­pens when code is pushed. Runtime safety checks & ad­dress san­i­tizer hap­pens when code is run (hopefully in de­vel­op­ment, be­fore CI).

One com­mon way to re­duce this class of is­sue is to en­sure cleanup code is al­ways run ex­actly once for code that needs it. Zig is de­signed to be a sim­ple lan­guage with no hid­den con­trol flow, and so it prefers the ex­plicit de­fer key­word to run code at the end of a scope over C++’s im­plicit ~Destructor or Rust’s im­plicit Drop.

For Zig code, when ex­actly should we be run­ning the cleanup code? If we’re pass­ing the same *T to many dif­fer­ent func­tions, how do we know when it’s no longer ac­ces­si­ble and can be cleaned up? How does it work when some func­tions need to con­tinue to ref­er­ence the mem­ory af­ter the func­tion is called? Our cur­rent ap­proach is a mix of:

arena life­times, where the scope of when it’s ac­ces­si­ble is clear (parser state does­n’t es­cape the call­ing func­tion and so AST nodes are a good choice there)

ref­er­ence-count­ing

pay re­ally close at­ten­tion

Many pro­jects opt to an­swer these kinds of ques­tions through a style guide. TigerBeetle’s TigerStyle is an ex­am­ple in Zig and Google’s 31,000 word C++ style guide is an­other. The chal­lenge with style guides is en­force­ment. How do you make sure the style guide is fol­lowed? Historically, code re­view was the an­swer with best-ef­fort en­force­ment via lin­ters & sta­tic an­a­lyz­ers.

Having a rigid style guide with clear own­er­ship ex­pec­ta­tions ex­plic­itly spelled out in the type sys­tem was a real op­tion for Bun. Since Zig has no op­er­a­tor over­load­ing, we would likely end up with a lot of code look­ing some­thing like this:

fn foo(a_ptr: SharedPtr(TCPSocket)) !void { const a: *TCPSocket = a_ptr.get(); de­fer a_ptr.deref();

const b = try do_­some­thing_with_a(a); de­fer b.deref();

// … }

This is less er­gonomic than the Zig we ex­pect:

fn foo(a: *TCPSocket) !void { const b = try do_­some­thing_with_a(a); // … }

What about C/C++?

About 20% of Bun’s code is writ­ten in C++ and Bun em­beds sev­eral C/C++ li­braries:

JavaScriptCore, the JavaScript en­gine that pow­ers Safari

uWeb­Sock­ets & usock­ets - our HTTP/WebSocket server, and event loop

lsh­pack & lsquic - HPACK and HTTP/3 li­braries

BoringSSL, Google’s OpenSSL fork

SQLite

C++ in­stead of Zig would be a rea­son­able choice for Bun. We would get con­struc­tors & de­struc­tors. We could delete lots of ex­tern “C” wrap­per code.

But, we would still be re­liant on style guides en­forced through code re­view, and even with ASAN, mem­ory cor­rup­tion and mem­ory leaks would still hap­pen.

Why Rust?

A large per­cent­age of bugs from that list are use-af­ter-free, dou­ble-free, and “forgot to free” in an er­ror path. In safe Rust, these are com­piler er­rors and RAII-like au­to­matic cleanup with Drop. Compiler er­rors are a bet­ter feed­back loop than a style guide.

Historically, rewrites are a ter­ri­ble idea. Excluding com­ments, Bun is 535,496 lines of Zig. A rewrite in an­other lan­guage would take a small team of en­gi­neers a full year. It would mean freez­ing bug­fixes, se­cu­rity fixes or fea­ture de­vel­op­ment for that time. The least risky ap­proach to get­ting some­thing ship­pable would be a me­chan­i­cal port from Zig to Rust, with the min­i­mal num­ber of be­hav­ioral changes, us­ing the ex­act same test suite we al­ready use for test­ing Bun.

Fortunately, Bun’s own test suite is writ­ten in TypeScript which means it does­n’t de­pend on the run­time’s pro­gram­ming lan­guage.

A year of zero user-fac­ing im­pact is not a re­al­is­tic op­tion we could con­sider. So, en­force­ment through code-style to fix sta­bil­ity is­sues was our best bet, and was our plan when we added Rust-inspired smart point­ers to Bun’s code­base.

But hon­estly, I did­n’t want to do it. Homegrown smart point­ers of­fer worse er­gonom­ics than Rust, with none of the guar­an­tees.

What if, in­stead, I spend a week test­ing if Anthropic’s new model can rewrite Bun in Rust?

At first, I did­n’t ex­pect it to work. A few days in, a high % of the test suite started pass­ing and I saw how much the new Rust code matched up with the orig­i­nal Zig code­base. My opin­ion went from “this is worth try­ing” to “I’m go­ing to merge this”.

Claude, rewrite Bun in Rust.

There are a lot of ways to do a ter­ri­ble job of this. For ex­am­ple, prompt­ing Claude “Rewrite Bun in Rust. Don’t make any mis­takes.” and then pray­ing it would work is not what I did.

Think about how a per­son would do this. The first big ques­tion is:

Incremental rewrite? Or, every­thing all at once?

In my ex­pe­ri­ence port­ing es­build’s tran­spiler from Go to Zig for the ini­tial ver­sion of Bun (without LLMs), every­thing all at once is bet­ter. An in­cre­men­tal rewrite adds tem­po­rary code that you hope gets deleted even­tu­ally, and would be painful in the short-medium term.

The sec­ond big ques­tion: how?

How do we keep Bun in Rust the same Bun as be­fore, with the same ar­chi­tec­ture, per­for­mance, and fea­ture-set while also get­ting the lan­guage fea­tures of Rust like the bor­row checker? How do we en­sure the team can still main­tain it af­ter the rewrite?

Do the rewrite that looks like we tran­spiled our Zig code to Rust. We can grad­u­ally refac­tor it to re­duce un­safe us­age and look more like id­iomatic Rust af­ter Bun v1.4 ships.

Those are the only two big ques­tions. Everything else is tac­tics.

Loops that write & re­view code

A lot of day-to-day en­gi­neer­ing work as soft­ware en­gi­neers can be over-sim­pli­fied into loops.

// Pseudocode, not real code: let task; while ((task = todoList.pop())) { const re­sult = task(); const feed­back = await Promise.all([review(result), re­view(re­sult)]); await ap­ply(feed­back, re­sult); }

A task has some con­text as­so­ci­ated with it (a Jira ticket, a GitHub is­sue, etc). The re­sult is the code you wrote to fix it. Code re­viewer(s) re­view the changes to check for re­gres­sions & cor­rect­ness. And then you ad­dress the feed­back.

I rewrote Bun in Rust us­ing about 50 dy­namic work­flows in Claude Code run con­tin­u­ously over the course of 11 days.

Each dy­namic work­flow was a loop like this - a work­flow for:

Generate a port­ing guide map­ping Zig pat­terns & types to Rust pat­terns & types

Mechanically port every .zig file to a .rs file, match­ing the PORTING.md and LIFETIMES.tsv

Fix every crate’s com­piler er­rors

Get sub­com­mands like bun test or bun build to work

Get every test in Bun’s en­tire test suite to pass

Several large refac­tors and cleanup passes

For most of those 11 days (and af­ter), I mon­i­tored work­flows - man­u­ally read­ing the out­puts to check for is­sues and bugs, and prompt­ing Claude to edit the loop to fix things.

How do you re­view a PR with +1 mil­lion lines added? How do you start to build the con­fi­dence needed to re­spon­si­bly merge large quan­ti­ties of LLM-authored code?

A lan­guage-in­de­pen­dent test suite with a mil­lion as­ser­tions, ad­ver­sar­ial code re­view and when some­thing does go wrong, fix­ing the process that gen­er­ates the code in­stead of hand-fix­ing the code.

Adversarial re­view

Adversarial re­view asks Claude (in a sep­a­rate con­text win­dow) to ex­haus­tively come up with rea­sons why the changes cre­ate bugs or do not work.

Split con­text win­dows

Usually with hu­mans, the per­son re­view­ing the code is not the per­son who au­thored the code. The per­son writ­ing the code wants to merge the code, which can bias their ac­tions to ship be­fore it’s ready.

Claude is the same way. The Claude that wrote the code wants the code to get ac­cepted. The Claude that re­views wants to find is­sues in the code.

1 im­ple­menter, 2 or more ad­ver­sar­ial re­view­ers per im­ple­menter. The re­view­er’s only job: find bugs & rea­sons why the code does not work. The im­ple­menter does­n’t re­view. The re­viewer does­n’t im­ple­ment.

✻ claude code · dy­namic work­flowad­ver­sar­ial re­view3 of the many bugs ad­ver­sar­ial re­view caught be­fore merge

bug 1 of 3 · the async close

✻claudeimplementer

its con­text: the .zig orig­i­nal, the port plan, its own rea­son­ing

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 not do that.

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 claims they were fuzzing their Zig code, while dur­ing our calls the whole Bun team told us that they were not fuzzing any­thing. This ap­pears to be an out­right fab­ri­ca­tion.

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 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?

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.

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 FAANG™ Life Simulator

one tap = one quar­ter of your life · feat. MILTON

daily run = every­one gets the same cursed time­line to­day. com­pare es­capes.

not af­fil­i­ated with any tril­lion-dol­lar com­pany, al­legedly.

mil­ton ↑

—

—

AGE 22Y1 · Q1

🏝️ FREEDOM (quit-forever fund)0%

📈 per­for­mance50

🚀 trac­tion0

🔥 burnout10

NET WORTH$0k

COMP / YR$190k

we are so back

GO HOME

Form HR-1099-RAT · Exit Interview · —

—

—

—

—

one square = one year of your life:

—

Post on 𝕏

July 8, 2026

I use LLMs a lot. By cur­rent dev stan­dards, my us­age rate is prob­a­bly av­er­age, and my meth­ods are prob­a­bly prim­i­tive. I work on one task at a time and dis­cuss it with Claude Code (at work) or Codex (at home, for now). Sometimes, I let the as­sis­tant write code, but I read the out­put thor­oughly, un­der­stand it, and re­vise it. I’m not in the deep end of au­tonomous agents or agent or­ches­tra­tion. Still, I spend hours each day in­ter­act­ing with LLMs across work and home. That’s a hell of a lot more than I did a few years ago, and I prob­a­bly don’t go a day with­out read­ing AI-generated text.

My job has changed from de­sign­ing and writ­ing code to de­sign­ing code, de­scrib­ing the de­sign to an LLM, re­view­ing code the LLM pro­duces, and then fi­nally writ­ing code. The LLM steps ex­pose me to ap­proaches I might not have con­sid­ered or been aware of. I also feel more com­fort­able in ar­eas where I don’t have deep knowl­edge.

My main pro­ject right now is to es­tab­lish a frame­work for large-scale, un­su­per­vised code gen­er­a­tion in our code­base. When I’m not work­ing with Claude to cre­ate tool­ing, I’m sift­ing through the un­su­per­vised agen­t’s (Qwen’s) out­put. Either way, I’m read­ing LLM con­tent.

If I want to know some­thing, I’ll prob­a­bly ask ChatGPT or read Gemini’s overview un­less I know what sites I want to check. I still have to fall back to brows­ing when the LLM’s an­swer is wrong, but it’s good enough for many ca­sual queries, es­pe­cially when use­less AI-generated ar­ti­cles clut­ter the search re­sults.

It’s been this way for about a year, and I don’t see my­self stop­ping. I feel more pro­duc­tive with LLMs, and I think con­tin­u­ally learn­ing how to use them ef­fec­tively is valu­able. However, my dis­po­si­tion has changed a bit in the last few months. Some small part of me has started to dread read­ing LLM out­put be­cause I know what I’m go­ing to find. False as­sump­tions and hal­lu­ci­na­tions. Emphatic, stac­cato frag­ments. ✨ Excessive emo­jis 🚀. It’s not just me—these are real pat­terns (🤮).

On their own, none of these an­noy­ances gets to me. Together, though, they’ve got­ten me sick of LLM writ­ing in a hurry.

I’m not try­ing to con­demn LLMs. Humans are fal­li­ble, too—we can be just as un­re­li­able or an­noy­ing. The prob­lem is rep­e­ti­tion. LLMs write in the same style, and they make the same kinds of mis­takes. Dealing with the same thing over and over is wear­ing me out. I can use per­son­al­iza­tion fea­tures if the in­ter­face of­fers them, but some idio­syn­crasies seep through. And of course, I don’t con­trol the style of con­tent gen­er­ated by other peo­ple.

I don’t know how to deal with this feel­ing yet. I did­n’t ex­pect to be so both­ered by it. Frustration at a flaky tool is un­der­stand­able, but the writ­ing pat­terns grind my gears, too. For now, I’ll grit my teeth and hope I don’t lose my lunch.

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.

Bonnie Tyler, the gravel-voiced star who eclipsed every­one’s heart

9 hours ago

James McCarthyBBC Wales

Getty Images

Bonnie Tyler is known to mil­lions as the gravel-voiced singer be­hind ’80s hit Total Eclipse of the Heart.

The star, who died aged 75 was born Gaynor Hopkins in a Neath coun­cil house where she grew up with a love for mu­sic be­fore be­ing dis­cov­ered by tal­ent scout Roger Bell in a Swansea club.

In May she was placed into an in­duced coma af­ter hav­ing emer­gency in­testi­nal surgery in Portugal, and last month, her spokesper­son said she was out of the coma but re­mained “very un­well and in in­ten­sive care”.

After find­ing fame she was dubbed the “the fe­male Rod Stewart” for her husky vo­cals, and went on to have a ca­reer that spanned 50 years.

Getty Images

Young Gaynor loved rock mu­sic and wanted to be in a band.

After seven years of gig­ging at rugby and work­ing men’s clubs, the chance to record fi­nally came up.

She said she had “no big ideas” about mak­ing records un­til Roger Bell came knock­ing.

“He knew that Ronnie Scott and Steve Wolf were look­ing for a girl to record their songs so he told them about me,” she said.

“I went to London and one of the first demos I recorded was Lost in France and then I was on Top Of The Pops.”

Lost in France, re­leased in 1976, was her first sin­gle to make the UK charts, mak­ing it to num­ber nine.

But her love of rock never left her and she wanted to do “raunchier stuff”.

Bonnie went on to sign with RCA, which had Elvis Presley on its books.

At the time she was work­ing un­der the name Sherene Davies but the la­bel sug­gested she change Sherene as it “sounded like a belly dancer”.

Getty Images

Bonnie said: “I got a broad­sheet news­pa­per and I made an ef­fort to write all the first names I came across on one list and all the sur­names on an­other and I went through them both and came up with Bonnie Tyler. And it’s been a bril­liant name.”

She re­leased Total Eclipse of the Heart five years af­ter Lost in France. It changed her life.

“The first time I heard it was when [songwriter] Jim Steinman just played it on the pi­ano in New York,” she said.

“He sang the song all the way through and I was like, ‘Oh my god, this song is amaz­ing. I can’t be­lieve Jim is giv­ing it to me’.

“When I recorded the song, I thought no-one is go­ing to end up play­ing this be­cause it’s so long.

“The orig­i­nal ver­sion is eight min­utes long.”

But a four-minute ra­dio ver­sion took the world by storm, with the bal­lad spend­ing two weeks as UK num­ber one, and four weeks in the US.

Bonnie was the first - and only - Welsh artist to have a num­ber one in the US.

She went on to have a string of other hits, in­clud­ing Holding out for a Hero, It’s A Heartache, Together, and If You Were A Woman [And I Was A Man].

Getty Images

The star was nom­i­nated for a best fe­male vo­cal Grammy three times - for the Total Eclipse of the Heart sin­gle, al­bum Faster Than The Speed Of Night and the sin­gle Here She Comes.

In 2013 she rep­re­sented the UK at the Eurovision Song Contest.

“I grew up in a coun­cil house. I never thought I would have an MBE,” she said in 2023.

That year she pub­lished an au­to­bi­og­ra­phy, called Straight from the Heart.

“I was a very shy lit­tle girl so how on Earth I got to where I am now is a bit of a jour­ney and I take you on that jour­ney,” she said.

“I did not think this would hap­pen to a Gaynor from Skewen, you know.”

On YouTube the video has been watched more than 1.3 bil­lion times.

After 43 years of singing it she in­sisted she never be­came bored of it.

“I love it,” she said.

Getty Images

“My mother brought me up to be­lieve in my­self,” she told the BBC last year.

“I was a very shy lit­tle girl grow­ing up in school, would­n’t say ‘boobah’ to a goose, and I was very, very shy.

“But I’ve over­come that, be­cause I love singing.”

Bonnie’s love for the in­dus­try was still clear in that in­ter­view, and she had just re­leased a new sin­gle Yes I Can, a song about find­ing in­ner strength and be­liev­ing in your­self.

Reports sug­gest that Bonnie and her hus­band, Robert Sullivan, own 22 homes world­wide, though they mainly split their time be­tween Portugal and their home in Mumbles, Swansea.

Getty Images

Despite com­ing from a big, mu­si­cal fam­ily, Tyler and Sullivan never had chil­dren.

“You know when most peo­ple get on a plane and they avoid chil­dren like the plague, don’t they? Not me. I’m like, ‘can I sit here’?

“I did have a mis­car­riage when I was 40, I left it too late, you know? I wish I had started ear­lier, but my ca­reer took over and it was al­ways, ‘next year, next year’.

“And then next year did­n’t come un­til I was 39.”

After Tyler mis­car­ried, she threw her­self into work.

“We did try for an­other cou­ple of years, but… we’re fine, we’re happy.”

She con­quered the mu­sic world, and loved Europe - but Bonnie Tyler will al­ways be re­mem­bered as the Welsh star who was­n’t hold­ing out for a hero, but be­came one to mil­lions her­self.