I am a soft­ware en­gi­neer, and I used to en­joy ar­gu­ing with peo­ple for tech­ni­cal cor­rect­ness. Code re­views, de­sign meet­ings, mail­ing-list threads, din­ner ta­bles. If some­one was wrong, I wanted them to know it, and I wanted them to know ex­actly why. I col­lected coun­ter­ar­gu­ments the way I col­lected patches. I be­lieved that if I just laid out the logic clearly enough, the other per­son would have no choice but to come around. Truth would win.

It al­most never worked that way.

Sometimes I won on points and lost the per­son. More of­ten I won noth­ing at all: I’d watch some­one grow more cer­tain of the very thing I had just dis­proven, while the room qui­etly drifted to their side. I would walk away tech­ni­cally right and com­pletely alone.

Over the years I’ve slowly stopped ar­gu­ing. Not be­cause I stopped car­ing about be­ing right, but be­cause I fi­nally un­der­stood what an ar­gu­ment ac­tu­ally is, and what it can and can­not do. Here is what changed my mind.

Being Correct Is Not Always Good

The first thing I had to give up was the be­lief that be­ing cor­rect is al­ways good. As an en­gi­neer, this felt like heresy. Correctness is the whole job. But cor­rect­ness in a fact is not the same as good­ness in a mo­ment.

Lao Tzu saw this 2,500 years ago. In chap­ter 2 of the Tao Te Ching:

Being and non-be­ing cre­ate each other.

Hard and easy com­plete each other.

Long and short de­fine each other.

High and low de­pend on each other.

Sound and si­lence har­mo­nize each other.

Being and non-be­ing cre­ate each other.

Hard and easy com­plete each other.

Long and short de­fine each other.

High and low de­pend on each other.

Sound and si­lence har­mo­nize each other.

Everything ex­ists only in re­la­tion to its op­po­site. There is no “right” with­out a “wrong” to make it right, and the mo­ment you in­sist on stand­ing on the high ground, you’ve cre­ated the low ground some­one else must stand on. Winning an ar­gu­ment man­u­fac­tures a loser. Being vis­i­bly cor­rect man­u­fac­tures some­one vis­i­bly wrong.

So be­ing right is not a pure good float­ing in space. It’s half of a pair, and it drags its op­po­site along with it. Once I stopped treat­ing cor­rect­ness as an ab­solute, I stopped need­ing to win.

Most Arguments Are About Ego, Not Ideas

When you ar­gue with some­one, you think you’re de­bat­ing an idea. Often you’re not. You’re chal­leng­ing their sense of self.

Many peo­ple are ego-dri­ven. Their opin­ions aren’t po­si­tions they hold; they are the po­si­tion. Prove the idea wrong and you haven’t cor­rected a fact, you’ve at­tacked a per­son. So they de­fend it the way any­one de­fends them­selves: not with rea­son, but with re­sis­tance. The stronger your ar­gu­ment, the harder they dig in.

You can’t win an ar­gu­ment like this, be­cause it was never an ar­gu­ment. It was a fight over whose ego stays in­tact. Even when you “win,” you lose, be­cause now you have an en­emy who is more con­vinced than be­fore.

So I’ve drawn a line. I only dis­cuss pros and cons with smart peo­ple; I don’t ar­gue right and wrong with ego-dri­ven ones. With the first kind, a dis­agree­ment is a joint search for the bet­ter an­swer, and both of us walk away sharper. With the sec­ond, there is no an­swer be­ing sought, only a self to be de­fended. Knowing which con­ver­sa­tion you’re in is half the bat­tle. The other half is hav­ing the dis­ci­pline to walk away from the sec­ond one.

People Are Not Rational

We like to be­lieve hu­mans are ra­tio­nal an­i­mals who oc­ca­sion­ally feel emo­tions. It’s the re­verse. We are emo­tional an­i­mals who oc­ca­sion­ally think.

Most peo­ple don’t rea­son their way to con­clu­sions and then feel ac­cord­ingly. They feel first, then rea­son back­ward to jus­tify the feel­ing. They fol­low the crowd, mis­take con­fi­dence for cor­rect­ness, and adopt what­ever the peo­ple around them al­ready be­lieve. Independent think­ing is rare, far rarer than we ad­mit.

Once you ac­cept this, ar­gu­ing with logic starts to look ab­surd. You’re bring­ing a proof to a feel­ing. The proof is air­tight. The feel­ing does­n’t read.

Correcting Others Rarely Helps Them

“But my mo­ti­va­tion is good,” you say. “I’m not at­tack­ing any­one. I’m just point­ing out a mis­take so they don’t get hurt.”

I be­lieved this for a long time. It sounds no­ble. But even with the best in­ten­tions, cor­rect­ing peo­ple usu­ally fails, and here’s the hard part: don’t do it any­way.

People don’t see your mo­ti­va­tion. They see crit­i­cism. They rarely un­der­stand why you both­ered, and they al­most never ap­pre­ci­ate it. Worse, most peo­ple don’t learn from ad­vice at all. They learn from con­se­quences. They have to touch the stove them­selves. Words bounce off; pain sticks.

This sounds cold. It is. But it’s also, sadly, true. The most re­spect­ful thing you can of­ten do is let peo­ple meet their own con­se­quences, be­cause that’s the only teacher they’ll ac­tu­ally lis­ten to.

The One Exception: When They Ask

There’s a clean ex­cep­tion to all of this, and it flips the en­tire logic.

Help peo­ple when they ex­plic­itly ask for help.

When some­one asks, the cause and ef­fect re­verse. You’re no longer im­pos­ing your judg­ment on some­one who never wanted it. Their ask­ing is the cause; your help­ing is the ef­fect. Now there’s an open­ing, a real one, be­cause they’ve de­cided they’re ready to hear it. The ego is low­ered. The de­fenses are down. The ad­vice lands.

So I don’t of­fer any­more. I wait for the door to open from the in­side. And when some­one opens it, I give every­thing I have.

Don’t Win the Argument, Profit From the Difference

If let­ting go of the ar­gu­ment sounds like pure loss, here’s the re­frame that turns it into a gain.

When you and some­one else see the world dif­fer­ently, you have two op­tions. You can spend your en­ergy try­ing to con­vince them you’re right, which, as every­thing above shows, al­most never works. Or you can treat that dif­fer­ence as an as­set and go build on it.

If you gen­uinely be­lieve some­thing oth­ers don’t, that’s not a de­bate to win. That’s an edge. The mar­ket re­wards be­ing right in a way that no ar­gu­ment ever will. Instead of per­suad­ing the skep­tic, ship the thing they think is wrong and let re­al­ity set­tle it. Their dis­agree­ment is­n’t an ob­sta­cle; it’s your moat. If every­one al­ready agreed with you, there’d be no op­por­tu­nity left.

This is es­pe­cially true if you’re start­ing your own com­pany. Differentiation is not a side ef­fect of busi­ness, it is the busi­ness. A startup ex­ists pre­cisely be­cause its founders be­lieve some­thing the rest of the world has­n’t ac­cepted yet. If you could win that ar­gu­ment in a meet­ing, it would­n’t be worth a com­pany. The en­tire value lives in the gap be­tween what you see and what oth­ers refuse to.

So I stopped try­ing to close that gap by talk­ing. I started try­ing to profit from it by build­ing. Let peo­ple dis­agree. Their dis­agree­ment is where the money, and the mean­ing, is.

You Can Only Change Yourself

Here’s the part that took me longest to ac­cept.

In this world, there is no one you can change. Not your spouses, not your friends, not your kids, and of course not strangers on the in­ter­net. Only your­self.

That’s not cyn­i­cism, and it’s not giv­ing up on peo­ple. It’s the op­po­site. It’s putting your en­ergy where it can ac­tu­ally do some­thing. Every hour spent try­ing to change some­one who did­n’t ask is an hour stolen from the one per­son (yourself) you can change.

And chang­ing your­self is enough. You don’t need to fix every­one else to live well. When you be­come clearer, calmer, more skilled, more hon­est, the world around you shifts on its own, not be­cause you forced any­one, but be­cause peo­ple re­spond to who you ac­tu­ally are. Change your­self and you’ve changed your en­tire ex­pe­ri­ence of the world. That is suf­fi­cient. Nothing more is re­quired.

Accept this, and a strange peace fol­lows. The ar­gu­ments fall away. The frus­tra­tion drains out. You stop try­ing to win peo­ple over and start let­ting them be who they are.

So turn the ques­tion around.

If the only per­son you can change is your­self, then the one ques­tion that mat­ters is: how do you ac­tu­ally get bet­ter? Not by win­ning ar­gu­ments. You get bet­ter by ask­ing oth­ers for feed­back, again and again, and truly lis­ten­ing to it. It’s the same ask­ing I de­scribed ear­lier, the one clean ex­cep­tion, now turned on my­self: I’m the one re­quest­ing help, so the ad­vice can fi­nally land. And you can­not do that with an ego in the way. The ego that needs to win is the same ego that can’t hear. It’s not just harm­ful; it’s a dis­as­ter, to every­one around you and to your­self most of all, be­cause it qui­etly walls you off from the one thing that would im­prove you.

So put it away. Stay hum­ble. Keep ask­ing. That is the whole dis­ci­pline.

I stopped ar­gu­ing not be­cause I stopped car­ing about be­ing right, but be­cause I fi­nally wanted some­thing more than be­ing right: I wanted to keep get­ting bet­ter. And the only door to that is the one ego keeps slam­ming shut.

Scientists built a syn­thetic cell that com­bines more life­like prop­er­ties than ever be­fore — proof of con­cept that it’s pos­si­ble to bring non­liv­ing ma­te­ri­als to life, or some­thing close to it, in the lab.

Introduction

For the very first time, bi­ol­o­gists packed non­liv­ing com­po­nents into a cell-like mem­brane, piece by piece, and wit­nessed the bag of mol­e­cules start to be­have like life. The lab-made syn­thetic cell grew, repli­cated its DNA, and di­vided, demon­strat­ing the ba­sic func­tions of a cell cy­cle.

It’s “an im­pres­sive step,” said Jack Szostak, who stud­ies the ori­gins of life at the University of Chicago and was not in­volved in the re­search. “I don’t know of any other ef­fort to put to­gether an ar­ti­fi­cial cell from bi­o­log­i­cal com­po­nents that has pro­gressed so far.”

The cell is not alive by any de­f­i­n­i­tion. It can’t sur­vive with­out con­stant de­liv­er­ies of food and ri­bo­somes, the ma­chin­ery needed to make pro­teins. It has no de­fenses or a good waste re­moval sys­tem. But it’s the strongest demon­stra­tion yet that it is pos­si­ble to gen­er­ate life from non­life, a goal that syn­thetic bi­ol­o­gists have been chas­ing for decades.

“It’s a big step for­ward to this holy grail of mak­ing a liv­ing thing out of dead com­po­nents,” said Sijbren Otto, a sys­tems chemist at the Stratingh Institute for Chemistry in the Netherlands who was not in­volved in the work. “It’s not com­pletely there yet, but it’s def­i­nitely get­ting quite close.”

Since these cells were pieced to­gether from scratch, and all the mol­e­c­u­lar parts were crafted in the lab, sci­en­tists can tin­ker with the sys­tem and switch com­po­nents in and out. “I have a blue­print, I have a full chem­i­cal in­gre­di­ent list of every com­po­nent,” said Kate Adamala, a syn­thetic bi­ol­o­gist at the University of Minnesota who led the new study, which is not yet peer-re­viewed. With such flex­i­bil­ity, this kind of syn­thetic cell could even­tu­ally be coaxed to cre­ate new ma­te­ri­als, such as bio­fu­els and drugs, and help re­searchers study dis­ease.

The syn­thetic bi­ol­o­gist Kate Adamala coaxed a cel­lu­lar soup of non­liv­ing bio­mol­e­cules en­closed in a mem­brane to act some­what like a liv­ing thing, even grow­ing and di­vid­ing into daugh­ter cells.

Courtesy of Kate Adamala

It could also give sci­en­tists in­sight into some of their deep­est ex­is­ten­tial ques­tions: What is the min­i­mum needed to sus­tain life? How could life start? What hap­pens if we al­ter the bi­ol­ogy that com­poses life on Earth to­day?

Or, as Adamala put it: “What else can bi­ol­ogy do?”

Building Life

Some 4 bil­lion years ago, a bunch of non­liv­ing mol­e­cules got to­gether to form the first pro­to­cells. They fed, grew, and di­vided. Then, over time, evo­lu­tion­ary processes emerged that let these cells change and di­ver­sify into many dif­fer­ent types, dec­o­rat­ing a bar­ren world with all man­ner of strange be­ings. A purely chem­i­cal world blos­somed into a bi­o­log­i­cal one. Scientists can­not agree on how this shift from non­life to life, or abio­gen­e­sis, hap­pened, but some have turned their sights on try­ing it out for them­selves in the lab.

For decades, re­searchers have taken dif­fer­ent ap­proaches to this chal­lenge. Some, like the syn­thetic bi­ol­o­gist John Glass at the J. Craig Venter Institute, are strip­ping down bac­te­r­ial cells to their small­est, barest genomes to re­veal a cel­l’s min­i­mum re­quire­ments to stay alive. Others, like Otto, try to build cells with mol­e­cules that dif­fer from those found in Earth bi­ol­ogy.

Adamala also works from the ground up, but with bi­o­log­i­cal mol­e­cules found in na­ture to­day. When she started her lab in 2016, she en­vi­sioned as­sem­bling a syn­thetic cell, a proof of con­cept, that could un­dergo a com­plete cy­cle of cell di­vi­sion us­ing its own genome.

She found an in­struc­tion man­ual in what all known cells have in com­mon: They grow, they du­pli­cate their DNA, they di­vide, and they evolve. They tran­scribe their DNA into RNA and then make pro­teins to carry out these tasks and oth­ers that keep a cell run­ning, such as me­tab­o­liz­ing mol­e­cules for en­ergy. All of this is done in­side a lipid mem­brane, which holds all the nec­es­sary ma­te­ri­als in one place. Adamala’s team needed to build their syn­thetic cell a genome and sup­ply it with all the ma­te­ri­als to carry out those tasks.

They de­vel­oped and op­ti­mized dif­fer­ent in­gre­di­ents, most in­spired by other labs, be­fore com­bin­ing them to­gether in­side li­po­somes — hol­low sacs en­closed by a sim­ple lipid mem­brane. This would serve as the cel­lu­lar body.

They started with a cel­l’s most fun­da­men­tal sys­tem: its mech­a­nism for copy­ing its DNA and pass­ing it down to daugh­ter cells. They adopted a DNA repli­ca­tion sys­tem, pi­o­neered by the syn­thetic bi­ol­o­gists Hannes Mutschler and Christophe Danelon, and tweaked it to work along­side other sys­tems, in­clud­ing a com­mer­cial pack of 36 en­zymes that let the cell read DNA and make pro­teins. Adamala’s team fid­dled with their cel­lu­lar brew, switch­ing genes in and out and ad­just­ing con­cen­tra­tions of var­i­ous mol­e­cules, to get the cru­cial in­for­ma­tion-car­ry­ing and pro­tein-mak­ing ge­netic sys­tems to jibe.

Their tiny syn­thetic genome did not en­code any meta­bolic genes, which would let the cell process food and en­ergy, or many of the com­plex mol­e­cules a cell needs. So, in par­al­lel, the re­searchers prepped some sup­ply packs.

They filled other li­po­somes with sugar, lipids, and en­zymes, as well as com­plex mol­e­cules, such as trans­fer RNA (tRNA) and ri­bo­somes, which work to­gether to trans­late ge­netic in­struc­tions into pro­teins. For their pro­to­cell to ac­cept these cru­cial sup­plies, the team also mod­i­fied a pro­tein that would sit in the cell mem­brane and at­tract the lipid bub­bles. When a bub­ble bumped into the cell, their mem­branes would fuse, re­leas­ing the sup­plies in­side.

It was­n’t easy to get all these ge­netic sys­tems to work to­gether suc­cess­fully. After some more tweak­ing and op­ti­miz­ing, the cell started grow­ing and repli­cat­ing its DNA.

“I was al­most ready to say ‘Done’ and ‘We’re go­ing to pub­lish it,’” Adamala re­called. But her vi­sion for a syn­thetic cell had one more step: di­vi­sion.

This was where the field had been stuck for some time. Researchers be­fore Adamala had fig­ured out dif­fer­ent ways to feed and grow syn­thetic cells and to repli­cate their DNA. But cell di­vi­sion is a dif­fer­ent beast. A typ­i­cal cell re­or­ga­nizes its cy­toskele­ton — a net­work of pro­tein fibers that pro­vide struc­tural sup­port — to halve its DNA and split. Synthetic bi­ol­o­gists could not fig­ure out how to get their cells to un­dergo this com­plex process.

So Adamala de­cided to ditch the cy­toskele­ton. One day, while tear­ing through the lit­er­a­ture, she came across an in­ter­est­ing mech­a­nism in a pa­per. By at­tach­ing pro­tein tags to a cell mem­brane, the syn­thetic bi­ol­o­gist Reinhard Lipowsky at the Max Planck Institute of Colloids and Interfaces at­tracted other pro­teins to crowd around and phys­i­cally bend the mem­brane, forc­ing the cell to di­vide. Following this ap­proach, Adamala tweaked a cell-mem­brane pro­tein and tested it in her pro­to­cells. After sev­eral tries, it worked.

“I was­n’t al­low­ing my­self to be­lieve it for a while,” she said. “It was like, ‘Holy shit, did I ac­tu­ally make a di­vid­ing cell?’ … At some point, you’ve been check­ing enough that [you think], ‘OK, now it’s real.’”

This pa­per “beautifully demon­strates this di­vi­sion mech­a­nism,” said Job Boekhoven, a sys­tems chemist at the Technical University of Munich who was not in­volved in the study. “That has been a huge achieve­ment.”

By putting to­gether sys­tems in­spired by dif­fer­ent labs — DNA repli­ca­tion; feeder li­po­somes; and swarm­ing, di­vi­sion-in­duc­ing pro­teins — and then op­ti­miz­ing them to work to­gether, Adamala’s team showed that it is pos­si­ble to in­duce the chem­i­cal world to form a bi­o­log­i­cal one in the lab.

“Combining all of these things is a stag­ger­ing tech­ni­cal ac­com­plish­ment,” Glass said. “I think it will prove to be a wa­ter­shed event for the syn­thetic-cell field and bi­ol­ogy in gen­eral.”

Michael Lynch, an evo­lu­tion­ary bi­ol­o­gist at Arizona State University who was also not in­volved in the study, agreed. It is “a syn­thetic bi­ol­ogy tour de force,” he said. However, he also cau­tioned against over-hyp­ing the cell since it’s not yet self-sus­tain­ing.

Once the syn­thetic cells were cre­ated, her stu­dents and oth­ers started call­ing them Adamala cells — a moniker she hated. She in­sisted that they name the cells af­ter any­thing else, jok­ingly sug­gest­ing pota­toes. So her stu­dents started call­ing them spud­cells. “I’m Polish, I’m mostly made of pota­toes, so that’s fine with me,” Adamala said.

Each cell is tiny. Its genome is way smaller than bac­te­r­ial genomes, and it does­n’t look like any­thing spe­cial. It’s “beautiful to me be­cause I’m su­per ex­cited about it,” Adamala said. “But if you look at it un­der the mi­cro­scope, it’s like, ‘OK, it’s a blob.’”

Evolution and Beyond

The cell could grow and di­vide. But could it take the next step to­ward life by evolv­ing?

The re­searchers started fid­dling with the syn­thetic cel­l’s DNA to see if they could get some cells to grow larger or di­vide faster — in ef­fect, cre­at­ing ge­netic vari­a­tion in the cell pop­u­la­tion. They found that the cells that grew big­ger also had more daugh­ter cells and started to be­come more pop­u­lous. In other words, those traits started be­ing se­lected for within the pop­u­la­tion, the first step to­ward evo­lu­tion.

What Adamala’s team demon­strated was not quite nat­ural se­lec­tion, the pri­mary mech­a­nism that dri­ves evo­lu­tion­ary change, in which or­gan­isms that are bet­ter adapted to their en­vi­ron­ment are more likely to sur­vive. Even if she got their cell to pro­duce more daugh­ter cells, she does­n’t think it would lead to evo­lu­tion. That’s be­cause Adamala’s team had to cre­ate ge­netic vari­a­tion syn­thet­i­cally, in­stead of al­low­ing for ran­dom mu­ta­tions in DNA. The en­zyme that builds new DNA strands works too well, she said; it does­n’t in­tro­duce mean­ing­ful mu­ta­tions into the se­quence. They will need to find an en­zyme that is more er­ror-prone — but not so er­ror-prone that the genome’s in­tegrity and the cel­l’s func­tion is lost.

“Biology needs to change fast enough, but not too fast,” Adamala said. She said that she needs to find the sweet spot be­tween or­der and chaos, ref­er­enc­ing the bio­chemist and com­plex­ity the­o­rist Stuart Kauffman, a pro­fes­sor emer­i­tus at the University of Pennsylvania, who ar­gues that bi­ol­ogy works best at the “edge of chaos.”

A clear demon­stra­tion of an evo­lu­tion­ary process is “clearly some­thing that’s miss­ing,” Boekhoven said. “I’m sure that that’s the next big step.” Other re­searchers have shown adap­tive evo­lu­tion in other types of syn­thetic cells. But those cells were bac­te­ria stripped of all but the bare min­i­mum of genes — they weren’t built from the ground up.

The cells are also lim­ited by the fact that they need to be fed many of their raw ma­te­ri­als. That the cells can’t make their own ri­bo­somes, the way nat­ural cells do, “limits [their] po­ten­tial for growth and sus­tained re­pro­duc­tion,” said Szostak, who was Adamala’s doc­toral ad­viser. “If their sys­tem was able to gen­er­ate its own ri­bo­somes and other pro­teins and RNAs, it would be much closer to ex­ist­ing bi­o­log­i­cal cells such as bac­te­ria.”

Adamala also thinks they will need to fig­ure out a way to add a cy­toskele­ton to im­prove their repli­ca­tion sys­tem. Currently, the cells waste a lot of en­ergy and time at­tract­ing mol­e­cules to crowd around and help them di­vide.

All told, sci­en­tists are far from build­ing any­thing re­motely close to a mod­ern liv­ing cell — but this new one is still the most life­like yet. “The mod­ern cell is like a Dreamliner,” Adamala said, re­fer­ring to the Boeing 787 air­plane. “We built a Wright flyer… the first bike frame with wings that flies 100 feet.”

Alongside shar­ing the new re­sults, Adamala and other syn­thetic bi­ol­o­gists an­nounced the for­ma­tion of a non­profit called Biotic, which they will use to make their syn­thetic bi­ol­ogy tools avail­able to re­searchers around the world. The team is re­leas­ing their data and meth­ods so that syn­thetic bi­ol­o­gists can start build­ing and im­prov­ing on their cell. The hope is that the work can be used, decades from now, to cre­ate plas­tics with­out fos­sil fu­els, for ex­am­ple, or fer­til­iz­ers or drugs.

These syn­thetic cells could also pave the way to the past, to the ori­gins of bi­ol­ogy it­self. Life on Earth would have started from much sim­pler mol­e­cules than the ones that spud­cells use. Still, Adamala’s cre­ation of a syn­thetic cell sys­tem from non-liv­ing ma­te­ri­als brings re­searchers a step closer to ex­plor­ing, in the lab, deeper ques­tions about life’s ori­gins and re­quire­ments, a dream she shares with oth­ers.

“If you want to un­der­stand what life is,” Boekhoven said, “you need to first build life.”

Godot has been suf­fer­ing from a slop prob­lem. In February, the main­tain­ers of the open source game en­gine, which pow­ers games like Slay the Spire 2 and The Case of the Golden Idol, said they were de­lib­er­at­ing how to ad­dress a ris­ing tide of AI slop pull re­quests, which had be­come “increasingly drain­ing and de­mor­al­iz­ing” for the pro­jec­t’s code re­view­ers.

Today, af­ter months of dis­cus­sion, the Godot Foundation and its main­tain­ers are draw­ing a line in the sand. In a blog post, the Foundation an­nounced that Godot’s guide­lines for con­trib­u­tors will soon be amended to for­bid AI-authored code, pull re­quests sub­mit­ted by AI agents, and AI-generated text in hu­man-to-hu­man com­mu­ni­ca­tion.

“It is time for us to rec­og­nize that these prob­lems aren’t go­ing away and there­fore we need to take steps to re­duce the bur­den on main­tain­ers while en­sur­ing we still have a pipeline to men­tor new con­trib­u­tors to be­come fu­ture main­tain­ers,” the Godot Foundation said.

The Foundation says the pileup of Godot pull re­quests pend­ing re­view is­n’t all bad: It’s a sign that in­ter­est in us­ing and con­tri­bu­tion to Godot is in­creas­ing. But the in­flux of con­tri­bu­tions au­thored or sub­mit­ted by AI is sap­ping the pro­jects’ main­tain­ers of their will­ing­ness to con­front the “already te­dious” work of re­view­ing pull re­quests.

“If your feed­back on PRs is just be­ing ab­sorbed by a ma­chine and not go­ing to­wards men­tor­ing a po­ten­tial fu­ture main­tainer, it be­comes much harder to jus­tify spend­ing your free time on PR re­view,” the Foundation said.

As the prob­lem be­comes in­creas­ingly un­sus­tain­able, the Godot Foundation says it’s in the process of up­dat­ing its con­tri­bu­tion poli­cies, fo­cus­ing on “adding bar­ri­ers to low-ef­fort slop” con­tri­bu­tions, en­cour­ag­ing main­tain­ers to re­view code, de­vel­op­ing new con­trib­u­tors into fu­ture main­tain­ers, and cru­cially, re­quir­ing that all con­tri­bu­tions come from hu­mans who are ac­count­able for their code—and fix­ing it if it fails.

“AI can­not take re­spon­si­bil­ity, and we can’t trust heavy users of AI to un­der­stand their code enough to fix it,” the Foundation said.

Keep up to date with the most im­por­tant sto­ries and the best deals, as picked by the PC Gamer team.

The Foundation says we can ex­pect Godot’s con­tribut­ing pol­icy to soon in­clude ex­plicit re­jec­tions of AI-authored code, not­ing that con­trib­u­tors should only use AI as­sis­tance for “menial things” and must dis­close its use. Additionally, the Foundation will re­ject any AI-generated text in hu­man-to-hu­man com­mu­ni­ca­tions, say­ing it’s “a ba­sic prin­ci­ple of re­spect”—though it says ma­chine trans­la­tions “are still ac­cept­able” if the orig­i­nal text was hu­man-au­thored.

“Things change every day with re­spect to the cur­rent suite of AI tools avail­able,” the Foundation said. “We will con­tinue tak­ing a con­ser­v­a­tive ap­proach in our poli­cies to­wards them, but we will re-eval­u­ate as things evolve.”

Lincoln has been writ­ing about games for 12 years—un­less you in­clude the es­says about pro­ce­dural sto­ry­telling in Dwarf Fortress he con­vinced his col­lege pro­fes­sors to ac­cept. Leveraging the brain­worms from a youth spent in World of Warcraft to write for sites like Waypoint, Polygon, and Fanbyte, Lincoln spent three years free­lanc­ing for PC Gamer be­fore join­ing on as a full-time News Writer in 2024, bring­ing an ex­per­tise in Caves of Qud bird diplo­macy, get­ting sons killed in Crusader Kings, and hit­ting di­nosaurs with ham­mers in Monster Hunter.

Linux 7.1 is now here, and of course with it comes an­other progress re­port. We’ve got M3 progress, Apple bugs, and more!

Welcome back Master Boot Record

When you long-press the power but­ton on your Mac to bring up the boot picker (or use the Startup Disk ap­pli­ca­tion), what you see listed as Asahi is not ac­tu­ally the par­ti­tion with the op­er­at­ing sys­tem on it. Apple’s boot tool­ing will only work with what it con­sid­ers to be a “valid” ma­cOS in­stal­la­tion in­side an APFS con­tainer. So that we can use Apple’s boot­loader and avoid need­ing users to run com­mands from Recovery every time they want to use Asahi, the Asahi Installer cre­ates a small APFS con­tainer (2.5 GB) with just enough of ma­cOS on it to con­vince Apple’s tools that it is a bootable in­stal­la­tion of ma­cOS with m1n1 as its ker­nel. This arrange­ment worked com­pletely un­changed from ma­cOS 12 to ma­cOS 26, and Apple even fixed a cou­ple of bugs in their tools that are only en­coun­tered when at­tempt­ing to boot raw bi­na­ries that are not a real XNU ker­nel.

Shortly af­ter the re­lease of the ma­cOS 27 Golden Gate de­vel­oper beta how­ever, we be­gan re­ceiv­ing re­ports that peo­ple were no longer able to boot into Linux on their ma­chines — the op­tion had sim­ply dis­ap­peared from both Startup Disk and the boot picker! Obviously this is quite con­cern­ing, and so we made in­ves­ti­gat­ing this a pri­or­ity.

Inspecting the disk us­ing disku­til re­vealed that all Asahi-related par­ti­tions were still pre­sent on the disk af­ter up­grad­ing to ma­cOS 27. No data loss was oc­cur­ring, which is a pos­i­tive sign. Additionally, Asahi was still bootable on the same ma­chine when us­ing the boot tool­ing from a sec­ond in­stall of ma­cOS 26.

chaos_princess be­gan in­spect­ing Apple’s own ma­cOS Installer and old streams from way back when we were first pok­ing at Apple’s boot tools. The ma­cOS Installer sets some APFS meta­data be­fore re­boot­ing the ma­chine, which fur­ther in­ves­ti­ga­tion re­vealed to be a flag that marks the vol­ume as bootable. Until ma­cOS 27, the boot tool­ing sim­ply ig­nored this flag en­tirely. After set­ting the flag man­u­ally on an Asahi APFS con­tainer, it be­comes avail­able in the ma­cOS 27 boot picker with no fur­ther changes.

Going for­ward, all new Asahi in­stalls will have this flag set au­to­mat­i­cally by the Asahi Installer. We’ve also added an in­staller mode that will fix ex­ist­ing in­stal­la­tions. If you’ve in­stalled the ma­cOS 27 de­vel­oper beta and can­not ac­cess your Asahi in­stall, please run the in­staller again and use the “Fix ma­cOS 27 boot picker com­pat­i­bil­ity” op­tion.

chaos_princess has also de­vel­oped a pro­gram that can be run from Linux to fix the is­sue. While we would even­tu­ally like to de­ploy this fix au­to­mat­i­cally, we need more test­ing data to con­firm that it is re­li­able and will not de­stroy any­ones’ filesys­tems. That’s where you come in. If you are will­ing to help us test this, clone this repo, then build and run it from Linux be­fore up­grad­ing to ma­cOS 27. If your Asahi vol­ume is still se­lec­table as a boot tar­get from ma­cOS, it has worked. Do be sure to let us know how it went by pop­ping in to one of our chan­nels on OFTC or Matrix, es­pe­cially if you run in to any is­sues.

Three bytes forc­ing shut­downs

ma­cOS 27 also brings firmware up­dates for all pe­riph­er­als with global firmware, in­clud­ing the SMC. One of the SMC’s myr­iad func­tions is bat­tery man­age­ment. Our Linux power sup­ply dri­ver talks to the SMC to get in­for­ma­tion such as charge state, volt­age, time un­til empty and bat­tery health. The dri­ver also uses the SMC’s firmware in­ter­face to con­fig­ure charge start and stop thresh­olds to pro­long the life of the bat­tery. ma­cOS 27’s SMC firmware changed one of the bat­tery man­age­ment in­ter­faces from re­turn­ing a 32-bit in­te­ger to re­turn­ing a sin­gle byte. This change con­fuses our dri­ver, which un­der cer­tain con­di­tions con­sid­ers the bat­tery as hav­ing failed and ini­ti­ates an emer­gency shut­down to pro­tect the sys­tem. We have al­ready patched this in the down­stream ker­nel; start­ing with ver­sion 7.0.12, the power sup­ply dri­ver can deal with both firmware ABIs.

On in­stalling be­tas

Bugs like these are an im­por­tant re­minder that de­vel­oper be­tas are just that, de­vel­oper be­tas. It is ill-ad­vised to in­stall them on pro­duc­tion ma­chines. The two is­sues we have had so far have luck­ily mi­nor, but that does­n’t mean that all fu­ture is­sues will be too. Global firmware up­dates are ef­fec­tively per­ma­nent too, and can only be rolled back with a DFU re­store of the ma­chine. Please re­frain from in­stalling de­vel­oper be­tas go­ing for­ward. We have sac­ri­fi­cial ma­chines we use to test these things on your be­half, there is no need to risk your own ex­pen­sive hard­ware and im­por­tant data.

The more things change…

Designing and val­i­dat­ing com­puter plat­forms and the ICs that go into them is ex­tremely ex­pen­sive and time con­sum­ing, so it makes very lit­tle sense to make changes to ex­ist­ing de­signs when they are not nec­es­sary. Early on in the pro­ject, we made a bet that Apple would agree and re­frain from mak­ing con­stant break­ing changes to ei­ther. Discounting a few of the larger SoC blocks like the GPU that are al­most re­quired to change every gen­er­a­tion, this bet has largely paid off.

Audio on an Apple Silicon lap­top in­volves a few dif­fer­ent ICs and SoC blocks. The de­facto in­dus­try stan­dard for au­dio ICs is I2S, an I2C-based bus op­ti­mised for au­dio data. Apple’s I2S con­troller has re­mained un­changed since M1. All of these au­dio ICs also need a sta­ble clock source, which must be con­fig­urable to ac­com­mo­date the wide va­ri­ety of au­dio data rates. Apple’s Numerically Controlled Oscillator (NCO) has also re­mained un­changed since M1. Apple have also used the ex­act same speaker and head­set am­pli­fier chips in al­most all Apple Silicon ma­chines. So, when chaos_princess started adding speaker and head­phone jack sup­port to M3 ma­chines, lit­tle more was re­quired than some triv­ial Devicetree ad­di­tions and con­fig files for asahi-au­dio and speak­er­safe­tyd. As such, M3 ma­chines now sport high-qual­ity au­dio out­put on Asahi Linux!

M3 ma­chines have also grown sup­port for both CPU fre­quency switch­ing and proper big.LIT­TLE task sched­ul­ing. Apple have not changed how CPU fre­quency switch­ing works since the base M2, mean­ing that all M3 and M3 Pro/Max/Ultra SoCs re­quired noth­ing more than Devicetree changes to work with our ex­ist­ing cpufreq dri­ver. Tasks should now be more in­tel­li­gently placed on ei­ther ef­fi­ciency or per­for­mance cores ac­cord­ing to their re­quire­ments, and the CPU cores them­selves should clock up and down based on load. This will both save en­ergy and im­prove per­for­mance!

Adding sup­port for the SMC’s hard­ware sen­sors was sim­i­larly triv­ial; the SMC’s firmware is not ma­te­ri­ally dif­fer­ent across ma­chines, so once again noth­ing more than a few Devicetree changes was re­quired here.

On top of the above, we also have PCIe, WiFi, Bluetooth, NVMe, key­board, track­pad, and other core SoC block dri­vers work­ing in Linux for M3 se­ries ma­chines. Most of this work has come by way of Yureka, who has been very busy hack­ing on both m1n1 and Linux with her M3 se­ries ma­chines for a while now. We still have a ways to go be­fore we can start en­abling Asahi Installer sup­port for these ma­chines, but progress is rapid so watch this space!

We’re writ­ing firmware now?

Most of the com­pli­cated hard­ware on this plat­form uses com­pli­cated firmware blobs. Most of this is based on RTKit, an RTOS-like firmware frame­work used by Apple to pre­sent a mostly stan­dard­ised in­ter­face for the ker­nel to talk to the var­i­ous bits of hard­ware. There are ex­cep­tions to this, how­ever. Some blocks, like DCP and AOP, use RTKit as the ba­sis for their firmware, but layer yet an­other set of ab­strac­tions called EPIC on top of it. Others still, like the Broadcom WiFi/Bluetooth chipset, use third-party firmware that Apple has no di­rect con­trol over. Then, there’s the Apple Video Decoder (AVD).

AVD is spe­cial. Its firmware is nei­ther RTKit nor EPIC, it’s a se­cret third thing. The hard­ware it­self is es­sen­tially an ARM Cortex-M3 con­trol­ling a se­ries of fixed-func­tion hard­ware units for de­cod­ing video frames en­coded in AVC (H.264), HEVC (H.265), VP9, and AV1 on more re­cent SoCs. The CM3 runs a blob of firmware that ex­poses an in­ter­face for XNU to point it to video data, and then pro­grams the ac­tual de­coder hard­ware it­self. This would nor­mally be fine, how­ever Apple made the in­ter­est­ing choice of bundling both the AVD’s firmware and a pile of con­fig­u­ra­tion data in­side the AVD kext. Making mat­ters worse, each SoC has a slightly dif­fer­ent AVD vari­ant. This is lo­gis­ti­cally chal­leng­ing, as the Asahi Installer would have to con­stantly be up­dated with (and keep track of) Apple’s changes to the off­sets of the firmware data in the kext. We could do this, but what if there’s a bet­ter way?

The firmware loaded by XNU is not ver­i­fied by the CM3. It will be­gin ex­e­cut­ing from its re­set vec­tor when sig­nalled, no mat­ter what is ac­tu­ally there. What if we just… used our own firmware?

Since the firmware is ef­fec­tively just there to ab­stract away the un­der­ly­ing video de­coder hard­ware, it does­n’t ac­tu­ally mat­ter what it does, so long as it in­stalls in­ter­rupt han­dlers for the var­i­ous hard­ware blocks. If we un­der­stand what the un­der­ly­ing hard­ware ex­pects, we can just pro­gram it all from a Linux dri­ver. To do this, we need to un­der­stand how the firmware dri­ves each de­coder.

Being stan­dard Cortex-M3 code, it is pos­si­ble to run the AVD firmware in an em­u­la­tor. A num­ber of so­lu­tions ex­ist to do this, in­clud­ing QEMU, which al­lows you to sin­gle-step your pro­gram and in­spect bus and reg­is­ter op­er­a­tions. The ground­work for this was laid many years ago by Jamie, R and Eileen, who through a com­bined ef­fort man­aged to re­verse en­gi­neer the in­struc­tions and data for­mats re­quired by the AVC and VP9 de­coders.

The XNU kext also ap­plies a unique set of tun­ables to each AVD re­vi­sion. We are not en­tirely cer­tain what these do, so ap­ply­ing these es­sen­tially needs to be a re­play of MMIO writes made by XNU. We need to keep track of each AVD re­vi­sion, each set of tun­ables, and which re­vi­sion they need to be ap­plied to. This would be im­pos­si­ble to main­tain sat­is­fac­to­rily in an up­stream Linux ker­nel dri­ver, so this should also prob­a­bly live in firmware.

While not much work hap­pened on this front for a long time, new con­trib­u­tor so­fus re­cently stepped up to fill the gap. With a blob of cus­tom AVD firmware that sim­ply in­stalls in­ter­rupt han­dlers and ap­plies each vari­ant’s set of tun­ables, he was able to write a work­ing V4L2 dri­ver for the AVC hard­ware! The hard­ware can de­code 10-bit AVC-encoded video up to 4K, and works well with soft­ware that im­ple­ments the V4L2 Request API. Keeping the firmware ba­sic and state­less, with user­space and the ker­nel be­ing re­spon­si­ble for pars­ing all video data and pro­gram­ming the de­coders them­selves, also en­ables us to more eas­ily sup­port other video ac­cel­er­a­tion APIs like VA-API and Vulkan Video at some point in the fu­ture.

There’s still some work to do be­fore we can ship AVD sup­port to users. AVD sup­ports VP9, HEVC and even AV1 on some SoCs, but we have not im­ple­mented sup­port for any of these yet. Some de­vices also have quirks that must be tested and ac­counted for in the dri­ver. We hope to have some­thing ship­pable for you all in the not too dis­tant fu­ture!

A large m1n1 re­lease

We have also re­cently tagged ver­sion 1.6.0 of m1n1. This is a con­se­quen­tial re­lease for dis­tros, as it is the first ver­sion that re­quires Rust for stage 2 builds. Previously, m1n1 only made use of Rust when built with chain­load­ing sup­port. Stage 1 m1n1 re­places the XNU ker­nel in Apple’s boot tool­ing, and is used only to mount the EFI System Partition and chain­load Stage 2 m1n1 from there. A lit­tle while ago how­ever, we made the de­ci­sion to move GPU ini­tial­i­sa­tion into m1n1. This re­moved the need for the ker­nel dri­ver to deal with the float­ing point num­bers found in Apple’s hard­ware ini­tial­i­sa­tion data, and also greatly sim­pli­fied the Devicetree bind­ings. The ver­sion of the GPU dri­ver we even­tu­ally sub­mit to the Linux Kernel Mailing List will there­fore rely on m1n1 to do this ini­tial­i­sa­tion for it. We also ported the Apple Device Tree pars­ing code to Rust, which is con­sumed by just about every other part of m1n1.

Given that m1n1 is ef­fec­tively firmware, it uses no_std Rust and tar­gets aarch64-none-soft­float. To avoid pulling in su­per­flu­ous de­pen­den­cies, you can pass BUILDSTD=1 to make to build core and al­loc with­out re­quir­ing a full soft­float tool­chain to be in­stalled.

Version 1.6.0 also brings a whole host of im­prove­ments to M3 se­ries sup­port, in­clud­ing sup­port for the SPMI con­troller and PCIe ini­tial­i­sa­tion. We also now sup­port tun­nelling the SoC’s hard­ware UART di­rectly over DebugUSB with kisd, which can be used to achieve much the same func­tion­al­ity as the Central Scrutiniser. Much of this work is also cour­tesy of Yureka.

We are also lay­ing the ground­work for M4 and A18 Pro (MacBook Neo) sup­port, with bet­ter han­dling of Apple’s non-ma­cOS boot mode and sup­port for new power do­main meta­data found in the Apple Device Tree.

Thanks again!

As al­ways, we would like to thank our gen­er­ous sup­port­ers on GitHub Sponsors and Open Collective, with­out whom we would not be able to con­tinue work­ing on un­fin­ished M1 and M2 fea­tures or work on M3, M4 and A18 Pro sup­port while sup­port­ing our en­thu­si­as­tic new con­trib­u­tors!

James Calligeros · 2026 – 06-30

18 thoughts on “Nintendo has raised its em­ploy­ees base salary by 10%”

Employee raises and build­ing new build­ings. Take notes Xbox and Playstation!

Employee raises and build­ing new build­ings. Take notes Xbox and Playstation!

They did, but they raised con­sole prices in­stead 😂

Nintendo is only rais­ing prices slowly be­cause Switch 2 is al­ready a bit over­priced to be­gin with, fool­ing your­self If you ac­tu­ally think Nintendo would take a loss on hard­ware or soft­ware for that mat­ter.

It’s not a bit over­priced. Specs re­ally close to Series S, with a screen, a dock, grip, and 2 con­trollers.

By the low­est amount of all the com­pa­nies that have an­nounced price in­creases and yet af­ter that: — salary in­crease — new 121 bil­lion yen R&D

They did, but they raised con­sole prices in­stead 😂

They did, but they raised con­sole prices in­stead 😂

Nintendo is only rais­ing prices slowly be­cause Switch 2 is al­ready a bit over­priced to be­gin with, fool­ing your­self If you ac­tu­ally think Nintendo would take a loss on hard­ware or soft­ware for that mat­ter.

It’s not a bit over­priced. Specs re­ally close to Series S, with a screen, a dock, grip, and 2 con­trollers.

By the low­est amount of all the com­pa­nies that have an­nounced price in­creases and yet af­ter that: — salary in­crease — new 121 bil­lion yen R&D

Nintendo is only rais­ing prices slowly be­cause Switch 2 is al­ready a bit over­priced to be­gin with, fool­ing your­self If you ac­tu­ally think Nintendo would take a loss on hard­ware or soft­ware for that mat­ter.

Nintendo is only rais­ing prices slowly be­cause Switch 2 is al­ready a bit over­priced to be­gin with, fool­ing your­self If you ac­tu­ally think Nintendo would take a loss on hard­ware or soft­ware for that mat­ter.

It’s not a bit over­priced. Specs re­ally close to Series S, with a screen, a dock, grip, and 2 con­trollers.

It’s not a bit over­priced. Specs re­ally close to Series S, with a screen, a dock, grip, and 2 con­trollers.

It’s not a bit over­priced. Specs re­ally close to Series S, with a screen, a dock, grip, and 2 con­trollers.

By the low­est amount of all the com­pa­nies that have an­nounced price in­creases and yet af­ter that: — salary in­crease — new 121 bil­lion yen R&D

By the low­est amount of all the com­pa­nies that have an­nounced price in­creases and yet af­ter that: — salary in­crease — new 121 bil­lion yen R&D

Awesome!~

Awesome!~

In to­day’s world. That is ac­tu­ally in­cred­i­ble.

In to­day’s world. That is ac­tu­ally in­cred­i­ble.

Huge W from Nintendo

Huge W from Nintendo

The OriginalGaner in Red is a fake

I know you are the real roll be­cause of your icon. Ok, I will try to make a list of peo­ple who have these icons who the real per­son. Roll=pink+Dark Blue Original gamer=Cyan+Dark­Blue CFG=Yellow+Brown Truthbringer=Pink+DarkPurple Did I get that cor­rectly?

I think OriginalGamer is BrightBlue+Green

No, you did­n’t. You’re lit­er­ally en­cour­ag­ing the trolls to con­tinue all this iden­tity theft BS. What is wrong with you?

He’s not, these Avis show up dif­fer­ent to every­one. To me you show up pur­ple with a pink back­ground.

The OriginalGaner in Red is a fake

The OriginalGaner in Red is a fake

I know you are the real roll be­cause of your icon. Ok, I will try to make a list of peo­ple who have these icons who the real per­son. Roll=pink+Dark Blue Original gamer=Cyan+Dark­Blue CFG=Yellow+Brown Truthbringer=Pink+DarkPurple Did I get that cor­rectly?

I think OriginalGamer is BrightBlue+Green

No, you did­n’t. You’re lit­er­ally en­cour­ag­ing the trolls to con­tinue all this iden­tity theft BS. What is wrong with you?

He’s not, these Avis show up dif­fer­ent to every­one. To me you show up pur­ple with a pink back­ground.

I know you are the real roll be­cause of your icon. Ok, I will try to make a list of peo­ple who have these icons who the real per­son. Roll=pink+Dark Blue Original gamer=Cyan+Dark­Blue CFG=Yellow+Brown Truthbringer=Pink+DarkPurple Did I get that cor­rectly?

I know you are the real roll be­cause of your icon. Ok, I will try to make a list of peo­ple who have these icons who the real per­son. Roll=pink+Dark Blue Original gamer=Cyan+Dark­Blue CFG=Yellow+Brown Truthbringer=Pink+DarkPurple Did I get that cor­rectly?

I think OriginalGamer is BrightBlue+Green

No, you did­n’t. You’re lit­er­ally en­cour­ag­ing the trolls to con­tinue all this iden­tity theft BS. What is wrong with you?

He’s not, these Avis show up dif­fer­ent to every­one. To me you show up pur­ple with a pink back­ground.

I think OriginalGamer is BrightBlue+Green

I think OriginalGamer is BrightBlue+Green

No, you did­n’t. You’re lit­er­ally en­cour­ag­ing the trolls to con­tinue all this iden­tity theft BS. What is wrong with you?

No, you did­n’t. You’re lit­er­ally en­cour­ag­ing the trolls to con­tinue all this iden­tity theft BS.

What is wrong with you?

He’s not, these Avis show up dif­fer­ent to every­one. To me you show up pur­ple with a pink back­ground.

He’s not, these Avis show up dif­fer­ent to every­one. To me you show up pur­ple with a pink back­ground.

He’s not, these Avis show up dif­fer­ent to every­one. To me you show up pur­ple with a pink back­ground.

Nintendo needs to buy Square Enix and then Sega

Nintendo needs to buy Square Enix and then Sega

But buy Capcom be­fore Sega of course. Seriously, how many crossovers be­tween Mario and Sonic with­out Mega Man are enough for you peo­ple?

But buy Capcom be­fore Sega of course. Seriously, how many crossovers be­tween Mario and Sonic with­out Mega Man are enough for you peo­ple?

But buy Capcom be­fore Sega of course. Seriously, how many crossovers be­tween Mario and Sonic with­out Mega Man are enough for you peo­ple?

This is a mis­in­ter­pre­ta­tion. Furukawa is stat­ing they have done things in the past to main­tain em­ployee re­ten­tion to in­clude rais­ing base salaries by 10% back in 2023. Nintendo is not rais­ing wages by 10% in 2026.

This is a mis­in­ter­pre­ta­tion.

Furukawa is stat­ing they have done things in the past to main­tain em­ployee re­ten­tion to in­clude rais­ing base salaries by 10% back in 2023.

Nintendo is not rais­ing wages by 10% in 2026.

I feel like nin­tendo does that ex­act op­po­site of what the rest of the video game in­dus­try does. When every com­pany does mas­sive lay offs, they raise their salaries. When com­pa­nies are fo­cus­ing on AI rather then mak­ing games, nin­tendo does­n’t use AI and they pump out more games faster. It re­ally is im­pres­sive how well nin­tendo does thing. I am fine if nin­tendo raises it’s prices for every­thing if they in­crease the salary for the work­ers.

I feel like nin­tendo does that ex­act op­po­site of what the rest of the video game in­dus­try does. When every com­pany does mas­sive lay offs, they raise their salaries. When com­pa­nies are fo­cus­ing on AI rather then mak­ing games, nin­tendo does­n’t use AI and they pump out more games faster. It re­ally is im­pres­sive how well nin­tendo does thing. I am fine if nin­tendo raises it’s prices for every­thing if they in­crease the salary for the work­ers.

And mean­while, Microsoft is shut­ting down and lay­ing off, Sony is squan­der­ing Bungie….

And mean­while, Microsoft is shut­ting down and lay­ing off, Sony is squan­der­ing Bungie….

As con­sumer pref­er­ences and the broader en­ter­tain­ment in­dus­try con­tinue to shift away from phys­i­cal discs to dig­i­tal, phys­i­cal game disc pro­duc­tion for all new games re­leas­ing on PlayStation con­soles will be dis­con­tin­ued start­ing January 2028.  Following this date, new games will be avail­able on PlayStation Store and at re­tail­ers in dig­i­tal for­mats only. This tran­si­tion has no im­pact on games that al­ready re­leased, or will be re­leas­ing, prior to January 2028 in disc for­mat.

This is a nat­ural di­rec­tion for Sony Interactive Entertainment to adapt to con­sumer trends as the gen­eral pref­er­ence for dig­i­tal me­dia sig­nif­i­cantly out­paces phys­i­cal discs. This tran­si­tion will en­able us to align more closely with how most of our com­mu­nity prefers to ac­cess and play games to­day.

We’ll continue to pri­or­i­tize our re­sources to drive in­no­va­tion in how play­ers can ac­cess games and pro­vide choices as to where play­ers pre­fer to pur­chase new games, whether that’s at re­tail­ers or PlayStation Store. We remain committed to de­liv­er­ing a world-class gam­ing ex­pe­ri­ence to our fans and we thank you for your con­tin­ued sup­port.

For im­por­tant up­dates on PlayStation Store for PS3 and PS Vita an­nounced to­day, please click here.

I’m happy to an­nounce the re­lease of Box3D, an open source 3D physics en­gine. It is now avail­able on GitHub.

Box3D repos­i­tory

You can think of Box3D as a fork of Box2D, ex­tended with many fea­tures needed for 3D games. Some ad­di­tions:

Triangle mesh col­li­sion

Height-field col­li­sion

Baked com­pound col­li­sion

The core ar­chi­tec­ture of Box3D re­mains al­most iden­ti­cal to Box2D.

C API

All li­brary source is C17

Sub-stepping solver

Continuous col­li­sion

Graph col­or­ing for large is­lands

Wide SIMD con­tact solver

Multi-threading hooks

Optional in­ter­nal sched­uler

Large world sup­port with dou­bles for po­si­tion

Cross plat­form de­ter­min­ism

Recording and re­play

If you want to see Box3D in ac­tion, watch this video:

There are two main rea­sons Box3D ex­ists. But there is a lot to un­pack. So stay awhile, and lis­ten.

Reason 1: The Legend of California

The first rea­son I de­vel­oped Box3D is that the game I’ve been work­ing on needs it. Let me ex­plain.

Problems with na­tive Unreal physics

I’ve been work­ing on The Legend of California at Kintsugiyama since 2022. This game is built us­ing the Unreal en­gine. We started with ver­sion 5.0. Our ex­per­i­ments with the na­tive physics en­gine (called Chaos) had some prob­lems. There was no sup­port for sim­u­lat­ing gy­ro­scopic torques. This means slen­der shapes could spin for a long time, con­serv­ing an­gu­lar ve­loc­ity. For ex­am­ple, see this video of a spin­ning ri­fle.

In 2015 I de­vel­oped a ~10 line drop-in al­go­rithm for adding gy­ro­scopic torques to any physics en­gine and pre­sented it at the Game Developer Conference: pre­sen­ta­tion. So I could have eas­ily added this fea­ture to the Chaos solver. Epic added this fea­ture in late 2024.

However, that was not my biggest prob­lem. Being a sur­vival game, one of the first things I worked on was chop­ping down trees. The falling trees moved er­rat­i­cally, tele­port­ing around the screen. My best guess is that Chaos was us­ing some sort of con­tin­u­ous col­li­sion fall­back. This sim­u­la­tion was a large cap­sule falling on a smooth tri­an­gle mesh. This sce­nario should have been easy to sim­u­late.

Another fac­tor is that The Legend of California needs to man­age a lot of en­ti­ties. Hundreds of thou­sands of en­ti­ties ex­ist on the server. We need a fast broad-phase for this. This is so cen­tral to our game that it seemed risky to hand this off to mid­dle­ware. I have a lot of ex­pe­ri­ence work­ing on broad-phase data struc­tures. I even did a GDC pre­sen­ta­tion on the topic.

So we reached a pivot point with our physics tech. All these fac­tors were adding up and I needed to make a de­ci­sion: try to fix the na­tive so­lu­tion or re­place it with an out­side physics en­gine.

I was con­sid­er­ing us­ing an ex­ist­ing open source physics en­gine, such as Jolt. Being a physics pro­gram­mer, I was pretty con­fi­dent that I could at least fork Jolt and get the out­comes we need for our game. However, a good friend sug­gested an­other course of ac­tion.

Valve to the res­cue

My friend Dirk Gregorius is an ac­com­plished physics pro­gram­mer, hav­ing shipped a cus­tom physics en­gine in Half-Life: Alyx called Rubikon. Dirk main­tains a hobby/​home ver­sion of Rubikon. Let’s call this “Rubikon-Lite”. He sug­gested that I could fork Rubikon-Lite and mod­ify it to my needs.

So that’s what I did. I hooked Rubikon-Lite di­rectly into Unreal. It worked great! We got gy­ro­scopic torques and trees fell nicely. Everything just worked.

The topic of re­plac­ing the physics en­gine in Unreal is likely a whole blog post (or more) on its own. I was able to make a few short­cuts be­cause:

we use our own script­ing sys­tem (not Blueprint)

we use the Esoterica an­i­ma­tion sys­tem ported to Unreal

we have a cus­tom ECS that hooks to Box3D di­rectly

Box2D v3.0 had many op­ti­miza­tions I wanted to bring into my Rubikon-Lite fork. At some point I re­al­ized I needed to keep my 2D and 3D ef­forts as sim­i­lar as pos­si­ble, for ef­fi­ciency and san­ity. So I re­placed al­most all the APIs, data struc­tures, and al­go­rithms in Rubikon-Lite with Box2D code. Fortunately, the data struc­tures for 2D and 3D are largely in­dif­fer­ent to spa­tial di­men­sions.

Eventually my Rubikon-Lite fork trans­formed into Box3D. Today Box3D still has some Rubikon-Lite code in the con­vex hull gen­er­a­tion and some col­li­sion al­go­rithms. The rest is code from Box2D and new code I wrote for Box3D.

On the Valve side, Rubikon con­tin­ues to evolve and Dirk has de­vel­oped op­ti­miza­tions (similar to those in Box3D) in a new en­gine called Ragnarok. Look for that in fu­ture Valve games.

Custom is bet­ter

The Legend of California is an am­bi­tious pro­ject with a large open world and server au­thor­ity. Falling trees, rag­dolls, vox­els, sa­loon doors, and tum­ble­weeds are all sim­u­lated on the server. Having a cus­tom physics en­gine means I can tai­lor the fea­ture set and per­for­mance to the needs of our game.

For per­for­mance, I’ve done a lot of work to op­ti­mize for falling trees. We have huge red­wood trees that fall fast onto a voxel ter­rain. Getting the mesh col­li­sion and CCD work­ing well is a big ef­fort.

I’ve also worked on build­ing col­li­sion meshes fast for our voxel sys­tem, since they need to be built at run­time. They build well with me­dian split be­cause vox­els are grid-like.

Streaming is an­other crit­i­cal fea­ture. Our strong­holds are built us­ing kit­bash­ing. A large strong­hold can eas­ily have around 50,000 sep­a­rate col­li­sion meshes. Loading these into the physics en­gine one-by-one is in­ef­fi­cient and uses a lot of mem­ory. So I built a com­pound col­li­sion sys­tem where the sep­a­rate col­li­sion shapes are cooked into an op­ti­mized data struc­ture that can be loaded as a sin­gle uber shape. This re­moves the over­head of cre­at­ing thou­sands of bod­ies and shapes.

Reason 2: Sustaining knowl­edge (and san­ity)

On the per­sonal side, I have been mak­ing physics en­gines for games since 2004. Every time I change jobs, I need to leave that work be­hind. This is partly the rea­son I de­vel­oped Box2D. It is an open source pro­ject that cap­tures my knowl­edge and ef­forts so I can use it as the ba­sis for fu­ture work. However, on the 3D side I keep re-in­vent­ing the wheel in many ways. I’m not to­tally against that, but it is a big tax.

Somehow I con­vinced the fine folks at Kintsugiyama to al­low me to not only make Box3D open source, but also work on it as part of my day job. This means it is some­thing I can fea­si­bly sup­port. So every­one, please give a big thanks to Kintsugiyama for mak­ing Box3D pos­si­ble.

Why use Box3D?

This one is go­ing to be brief. If you like Box2D and its de­sign, then you’ll prob­a­bly like Box3D. They are sib­lings af­ter all.

Box3D is open source. I’m not try­ing to com­pete with other physics en­gines. Open source is not a busi­ness for me. I de­velop Box2D and Box3D be­cause I love work­ing on game physics. I’m de­lighted to see all the amaz­ing games cre­ated with Box2D over the years.

Getting started with Box3D

Install vanilla git and CMake, then clone the Box3D repos­i­tory. You can find the build in­struc­tions in the README. After you get a build, run the sam­ples and see the fea­tures it has to of­fer. Look at the sam­ple code to get started with cod­ing.

The en­gine head­ers have full Doxygen com­ments and the writ­ten man­ual is in progress. Here’s the hosted doc­u­men­ta­tion.

You can find min­i­mal ex­am­ple code in the HelloWorld test.

Who is us­ing Box3D?

Box3D is used in a few places al­ready. Besides The Legend of California, it’s used in:

s&box, a game plat­form by Facepunch Studios

Esoterica, an open source game en­gine led by Bobby Anguelov

A 1000-player space game, a mul­ti­player game by Glenn Fiedler

What is the fu­ture of Box3D?

Despite us­age in a few games now, I still con­sider Box3D to be al­pha soft­ware. I will soon tag v0.1 and build from there to the v1.0 re­lease. The en­gine needs more test­ing and more com­plete doc­u­men­ta­tion. However, the fea­ture set is in a good place al­ready. Here are some tasks I’m con­sid­er­ing:

Enhance the char­ac­ter move­ment fea­tures

Improved ghost col­li­sion mit­i­ga­tion

Optimizations

Improved joint solver

I ex­pect to sup­port Box3D in­def­i­nitely, along with Box2D. However, once it be­comes ma­ture, I may take a break from fea­ture work. Unlike Box2D, I ex­pect to open up Box3D to pull re­quests, prob­a­bly us­ing a CLA.

I plan to con­tinue blog­ging about Box3D and mak­ing videos. It should be fun!

I won’t be mak­ing a sep­a­rate web­site or Discord server for Box3D. So look for up­dates on this site and join the Box2D Discord server to chat with me and the com­mu­nity.

Following The Legend of California

If you want to see Box3D in our game, fol­low The Legend of California via the home page and Steam.

Supporting Box3D de­vel­op­ment

Sponsor Box3D on GitHub

Sponsor Box3D on Patreon

Thank you for your sup­port!

by Nicolas Hulscher, MPH

A newly pub­lished peer-re­viewed study in Gut Microbes has un­cov­ered a pre­vi­ously un­known can­cer-fight­ing bac­terium iso­lated from am­phib­ian and rep­tile gut mi­cro­bio­mes—de­liv­er­ing re­sults that ex­ceeded mod­ern on­col­ogy treat­ments.

In an im­muno­com­pe­tent mouse model of col­orec­tal can­cer, a sin­gle in­tra­venous dose of Ewingella amer­i­cana led to com­plete tu­mor elim­i­na­tion in 100% of treated an­i­mals, with no re­cur­rence upon re-ex­po­sure to can­cer cells—sug­gest­ing durable, long-term im­mune pro­tec­tion.

Even more strik­ing, the bac­terium out­per­formed both chemother­apy (doxorubicin, “red devil”) and im­mune check­point block­ade (anti–PD-L1)—two pil­lars of mod­ern can­cer ther­apy.

What makes this dis­cov­ery par­tic­u­larly com­pelling is the mech­a­nism. E. amer­i­cana is not a pas­sive drug—it is a liv­ing, tu­mor-tar­get­ing or­gan­ism. As a fac­ul­ta­tive anaer­obe, it pref­er­en­tially ac­cu­mu­lates within the hy­poxic tu­mor mi­croen­vi­ron­ment, where it rapidly pro­lif­er­ates and ex­erts di­rect cy­to­toxic ef­fects while si­mul­ta­ne­ously ac­ti­vat­ing a broad im­mune re­sponse. Within hours, tu­mors be­come in­fil­trated with T cells, B cells, and neu­trophils, ac­com­pa­nied by surges in key in­flam­ma­tory cy­tokines like TNF-α and IFN-γ.

Investigators ob­served ap­prox­i­mately a 3,000-fold in­crease in bac­te­r­ial load within tu­mors within 24 hours, in­di­cat­ing highly ef­fi­cient tu­mor hom­ing and in­tra­tu­moral ex­pan­sion. This dual-ac­tion ap­proach—di­rect tu­mor de­struc­tion com­bined with im­mune ac­ti­va­tion—dis­tin­guishes it fun­da­men­tally from con­ven­tional ther­a­pies, which typ­i­cally rely on a sin­gle mech­a­nism of ac­tion.

Equally no­table is the safety pro­file ob­served in this pre­clin­i­cal model. Despite in­tra­venous ad­min­is­tra­tion of live bac­te­ria, treated an­i­mals showed no sig­nif­i­cant weight loss, no de­tectable or­gan tox­i­c­ity, and no ab­nor­mal­i­ties in hema­to­logic or bio­chem­i­cal pa­ra­me­ters. The or­gan­ism was rapidly cleared from cir­cu­la­tion within 24 hours, while re­main­ing se­lec­tively lo­cal­ized within tu­mor tis­sue—an un­usual and highly fa­vor­able phar­ma­co­ki­netic pat­tern.

Importantly, this was not a ge­net­i­cally en­gi­neered con­struct. E. amer­i­cana is a nat­u­rally oc­cur­ring bac­terium, sug­gest­ing that vast, largely un­ex­plored mi­cro­bial ecosys­tems—par­tic­u­larly those of non-hu­man species—may har­bor pow­er­ful ther­a­peu­tic agents.

While these re­sults re­main pre­clin­i­cal and re­quire val­i­da­tion in hu­man tri­als, the sig­nal is dif­fi­cult to ig­nore. A sin­gle-dose in­ter­ven­tion achiev­ing com­plete tu­mor erad­i­ca­tion, durable im­mune mem­ory, and su­pe­ri­or­ity over es­tab­lished ther­a­pies rep­re­sents one of the most strik­ing out­comes re­ported in re­cent can­cer re­search.

Nicolas Hulscher, MPH

Epidemiologist and Foundation Administrator, McCullough Foundation

Support our mis­sion: mc­cul­loughfnd.org

Please con­sider fol­low­ing both the McCullough Foundation and my per­sonal ac­count on X (formerly Twitter) for fur­ther con­tent.

June 30, 2026

v1.5

An up­dated Lean 4 for­mal proof en­gi­neer­ing model op­ti­mised for au­to­mated the­o­rem prov­ing and aut­o­for­mal­iza­tion. 119B to­tal pa­ra­me­ters, 6.5B ac­tive.

Speed

Performance

Modalities

Context

256k

Price

$0

Speed

Performance

Modalities

Context

256k

Price

$0

Features

Chat Completions

Function Calling

Agents & Conversations

Built-In Tools

Structured Outputs

Predicted Outputs

Prefix

OCR

Annotations - Structured

BBox Extraction

Document QnA

FIM

Embeddings

Moderations

Chat Moderations

Transcriptions

Text to Speech

Timestamps

Batching