10 interesting stories served every morning and every evening.




1 1,389 shares, 50 trendiness

Astral to join OpenAI

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.

...

Read the original on astral.sh »

2 908 shares, 48 trendiness

Google details new 24-hour process to sideload unverified Android apps

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.

TCLs 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

...

Read the original on arstechnica.com »

3 443 shares, 16 trendiness

anthropic legal requests by thdxr · Pull Request #18186 · anomalyco/opencode

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.

...

Read the original on github.com »

4 395 shares, 19 trendiness

4Chan responds to £520,000 Ofcom fine with AI picture of hamster

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.

...

Read the original on www.bbc.com »

5 358 shares, 13 trendiness

macOS 26 breaks /etc/resolver/ supplemental DNS for custom TLDs

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.

...

Read the original on gist.github.com »

6 326 shares, 14 trendiness

Safety Impact

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.

...

Read the original on waymo.com »

7 325 shares, 14 trendiness

An update on Steam / GOG changes for OpenTTD

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.

...

Read the original on www.openttd.org »

8 278 shares, 21 trendiness

Wayland set the Linux Desktop back by 10 years

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.

...

Read the original on omar.yt »

9 273 shares, 16 trendiness

cockpit-project/cockpit: Cockpit is a web-based graphical interface for servers.

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.

...

Read the original on github.com »

10 256 shares, 16 trendiness

How the Turner Twins Are Mythbusting Modern Gear

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.

...

Read the original on www.carryology.com »

To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".

10HN is also available as an iOS App

If you visit 10HN only rarely, check out the the best articles from the past week.

If you like 10HN please leave feedback and share

Visit pancik.com for more.