From the be­gin­ning, our goal has been to build tools that rad­i­cally change what it feels like to work with Python — tools that feel fast, ro­bust, in­tu­itive, and in­te­grated.

Today, we’re tak­ing a step for­ward in that mis­sion by an­nounc­ing that we’ve en­tered into an agree­ment to join OpenAI as part of the Codex

team.

Over the past few years, our tools have grown from zero to hun­dreds of mil­lions of down­loads per month across Ruff, uv, and

ty. The Astral tool­chain has be­come foun­da­tional to mod­ern Python de­vel­op­ment. The num­bers — and the im­pact — went far be­yond my most am­bi­tious ex­pec­ta­tions at every step of the way.

Open source is at the heart of that im­pact and the heart of that story; it sits at the cen­ter of every­thing we do. In line with our phi­los­o­phy and

OpenAI’s own an­nounce­ment, OpenAI will con­tinue sup­port­ing our open source tools af­ter the deal closes. We’ll keep build­ing in the open, along­side our com­mu­nity — and for the broader Python ecosys­tem — just as we have from the start.

I view build­ing tools as an in­cred­i­bly high-lever­age en­deavor. As I wrote in our

launch post three years ago: “If you could make the Python ecosys­tem even 1% more pro­duc­tive, imag­ine how that im­pact would com­pound?”

Today, AI is rapidly chang­ing the way we build soft­ware, and the pace of that change is only ac­cel­er­at­ing. If our goal is to make pro­gram­ming more pro­duc­tive, then build­ing at the fron­tier of AI and soft­ware feels like the high­est-lever­age thing we can do.

It is in­creas­ingly clear to me that Codex is that fron­tier. And by bring­ing Astral’s tool­ing and ex­per­tise to OpenAI, we’re putting our­selves in a po­si­tion to push it for­ward. After join­ing the Codex team, we’ll con­tinue build­ing our open source tools, ex­plore ways they can work more seam­lessly with Codex, and ex­pand our reach to think more broadly about the fu­ture of soft­ware de­vel­op­ment.

Through it all, though, our goal re­mains the same: to make pro­gram­ming more pro­duc­tive. To build tools that rad­i­cally change what it feels like to build soft­ware.

On a per­sonal note, I want to say thank you, first, to the Astral team, who have al­ways put our users first and shipped some of the most beloved soft­ware in the world. You’ve pushed me to be a bet­ter leader and a bet­ter pro­gram­mer. I am so ex­cited to keep build­ing with you.

Second, to our in­vestors, es­pe­cially

Casey Aylward from Accel, who led our Seed and Series A, and Jennifer Li from Andreessen Horowitz, who led our Series B. As a first-time, tech­ni­cal, solo founder, you showed far more be­lief in me than I ever showed in my­self, and I will never for­get that.

And third, to our users. Our tools ex­ist be­cause of you. Thank you for your trust. We won’t let you down.

The “advanced flow” will be avail­able be­fore ver­i­fi­ca­tion en­force­ment be­gins later this year.

Google is plan­ning big changes for Android in 2026 aimed at com­bat­ing mal­ware across the en­tire de­vice ecosys­tem. Starting in September, Google will be­gin re­strict­ing ap­pli­ca­tion side­load­ing with its de­vel­oper ver­i­fi­ca­tion pro­gram, but not every­one is on board. Android Ecosystem President Sameer Samat tells Ars that the com­pany has been lis­ten­ing to feed­back, and the re­sult is the newly un­veiled ad­vanced flow, which will al­low power users to skip app ver­i­fi­ca­tion.

With its new lim­its on side­load­ing, Android phones will only in­stall apps that come from ver­i­fied de­vel­op­ers. To ver­ify, devs re­leas­ing apps out­side of Google Play will have to pro­vide iden­ti­fi­ca­tion, up­load a copy of their sign­ing keys, and pay a $25 fee. It all seems rather oner­ous for peo­ple who just want to make apps with­out Google’s in­ter­ven­tion.

Apps that come from un­ver­i­fied de­vel­op­ers won’t be in­stal­lable on Android phones—un­less you use the new ad­vanced flow, which will be buried in the de­vel­oper set­tings.

When side­load­ing apps to­day, Android phones alert the user to the “unknown sources” tog­gle in the set­tings, and there’s a flow to help you turn it on. The ver­i­fi­ca­tion by­pass is dif­fer­ent and will not be re­vealed to users. You have to know where this is and proac­tively turn it on your­self, and it’s not a quick process. Here are the steps:

Enable de­vel­oper op­tions by tap­ping the soft­ware build num­ber in About Phone seven times

In Settings > System, open Developer Options and scroll down to “Allow Unverified Packages.”

Flip the tog­gle and tap to con­firm you are not be­ing co­erced

Return to the un­ver­i­fied pack­ages menu at the end of the se­cu­rity de­lay

Scroll past ad­di­tional warn­ings and se­lect ei­ther “Allow tem­porar­ily” (seven days) or “Allow in­def­i­nitely.”

Check the box con­firm­ing you un­der­stand the risks.

You can now in­stall un­ver­i­fied pack­ages on the de­vice by tap­ping the “Install any­way” op­tion in the pack­age man­ager.

The ac­tual leg­work to ac­ti­vate this fea­ture only takes a few sec­onds, but the 24-hour count­down makes it some­thing you can­not do spur of the mo­ment. But why 24 hours? According to Samat, this is de­signed to com­bat the ris­ing use of high-pres­sure so­cial en­gi­neer­ing at­tacks, in which the scam­mer con­vinces the vic­tim they have to in­stall an app im­me­di­ately to avoid se­vere con­se­quences.

You’ll have to wait 24 hours to by­pass ver­i­fi­ca­tion.

You’ll have to wait 24 hours to by­pass ver­i­fi­ca­tion.

“In that 24-hour pe­riod, we think it be­comes much harder for at­tack­ers to per­sist their at­tack,” said Samat. “In that time, you can prob­a­bly find out that your loved one is­n’t re­ally be­ing held in jail or that your bank ac­count is­n’t re­ally un­der at­tack.”

But for peo­ple who are sure they don’t want Google’s ver­i­fi­ca­tion sys­tem to get in the way of side­load­ing any old APK they come across, they don’t have to wait un­til they en­counter an un­ver­i­fied app to get started. You only have to se­lect the “indefinitely” op­tion once on a phone, and you can turn dev op­tions off again af­ter­ward.

According to Samat, Google feels a re­spon­si­bil­ity to Android users world­wide, and things are dif­fer­ent than they used to be with more than 3 bil­lion ac­tive de­vices out there.

“For a lot of peo­ple in the world, their phone is their only com­puter, and it stores some of their most pri­vate in­for­ma­tion,” Samat said. “Over the years, we’ve evolved the plat­form to keep it open while also keep­ing it safe. And I want to em­pha­size, if the plat­form is­n’t safe, peo­ple aren’t go­ing to use it, and that’s a lose-lose sit­u­a­tion for every­one, in­clud­ing de­vel­op­ers.”

But what does that safety look like? Google swears it’s not in­ter­ested in the con­tent of apps, and it won’t be check­ing proac­tively when de­vel­op­ers reg­is­ter. This is only about iden­tity ver­i­fi­ca­tion—you should know when you’re in­stalling an app that it’s not an im­poster and does not come from known pur­vey­ors of mal­ware. If a ver­i­fied de­vel­oper dis­trib­utes mal­ware, they’re un­likely to re­main ver­i­fied. And what is mal­ware? For Samat, mal­ware in the con­text of de­vel­oper ver­i­fi­ca­tion is an ap­pli­ca­tion pack­age that “causes harm to the user’s de­vice or per­sonal data that the user did not in­tend.”

So a rootkit can be mal­ware, but a rootkit you down­loaded in­ten­tion­ally be­cause you want root ac­cess on your phone is not mal­ware, from Samat’s per­spec­tive. Likewise, an al­ter­na­tive YouTube client that by­passes Google’s ads and fea­ture lim­its is­n’t caus­ing the kind of harm that would lead to is­sues with ver­i­fi­ca­tion. But these are just broad strokes; Google has not com­mented on any spe­cific apps.

Google says side­load­ing is­n’t go­ing away, but it is chang­ing.

Google says side­load­ing is­n’t go­ing away, but it is chang­ing.

Google is pro­ceed­ing cau­tiously with the ver­i­fi­ca­tion roll­out, and some de­tails are still spotty. Privacy ad­vo­cates have ex­pressed con­cern that ver­i­fi­ca­tion will cre­ate a data­base that puts in­de­pen­dent de­vel­op­ers at risk of le­gal ac­tion. Samat says that Google does push back on ju­di­cial or­ders for user data when they are im­proper. The com­pany fur­ther sug­gests it’s not in­tend­ing to cre­ate a per­ma­nent list of de­vel­oper iden­ti­ties that would be vul­ner­a­ble to le­gal de­mands. We’ve asked for more de­tail on what data Google re­tains from the ver­i­fi­ca­tion process and for what length of time.

There is also con­cern that de­vel­op­ers liv­ing in sanc­tioned na­tions might be un­able to ver­ify due to the re­quired fee. Google notes that the ver­i­fi­ca­tion process may vary across coun­tries and was not cre­ated specif­i­cally to bar de­vel­op­ers in places like Cuba or Iran. We’ve asked for de­tails on how Google will han­dle these edge cases and will up­date if we learn more.

Rolling out in 2026 and be­yond

Android users in most of the world don’t have to worry about de­vel­oper ver­i­fi­ca­tion yet, but that day is com­ing. In September, ver­i­fi­ca­tion en­force­ment will be­gin in Brazil, Singapore, Indonesia, and Thailand. Impersonation and guided scams are more com­mon in these re­gions, so Google is start­ing there be­fore ex­pand­ing ver­i­fi­ca­tion glob­ally next year. Google has stressed that the ad­vanced flow will be avail­able be­fore the ini­tial roll­out in September.

Google stands by its as­ser­tion that users are 50 times more likely to get mal­ware out­side Google Play than in it. A big part of the gap, Samat says, is Google’s de­ci­sion in 2023 to be­gin ver­i­fy­ing de­vel­oper iden­ti­ties in the Play Store. This pro­vided a frame­work for uni­ver­sal de­vel­oper ver­i­fi­ca­tion. While there are cer­tainly rea­sons Google might like the con­trol ver­i­fi­ca­tion gives it, the Android team has felt real pres­sure from reg­u­la­tors in ar­eas with mal­ware is­sues to ad­dress plat­form se­cu­rity.

“In a lot of coun­tries, there is chat­ter about if this is­n’t safer, then there may need to be reg­u­la­tory ac­tion to lock down more of this stuff,” Samat told Ars Technica. “I don’t think that it’s well un­der­stood that this is a real se­cu­rity con­cern in a num­ber of coun­tries.”

Google has al­ready started de­liv­er­ing the ver­i­fier to de­vices around the world—it’s in­te­grated with Android 16.1, which launched late in 2025. Eventually, the ver­i­fier and ad­vanced flow will be on all cur­rently sup­ported Android de­vices. However, the UI will be con­sis­tent, with Google pro­vid­ing all the com­po­nents and scare screens. So what you see here should be sim­i­lar to what ap­pears on your phone in a few months, re­gard­less of who made it.

Ryan Whitwam is a se­nior tech­nol­ogy re­porter at Ars Technica, cov­er­ing the ways Google, AI, and mo­bile tech­nol­ogy con­tinue to change the world. Over his 20-year ca­reer, he’s writ­ten for Android Police, ExtremeTech, Wirecutter, NY Times, and more. He has re­viewed more phones than most peo­ple will ever own. You can fol­low him on Bluesky, where you will see pho­tos of his dozens of me­chan­i­cal key­boards.

TCL’s German QLED ban puts pres­sure on TV brands to be more hon­est about QDs

Coal plant forced to stay open due to emer­gency or­der is­n’t even run­ning

After three months, Samsung is end­ing sales of the $2,899 Galaxy Z TriFold

There was an er­ror while load­ing. Please re­load this page.

Successfully merg­ing this pull re­quest may close these is­sues.

This file con­tains hid­den or bidi­rec­tional Unicode text that may be in­ter­preted or com­piled dif­fer­ently than what ap­pears be­low. To re­view, open the file in an ed­i­tor that re­veals hid­den Unicode char­ac­ters.

Learn more about bidi­rec­tional Unicode char­ac­ters

There was an er­ror while load­ing. Please re­load this page.

There was an er­ror while load­ing. Please re­load this page.

Successfully merg­ing this pull re­quest may close these is­sues.

This file con­tains hid­den or bidi­rec­tional Unicode text that may be in­ter­preted or com­piled dif­fer­ently than what ap­pears be­low. To re­view, open the file in an ed­i­tor that re­veals hid­den Unicode char­ac­ters.

Learn more about bidi­rec­tional Unicode char­ac­ters

There was an er­ror while load­ing. Please re­load this page.

Add this sug­ges­tion to a batch that can be ap­plied as a sin­gle com­mit.

This sug­ges­tion is in­valid be­cause no changes were made to the code.

Suggestions can­not be ap­plied while the pull re­quest is closed.

Suggestions can­not be ap­plied while view­ing a sub­set of changes.

Only one sug­ges­tion per line can be ap­plied in a batch.

Add this sug­ges­tion to a batch that can be ap­plied as a sin­gle com­mit.

Applying sug­ges­tions on deleted lines is not sup­ported.

You must change the ex­ist­ing code in this line in or­der to cre­ate a valid sug­ges­tion.

This sug­ges­tion has been ap­plied or marked re­solved.

Suggestions can­not be ap­plied from pend­ing re­views.

Suggestions can­not be ap­plied on multi-line com­ments.

Suggestions can­not be ap­plied while the pull re­quest is queued to merge.

Suggestion can­not be ap­plied right now. Please check back later.

“Companies — wher­ever they’re based — are not al­lowed to sell un­safe toys to chil­dren in the UK. And so­ci­ety has long pro­tected young­sters from things like al­co­hol, smok­ing and gam­bling. The dig­i­tal world should be no dif­fer­ent,” she said.

Skip to con­tent

You signed in with an­other tab or win­dow. Reload to re­fresh your ses­sion.

You signed out in an­other tab or win­dow. Reload to re­fresh your ses­sion.

You switched ac­counts on an­other tab or win­dow. Reload to re­fresh your ses­sion.

You must be signed in to star a gist

You must be signed in to fork a gist

Embed this gist in your web­site.

Save adamamyl/​81b78e­ced40feae50eae7c4f3bec1f5a to your com­puter and use it in GitHub Desktop.

Embed this gist in your web­site.

Save adamamyl/​81b78e­ced40feae50eae7c4f3bec1f5a to your com­puter and use it in GitHub Desktop.

Sign up for free

to join this con­ver­sa­tion on GitHub.

Already have an ac­count?

Sign in to com­ment

You can’t per­form that ac­tion at this time.

It may seem like the miles dri­ven by Waymo (in the 100’s of mil­lions of miles) pales in com­par­i­son to the bil­lions of miles dri­ven in the cities where Waymo dri­ves, or tril­lions of miles dri­ven an­nu­ally in the en­tire United States. When com­par­ing the rates of two pop­u­la­tions, how­ever, the con­clu­sions you can draw from data are gov­erned by what is called sta­tis­ti­cal power. The ques­tion be­ing an­swered by the Safety Impact Data Hub is are the Waymo and bench­mark crash rates dif­fer­ent? The in­put to this cal­cu­la­tion is the num­ber of crashes and the num­ber of miles dri­ven by Waymo and the bench­mark pop­u­la­tions and is mod­eled us­ing a Poisson dis­tri­b­u­tion, the most com­mon dis­tri­b­u­tion for han­dling count data.

An ex­am­ple of this prob­lem would be to ex­am­ine the num­ber of stu­dents that do not pass an exam. In a school dis­trict, say that 300 out of 1,000 stu­dents that take the same test do not pass (3 do not pass per 10 test­tak­ers). One could ask whether a Class A of 20 stu­dents per­formed dif­fer­ently than the over­all pop­u­la­tion on this test (note we are as­sum­ing pass­ing or not pass­ing the test is in­de­pen­dent of be­ing in Class A for the sake of this sim­pli­fied ex­am­ple). Say Class A had 10 out of 20 stu­dents that did not pass the exam (5 do not pass per 10 test tak­ers). Class A had a not pass rate that is dou­ble the rate of the school dis­trict. When we use a Poisson con­fi­dence in­ter­val, how­ever, the rate of not pass­ing in the class of 20 is not sta­tis­ti­cally dif­fer­ent from the school dis­trict av­er­age at the 95% con­fi­dence level. If we in­stead com­pare Class A to the en­tire state of 100,000 stu­dents (with the same 3 not pass per 10 test tak­ers rate, or 30,000 out of 100,000 to not pass), the 95% con­fi­dence in­ter­vals of this com­par­i­son are al­most iden­ti­cal to the com­par­i­son to the county (300 out of 1000 test tak­ers). This means that for this com­par­i­son, the un­cer­tainty in the small num­ber of ob­ser­va­tions in Class A (only 20 stu­dents) is much more than the un­cer­tainty in the larger pop­u­la­tion. Take an­other class, Class B, that had only 1 out of 20 stu­dents not pass the test (0.5 do not pass per 10 test tak­ers). When ap­ply­ing the 95% con­fi­dence in­ter­vals, this Class B does have a sta­tis­ti­cally dif­fer­ent pass rate from the county av­er­age (as well when com­pared to the state). This ex­am­ple shows that when com­par­ing rates of events in two pop­u­la­tions where one pop­u­la­tion is much larger than the other (measured by test tak­ers, or miles dri­ven), the two things that drive sta­tis­ti­cal sig­nif­i­cance are: (a) the num­ber of ob­ser­va­tions in the smaller pop­u­la­tion (more ob­ser­va­tions = sig­nif­i­cance sooner) and (b) big­ger dif­fer­ences in the rates of oc­cur­rence (bigger dif­fer­ence = sig­nif­i­cance sooner).

Now con­sider an­other ex­per­i­ment with Waymo data. Consider the fig­ure be­low that keeps the num­ber of Waymo airbag de­ploy­ment in any ve­hi­cle crashes (34) and VMT (71.1 mil­lion miles) con­stant while as­sum­ing dif­fer­ent or­ders of mag­ni­tude of miles dri­ven in the hu­man bench­mark pop­u­la­tion (benchmark rate of 1.649 in­ci­dents per mil­lion miles with 17.8 bil­lion miles trav­eled). The point es­ti­mate is that Waymo has 71% fewer of these crashes than the bench­mark. The con­fi­dence in­ter­vals (also some­times called er­ror bars) show un­cer­tainty for this re­duc­tion at a 95% con­fi­dence level (95% con­fi­dence is the stan­dard in most sta­tis­ti­cal test­ing). If the er­ror bars do not cross 0%, that means that from a sta­tis­ti­cal stand­point we are 95% con­fi­dent the re­sult is not due to chance, which we also re­fer to as sta­tis­ti­cal sig­nif­i­cance. This “simulation” shows the ef­fect on sta­tis­ti­cal sig­nif­i­cance when vary­ing the VMT of the bench­mark pop­u­la­tion. This com­par­i­son would be sta­tis­ti­cally sig­nif­i­cant even if the bench­mark pop­u­la­tion had fewer miles dri­ven than the Waymo pop­u­la­tion (10 mil­lion miles). Furthermore, as long as the hu­man bench­mark has more than 100 mil­lion miles, there is al­most no dis­cern­able dif­fer­ence in the con­fi­dence in­ter­vals of the com­par­i­son. This means that com­par­isons in large US cities (based on bil­lions of miles) are no dif­fer­ent from a sta­tis­ti­cal per­spec­tive than a com­par­i­son to the en­tire US an­nual dri­ving (trillions of miles). Like the school test ex­am­ple, Waymo has dri­ven enough miles (tens to hun­dred of mil­lions of miles) and the re­duc­tions are large enough (70%-90% re­duc­tions) that sta­tis­ti­cal sig­nif­i­cance can be achieved.

I wanted to pro­vide an up­date on the sit­u­a­tion with OpenTTD on Steam and GOG, and what the Atari re-re­lease of Transport Tycoon Deluxe means for OpenTTD. There has been a lot of spec­u­la­tion and, in some cases, mis­in­for­ma­tion spread about what has hap­pened. Our ini­tial an­nounce­ment per­haps did­n’t pro­vide as much de­tail as we could have, but I want to re­as­sure OpenTTD fans that we have not been “pressured” by Atari to make these changes.

Atari ap­proached us to ex­plain their plans for the Transport Tycoon Deluxe re-re­lease, and what it might mean for OpenTTD. They are keen to work with us, and hope that the new re­lease will be wel­comed by the com­mu­nity who have been play­ing OpenTTD for the past 20+ years. We dis­cussed these plans, and we un­der­stood that a com­pro­mise would be needed to bal­ance Atari’s com­mer­cial in­ter­ests (which of course they are en­ti­tled to pur­sue as the rights holder) against the avail­abil­ity of a free, well-de­vel­oped evo­lu­tion of the game. The de­ci­sion was made that ac­cess to OpenTTD on these plat­forms would be con­di­tional, for new play­ers, on pur­chas­ing Transport Tycoon Deluxe first, while re­tain­ing the abil­ity to down­load OpenTTD for free from our web site. Some have sug­gested that we should have cho­sen to re­move OpenTTD from Steam and GOG en­tirely, but that would have caused un­nec­es­sary dis­rup­tion to the many thou­sands of peo­ple cur­rently en­joy­ing the game on these plat­forms, and would have po­ten­tially pre­vented new play­ers from dis­cov­er­ing the game in fu­ture.

The OpenTTD pro­ject owes a lot - in­deed, it owes every­thing - to Transport Tycoon Deluxe and to Chris Sawyer. Without TTD, there would be no OpenTTD - it’s as sim­ple as that.

As I cov­ered in 2024, OpenTTD started off as a pretty much per­fect clone of TTD, and though the game has evolved al­most be­yond be­lief since 2004, it is still rooted in the fun­da­men­tals of Transport Tycoon Deluxe. Agreeing to col­lab­o­rate with Atari on their re-re­lease not only en­ables you to go back and play the orig­i­nal game as it was in 1995, but helps to en­sure OpenTTD re­mains a thriv­ing pro­ject for years to come.

Additionally, as part of the dis­cus­sions we held, Atari agreed to make a con­tri­bu­tion to­wards the run­ning costs of our server in­fra­struc­ture. We are also ex­tremely grate­ful for the many do­na­tions that have come in over the past few days from users - your sup­port will help keep our ser­vices go­ing, and it is deeply ap­pre­ci­ated.

I un­der­stand that these changes have pro­voked strong feel­ings in the com­mu­nity, but I feel it im­por­tant to em­pha­sise that Atari have worked col­lab­o­ra­tively with us, and that OpenTTD as a pro­ject re­tains its full in­de­pen­dence. Even af­ter read­ing this, you may still not agree with the choices that we’ve made, but I would please ask you to share your views re­spect­fully. The Transport Tycoon com­mu­nity has been a source of joy in my own life for well over a quar­ter of a cen­tury, and it would be fan­tas­tic for us to be able to con­tinue to en­joy these bril­liant games well into the fu­ture.

Wayland has been a broad mis­di­rec­tion and mis­al­lo­ca­tion of time and de­vel­oper re­sources at the ex­pense of users. With more mi­gra­tion from other op­er­at­ing sys­tems, the pres­sure to fix fun­da­men­tal prob­lems has be­come more promi­nent. After 17 years of de­vel­op­ment, now is a good time to re­flect on some of the larger promises that have been made around the de­vel­op­ment of Wayland as a re­place­ment for the X11 dis­play pro­to­col.

If you’re not in this space, hope­fully it will still be in­ter­est­ing as an en­gi­neer­ing post-mortem on tak­ing on new green­field pro­jects. Namely: What are the is­sues with what ex­ists, why can they not be fixed, what do we hope to achieve with a new pro­ject, and how long do we ex­pect it to take?

If you’re al­ready fa­mil­iar with X11 and Wayland feel free to skip to the next part.

For peo­ple not fa­mil­iar with Linux, here’s a quick run­down of the terms in this space, roughly in the or­der of high­est-level to low­est-level:

* Applications

These are the things you want to run

* These are the things you want to run

* Desktop Environment (DE)

This is what man­ages things like win­dow them­ing, no­ti­fi­ca­tions, task bars, etc.

* This is what man­ages things like win­dow them­ing, no­ti­fi­ca­tions, task bars, etc.

* Compositor

This is what lay­ers win­dows on top of each other and does an­i­ma­tions, graph­i­cal ef­fects, etc.

* This is what lay­ers win­dows on top of each other and does an­i­ma­tions, graph­i­cal ef­fects, etc.

* Display Server

This is the thing that man­ages the dis­play, it also ab­stracts away some of the hard­ware de­tails so all the above work on NVidia, AMD, Intel, etc.

* This is the thing that man­ages the dis­play, it also ab­stracts away some of the hard­ware de­tails so all the above work on NVidia, AMD, Intel, etc.

* Kernel / Operating System

The lower-layer thing that man­ages hard­ware re­sources, for us this is Linux

* The lower-layer thing that man­ages hard­ware re­sources, for us this is Linux

The above is not a com­plete list, but it’s enough to give some fram­ing for un­der­stand­ing that X11 is a fun­da­men­tal piece of most Linux en­vi­ron­ments.

X11 is cur­rently still the most com­mon pop­u­lar dis­play server in the Linux ecosys­tem. It was de­vel­oped in the mid-1980s and, as legacy pro­jects tend to do, has ac­cu­mu­lated func­tion­al­ity that makes it dif­fi­cult to main­tain, ac­cord­ing to the de­vel­op­ers.

So, in 2008, Kristian Høgsberg started the pro­ject that be­came known as Wayland. Wayland (in the­ory) re­places the dis­play server, as well as some parts of the com­pos­i­tor and desk­top en­vi­ron­ment with a sim­pler dis­play pro­to­col and ref­er­ence im­ple­men­ta­tion. The orig­i­nal con­ceit be­hind Wayland is to only im­ple­ment what is needed for a sim­ple Linux desk­top. The orig­i­nal im­ple­men­ta­tion was a lit­tle over 3,000 lines of code.

It’s 2026, and Wayland has reached a mar­ket share of around 40-50%, or closer to 50-60% de­pend­ing on your source. I would ar­gue a prod­uct that has taken 17 years to gain sub­stan­tial mar­ket­share has is­sues hin­der­ing adop­tion. Compare the de­vel­op­ment of Wayland to a sim­i­lar pro­ject for man­ag­ing au­dio: PipeWire. Within ~8 years, every al­ter­na­tive has been mostly re­placed. It’s been adopted as the de­fault in Ubuntu since 22.04, roughly 4 years af­ter it first launched!

These are the most com­mon is­sues I have seen from the per­spec­tive of a user, so I will try to stay light on what I con­sider to be mostly ir­rel­e­vant tech­ni­cal de­tails and in­stead fo­cus on larger is­sues around the roll­out and de­sign of Wayland.

The rea­son I use Linux and other Unix-likes is that they give me the abil­ity to do what­ever I want on my sys­tem, in­clud­ing mak­ing mis­takes! So why is my dis­play server telling me that cer­tain ap­pli­ca­tions that I in­stalled and chose to run aren’t al­lowed to talk to each other in the name of se­cu­rity?

There are mul­ti­ple cases of this: OBS can’t screen record (it seg­faults in­stead), I can’t copy-paste, and I can’t see win­dow pre­views un­less every­thing im­ple­ments a spe­cific ex­ten­sion to the core pro­to­col.

The ac­tual “threat model” here is baf­fling and does­n’t seem to re­flect a need for users. Applications are not able to see each oth­er’s win­dows, but they’re not able to in­ter­act in any other way that could po­ten­tially cause prob­lems?

I also don’t care for the “security” ar­gu­ment when parts of the core ref­er­ence im­ple­men­ta­tion are writ­ten in a mem­ory-un­safe lan­guage. To be clear, I am not say­ing that soft­ware writ­ten in C is bad, I’m specif­i­cally call­ing out that mak­ing a se­cu­rity arug­ment about soft­ware then re­peat­ing de­ci­sions of the pre­vi­ous (40-year-old) im­ple­men­ta­tion is a bad look.

Several of the de­sign de­ci­sions that Wayland makes are claimed in the name of per­for­mance. Namely, col­laps­ing many lay­ers is sup­posed to re­duce the num­ber of copies when mov­ing data be­tween dif­fer­ent com­po­nents.

However, what­ever the rea­son, these per­for­mance gains haven’t ma­te­ri­al­ized, or are so anec­do­tal in ei­ther di­rec­tion that it’s dif­fi­cult to claim a clear win over X11. In fact, you can find ex­am­ples show­ing roughly a 40% slow­down when us­ing Wayland over X11! I’m sure there are sim­i­lar bench­marks claim­ing Wayland wins and vice versa (happy to link them as well if pro­vided).

The prob­lem is that, even if Wayland was twice as fast, it does­n’t com­pare to im­prove­ments in hard­ware over the same pe­riod. It would’ve been bet­ter to just wait! The per­for­mance im­prove­ments would have to be much more sub­stan­tial for this to be a rea­son­able ar­gu­ment in fa­vor of Wayland. The fact that the ques­tion even ex­ists as to whether one or the other is faster af­ter a sub­stan­tial pe­riod is an ob­vi­ous fail­ure.

Additionally, those per­for­mance gains don’t mat­ter if I’m not able to make use of them. For ex­am­ple, if I’m us­ing the most pop­u­lar graph­ics card ven­dor in my sys­tem, I should­n’t ex­pect things to work out of the box.

One re­but­tal I’ve heard is that it’s not an is­sue with Wayland, it’s an is­sue with the com­pos­i­tor/​ex­ten­sion/​ap­pli­ca­tion. After all, “Wayland” is­n’t a piece of soft­ware, it’s a sim­ple pro­to­col that other soft­ware chooses to im­ple­ment!

Of course, what this means in prac­tice is that there are mul­ti­ple (usually in­com­pat­i­ble) im­ple­men­ta­tions of mul­ti­ple dif­fer­ent stan­dards. Maybe this would be fine if the con­cept of a desk­top op­er­at­ing sys­tem was com­pletely new and un­known, but users balk when dis­cov­er­ing things like drag and drop or screen shar­ing are not na­tively sup­ported and are es­sen­tially still in “beta” sta­tus.

Instead of pro­vid­ing a bet­ter way of do­ing some­thing, com­mon fea­tures are not sup­ported at all, and in­stead it’s the job of every­one else in the ecosys­tem to agree on a stan­dard. That’s not a stun­ning ar­gu­ment in fa­vor of re­plac­ing some­thing that al­ready ex­ists and that has al­ready been stan­dard­ized in X11!

Wayland has been around for only 17 years, while X11 has closer to 40 years of de­vel­op­ment be­hind it. Things are still un­der de­vel­op­ment and ob­vi­ously will get bet­ter, so why com­plain about is­sues that will in­evitably get fixed?

Because it’s been 17 years and peo­ple are still run­ning into ma­jor is­sues!

I was un­pleas­antly sur­prised when us­ing KDE Plasma that the de­fault dis­play server had been changed to Wayland. I no­ticed very quickly on startup when I en­coun­tered enough graph­i­cal hitches to re­al­ize I was run­ning Wayland and quickly switch back. Anecdotal ex­pe­ri­ence is not enough to say this is a broad is­sue, but my point is that when an av­er­age user en­coun­ters graph­i­cal is­sues within 60 sec­onds of us­ing it, maybe it’s not ready to be made the de­fault! It was only within the last 6 months that OBS stopped seg­fault­ing when try­ing to launch on Wayland. I as­sume I’m in de­cent com­pany when even the de­vel­oper of a ma­jor com­pos­i­tor is still not able to use Wayland in 2026.

The num­ber of “simple” util­i­ties that seem par­tially sup­ported or half-baked is in­cred­i­ble and seems to be a mas­sive du­pli­ca­tion of ef­fort. The tool­ing around X11 that has been de­vel­oped over the last 40 years seems to have been com­pletely dropped and no al­ter­na­tive has been pro­vided. Instead of pro­vid­ing an ob­vi­ous tran­si­tion path, Wayland has in­tro­duced even more frag­men­ta­tion.

Older soft­ware that has a ton of “legacy cruft” has been tested and bugs have long since been fixed. I fully be­lieve with an­other 20 years of de­vel­op­ment things will be bet­ter. The prob­lem is that I am be­ing forced to make the switch now. See: The push from KDE and RedHat to Wayland and drop­ping sup­port for older tech­nolo­gies.

This post prob­a­bly best en­cap­su­lates the de­vel­oper opin­ion to­wards users try­ing to mi­grate to the next it­er­a­tion of the Linux desk­top:

Maybe Wayland does­n’t work for your pre­cious use-case. More likely, it does work, and you swal­lowed some pro­pa­ganda based on an as­sump­tion which might have been cor­rect 7 years ago. Regardless, I sim­ply don’t give a shit about you any­more.

We’ve sac­ri­ficed our spare time to build this for you for free. If you turn around and ha­rass us based on some ut­terly non­sen­si­cal con­spir­acy the­o­ries, then you’re a fuck­ing ass­hole.

It’s even more ironic com­pared to the post made a week later, ex­press­ing the same frus­tra­tion with the Rust com­mu­nity that peo­ple have with Wayland!

Drew has since deleted this post, so I un­der­stand if he no longer stands by those opin­ions. However, it’s a rep­re­sen­ta­tive slice of de­vel­oper sen­ti­ment to­wards users that are now be­ing forced to use un­fin­ished soft­ware. Entitlement and bul­ly­ing of open-source main­tain­ers is not ap­pro­pri­ate, and it’s un­der­stand­able that the de­vel­op­ers lash out af­ter feel­ing beaten down by en­ti­tled users. However, to have some sym­pa­thy on the user side, it’s likely born out of frus­tra­tion of be­ing forced to use the new hot­ness and then en­coun­ter­ing break­ing bugs that are im­pos­si­ble for the av­er­age user to work around.

It is not the fault of the orig­i­nal de­vel­op­ers for build­ing what they wanted to build. I think it’s im­por­tant to keep in mind that they did­n’t nec­es­sar­ily choose for Wayland to be­come as pop­u­lar as it has or the foun­da­tion for the desk­top of the fu­ture. See the di­a­gram be­low:

Having Wayland as a de­vel­op­ers-only play­ground is fine! Have fun build­ing stuff! But the sec­ond ac­tual users are forced to use it ex­pect them to be frus­trated! At this point I con­sider Wayland to be a fun toy built en­tirely to pacify de­vel­op­ers tired of work­ing on a fin­ished legacy pro­ject.

Since most of this post has been over­whelm­ingly neg­a­tive against the de­vel­op­ment of Wayland, it’s in­stead bet­ter to learn as much as pos­si­ble and look for­ward to­wards “what would I want to be able to do”. Windowing tech­nol­ogy is ab­solutely not “done”, and in­stead of fol­low­ing other op­er­at­ing sys­tems, it would be fan­tas­tic if Linux could do things no other en­vi­ron­ment could do.

For ex­am­ple, be­ing able im­ple­ment non-rec­tan­gu­lar win­dows, ex­pos­ing con­text ac­tions (similar to MacOS), or mak­ing it eas­ier to au­to­mate or script parts of the desk­top en­vi­ron­ment would be in­cred­i­bly ex­cit­ing!

It’s dif­fi­cult to over­state the amount of progress in sup­port for gam­ing, new (and old) hard­ware, as well as the amount of over­all “polish”. Every de­vel­oper should be proud to be a part of that!

After 17 years, Wayland is still not ready for prime time. Notable break­age is be­ing doc­u­mented, and adop­tion has been cor­re­spond­ingly slow.

For some users the switch is seam­less. For oth­ers (including my­self), they tend to bounce off af­ter en­coun­ter­ing work­flow-break­ing is­sues. I think it’s ob­vi­ous at this point that the trade-offs have not been worth the has­sle.

My pre­dic­tion is that within the next 5 years the fol­low­ing will be true:

Projects will drop Wayland sup­port and go back to X11

There will be a new dis­play pro­to­col that dis­places both X11 and Wayland

The new dis­play pro­to­col will be a drop-in re­place­ment (similar to XWayland)

Fragmentation will still be an is­sue (this one’s a free­bie)

See you in 2030 for the year of the Linux Desktop.

Included are some of the links ref­er­enced in this post as well as some ad­di­tional read­ing.

Cockpit is an in­ter­ac­tive server ad­min in­ter­face. It is easy to use and very light­weight. Cockpit in­ter­acts di­rectly with the op­er­at­ing sys­tem from a real Linux ses­sion in a browser.

You can in­stall Cockpit on many Linux op­er­at­ing sys­tems in­clud­ing Debian, Fedora and RHEL.

Cockpit makes Linux dis­cov­er­able, al­low­ing sysad­mins to eas­ily per­form tasks such as start­ing con­tain­ers, stor­age ad­min­is­tra­tion, net­work con­fig­u­ra­tion, in­spect­ing logs and so on.

Jumping be­tween the ter­mi­nal and the web tool is no prob­lem. A ser­vice started via Cockpit can be stopped via the ter­mi­nal. Likewise, if an er­ror oc­curs in the ter­mi­nal, it can be seen in the Cockpit jour­nal in­ter­face.

You can also eas­ily add other ma­chines that have Cockpit in­stalled and are ac­ces­si­ble via SSH and jump be­tween these hosts.

Ross and Hugo Turner are ge­net­i­cally iden­ti­cal pro­fes­sional ad­ven­tur­ers. By dress­ing one in cut­ting-edge tech­ni­cal ap­parel and the other in 100-year-old her­itage kit on the world’s tough­est ex­pe­di­tions, they are con­duct­ing the ul­ti­mate A/B test on mod­ern gear.

On the vast, blind­ing ex­panse of the Greenland Ice Cap, two fig­ures strug­gle against the wind. To a dis­tant ob­server, it looks like a tear in the space-time con­tin­uum.

One fig­ure is a vi­sion of mod­ern moun­taineer­ing: clad in stream­lined, syn­thetic in­su­la­tion, wa­ter­proof mem­branes, and mod­ern plas­tic boots. The other looks like he just stepped out of a sepia-toned pho­to­graph from 1914: wrapped in heavy wool, gabar­dine cot­ton, and cum­ber­some leather boots treated with dub­bin.

They are strug­gling up the ice at the ex­act same pace. They share the same par­ents. They share 100% of their DNA. Ross and Hugo Turner—The Turner Twins—are pro­fes­sional ad­ven­tur­ers, but they are also liv­ing, breath­ing sci­en­tific in­stru­ments. In a world ob­sessed with the “cutting edge,” they’re us­ing their unique ge­netic mir­ror to ask a fun­da­men­tal ques­tion about ad­ven­ture gear: ex­actly how far has a cen­tury of tex­tile in­no­va­tion taken us? And what have we per­haps for­got­ten?

Their find­ings are enough to make any ad­ven­turer re­think their en­tire lay­er­ing sys­tem.

The Turner Twins’ tra­jec­tory into the world of high-stakes ex­plo­ration was­n’t born from a child­hood ob­ses­sion with Everest; it spawned from a near-tragedy.

At age 17, just prior to their 18th birth­day, Hugo dove into the sea and hit a sand­bank. He frac­tured his C7 ver­te­bra. In a week where eight other peo­ple were ad­mit­ted to the same hos­pi­tal with sim­i­lar in­juries, Hugo was the only one to walk out. The prox­im­ity to per­ma­nent paral­y­sis was a pro­found wake-up call.

“We had a midlife cri­sis at 17,” Ross ex­plains. “Life got put in per­spec­tive.”

They needed to live and test their lim­its. They started by row­ing the Atlantic to raise funds for Spinal Research, a UK-based char­ity they’ve worked with for years. But the real epiphany came on a London tube train years later, read­ing about the cen­te­nary of Ernest Shackleton’s Imperial Trans-Antarctic Expedition. They looked at the grayed pho­tos of men in tweed on the ice and won­dered: How did they sur­vive?

They re­al­ized they pos­sessed the ul­ti­mate sci­en­tific tool: a per­fect con­trol sub­ject and a per­fect vari­able. If they went on an ex­pe­di­tion, and Ross wore mod­ern kit while Hugo wore his­toric repli­cas, any dif­fer­ence in per­for­mance—be it core tem­per­a­ture, calo­rie burn, or cog­ni­tive func­tion—could be at­trib­uted solely to the gear, not ge­net­ics.

Now, here’s the fun bit for gear geeks like us: it’s not cos­play; it’s rig­or­ous his­tor­i­cal re­con­struc­tion. “There’s no point in say­ing, ’Oh, it looks cor­rect,’” Hugo says. “If it’s just an ad­ven­ture in tra­di­tional dress, it’s not a proper test.”

To en­sure gen­uine data, they dive deep into the archives of carry his­tory. Their rule is strict: ma­te­ri­als must be 100% nat­ural—wool, silk, cot­ton, fur, and leather.

The process of recre­at­ing this kit is a mon­u­men­tal chal­lenge in sup­ply chain ar­chae­ol­ogy. They track down the orig­i­nal man­u­fac­tur­ers, many of whom are still op­er­at­ing as her­itage brands in the UK, and con­vince them to restart pro­duc­tion lines that have been dor­mant for decades.

A prime ex­am­ple is the footwear. For a re­cent ex­pe­di­tion recre­at­ing George Mallory’s 1924 Everest at­tempt, they part­nered with Crockett & Jones in Northampton, the ac­tual man­u­fac­turer of Shackleton’s boots.

“Their com­mer­cial boot, the Snowdon, was the ba­sis for the first Mallory boot,” Ross de­tails. But early tests on Mt. Elbrus proved dis­as­trous; the boots weren’t warm enough for high al­ti­tude. The re­design process was ag­o­niz­ingly com­plex, in­volv­ing 18 months of pro­to­typ­ing.

Crockett & Jones had to stop their mod­ern pro­duc­tion line just to build these pro­to­types. The fi­nal prod­uct was a mas­ter­piece of for­got­ten tech­nol­ogy—a lit­eral “sandwich” for the feet. It fea­tured a leather in­ner boot, to­tally cov­ered by a thick layer of yurt felt wool, then en­cased in yet an­other leather outer boot, all sit­ting on a mas­sive rub­ber mid­sole for in­su­la­tion.

“The Mallory shoe went through 40 pairs of hands do­ing lit­tle tech­ni­cal de­tails,” Ross says. “It was an enor­mous un­der­tak­ing be­cause boots like that nowa­days sim­ply aren’t made.”

While one twin is dressed like a 1920s gen­tle­man ex­plorer, both are wired up with tech­nol­ogy that would make NASA jeal­ous.

Gone are the days of lug­ging heavy ma­chin­ery up moun­tains. Today, their bio­met­rics are tracked by in­gestible sen­sor pills that mon­i­tor core tem­per­a­ture from the in­side out, patches that an­a­lyze sweat com­po­si­tion, and smart­phone-con­nected hy­grom­e­ters taped to their skin to mea­sure mois­ture buildup un­der lay­ers.

“We are tak­ing tech­nol­ogy way out­side its com­fort zone,” Ross notes. They re­cently adapted pe­di­atric ther­mome­ter patches—meant to track a baby’s fever via an app—hack­ing the soft­ware to reg­is­ter tem­per­a­tures from 0 to 50 de­grees Celsius to cre­ate ther­mal maps of their bod­ies dur­ing climbs.

They mea­sure cog­ni­tive de­cline in hy­poxia, gut mi­cro­biome changes un­der stress, and pre­cise meta­bolic rates. It’s this hard data that sep­a­rates their work from mere nos­tal­gia.

So, what hap­pens when you pit 1924 against 2024? The re­sults con­front the very foun­da­tion of the mod­ern out­door in­dus­try’s mar­ket­ing ma­chine.

The as­sump­tion is that a cen­tury of GORE-TEX, PrimaLoft, and rip­stop ny­lon has ex­po­nen­tially in­creased our safety and warmth. The Twins’ data sug­gests the gap is much nar­rower than we think.

During their sim­u­la­tion of Mallory’s Everest ex­pe­di­tion, the data showed that on sum­mit night, the av­er­age body tem­per­a­ture dif­fer­ence be­tween the twin in mod­ern down and the twin in com­pli­cated lay­ers of silk, wool, and gabar­dine was a stag­ger­ing 1.8°C.

Furthermore, they found that nat­ural ma­te­ri­als man­aged mois­ture in ways mod­ern syn­thet­ics strug­gle to repli­cate. While trekking across Greenland, the twin in the woollen jumper was­n’t clammy.

“There’s so much air in be­tween the ca­ble knit,” Ross de­scribes. “Your back be­comes just a huge field of frost. We just wipe it down and the air kind of wicks off the back. That mois­ture is gone.”

The his­toric gear worked spec­tac­u­larly well, but it came with a caveat: it re­quired im­mense skill to op­er­ate.

The true take­away from the Turner Twins’ ex­per­i­ments is­n’t that we should all burn our tech­ni­cal shells and start wear­ing tweed. It’s that tech­nol­ogy has made us lazy with our mi­cro-cli­mate reg­u­la­tion.

Modern gear al­lows for a “set and for­get” men­tal­ity—one big zip to reg­u­late tem­per­a­ture from -20°C to 0°C. The old ex­plor­ers, by con­trast, were mas­ters of ac­tive man­age­ment.

They an­a­lyzed Mallory’s lay­er­ing sys­tem and found ge­nius in its com­plex­ity. He wore six lay­ers on his torso. He placed a silk shirt over a wool jumper, trap­ping air in a way that mim­ic­ked the loft of mod­ern down.

“They were ex­tremely well-in­formed and ed­u­cated about how their kit worked,” Ross ar­gues. “They knew ex­actly what they were do­ing.”

The data proves that the gear of the past is ca­pa­ble, but it has a nar­rower op­er­at­ing win­dow. If you stop mov­ing in Mallory’s kit at 8,000 me­ters, you will freeze quickly. Modern gear buys you a safety mar­gin if you be­come sta­tic.

For the Twins, the ul­ti­mate les­son for any mod­ern ad­ven­turer is to re­claim that lost knowl­edge. “Find your own lim­i­ta­tions with the kit you have,” Ross ad­vises. “A lot of peo­ple go on pro­jects and pack way too much be­cause they think, ‘I need tech­ni­cal item X, Y, and Z.’ Understanding that old-school men­tal­ity of what you ac­tu­ally need is prob­a­bly more ef­fi­cient.”

The Turner Twins are prov­ing that while pro­tec­tive gear has evolved, the hu­man en­gine has­n’t. The most cru­cial piece of carry is­n’t some­thing you can buy; it’s the knowl­edge of how to use what you have, whether it was made last year, or a cen­tury ago.

You can fol­low the Turner Twins’ ad­ven­tures here.