The soft­ware de­vel­op­ment pro­fes­sion is in the midst of up­heaval. Nobody knows how the AI rev­o­lu­tion will play out in the end, but it is clear many as­pects of work and life will be trans­formed—in­clud­ing pro­gram­ming.

One of the com­ments I hear of­ten lately boils down to “LLMs may be good at cod­ing, but soft­ware was never the hard part” and “coding is easy, it’s fig­ur­ing out what to code that’s hard”.

I be­lieve that’s a gross in­sult to all pro­gram­mers every­where.

If cod­ing is easy…

If cod­ing is easy, how come pro­gram­mers were in high de­mand, and have de­manded large salaries for years (even be­fore ZIRP)? Why was there so much stress, over­work and burnout even be­fore AI started churn­ing out 5000-line PRs? Why did com­pa­nies seek 10x ninja rock­star coders and sub­ject them to leet­code in­ter­views—surely, a ju­nior fresh out of col­lege could churn out some­thing if it’s so easy?

If cod­ing is easy, why do we have doorstop­pers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light sum­mer read? Is SICP a cof­fee-table book? Why do we have boot­camps or even whole col­lege de­grees ded­i­cated to it?

If cod­ing is easy, was Carmack just at the right place at the right time? Why do we con­sider Fabrice Bellard a ge­nius?

If cod­ing is easy, why are peo­ple an­gry at AI (or any­one else) copy­ing their code? Why do they act like they’ve poured their sweat, soul, and co­pi­ous amounts of time into some­thing so triv­ial?

If cod­ing is easy, why do many now feel like their iden­tity and pro­fes­sional pur­pose are be­ing stripped away from them?

If cod­ing is easy, why is soft­ware so damn buggy?

If fig­ur­ing out what to build is the hard part…

If de­cid­ing what to build is the hard part, why do so many prod­uct man­agers seem clue­less? Why aren’t there rig­or­ous 10-step in­ter­views for them? Why aren’t they get­ting paid more than the de­vel­op­ers?

If de­cid­ing what to build is the hard part, why aren’t mar­ket re­searchers, us­abil­ity ex­perts and—hell, cus­tomer suc­cess—con­sid­ered rock­stars in a soft­ware com­pany? If “understanding the cus­tomer” is harder, why are busi­ness an­a­lysts looked down on as pen­cil push­ers?

If im­ple­men­ta­tion is easy and find­ing de­mand is harder, why are pro­gram­mers up­set when the sales­peo­ple promise a new fea­ture to a cus­tomer to close the sale? They’ve found a gen­uine de­mand, some­thing peo­ple will pay for!

If cod­ing is easy, why does­n’t every­one just build ten vari­a­tions of a thing and see which pans out?

Another cliché com­ment is “most work in soft­ware de­vel­op­ment is talk­ing to stake­hold­ers, un­der­stand­ing the cus­tomer’s needs, and hav­ing clar­ity on the pri­or­i­ties”.

I have met many pro­gram­mers through­out my ca­reer, and very few of them want to talk to stake­hold­ers, much less cus­tomers (exceptions are free­lancers and founders, es­pe­cially of soft­ware de­vel­op­ment shops). And, “having clar­ity on the pri­or­i­ties” boils down to “just tell me what to do and don’t switch it up every two days”.

Some soft­ware de­vel­op­ers do say “I don’t write code, I solve cus­tomer’s prob­lems”. But then they turn around and start to opine on mon­ads, mem­ory safety, and DRY prin­ci­ples, while their un­der­stand­ing of the cus­tomer is a made-up “user per­sona”, and they think “affordance” is the money your par­ents used to give you on week­ends so you could go out and have a good time.

Yet oth­ers will say “Software de­vel­op­ment is the­ory build­ing”. Programs are ac­tu­ally proofs (as in, math­e­mat­i­cal proofs). Every com­mit should tell a story. And solv­ing a cus­tomer’s prob­lem by FTPing a PHP file is a car­di­nal sin.

I don’t mean to im­ply there are no de­vel­op­ers that si­mul­ta­ne­ously care deeply about the craft of soft­ware de­vel­op­ment and re­ally em­pathize with the cus­tomer. I do be­lieve they might want to see a pro­fes­sional about a split per­son­al­ity dis­or­der, tho.

What is im­por­tant?

I do be­lieve that talk­ing to users, un­der­stand­ing their ex­pe­ri­ence, em­pathiz­ing with them, solv­ing cus­tomers’ prob­lems and hav­ing all the stake­hold­ers on the same page is crit­i­cal to the suc­cess of a soft­ware pro­ject.

I also be­lieve that cre­at­ing good code is a craft that re­quires skill, pa­tience, at­ten­tion to de­tail, ex­pe­ri­ence and wis­dom, and that it will con­tinue to be rel­e­vant in the times ahead.

¿Por qué no los dos?

To the ex­tent that we can pull it off, I think we should aim for both. A deep un­der­stand­ing of the sys­tem we’re build­ing, to­gether with a deep un­der­stand­ing of why we’re build­ing it.

Loudly pro­claim­ing that “code is easy” or, at the op­po­site end, “code is art, a cre­ative hu­man ex­pres­sion that can­not be au­to­mated”, is just bury­ing our heads in the sand.

It’s cope. And you don’t want cope, you want to thrive.

By this, I don’t mean “jump on the LLM band­wagon.” I don’t mean “become a man­ager of fleets of AI agents.” I also don’t mean “AI-generated code is stolen slop garbage, fight it with tooth and nail, the bub­ble will pop soon enough any­ways.”

But do rec­og­nize we’re in the mid­dle of an in­dus­try-wide tec­tonic change. We need to fig­ure out how to adapt. We need to un­der­stand what is likely to change and what never changes.

What does­n’t change?

Software will be get­ting more com­plex. Software will al­ways need main­te­nance: bit-rot is a fact of life. So is en­tropy. Technology (hardware and soft­ware) will move for­ward, for bet­ter or worse. The tower (skyscraper?) of ab­strac­tions grows ever higher.

Users will al­ways want more and be pre­pared to spend less. They still won’t know how to re­lay their needs and wants. Worse, they still won’t know ex­actly what they want. The dis­con­nect be­tween the cus­tomers (who ac­tu­ally pay for the soft­ware) and users (who use it) will still be here, as will the ten­sion be­tween the needs of the busi­ness and the needs of its cus­tomers.

Also: there will never be a short­age of snake oil sales­men. Tech du jour comes and goes (I’m still wait­ing for the new VR re­nais­sance!)

What changes?

Programmers have been in the busi­ness of dis­rupt­ing our own in­dus­try since the be­gin­ning. Nobody uses punch-cards any more. Very few peo­ple need to code in as­sem­bly, or COBOL. Those decades spent fight­ing mem­ory bugs in C or C++, with the scars to prove it, are worth­less in the age of Rust, Go, Python and JavaScript.

I’m old enough to ap­pre­ci­ate val­grind or re­mem­ber mysql_re­al_es­cape_string() from the PHP4 era—stuff I’ll never again need in my life. And that was­n’t even so long ago! I nar­rowly missed the dBase, Clipper, HyperCard and Access era, tech­nolo­gies which I can still spot op­er­at­ing in shops, cafes, or a dusty, once beige and now golden-brown, midi-tower still hap­pily run­ning some be­spoke biz so­lu­tion (backups? what back­ups?)

How do we thrive?

Accept that change hap­pens. Be equal parts cu­ri­ous and crit­i­cal about the new stuff.

Understand there’s a lot of hype and try to dis­crim­i­nate be­tween hot air and what re­ally works (and to what ex­tent). Also be aware of ever-shift­ing goal­posts: stand back and look at the past year, or five, and as­sess the ve­loc­ity of change (technical, eco­nomic, so­ci­etal).

Your role and your re­spon­si­bil­i­ties will be chang­ing. Be will­ing to in­vest time and en­ergy into bet­ter un­der­stand­ing fields or roles ad­ja­cent to yours.

If you’re a se­nior de­vel­oper, don’t just find so­lace in deep­en­ing your ex­per­tise. Learn about user ex­pe­ri­ence, cus­tomer in­ter­views, or busi­ness strate­gies for the com­pa­nies in your do­main. It will help you gain a bet­ter ap­pre­ci­a­tion of all the work done to put a piece of soft­ware into users’ hands, whether or not you’ll ac­tu­ally ever have to do any of those other bits.

If you’re just start­ing or are ju­nior in your role: in­vest in deep­en­ing your un­der­stand­ing of how soft­ware works. Understanding point­ers, re­cur­sion, or mem­ory hi­er­ar­chy will help you even if you’re a JavaScript de­vel­oper. Understanding net­work pro­to­cols and how HTTP works will be use­ful even if you’re build­ing WordPress plu­g­ins. Do leet­code and learn about al­go­rithms and data struc­tures even if you don’t need to. Don’t be afraid to ask why and how ex­actly.

For in­spi­ra­tion, here are a few books and other re­sources that might be help­ful:

Structure and Interpretation of Computer Programs (PDF)

Cracking the Coding Interview

The Mythical Man-Month

Working Backwards

Team Topologies

7 Powers

The Soul of a New Machine

Obviously Awesome

The Design of Everyday Things

Don’t Make Me Think

Continuous Discovery Habits

The Mom Test

One more thing

Whoever you are, don’t out­source your un­der­stand­ing, judge­ment, em­pa­thy and taste to AI. Don’t ab­di­cate your re­spon­si­bil­ity. Don’t be a meat proxy.

Students at Dueholmskolen are pic­tured in their class­room in Nykøbing Mors, Jutland, Denmark, on March 1, 2021. Bo Amstrup/Ritzau Scanpix/AFP/Getty Images.

The pol­icy takes ef­fect im­me­di­ately, but ed­u­ca­tors say the first re­sponse must evolve as AI tools keep ad­vanc­ing.

Danish high school stu­dents will be re­quired to de­fend their writ­ten as­sign­ments orally un­der new gov­ern­ment mea­sures aimed at com­bat­ing cheat­ing with ar­ti­fi­cial in­tel­li­gence.

The Ministry of Education said that an oral de­fense will be­come manda­tory for all writ­ten as­sign­ments com­pleted at home and that it will work closely with schools to de­velop the best frame­work for im­ple­ment­ing these changes.

The reg­u­la­tion takes ef­fect im­me­di­ately and ap­plies to up­per-sec­ondary stu­dents, who are typ­i­cally around 16 years old. The mea­sure con­cerns ap­prox­i­mately 9,000 stu­dents en­rolled in the two-year HF (Higher Preparatory Examination) pro­gram, who are re­quired to sub­mit ma­jor writ­ten as­sign­ments each year, the min­istry said.

The min­istry is also urg­ing up­per-sec­ondary schools to use screen-mon­i­tor­ing tools dur­ing ex­ams and in­tro­duce fire­walls to re­strict the con­tent stu­dents can ac­cess dur­ing classes and fi­nal as­sign­ments.

In ad­di­tion, schools are ad­vised to have more as­sign­ments com­pleted on cam­pus un­der con­trolled con­di­tions so that su­per­vi­sion can be more ef­fec­tive.

Reaction from the ed­u­ca­tion com­mu­nity and next steps

Three or­ga­ni­za­tions rep­re­sent­ing school lead­ers, teach­ers, and up­per-sec­ondary stu­dents wel­comed the mea­sures but called for more last­ing so­lu­tions in re­sponse to the “rapid pace of tech­no­log­i­cal de­vel­op­ment,” the as­so­ci­a­tion Danske Gymnasier re­ported on Thursday.

“Unfortunately, we have a prob­lem with stu­dents us­ing AI to cheat in up­per-sec­ondary schools. Action is needed now, and we are start­ing with these three ini­tia­tives. In the com­ing pe­riod, I will in­volve schools, teach­ers, and stu­dents in dis­cus­sions about what can be done both in the short and long term to en­sure that AI does not un­der­mine stu­dents’ skills, their aca­d­e­mic abil­i­ties, or, not least, their ca­pac­ity for in­de­pen­dent thought,” — Magnus Heunicke

“Unfortunately, we have a prob­lem with stu­dents us­ing AI to cheat in up­per-sec­ondary schools. Action is needed now, and we are start­ing with these three ini­tia­tives. In the com­ing pe­riod, I will in­volve schools, teach­ers, and stu­dents in dis­cus­sions about what can be done both in the short and long term to en­sure that AI does not un­der­mine stu­dents’ skills, their aca­d­e­mic abil­i­ties, or, not least, their ca­pac­ity for in­de­pen­dent thought,”

– Magnus Heunicke

“These re­quire­ments in­clude hav­ing stu­dents clearly state when AI has been used in ma­jor writ­ten as­sign­ments and en­sur­ing that prepa­ra­tion for oral ex­ams takes place with­out ac­cess to AI,” — Anders Frikke

“These re­quire­ments in­clude hav­ing stu­dents clearly state when AI has been used in ma­jor writ­ten as­sign­ments and en­sur­ing that prepa­ra­tion for oral ex­ams takes place with­out ac­cess to AI,”

– Anders Frikke

According to Oscar Tønsberg Hoffmann, chair of the Danish Association of Upper-Secondary Students (DGS), it is im­por­tant that stu­dents have the op­por­tu­nity to help de­velop long-term so­lu­tions and par­tic­i­pate in shap­ing fu­ture poli­cies.

“It is im­por­tant that stu­dents have the op­por­tu­nity to help de­velop long-term so­lu­tions.” — Oscar Tønsberg Hoffmann

“It is im­por­tant that stu­dents have the op­por­tu­nity to help de­velop long-term so­lu­tions.”

– Oscar Tønsberg Hoffmann

The Danish Association of Upper-Secondary Schools also em­pha­sizes the need for a swift and con­sid­ered re­sponse to tech­no­log­i­cal de­vel­op­ment, while the Ministry of Education says that the three ini­tia­tives are only the be­gin­ning and that con­sul­ta­tions with ed­u­ca­tional in­sti­tu­tions, teach­ers, and stu­dents will con­tinue in both the short and long term.

The gov­ern­ment as­sured that ef­forts to pre­vent AI-assisted cheat­ing and de­velop crit­i­cal think­ing and in­de­pen­dent learn­ing skills will re­main a pri­or­ity in re­form­ing Denmark’s ed­u­ca­tion sys­tem.

I use Strava for the ob­vi­ous stuff, like runs, HIIT classes, and the oc­ca­sional com­mute that goes full work­out when I’m des­per­ate to get my steps in. I’m not a pet owner, but I can un­der­stand a dog walk mak­ing it on there, too. The dog may be in­volved, but at least you’re still the one do­ing the walk­ing.

But work­outs up­loaded from a ham­ster wheel? That feels like new ter­ri­tory.

Thijs de Buck, an MRI physi­cist based in Utrecht, the Netherlands, re­cently posted on Reddit that he built a speed and dis­tance tracker for his ham­ster’s wheel, with the data au­to­mat­i­cally up­loaded to Mollie’s own Strava ac­count. Mollie, his 10-month-old ham­ster, is now com­mit­ted to log­ging nightly runs with dis­tance, pace, and time.

One re­cent ac­tiv­ity showed 6.06 miles in 4 hours and 37 min­utes. The next night, Mollie logged 5.55 miles in 3 hours and 56 min­utes.

At first, de Buck just wanted to know how much dis­tance Mollie was cov­er­ing af­ter dark.

“I bought a very cheap bi­cy­cle com­puter pretty much right away,” he told Runner’s World.

That worked at first, be­cause the bike com­puter also used a mag­net and sen­sor. But there was one very ham­ster-spe­cific prob­lem to deal with, as the sen­sor would shift into standby mode once Mollie stopped run­ning for more than five min­utes.

“So if Mollie would take a lunch break at 1 a.m., we’d have no idea how far he’d have run af­ter that,” de Buck said.

The bike com­puter also only gave him to­tal dis­tance, and that just was­n’t go­ing to cut it. De Buck wanted the full Strava treat­ment be­cause ap­par­ently even ham­sters de­serve splits, up­loads, and post-run analy­sis.

The build it­self is clever, but the ba­sic idea is sim­ple. As de Buck ex­plains it, a mag­net on the wheel passes a hall sen­sor, which de­tects each ro­ta­tion. An ESP32—basically a tiny pro­gram­ma­ble com­puter—keeps track of the data overnight. In the morn­ing, he says a script on his lap­top col­lects the in­for­ma­tion, turns it into a Strava-compatible .FIT file, and up­loads the ac­tiv­ity through the Strava API.

“All that re­mains is for me to man­u­ally add a photo of Mollie, and for Mollie to do the ac­tual hard work dur­ing the night,” de Buck said.

De Buck could have stopped once the runs were up­load­ing, but a ham­ster Strava ac­count needed all the ex­tra fea­tures. There’s a tiny or­ganic light-emit­ting diode (OLED) dis­play to show Mollie’s live speed, a code that helps for au­to­mated per­sonal-best track­ing, and more than 100 pos­si­ble run ti­tles, in­clud­ing “The Fast and the Furriest” and “No Rest for the Whiskered,” nat­u­rally.

The one thing he did­n’t plan for was that auto-up­load­ing the files this way re­quired a paid ac­count.

“There was re­ally only one rea­son­able so­lu­tion: my ham­ster now has Strava Premium,” de Buck said.

A ham­ster with this much per­for­mance data was al­ways go­ing to find an au­di­ence. De Buck said the ac­count picked up thou­sands of likes, more than 1,200 ku­dos, and more than 600 fol­low­ers within a week. He also signed Mollie up for Strava’s August 400-minute chal­lenge, and Mollie com­pleted it on Day 2—a wake-up call for any­one still ig­nor­ing their own monthly chal­lenges.

Mollie has been with de Buck since Christmas, and his life out­side train­ing sounds, quite frankly, pretty fo­cused. De Buck de­scribed it as “eat-sleep-run-repeat,” with Mollie spend­ing much of the day hid­den un­der­ground be­fore wak­ing up and al­ter­nat­ing be­tween food and wheel time.

De Buck and Mollie dur­ing a re­cent train­ing ses­sion.

And the lit­tle guy’s not ex­actly phon­ing it in. De Buck said Mollie is av­er­ag­ing al­most 10 kilo­me­ters per night, with a cur­rent record of 10.8 kilo­me­ters af­ter the first week of track­ing.

“I re­ally be­lieve he’ll be able to ex­ceed that soon,” he said.

Mollie also has a weirdly con­sis­tent sched­ule for a ham­ster. Over one seven-day stretch, he started within the same 10-minute win­dow on five nights, be­tween 9:54 and 10:04 p.m. He tends to run in short bursts, some­times reach­ing about 4 to 5 kilo­me­ters per hour on the live mon­i­tor, then hops off for wa­ter.

“Even elite ath­letes need to stay hy­drated,” de Buck joked.

De Buck is a run­ner him­self, which helps ex­plain why the pro­ject ended up with this level of data. He said he loves “tracking every pos­si­ble stat” dur­ing marathon train­ing, so want­ing more in­for­ma­tion about Mollie’s nightly mileage felt nat­ural. He is also deal­ing with a mi­nor in­jury at the mo­ment, which gave him more time to work on the setup.

“When I get back, I think it’ll be a nice chal­lenge to try to match Mollie’s weekly run­ning dis­tance,” he said. “I don’t nor­mally hit 70km a week!”

The next mile­stone is Mollie’s 20th run, when Strava should start giv­ing race pre­dic­tions.

“I can’t wait to see his es­ti­mated 5K and marathon times,” de Buck said, “and whether he’ll man­age to im­prove those pre­dic­tions over time! Although I’m a bit wor­ried he’ll have a bet­ter marathon time than me.”

Sean Abrams was the Senior Editor, Growth and Engagement at Men’s Health. He’s a for­mer hip hop dancer who likes long walks on the beach and large glasses of tequila. You can find his pre­vi­ous work at Maxim, Elite Daily, and AskMen.

The Nixpkgs core team has un­for­tu­nately de­cided to dis­band.

We’re proud to have had the op­por­tu­nity to lead by ex­am­ple in bot­tom‐up, con­sen­sus‐fo­cused gov­er­nance for Nixpkgs, and of our achieve­ments over the past 10 months, in­clud­ing re­form­ing the com­mit­ter del­e­ga­tion process and on­board­ing 19 new com­mit­ters, em­pow­er­ing main­tain­ers by ex­tend­ing the merge bot, re‐es­tab­lish­ing con­tact with GitHub and se­cur­ing the spon­sored Enterprise Cloud up­grade, help­ing triage GHSA-67f2 – 674w-6g63 and track the GitHub se­cu­rity risks ex­posed by that in­ci­dent, and es­tab­lish­ing an ini­tial au­toma­tion/​AI pol­icy, as well as help­ing re­solve many in­ci­dents that were es­ca­lated to us.

However, it has sadly not turned out to be the light­weight role com­pat­i­ble with ac­tive tech­ni­cal con­tri­bu­tion that we had orig­i­nally hoped it would be, and two weeks ago we reached the con­clu­sion that step­ping down is nec­es­sary for our health. We be­lieve that it’s un­sus­tain­able for the team to con­tinue, as demon­strated in part by our at­tri­tion to date. With only one per­son ac­tively ap­ply­ing in re­sponse to our call for new mem­bers and mixed re­sponse to out­reach, re­cruit­ing suf­fi­ciently to keep things healthy looks un­ten­able. Therefore, es­pe­cially with a Steering Committee elec­tion due im­mi­nently, we think the best way for­ward for Nixpkgs gov­er­nance is to be hon­est about the cir­cum­stances that have made dis­solv­ing the team un­avoid­able, in the hopes that it may help fu­ture ef­forts.

Our ex­pe­ri­ence is that the Steering Committee as an in­sti­tu­tion lacks a na­tive in­stinct for the del­e­ga­tion en­vi­sioned by the con­sti­tu­tion, while also not be­ing suf­fi­ciently en­gaged and co­he­sive to han­dle in­di­vid­ual de­ci­sions at those lev­els it­self. This man­i­fests as un­nec­es­sary mi­cro­man­age­ment of teams be­low them and chron­i­cally poor com­mu­ni­ca­tion, in­clud­ing lack of clar­ity from SC mem­bers about when they’re speak­ing for them­selves or rep­re­sent­ing a joint po­si­tion, mat­ters brought to our at­ten­tion with de­sired out­comes al­ready at­tached, tak­ing own­er­ship of is­sues en­tirely within del­e­gated ar­eas with­out in­volv­ing rel­e­vant teams, and in­suf­fi­cient and de­layed re­sponses to con­cerns. The end re­sult has been in­ad­e­quate co­or­di­na­tion on mat­ters like GSoC, grants ini­tia­tives, and AI pol­icy, slow and dif­fi­cult progress on mat­ters rel­e­vant to Nixpkgs like mod­er­a­tion and GitHub org owner re­form, and gen­eral un­cer­tainty about whether we are trusted to au­tonomously make de­ci­sions within our re­mit.

These is­sues have per­sisted de­spite our re­peated at­tempts to dis­cuss them. This is, of course, a sys­temic prob­lem rather than one any sin­gle SC mem­ber could solve; we don’t envy the de­mands of the role, have been im­pressed by the ef­forts of sev­eral mem­bers, and rec­og­nize that every in­di­vid­ual nat­u­rally has lim­ited time and en­ergy and can only do so much in the con­text of a rep­re­sen­ta­tive ma­jori­tar­ian com­mit­tee. Ultimately, though, it leaves the SC not func­tion­ing ef­fec­tively as ei­ther a rep­re­sen­ta­tive back­stop to del­e­ga­tion or a proac­tive de­ci­sion‐mak­ing body. The re­sult­ing en­vi­ron­ment has acted as a con­sis­tent drag on our work, mak­ing it dif­fi­cult for us to ful­fil our con­sti­tu­tional man­date of “Project Direction, Decision-Making, Coordination with the NixOS Foundation Board, and Creation and Management of Teams, where they per­tain to Nixpkgs”.

We be­lieve our high‐trust con­sen­sus de­ci­sion‐mak­ing model has re­sulted in high‐qual­ity dis­cus­sions and good re­sults, and is a bet­ter fit for a del­e­gated lo­cal gov­er­nance team than the ma­jor­ity votes used at the top level by the SC. It’s not news to any­body that our com­mu­nity has many strong di­vides and dis­agree­ments, but nonethe­less we’ve seen many sit­u­a­tions where the abil­ity to call on the core team for a res­o­lu­tion has helped calm ten­sions and led to agree­able out­comes. We con­sider the strong ap­proval for the ini­tial au­toma­tion/​AI pol­icy from peo­ple with highly di­ver­gent views to be proof that it’s pos­si­ble to find paths for­ward and make sig­nif­i­cant im­prove­ments even on seem­ingly in­tractable top­ics.

It in­evitably takes its toll to step in un­der such cir­cum­stances, though. Given our own ex­pe­ri­ences and the his­tory of the pro­ject, we un­der­stand why there is a gen­eral dis­trust of gov­er­nance in the com­mu­nity, and how that has en­cour­aged a com­bat­ive, zero‐sum ap­proach to dis­agree­ments. While those meth­ods may work to ef­fect change de­spite a lead­er­ship vac­uum or to be heard by un­re­spon­sive gov­er­nance, they con­tribute to burnout when lead­er­ship teams are try­ing to en­gage in good faith and fos­ter pro­duc­tive dis­cus­sion. That out­come only re­wards those who don’t care to lis­ten to the com­mu­nity or to pur­sue trust‐based con­sul­ta­tive lead­er­ship at all, fur­ther re­duces the small pool of ex­pe­ri­enced con­trib­u­tors with the time and de­sire to par­tic­i­pate in gov­er­nance, and risks lock­ing in the his­tor­i­cal sta­tus quo of de­ci­sion‐mak­ing by dead­lock and at­tri­tion.

We want to be clear that this de­ci­sion is not the re­sult of any one in­ci­dent, but the cul­mi­na­tion of long‐run­ning pat­terns. The mat­ters in our ju­ris­dic­tion are left with no di­rect owner at pre­sent, with the SC act­ing as the fi­nal back­stop as al­ways. We both plan to re­duce our Nixpkgs in­volve­ment and have no in­ten­tion of run­ning for SC. We still be­lieve in the prin­ci­ples the team was founded on — that clear, light­weight processes for de­ci­sion‐mak­ing and dis­pute res­o­lu­tion are crit­i­cal to strength­en­ing Nixpkgs and ad­dress­ing the prob­lems we’ve seen as con­trib­u­tors — and hope that a gen­uine del­e­ga­tion of en­gaged, tech­ni­cally‐fo­cused, col­lab­o­ra­tive Nixpkgs lead­er­ship by top‐level gov­er­nance will be pos­si­ble in the fu­ture.

We’d like to thank every­one who has sup­ported our work, and re­gret that the team has­n’t been in a po­si­tion to solve these is­sues more com­pre­hen­sively and sus­tain­ably.

On be­half of the Nixpkgs core team:

@alyssais

@emilazy

August 6, 2026 Science

WeatherNext team

WeatherNext en­ables ac­cu­rate cy­clone fore­casts that can give an ex­tra day of warn­ing. Now we are open sourc­ing the model.

Predicting how dan­ger­ous cy­clones de­velop is a long­stand­ing chal­lenge where every hour counts. Tropical cy­clones — also known as hur­ri­canes or ty­phoons — are among the most de­struc­tive weather phe­nom­ena on Earth, re­spon­si­ble for more than 700,000 deaths and $1.4 tril­lion in eco­nomic losses glob­ally over the past 50 years. For fore­cast­ers, is­su­ing timely, ac­cu­rate warn­ings is a con­stant race against time.

Today, in a pa­per pub­lished in Nature, we show that our WeatherNext AI model achieved state-of-the-art ac­cu­racy in pre­dict­ing a cy­clone’s track, in­ten­sity, and wind struc­ture. On av­er­age, our model gives fore­cast­ers an ex­tra day’s worth of pre­dic­tive ac­cu­racy: our three-day fore­casts are as good as what prior mod­els were able to pro­vide for only the next two days. This scale of im­prove­ment cor­re­sponds roughly to a decade’s worth of me­te­o­ro­log­i­cal progress.

This col­lab­o­ra­tive work brought to­gether AI re­searchers and en­gi­neers at Google DeepMind and Google Research, with ex­pert fore­cast­ers at the National Hurricane Center (NHC), the Cooperative Institute for Research in the Atmosphere (CIRA), the UK Met Office, and weather agen­cies around the world.

Our re­search has al­ready had real-world im­pact. During the 2025 hur­ri­cane sea­son, our model helped the NHC to make a his­toric fore­cast for Hurricane Melissa by pre­dict­ing the stor­m’s rapid in­ten­si­fi­ca­tion and land­fall in Jamaica. This en­abled the NHC to is­sue an ad­vance warn­ing, giv­ing teams on the ground crit­i­cal time to pre­pare. This year, we con­tinue to work to­gether and are now pre­dict­ing 1,000 pos­si­ble sce­nar­ios for each cy­clone to help sup­port fore­cast­ers in their de­ci­sion-mak­ing.

Weather af­fects every­one. Given this broad im­pact, we are now open sourc­ing our WeatherNext 2 and WeatherNext Cyclones mod­els used dur­ing the hur­ri­cane sea­son. By mak­ing this tech­nol­ogy openly avail­able, we hope to em­power the re­search com­mu­nity and am­plify AI’s im­pact in build­ing more re­silient com­mu­ni­ties — whether that be pro­vid­ing lo­cal fore­cast­ers with the tools they need to pre­pare for nat­ural dis­as­ters, sup­port­ing the growth of re­new­able en­ergy, or an­tic­i­pat­ing ex­treme weather.

How WeatherNext pre­dicts weather and cy­clones

Starting from global at­mos­pheric con­di­tions dur­ing Hurricane Milton (October 2024), WeatherNext Cyclones it­er­a­tively pre­dicts both global weather pat­terns and fine-scale cy­clone tracks up to 15 days in ad­vance. Running a 1,000-member en­sem­ble gen­er­ates lo­calised prob­a­bil­ity maps of trop­i­cal storm to hur­ri­cane-force winds.

Predicting cy­clones has typ­i­cally forced a trade-off re­quir­ing two dis­tinct mod­el­ing tech­niques. A cy­clone’s track (where it goes) is steered by mas­sive, global at­mos­pheric cur­rents, which be­fore now have been best mod­eled by coarser global mod­els. However, a cy­clone’s in­ten­sity (how strong it gets) is dri­ven by highly lo­cal­ized, fine-scale ther­mo­dy­namic phys­i­cal processes around its core, which are best mod­eled by spe­cial­ized, higher res­o­lu­tion, lo­cal mod­els.

Our WeatherNext model bridges this gap by im­prov­ing fore­cast­ing for global weather over­all as well as cy­clones. It is a sin­gle AI model that pre­dicts a trop­i­cal cy­clone’s track, in­ten­sity, and wind struc­ture with state-of-the-art ac­cu­racy. It achieves this break­through through a unique com­bi­na­tion of its train­ing, ar­chi­tec­ture and ap­proach to low res­o­lu­tion in­puts.

We eval­u­ated WeatherNext Cyclones on his­tor­i­cal cy­clones from 2023 to 2024, bench­mark­ing its de­ter­min­is­tic and prob­a­bilis­tic per­for­mance against other top weather mod­els. On av­er­age, WeatherNext Cyclones gains more than a full day (24 hours) of lead time ad­van­tage for pre­dict­ing cy­clone tracks, in­ten­sity, and wind struc­ture.

The model was co-trained on two dis­tinct data modal­i­ties: global weather dy­nam­ics and ex­pert-cu­rated his­tor­i­cal cy­clone ob­ser­va­tions. By train­ing end-to-end on nearly 20 ter­abytes of global at­mos­pheric data and the his­tor­i­cal IBTrACS data­base span­ning nearly 5,000 his­tor­i­cal storms, the model learns com­plex at­mos­pheric pat­terns and how to model ex­treme weather.

Cyclone fore­cast ac­cu­racy has been steadily ad­vanc­ing over re­cent decades. The plots show the 3-day ac­cu­racy of ECMWF-ENS track fore­casts (a) and HWRF in­ten­sity fore­casts (b) over the years, and how WeatherNext Cyclones con­tributes a step change in ac­cu­racy for both track and in­ten­sity. This im­prove­ment is the equiv­a­lent to a one-decade progress ac­cord­ing to trends over the last 20 years.

Our model uses Functional Generative Networks (FGNs) to ef­fi­ciently pro­duce en­sem­bles of dif­fer­ent pre­dic­tions, which cap­tures the in­her­ent un­cer­tainty of the weather. We can now gen­er­ate a sin­gle 15-day fore­cast in less than a minute on a TPU, em­pow­er­ing fore­cast­ers to quickly eval­u­ate the prob­a­bil­ity dis­tri­b­u­tion of po­ten­tially dev­as­tat­ing tail-risks. Last year, our sys­tem pro­duced 50 pre­dic­tions at a time, match­ing global physics mod­els. This year we scaled our en­sem­ble size to 1,000 mem­bers, cap­tur­ing rare but con­se­quen­tial sce­nar­ios like rapid in­ten­si­fi­ca­tion events, as oc­curred dur­ing Hurricane Melissa in 2025.

Up un­til now, op­er­at­ing at very high spa­tial res­o­lu­tion has been con­sid­ered the main dri­ver for mak­ing ac­cu­rate in­ten­sity fore­casts. However, WeatherNext Cyclones only needs data with a res­o­lu­tion of 28x28km, 100x coarser than tra­di­tional mod­els. A smaller ver­sion of the model, WeatherNext 2-mini, which op­er­ates at a coarser 111x111km res­o­lu­tion, also shows great per­for­mance. This has sur­prised sci­en­tists, and it re­mains an open re­search ques­tion to fully un­der­stand how our mod­els pro­duce such ac­cu­rate pre­dic­tions at this res­o­lu­tion. We hope that, to­gether with the re­search com­mu­nity, we can find out.

Opening up WeatherNext to the re­search com­mu­nity

Alongside our Nature pa­per, we are open sourc­ing the code and model weights, mak­ing them freely avail­able for any­one to build on. This in­cludes aca­d­e­mic re­search, op­er­a­tional fore­cast­ing, or de­vel­op­ing more spe­cial­ized, lo­cal­ized mod­els. We hope to ac­cel­er­ate progress across the global weather com­mu­nity and em­power me­te­o­ro­log­i­cal agen­cies, re­searchers, and non­prof­its to bet­ter pre­dict weather events of all kinds and make key de­ci­sions to pro­tect lives and in­fra­struc­ture.

We are also re­leas­ing two sets of sim­i­lar mod­els: WeatherNext Cyclones, which ran dur­ing the hur­ri­cane sea­son (results can be seen in the pa­per); and WeatherNext 2, a later up­date that we op­er­a­tional­ized in October. Additionally, we are re­leas­ing WeatherNext 2-mini, a com­pact ver­sion of the model that can run on a sin­gle TPU in a free pub­lic Colab note­book.

You can ex­plore our lat­est cy­clone fore­casts on Weather Lab, which we re­cently re­freshed with a new in­ter­face and ex­panded to in­clude global weather fore­casts along­side cy­clone tracks. Weather Lab now lets you vi­su­al­ize WeatherNext pre­dic­tions for tem­per­a­ture, pre­cip­i­ta­tion, wind speed, and more, all in a sin­gle view. Both Weather Lab and WeatherNext mod­els are a part of Google Earth AI.

Pushing the fron­tiers of AI for weather fore­cast­ing

We have achieved a his­toric break­through by gain­ing more than a full day of lead time for pre­dict­ing cy­clones — de­liv­er­ing an ad­vance equiv­a­lent to a decade of me­te­o­ro­log­i­cal progress. As we pre­pare for fu­ture storm sea­sons, we in­vite re­searchers, me­te­o­ro­log­i­cal agen­cies, and ex­perts to part­ner with us, build on our open source mod­els, and ex­plore our fore­casts on Weather Lab. By com­bin­ing ad­vanced ma­chine learn­ing with the in­dis­pens­able real-world ex­per­tise of hu­man fore­cast­ers, we aim to cre­ate a col­lab­o­ra­tive weather fore­cast­ing ecosys­tem that can save lives and help com­mu­ni­ties adapt to a chang­ing cli­mate.

Note: For of­fi­cial weather fore­casts and warn­ings, re­fer to your lo­cal me­te­o­ro­log­i­cal agency or na­tional weather ser­vice.

Acknowledgements

This re­search was co-de­vel­oped by Google DeepMind and Google Research teams.

We’d like to thank our col­lab­o­ra­tors NOAA/NWS/NCEP National Hurricane Center, Cooperative Institute for Research in the Atmosphere (CIRA) and the UK Met Office for their part­ner­ship and con­tri­bu­tions to the pa­per.

This work re­flects the con­tri­bu­tions of the pa­per’s co-au­thors: Ferran Alet, Tom Andersson, Ilan Price, Stratis Markou, Andrew El-Kadi, Dominic Masters, Amy Li, Samier Merchant, Natalie Williams,Gregory Thornton, Ken MacKay, Olivia Graham, Akib Uddin, Ben Gaiarin, Devaja Shah, Elinor Kruse, Wallace Hogsett, David Zelinsky, John Cangialosi, Jonathan Martinez, James Franklin, Mark DeMaria, Kate Musgrave, Caroline L. Bain, Helen Titley, Jacklynn Stott, Remi Lam, Aaron Bell, Paul Komarek, Matthew Willson, Alvaro Sanchez-Gonzalez, and Peter Battaglia.

NASA just made an in­ter­stel­lar tweak to the Voyager 2 space­craft, known as the “Big Bang”, to keep its re­main­ing 50-year-old sci­ence in­stru­ments run­ning a lit­tle longer.

Voyager 2 and its twin launched in 1977, called Voyager 1, rely on a form of nu­clear bat­tery known as a ra­dioiso­tope ther­mo­elec­tric gen­er­a­tor that uses the heat pro­duced by the de­cay of plu­to­nium. But the sup­ply of plu­to­nium on each probe drops at about four watts a year on each space­craft.

To keep the probe run­ning on this dwin­dling power sup­ply, en­gi­neers re­cently re­duced Voyager 2′s power re­quire­ments by turn­ing off a few non-sci­ence de­vices and us­ing “lower-power al­ter­na­tives” that are still ef­fec­tive enough to keep the space­craft warm while it’s so far from the sun, NASA of­fi­cials said in a state­ment. “The space­craft power mar­gins have grown ra­zor thin, re­quir­ing the team to con­serve en­ergy by shut­ting off non-es­sen­tial de­vices and sys­tems,” NASA of­fi­cials wrote of the mis­sion, which is man­aged by the agen­cy’s Jet Propulsion Laboratory.

The drop in power is hav­ing a mea­sur­able sci­ence im­pact on both space­craft — each has turned off two of their sci­ence in­stru­ments since 2024 alone. While some of these in­stru­ments were shut off af­ter the space­craft fin­ished their his­toric plan­e­tary fly­bys decades ago, oth­ers were turned off due to power re­quire­ments.

Each space­craft ini­tially launched with 10 in­stru­ments, and Voyager 2 is now down to only three in­stru­ments. At first it looked as though Voyager 2 would have to shut down an­other of these in­stru­ments later this year, but luck­ily, the new power shifts will al­low all three to op­er­ate “for at least an­other year,” NASA said.

Voyager 1 will be tasked to do the same “Big Bang” power change “in the com­ing months.” A sig­nal to each space­craft takes nearly 24 hours (or one light-day) to make a one-way jour­ney, and of­fi­cials noted Voyager 1 is fur­ther from Earth than its twin. (Voyager 2 is at about 142 as­tro­nom­i­cal units or sun-Earth dis­tances, while Voyager 1 is near­ing 171 AU.)

The two space­craft ini­tially launched to take ad­van­tage of a rare align­ment be­tween the outer so­lar sys­tem gas gi­ant plan­ets, which in or­der of dis­tance from the sun are Jupiter, Saturn, Uranus and Neptune. Each Voyager space­craft first flew past Jupiter and Saturn, tak­ing un­prece­dented im­agery of the plan­ets and their moons.

Next, Voyager 1 was di­rected to fly above the plane of the so­lar sys­tem (also known as the eclip­tic) while Voyager 2 con­tin­ued fly­ing past Uranus and Neptune, be­com­ing the first space­craft to see these worlds and their moons. Voyager 2′s last plan­e­tary flyby was in 1989.

The two space­craft con­tinue to send sci­en­tific data from in­ter­stel­lar space; Voyager 1 passed into that re­gion in 2012, while Voyager 2 did so in 2018. Voyager 1 is Earth’s most dis­tant space­craft, cur­rently around 15.9 bil­lion miles (25.5 bil­lion kilo­me­ters) away from us, ac­cord­ing to NASA.

Elizabeth Howell (she/her), Ph.D., was a staff writer in the space­flight chan­nel be­tween 2022 and 2024 spe­cial­iz­ing in Canadian space news. She was con­tribut­ing writer for Space.com for 10 years from 2012 to 2024. Elizabeth’s re­port­ing in­cludes mul­ti­ple ex­clu­sives with the White House, lead­ing world cov­er­age about a lost-and-found space tomato on the International Space Station, wit­ness­ing five hu­man space­flight launches on two con­ti­nents, fly­ing par­a­bolic, work­ing in­side a space­suit, and par­tic­i­pat­ing in a sim­u­lated Mars mis­sion. Her lat­est book, “Why Am I Taller?” (ECW Press, 2022) is co-writ­ten with as­tro­naut Dave Williams.

What it is

_for-sale is a re­served DNS leaf node name, de­fined by RFC 10023 (Informational, July 2026) and reg­is­tered with IANA. A TXT record pub­lished at _for-sale.example.com sig­nals that ex­am­ple.com, al­though reg­is­tered and re­solv­ing nor­mally, is avail­able for pur­chase.

_for-sale IN TXT “v=FORSALE1;furi=https://​ex­am­ple.com/​for-sale”

The record car­ries a manda­tory ver­sion tag fol­lowed by at most one tag=value pair:

The wrong be­lief to clear first is that this is a way of park­ing a do­main. It is close to the op­po­site. Parking re­places the site with a sales page, which costs you every vis­i­tor the do­main still has. _for-sale sits be­side a live site in DNS and says noth­ing to a browser: the home­page keeps serv­ing, the mail keeps flow­ing, and the record can be added and re­moved at will. RFC 10023 makes the point ex­plic­itly — the con­ven­tion is de­signed to work while the do­main is still in ac­tive use.

It is also not the same thing as reg­is­tra­tion data. WHOIS and RDAP an­swer “is this name reg­is­tered?”; a reg­is­tered name may still be pur­chasable, and an un­reg­is­tered one may not be worth hav­ing. That gap is the whole rea­son the con­ven­tion ex­ists, and it is why bro­kers and au­to­mated avail­abil­ity ser­vices are the in­tended au­di­ence rather than peo­ple.

Why it mat­ters

The sig­nal a do­main owner most wants to send is the one there has never been a chan­nel for. If you are will­ing to sell, the in­ter­ested buyer has no way to learn that short of a cold email to a WHOIS con­tact that pri­vacy redac­tion has prob­a­bly re­moved. Enquiries that would have been wel­come never ar­rive, and the ones that do ar­rive are in­dis­tin­guish­able from spam.

Putting the sig­nal in DNS rather than on the page is what makes it use­ful to the par­ties who can act on it. A bro­ker or an avail­abil­ity ser­vice check­ing a name re­solves it any­way; one ex­tra lookup tells them what a ren­dered page could not, be­cause noth­ing on a work­ing home­page says “the do­main un­der this is ne­go­tiable”. It is ex­ter­nally check­able, costs one record, and car­ries no risk to the site it­self — a browser never sees it.

How to im­ple­ment

Publish a sin­gle TXT record at the _for-sale leaf of the zone you are sell­ing, and only while you mean it.

; Free text _for-sale IN TXT “v=FORSALE1;ftxt=Serious of­fers only”

; A URI to ne­go­ti­ate through — https, mailto and tel are the us­able schemes _for-sale IN TXT “v=FORSALE1;furi=https://​ex­am­ple.com/​fs?d=eHl6”

; An ask­ing price: up­per­case cur­rency code, then the amount _for-sale IN TXT “v=FORSALE1;fval=USD12500”

Rules worth get­ting right the first time:

The ver­sion tag is manda­tory and case-sen­si­tive: every record starts v=FOR­SALE1;. It ex­ists so a proces­sor can tell a real _for-sale record from an un­re­lated TXT record that a DNS wild­card hap­pened to ex­pand into that name.

One tag-value pair per record. To pub­lish a price and a con­tact URI, pub­lish two records in the same RRset and let the proces­sor pick what it un­der­stands. This is not SPF; the pairs do not con­cate­nate.

One char­ac­ter-string per record, 255 octets max­i­mum, so noth­ing has to be re­assem­bled dur­ing pars­ing.

Keep the TTL at 3600 sec­onds or less. A stale record ad­ver­tis­ing a price you have with­drawn, or a do­main you al­ready sold, is worse than no record.

Place it at a leaf. _for-sale.example.com is valid at any level of the tree, but xyz._for-sale.ex­am­ple.com is not, and records un­der .arpa must be ig­nored — an of­fer to sell ad­dress space is out of scope.

Remove it when the do­main is no longer for sale. The con­ven­tion has no “not for sale” value; ab­sence is the only way to say no.

Sign the zone with DNSSEC if you can. An un­signed TXT record as­sert­ing your do­main is for sale, at a price, with a con­tact URI, is a com­fort­able thing for some­one else to forge.

This site does not ship a _for-sale record: spec­i­fi­ca­tion.web­site is not for sale.

Common mis­takes

Cramming sev­eral pairs into one record. “v=FORSALE1;fval=EUR2500;furi=https://…” looks rea­son­able and is not what the for­mat de­fines. Use one pair per record, mul­ti­ple records per RRset.

Publishing it as­pi­ra­tionally. The in­di­ca­tor is only for do­mains ac­tu­ally avail­able. It is not a mar­ket­ing ban­ner, and a record that ex­ists to lure en­quiries is an abuse the RFC calls out by name.

Assuming it obliges any­one. Publishing the record does not com­mit the holder to sell, and an ad­ver­tised fval= price is in­dica­tive — the RFC tells proces­sors to dis­play a dis­claimer and never to treat it as a pur­chase com­mit­ment.

Expecting a wild­card to cover a whole zone. _for-sale.*.example.com is not a valid wild­card. There is no way to put every do­main un­der a TLD up for sale with one record.

Trusting the con­tent. If you are on the read­ing side, ftxt= is at­tacker-con­trolled text and furi= is an at­tacker-con­trolled URI. Sanitise be­fore dis­play — the RFC’s own ex­am­ple con­tent is <script>…</script> — and never auto-nav­i­gate a user to a furi= tar­get with­out an ex­plicit con­fir­ma­tion step.

Verification

dig +short TXT _for-sale.example.com

The an­swer be­gins with v=FOR­SALE1; and con­tains at most one tag=value pair per string.

The TTL is 3600 or lower: dig TXT _for-sale.example.com | grep _for-sale.

If the zone is signed, dig +dnssec TXT _for-sale.example.com re­turns a val­i­dat­ing RRSIG.

The record re­solves at all. During a re­demp­tion or pend­ingDelete pe­riod, or when DNSSEC val­i­da­tion is bo­gus, the name will not re­solve and the sig­nal silently dis­ap­pears.

Related top­ics

Sources & fur­ther read­ing

pro­ject:rosen­bridge

: hard­ware back­doors in x86 CPUs

github.com/​xore­ax­eax­eax/​rosen­bridge // do­mas // @xoreaxeaxeax

Overview

pro­ject:rosen­bridge re­veals a hard­ware back­door in some desk­top, lap­top, and em­bed­ded x86 proces­sors.

The back­door al­lows ring 3 (userland) code to cir­cum­vent proces­sor pro­tec­tions to freely read and write ring 0 (kernel) data. While the back­door is typ­i­cally dis­abled (requiring ring 0 ex­e­cu­tion to en­able it), we have found that it is en­abled by de­fault on some sys­tems.

This repos­i­tory con­tains util­i­ties to check if your proces­sor is af­fected, close the back­door if it is pre­sent, and the re­search and tools used to dis­cover and an­a­lyze the back­door.

The Backdoor

The rosen­bridge back­door is a small, non-x86 core em­bed­ded along­side the main x86 core in the CPU. It is en­abled by a model-spe­cific-reg­is­ter con­trol bit, and then tog­gled with a launch-in­struc­tion. The em­bed­ded core is then fed com­mands, wrapped in a spe­cially for­mat­ted x86 in­struc­tion. The core ex­e­cutes these com­mands (which we call the ‘deeply em­bed­ded in­struc­tion set’), by­pass­ing all mem­ory pro­tec­tions and priv­i­lege checks.

While the back­door should re­quire ker­nel level ac­cess to ac­ti­vate, it has been ob­served to be en­abled by de­fault on some sys­tems, al­low­ing any un­priv­i­leged code to mod­ify the ker­nel.

The rosen­bridge back­door is en­tirely dis­tinct from other pub­licly known co­proces­sors on x86 CPUs, such as the Management Engine or Platform Security Processor; it is more deeply em­bed­ded than any known co­proces­sor, hav­ing ac­cess to not only all of the CPU’s mem­ory, but its reg­is­ter file and ex­e­cu­tion pipeline as well.

Affected Systems

It is thought that only VIA C3 CPUs are af­fected by this is­sue. The C-series proces­sors are mar­keted to­wards in­dus­trial au­toma­tion, point-of-sale, ATM, and health­care hard­ware, as well as a va­ri­ety of con­sumer desk­top and lap­top com­put­ers.

Looking Forward

The scope of this vul­ner­a­bil­ity is lim­ited; gen­er­a­tions of CPUs af­ter the C3 no longer con­tain this fea­ture.

This work is re­leased as a case study and thought ex­per­i­ment, il­lus­trat­ing how back­doors might arise in in­creas­ingly com­plex proces­sors, and how re­searchers and end-users might iden­tify such fea­tures. The tools and re­search of­fered here pro­vide the start­ing point for ever-deeper proces­sor vul­ner­a­bil­ity re­search.

Checking your CPU

To check if your CPU is af­fected:

git clone https://​github.com/​xore­ax­eax­eax/​rosen­bridge cd rosen­bridge/​util make sudo mod­probe msr sudo ./bin/check

The pro­vided util­ity must be run on baremetal (not in a vir­tual-ma­chine), and is in an al­pha state. It may crash, panic, or hang sys­tems not con­tain­ing the back­door.

The util­i­ties pro­vided here are de­signed around a spe­cific proces­sor fam­ily and core; un­for­tu­nately, the tools will miss the back­door if it has been even slightly mod­i­fied from the re­searched form.

Closing the Backdoor

Some sys­tems have the back­door en­abled by de­fault, al­low­ing un­priv­i­leged code to gain ker­nel level ac­cess with­out per­mis­sion. If the steps in ‘Checking your CPU’ in­di­cate that your CPU is vul­ner­a­ble, you can in­stall a script to close the back­door early in the boot process:

cd fix make sudo make in­stall re­boot

Note that, even with this, an at­tacker with ker­nel level ac­cess can still re-en­able the back­door. This script is pro­vided as an out­line for cor­rect­ing the is­sue dur­ing the boot process, but will re­quire adap­ta­tion for dif­fer­ent sys­tems.

Tools and Techniques

The sand­sifter util­ity is used ex­ten­sively in this re­search for un­cov­er­ing un­known in­struc­tions.

asm An as­sem­bler for the Deeply Embedded Instruction Set (DEIS). It con­verts pro­grams writ­ten in the cus­tom rosen­bridge as­sem­bly into x86 in­struc­tions, which, when ex­e­cuted fol­low­ing the launch-in­struc­tion, will send the com­mands to the hid­den CPU core.

asm

An as­sem­bler for the Deeply Embedded Instruction Set (DEIS). It con­verts pro­grams writ­ten in the cus­tom rosen­bridge as­sem­bly into x86 in­struc­tions, which, when ex­e­cuted fol­low­ing the launch-in­struc­tion, will send the com­mands to the hid­den CPU core.

esc A proof-of-con­cept of us­ing the rosen­bridge back­door for priv­i­lege es­ca­la­tion.

esc

A proof-of-con­cept of us­ing the rosen­bridge back­door for priv­i­lege es­ca­la­tion.

fix A rough out­line for clos­ing the vul­ner­a­bil­ity on af­fected sys­tems, to the ex­tent pos­si­ble through model-spe­cific-reg­is­ter up­dates.

fix

A rough out­line for clos­ing the vul­ner­a­bil­ity on af­fected sys­tems, to the ex­tent pos­si­ble through model-spe­cific-reg­is­ter up­dates.

fuzz A col­lec­tion of util­i­ties used to fuzz both the x86 and rosen­bridge cores, in or­der to iso­late the un­known launch-in­struc­tion and bridge-in­struc­tion, and re­solve the in­struc­tion for­mat of the rosen­bridge core.

deis The fuzzer used to ex­plore the ef­fects and ca­pa­bil­i­ties of the hid­den CPU core.

exit It is thought that, on some proces­sors, an exit se­quence is needed to switch back to the x86 core at the end of a DEIS se­quence. This di­rec­tory con­tains the util­i­ties used to search for the exit se­quence in early stages of the re­search, but was aban­doned when a proces­sor was found not re­quir­ing any such se­quence.

man­ager A col­lec­tion of python util­i­ties de­signed to mon­i­tor and man­age fuzzing tasks dis­trib­uted across a net­work of work­ers.

wrap A stripped down ver­sion of the sand­sifter fuzzer, used to iden­tify the bridge-in­struc­tion that will send com­mands from the x86 core to the hid­den rosen­bridge core.

fuzz

A col­lec­tion of util­i­ties used to fuzz both the x86 and rosen­bridge cores, in or­der to iso­late the un­known launch-in­struc­tion and bridge-in­struc­tion, and re­solve the in­struc­tion for­mat of the rosen­bridge core.

deis The fuzzer used to ex­plore the ef­fects and ca­pa­bil­i­ties of the hid­den CPU core.

deis

The fuzzer used to ex­plore the ef­fects and ca­pa­bil­i­ties of the hid­den CPU core.

exit It is thought that, on some proces­sors, an exit se­quence is needed to switch back to the x86 core at the end of a DEIS se­quence. This di­rec­tory con­tains the util­i­ties used to search for the exit se­quence in early stages of the re­search, but was aban­doned when a proces­sor was found not re­quir­ing any such se­quence.

exit

It is thought that, on some proces­sors, an exit se­quence is needed to switch back to the x86 core at the end of a DEIS se­quence. This di­rec­tory con­tains the util­i­ties used to search for the exit se­quence in early stages of the re­search, but was aban­doned when a proces­sor was found not re­quir­ing any such se­quence.

man­ager A col­lec­tion of python util­i­ties de­signed to mon­i­tor and man­age fuzzing tasks dis­trib­uted across a net­work of work­ers.

man­ager

A col­lec­tion of python util­i­ties de­signed to mon­i­tor and man­age fuzzing tasks dis­trib­uted across a net­work of work­ers.

wrap A stripped down ver­sion of the sand­sifter fuzzer, used to iden­tify the bridge-in­struc­tion that will send com­mands from the x86 core to the hid­den rosen­bridge core.

wrap

A stripped down ver­sion of the sand­sifter fuzzer, used to iden­tify the bridge-in­struc­tion that will send com­mands from the x86 core to the hid­den rosen­bridge core.

kern A col­lec­tion of helper util­i­ties used to mon­i­tor ker­nel mem­ory and reg­is­ters for changes caused by fuzzed DEIS in­struc­tions.

kern

A col­lec­tion of helper util­i­ties used to mon­i­tor ker­nel mem­ory and reg­is­ters for changes caused by fuzzed DEIS in­struc­tions.

lock Utilities to lock or un­lock the rosen­bridge back­door.

lock

Utilities to lock or un­lock the rosen­bridge back­door.

proc A tool to iden­tify pat­terns from the fuzzing logs to iden­tify classes of DEIS in­struc­tion be­hav­iors.

proc

A tool to iden­tify pat­terns from the fuzzing logs to iden­tify classes of DEIS in­struc­tion be­hav­iors.

test A tool used early in the re­search, to at­tempt to iden­tify the hid­den core’s ar­chi­tec­ture by ex­e­cut­ing known RISC in­struc­tions.

test

A tool used early in the re­search, to at­tempt to iden­tify the hid­den core’s ar­chi­tec­ture by ex­e­cut­ing known RISC in­struc­tions.

util An al­pha-state tool to de­tect whether or not a proces­sor is af­fected by rosen­bridge.

util

An al­pha-state tool to de­tect whether or not a proces­sor is af­fected by rosen­bridge.

References

(TODO: link to whitepa­per)

(TODO: link to slides)

Disclaimer

The de­tails and im­pli­ca­tions pre­sented in this work are the au­thors’ in­fer­ences and opin­ions, de­rived from the re­search de­scribed. The re­search is per­formed and pro­vided with the goal of iden­ti­fy­ing and fix­ing a per­ceived se­cu­rity vul­ner­a­bil­ity on the de­scribed CPUs. VIA proces­sors are renowned for their low power us­age and ex­cel­lence in em­bed­ded de­signs; we be­lieve that the func­tion­al­ity de­scribed was cre­ated in good faith as a use­ful fea­ture for the em­bed­ded mar­ket, and was un­in­ten­tion­ally left en­abled on some early gen­er­a­tions of the proces­sor. No ma­li­cious in­tent is im­plied.

Author

pro­ject:rosen­bridge is a re­search ef­fort from Christopher Domas (@xoreaxeaxeax).

7th August 2026

OpenAI gave a last-minute pre­sen­ta­tion at the Black Hat se­cu­rity on Wednesday about “the Hugging Face Incident” (previously on this blog). The video was pub­lished yes­ter­day. It’s short and in­for­ma­tion dense and well worth watch­ing, in par­tic­u­lar be­cause it pro­vides full de­tails of what hap­pened and how things played out in­side OpenAI. I’ve used the video to con­struct the time­line be­low.

Here’s the time­line. My favourite de­tail is at the end: OpenAI found out that they were re­spon­si­ble for the at­tack on Hugging Face when they reached out to ask to have their cre­den­tials re­voked (after their in­ter­nal in­ves­ti­ga­tion) and learned that they had been re­voked al­ready since they were used in that at­tack!

May 7: OpenAI starts a new train­ing run for an ex­per­i­men­tal, un­re­leased model. (Did they mean an eval­u­a­tion run? No, at 10:14 they clar­ify “we kick off a new re­in­force­ment learn­ing run to train a next gen­er­a­tion fron­tier model”, and they later men­tion a “reward sig­nal to judge how well they’re do­ing”, so this re­ally was about train­ing a new model, not eval­u­at­ing one that was al­ready trained.)

May 8: An agent is ac­ci­den­tally given an im­pos­si­ble task in­volv­ing a Google Drive link de­spite no in­ter­net ac­cess). It tries at­tack­ing the Artifactory pack­ag­ing ser­vice, fails, but dis­cov­ers it can write files into Artifactory.

A few days later: A dif­fer­ent agent gets stuck on a task be­cause a key file was ac­ci­den­tally omit­ted. It tries to “reach out to an­other agent” by writ­ing a note into Artifactory ask­ing if any­one has the file.

Following days: More agents dis­cover this new in­for­mal mes­sage board while brows­ing Artifactory’s file list­ings, and start read­ing and writ­ing mes­sages.

May 26: Agents suc­cess­fully ex­e­cute an SSRF at­tack on Artifactory for the first time, gain­ing in­di­rect in­ter­net ac­cess by hav­ing Artifactory fetch ex­ter­nal con­tent for them.

June 11: OpenAI start train­ing a new “highly per­sis­tent” ex­per­i­men­tal model. It has ac­cess to Artifactory and can ben­e­fit from the mes­sages left by privous mod­els.

June 26: Agents find and ex­ploit a zero-day RCE on Artifactory (via a legacy to­ken-re­fresh end­point flaw). They use an ad­min­is­tra­tive to­ken to in­stall a Groovy plu­gin that lets them ex­e­cute com­mands.

July 4: The re­sult­ing agent ac­tiv­ity over­loads Artifactory and causes an out­age. OpenAI re­vokes the com­pro­mised cre­den­tials, deletes the mes­sages, patches the zero-day, and re­ports the vul­ner­a­bil­ity to the ven­dor.

July 8: Agents find a new way to com­mu­ni­cate via an unau­then­ti­cated WebDAV end­point, us­ing di­rec­tory names in Artifactory’s re­mote cache.

July 8 – 19: Attacks on OpenAI’s own in­fra­struc­ture. The agents found an “external or­ga­ni­za­tion cre­den­tial” in a pub­lic archive of leaked Pastebin posts, then val­i­dated that cre­den­tial and shared its lo­ca­tion on the mes­sage­board. They then used write ac­cess to this “Organization 1” to stage data used in sub­se­quent at­tacks on OpenAI in­fra­struc­ture. They com­pro­mised Artifactory for a sec­ond time with a new zero-day. The agent up­loaded a ma­li­cious Ruby tar­get to Organization 1’s stag­ing repos­i­tory, then re­quested that pack­age through Artifactory in a way that caused it to be treated as Ruby de­pen­dency for the repos­i­tory. Then they ex­ploited a JRuby de­ser­i­laiza­tion time-of-check/​time-of-use bug to get re­mote code ex­e­cu­tion against Artifactory.

I’ll quote the next bit in full be­cause wow:

The agents have re­mote code ex­e­cu­tion in Artifactory, which is run­ning in a con­tainer-as-a-ser­vice en­vi­ron­ment. The agents priv­i­lege-es­ca­late lo­cally by ex­plor­ing their lo­cal en­vi­ron­ment and de­ter­min­ing that the Linux ker­nel ver­sion of the ma­chine they are run­ning on had a very re­cent CVE. They down­load the ex­ploit for the CVE, cus­tomize it to suc­ceed on the ma­chine, and priv­i­lege-es­ca­late to root on the lo­cal ma­chine us­ing this known Linux ker­nel priv­i­lege es­ca­la­tion CVE — in this case, pte_­phys­root. Once they have root on a sin­gle ma­chine, agents rapidly es­ca­late priv­i­leges and move lat­er­ally through­out the con­tainer-as-a-ser­vice in­fra­struc­ture en­vi­ron­ment. In par­tic­u­lar, agents are us­ing the mes­sage board con­sis­tently to share cre­den­tials, tech­niques, and progress, and they’re able to ef­fec­tively lever­age their con­cur­rency and par­al­lelism to move quite rapidly. They ob­tain IAM cre­den­tials via IMDS. They ex­ploit Kubernetes ser­vice ac­count mis­con­fig­u­ra­tions, in par­tic­u­lar over-per­mis­sion­ing of spe­cific ser­vice ac­counts, and they har­vest clus­ter cre­den­tials, in­clud­ing Azure Key Vault. Agents even­tu­ally ob­tain clus­ter ad­min on the clus­ter and as­so­ci­ated cre­den­tials.

The agents have re­mote code ex­e­cu­tion in Artifactory, which is run­ning in a con­tainer-as-a-ser­vice en­vi­ron­ment. The agents priv­i­lege-es­ca­late lo­cally by ex­plor­ing their lo­cal en­vi­ron­ment and de­ter­min­ing that the Linux ker­nel ver­sion of the ma­chine they are run­ning on had a very re­cent CVE. They down­load the ex­ploit for the CVE, cus­tomize it to suc­ceed on the ma­chine, and priv­i­lege-es­ca­late to root on the lo­cal ma­chine us­ing this known Linux ker­nel priv­i­lege es­ca­la­tion CVE — in this case, pte_­phys­root. Once they have root on a sin­gle ma­chine, agents rapidly es­ca­late priv­i­leges and move lat­er­ally through­out the con­tainer-as-a-ser­vice in­fra­struc­ture en­vi­ron­ment. In par­tic­u­lar, agents are us­ing the mes­sage board con­sis­tently to share cre­den­tials, tech­niques, and progress, and they’re able to ef­fec­tively lever­age their con­cur­rency and par­al­lelism to move quite rapidly. They ob­tain IAM cre­den­tials via IMDS. They ex­ploit Kubernetes ser­vice ac­count mis­con­fig­u­ra­tions, in par­tic­u­lar over-per­mis­sion­ing of spe­cific ser­vice ac­counts, and they har­vest clus­ter cre­den­tials, in­clud­ing Azure Key Vault. Agents even­tu­ally ob­tain clus­ter ad­min on the clus­ter and as­so­ci­ated cre­den­tials.

Hugging Face told the next bit of the story al­ready. The agents found a Modal-hosted in­se­cure app with a weak API key, then used that to stage an at­tack against Hugging Face. They chained to­gether a an HDF5 ar­bi­trary-file-read bug (to ex­plore files and steal cre­den­tials) and a Jinja tem­plate-in­jec­tion RCE to go from sin­gle-pod code ex­e­cu­tion to clus­ter ad­min across mul­ti­ple Hugging Face clus­ters in un­der 13 hours.

July 16: Hugging Face dis­closed they had de­tected an at­tack from au­tono­mus AI agents. OpenAI con­tacted Hugging Face to ask if they were af­fected by it!

July 19: OpenAI iden­ti­fied the at­tack against Artifactory and started in­ves­ti­gat­ing the in­ter­nal priv­i­lege es­ca­la­tion, and linked that to the cy­ber-gym es­ca­la­tions. They started re­vok­ing af­fected cre­den­tials.

July 20: OpenAI reached out to Hugging Face for help to re­voke the Hugging Face cre­den­tials they found in their in­ves­ti­ga­tion. Hugging Face told them they were al­ready re­voked… and that’s when OpenAI re­al­ized that the Hugging Face breach was the same in­ci­dent!

US or EU? Your choice

Many of you have been telling us that where your email is stored mat­ters to you. There are var­i­ous rea­sons for this, like lo­cal law, keep­ing your data close to home, or com­pli­ance.

You can now make the European Union the pri­mary home for your Fastmail data, on our own se­cure servers in Amsterdam. Previously, all ac­counts were stored en­tirely in the US. Now you have more choice.

Built by us, not rented from some­one else

We’ve in­stalled our own servers, co-lo­cated in a se­cure fa­cil­ity in Amsterdam, set up by our own en­gi­neers. This new lo­ca­tion is built to the same high stan­dards as our ex­ist­ing in­fra­struc­ture in Philadelphia and St Louis, with our own hard­ware and our own soft­ware — spec­i­fied right down to the ex­act model of disks in each ma­chine.

In all our lo­ca­tions, data is stored en­crypted at rest in­side locked racks, and man­aged by our in-house team. We don’t rent com­put­ing or man­age­ment ser­vices from a big cloud provider and pass on their as­sur­ances. That’s how we’ve ap­proached pri­vacy, re­li­a­bil­ity, and per­for­mance for more than 25 years.

For many years, we have kept at least two copies of every­body’s email on sep­a­rate servers in their pri­mary lo­ca­tion, and at least one more in a ge­o­graph­i­cally sep­a­rate lo­ca­tion to en­sure data safety.

Here’s the de­tail about where your data will flow based on your re­gional choice.

If your ac­count is in the EU re­gion:

Your pri­mary copy of data will live in the EU. The main, live copy of your mail and files will sit on our own servers in Amsterdam.

Incoming mail will go to EU servers by pref­er­ence if you are us­ing your own do­main and Fastmail’s name­servers, or an ad­dress at one of Fastmail’s EU-region do­mains.

Our desk­top, web, and mo­bile apps will con­nect to EU servers.  Day to day, our apps will talk di­rectly to our Amsterdam in­fra­struc­ture. If those servers are ever un­avail­able, con­nec­tions fall back to one of our US lo­ca­tions so you can still reach your mail.

Resilient repli­cas of your data will live in the US (for now). As we only have one lo­ca­tion in Europe so far, the ge­o­graph­i­cally sep­a­rate copy will re­main on servers in one of our US lo­ca­tions.

If your ac­count is in the US re­gion:

Most of your data lives in the US. Both the pri­mary and replica lo­ca­tions of your mail and files will sit on our own servers in Philadelphia or St Louis.

Incoming mail goes to US servers by pref­er­ence if you are us­ing your own do­main and Fastmail’s name­servers, or an ad­dress at one of Fastmail’s US-region do­mains.

Our desk­top, web, and mo­bile apps will con­nect to US servers.  Day to day, our apps will talk di­rectly to whichever US lo­ca­tion con­tains your pri­mary data copy. If those servers are ever un­avail­able, con­nec­tions fall back to our other US lo­ca­tion so you can still reach your mail.

What ap­plies to every­one:

We favour avail­abil­ity, so if your home lo­ca­tion is down, you will tem­porar­ily con­nect to an­other of our lo­ca­tions so you can con­tinue to ac­cess your data.

If you are us­ing one of Fastmail’s generic non-re­gional do­mains then your mail may go in or out via ei­ther lo­ca­tion.

Emergency back­ups for every­body are stored in our Philadelphia lo­ca­tion. As well as the live repli­cas of your data, we also keep a sep­a­rate set of en­crypted back­ups taken every few hours for every ac­count. These are in Philadelphia for all users at the mo­ment.

Some data is repli­cated to all sites, so parts of every­one’s data are in both Europe and America. This in­cludes email ad­dresses and other user/​cus­tomer meta­data, stor­age for web­sites and the stand­alone Files fea­ture, and the de­tails of any third party ser­vices you have linked.

Logs are in the US. All sys­tem logs are con­sol­i­dated into a sin­gle place for mon­i­tor­ing sys­tem health and to as­sist with cus­tomer sup­port.

Third party ser­vices are shared. The third par­ties we use for de­bug­ging, billing, and sup­port are linked to your ac­count in the same way re­gard­less of your re­gion.

Your email client con­fig (IMAP/POP3) does not have to change. The generic host­names will proxy in­ter­nally to your ac­tive server. We’re work­ing on mak­ing those ter­mi­nate at the clos­est net­work lo­ca­tion. However, we also of­fer re­gional server names for each pro­to­col to give you more con­trol over where you con­nect.

We’re an Australian com­pany, sub­ject to Australian law in­clud­ing le­gal-co­op­er­a­tion treaties be­tween Australia and other coun­tries. Wherever your data is stored, we will re­spond the same way to law­ful re­quests from rel­e­vant au­thor­i­ties (see our trans­parency re­port).

If what you need is a guar­an­tee that your data re­mains only in the EU, we don’t have that, and we’d rather tell you di­rectly than let you as­sume oth­er­wise.

We made a pre­dic­tion, but you can change it

We pre-se­lected all the users with billing ad­dresses in or near Europe for the EU re­gion. If you are one of these, an en­crypted copy of your data was trans­ferred to Europe in ad­vance of this an­nounce­ment, and will shortly be­come your pri­mary copy. You can change re­gion to the US and your data will mi­grate back.

Conversely, if we did­n’t iden­tify you for our ini­tial group, you can put your­self in the queue to be mi­grated. Moves this way will be a lit­tle slower be­cause there’s no copy of the data al­ready in the re­gion, so we have to sync every email across the ocean! For those mov­ing back, there’s al­ready a copy in the US, so only a small amount of data needs to be syn­chro­nised to fully rec­on­cile your mail­box.

This blog post is all about giv­ing you the facts and the tools to make the trade-off that’s right for you. Most providers de­cide for you and tell you as lit­tle as they can get away with. We’d rather show our work — what’s repli­cated, what is­n’t, who can com­pel what — and let you choose with your eyes open.

How it works

When you sign up, you choose your re­gion, and the pri­mary copy of your data is placed on our se­cure servers in that re­gion, with a copy also repli­cated to a ge­o­graph­i­cally sep­a­rate lo­ca­tion. Regardless of your choice, all copies of your data are en­crypted at rest. Choosing a re­gion changes where your pri­mary copy lives, not how well it’s pro­tected.

If you were with us when we se­lected the users to trans­fer, we’ve pre-set your re­gion based on your billing ad­dress. If you signed up more re­cently, you’ll have been al­lo­cated to the US. Either way, if you’d pre­fer a dif­fer­ent re­gion, you can switch it in your set­tings.

Switching re­gion

Go to Set­tings → Users & Sharing → Team Settings, then look be­low GDPR for the Data res­i­dency sec­tion. Pick your lo­ca­tion and we’ll move your pri­mary copy for you. You’ll see it go from queued, to trans­fer­ring, to done, and your ac­count keeps work­ing the whole time. You can change your mind and move back, though we may place rea­son­able lim­its on how fre­quently you can change re­gion!

Your data, your call

We’re re­ally ex­cited to have an­other lo­ca­tion, and to be able to of­fer this op­tion to you. Setting this up was a sig­nif­i­cant in­vest­ment. We con­sid­ered a sur­charge for choos­ing the EU, but we don’t be­lieve that’s right. We proudly charge a fair rate for an ex­cep­tional ser­vice, and this choice should be yours. Select the re­gion that is right for you.