10 interesting stories served every morning and every evening.

Go 1.27 interactive tour

victoriametrics.com

Go 1.27 is com­ing soon, so it’s a good time to get a head start on what’s new. The of­fi­cial re­lease notes are pretty dry, so here’s a hands-on ver­sion with runnable ex­am­ples show­ing what changed and how the new be­hav­ior works.

A quick credit first: the in­ter­ac­tive Go tours were started by Anton Zhiyanov, who wrote one for every re­lease from Go 1.22 through Go 1.26. He’s de­cided to stop, so we’re pick­ing up where he left off. His ear­lier tours are all still worth a read:

Go 1.22 in­ter­ac­tive tour

Go 1.23 in­ter­ac­tive tour

Go 1.24 in­ter­ac­tive tour

Go 1.25 in­ter­ac­tive tour

Go 1.26 in­ter­ac­tive tour

Thanks, Anton.

Before we start dig­ging into the new fea­tures, let’s set the con­text.

This ar­ti­cle is based on the of­fi­cial re­lease notes and the Go source code, li­censed un­der the BSD-3-Clause. This is not an ex­haus­tive list; see the of­fi­cial re­lease notes for that.

Links point to the doc­u­men­ta­tion (𝗗), pro­pos­als (𝗣), most rel­e­vant com­mits (𝗖𝗟), and au­thors (𝗔) for each fea­ture; check them out for mo­ti­va­tion, us­age, and im­ple­men­ta­tion de­tails. The au­thors (𝗔) are the peo­ple who con­tributed to the fea­ture (writing the im­ple­men­ta­tion, the tests, or, for fea­tures that grad­u­ated from an ear­lier ex­per­i­ment, the orig­i­nal de­sign), not nec­es­sar­ily a sin­gle main au­thor.

Error han­dling is of­ten skipped to keep the ex­am­ples short. Don’t do this in pro­duc­tion ツ

Generic meth­ods

#

This is the head­line of the re­lease. A method de­c­la­ra­tion may now de­clare its own type pa­ra­me­ters, in­de­pen­dent of the re­ceiver’s. Before Go 1.27, only top-level func­tions could be generic, so a generic op­er­a­tion on a type had to live as a pack­age-level func­tion in­stead of a method.

Say we have a generic con­tainer and want a Map op­er­a­tion that can change the el­e­ment type:

type Box[T any] struct{ v T }

// The method de­clares its own type pa­ra­me­ter U (new in Go 1.27). func (b Box[T]) Map[U any](f func(T) U) Box[U] { re­turn Box[U]{v: f(b.v)} }

Now Map is a method of Box and can trans­form an int box into a string box:

func main() { b := Box[int]{v: 21} dou­bled := b.Map(func(n int) int { re­turn n * 2 }) la­bel := dou­bled.Map(func(n int) string { re­turn fmt.Sprintf(“value=%d”, n) }) fmt.Println(la­bel.v) }

value=42

There is one im­por­tant re­stric­tion: in­ter­faces still can’t de­clare type-pa­ra­me­ter­ized meth­ods, and a generic method can’t be used to sat­isfy an in­ter­face. Put a generic method in an in­ter­face and the com­piler stops you:

type Mapper in­ter­face { Map[U any](f func(int) U) any // in­ter­faces can’t de­clare generic meth­ods }

in­ter­face method must have no type pa­ra­me­ters

𝗗 Generic meth­ods

𝗣 77273

𝗖𝗟 524b860, e84­da04, e212a16

𝗔 Robert Griesemer, Mark Freeman

Struct lit­eral field se­lec­tors

#

A key in a struct lit­eral may now be any valid field se­lec­tor for the struct type, not just a top-level field name. In prac­tice this means you can set a pro­moted field (one that comes from an em­bed­ded struct) di­rectly, with­out spelling out the em­bed­ded type.

type Base struct { ID int }

type User struct { Base Name string }

Before Go 1.27 you had to write User{Base: Base{ID: 7}, Name: Mittens”}. Now the pro­moted ID works as a key on its own:

u := User{ID: 7, Name: Mittens”} fmt.Println(u.ID, u.Name)

7 Mittens

𝗗 Composite lit­er­als

𝗣 9859

𝗖𝗟 1a8f9d8, 9f7e98d, 30bfe53, e2c1885

𝗔 Robert Griesemer, Cherry Mui

Generalized func­tion type in­fer­ence

#

Function type in­fer­ence has been gen­er­al­ized to ap­ply in all con­texts where a generic func­tion is used where a match­ing func­tion type is ex­pected: not just plain as­sign­ment to a vari­able (which al­ready worked), but also con­ver­sions and com­pos­ite lit­er­als. In those cases you pre­vi­ously had to spell out the type ar­gu­ments by hand.

Take two generic helpers and drop them into a slice whose el­e­ment type is func([]int) int:

func first[T any](s []T) T { re­turn s[0] } func last[T any](s []T) T { re­turn s[len(s)-1] }

// The slice’s el­e­ment type dri­ves in­fer­ence: T=int for each en­try. // Before Go 1.27 this failed with cannot use generic func­tion // with­out in­stan­ti­a­tion”; you had to write first[int], last[int]. ops := []func([]int) int{first, last} for _, op := range ops { fmt.Println(op([]int{10, 20, 30})) }

10 30

𝗗 Assignability

𝗣 77245

𝗖𝗟 ef06728, f757de8

𝗔 Robert Griesemer, Mark Freeman

Faster mem­ory al­lo­ca­tion

#

The com­piler now gen­er­ates calls to size-spe­cial­ized mem­ory al­lo­ca­tion rou­tines, cut­ting the cost of some small (under 80 bytes) al­lo­ca­tions by up to 30%. Improvements vary with the work­load, but the over­all gain is ex­pected to be around 1% in real al­lo­ca­tion-heavy pro­grams. The trade­off is about 60 KB of ex­tra bi­nary size, in­de­pen­dent of the work­load.

There’s noth­ing to change in your code; it just gets a lit­tle faster. If you need to turn it off, build with GOEXPERIMENT=nosizespecializedmalloc. That opt-out is ex­pected to be re­moved in Go 1.28.

𝗗 Runtime re­lease notes

𝗣 79286

𝗖𝗟 2a93576

𝗔 Michael Matloob

Goroutine la­bels in trace­backs

#

For mod­ules whose go.mod sets Go 1.27 or later, trace­backs now in­clude run­time/​pprof gor­ou­tine la­bels in the header line of each gor­ou­tine. If you al­ready at­tach la­bels for pro­fil­ing with pprof.Do, that con­text now shows up in crash dumps, SIGQUIT traces, and run­time.Stack out­put too (handy for telling apart oth­er­wise iden­ti­cal gor­ou­tines).

Here we at­tach a la­bel, then dump the cur­rent gor­ou­tine’s stack to see it in ac­tion:

ctx := con­text.Back­ground() pprof.Do(ctx, pprof.La­bels(“re­quest”, 42″), func(ctx con­text.Con­text) { buf := make([]byte, 1<<12) n := run­time.Stack(buf, false) fmt.Printf(“%s”, buf[:n]) })

gor­ou­tine 1 [running] {request: 42}: main.main.func1(…) …/main.go:14 +0x38 run­time/​pprof.Do(…) …/runtime/pprof/runtime.go:57 +0x8c main.main() …/main.go:12 +0x6c

The pointer ar­gu­ments, off­sets, and file paths dif­fer from run to run; what’s new is the {request: 42} ap­pended right af­ter the gor­ou­tine’s [running] state: its pprof la­bels. That same {…} an­no­ta­tion ap­pears on the header of every la­beled gor­ou­tine in a panic or SIGQUIT trace­back. You can dis­able it with GODEBUG=tracebacklabels=0 (the set­ting was added in Go 1.26). The opt-out is ex­pected to stay in­def­i­nitely, in case la­bels carry sen­si­tive data you don’t want in trace­backs.

𝗗 run­time/​pprof

𝗣 76349

𝗖𝗟 3694f33, 19c994c

𝗔 David Finkel

Goroutine leak pro­file

#

Go 1.26 in­tro­duced a gor­ou­tine leak de­tec­tor as an ex­per­i­ment. In Go 1.27 it grad­u­ates to a reg­u­lar pro­file: run­time/​pprof ex­poses a gor­ou­tine­leak pro­file that runs a GC cy­cle to find gor­ou­tines that are per­ma­nently blocked (leaked) and re­ports their stacks; no GOEXPERIMENT needed any­more.

A leaked” gor­ou­tine is one blocked for­ever on a chan­nel, mu­tex, or sim­i­lar, with no way to ever make progress. The clas­sic ex­am­ple is a gor­ou­tine that sends to a chan­nel it alone holds, so no­body can ever re­ceive from it:

func leak() { ch := make(chan int) // only this gor­ou­tine ever sees ch ch <- 1 // blocks for­ever: no­body will ever re­ceive }

Start one, let it park, then dump the pro­file:

go leak() // this gor­ou­tine can never fin­ish

run­time.Gosched() // let it park on the send

// The GC-backed scan finds gor­ou­tines that can never make progress. pprof.Lookup(“gor­ou­tine­leak”).WriteTo(os.Std­out, 1)

gor­ou­tine­leak pro­file: to­tal 1 1 @ 0x… 0x… 0x… 0x… 0x… # 0x… main.leak+0x27 …/main.go:11

The to­tal 1 line says the de­tec­tor found ex­actly one leaked gor­ou­tine, and the stack pins it to main.leak: the ch <- 1 send that will never com­plete (the ad­dresses vary from run to run). In a real ser­vice you’d usu­ally scrape the /debug/pprof/goroutineleak net/​http/​pprof end­point in­stead of writ­ing to std­out.

𝗗 run­time/​pprof

𝗣 74609

𝗖𝗟 253aa2a, 1644917, afcf04c

𝗔 Vlad Saioc, Austin Clements, Cherry Mui

Post-quantum sig­na­tures

#

The new crypto/​mldsa pack­age im­ple­ments ML-DSA, the post-quan­tum dig­i­tal sig­na­ture scheme spec­i­fied in FIPS 204. It comes in three pa­ra­me­ter sets (MLDSA44, MLDSA65, and MLDSA87), trad­ing key/​sig­na­ture size for se­cu­rity level.

priv, _ := mldsa.Gen­er­ateKey(mldsa.MLD­SA65())

msg := []byte(“victoria met­rics”) sig, _ := priv.Sign(rand.Reader, msg, crypto.Hash(0))

fmt.Println(“scheme: , mldsa.MLD­SA65()) fmt.Println(“sig size:”, mldsa.MLD­SA65().Sig­na­ture­Size()) fmt.Println(“ver­i­fied:”, mldsa.Ver­ify(priv.Pub­licKey(), msg, sig, nil) == nil)

scheme: ML-DSA-65 sig size: 3309 ver­i­fied: true

ML-DSA sup­port also reaches crypto/​x509 (private keys, pub­lic keys, and sig­na­tures) and crypto/​tls (the new MLDSA44, MLDSA65, and MLDSA87 sig­na­ture schemes in TLS 1.3).

𝗗 crypto/​mldsa

𝗣 77626

𝗖𝗟 7bc111c

𝗔 Filippo Valsorda, Daniel McCarney

The uuid pack­age

#

Go fi­nally has a UUID pack­age in the stan­dard li­brary. The new top-level uuid pack­age gen­er­ates and parses UUIDs per RFC 9562, us­ing a cryp­to­graph­i­cally se­cure ran­dom source. Random-component UUIDs are com­pa­ra­ble, so you can use == on them di­rectly.

Wikipedia:Wikipedia Signpost/2026-08-02/News and notes - Wikipedia

en.wikipedia.org

From Wikipedia, the free en­cy­clo­pe­dia

News and notes

Foundation re­jects vol­un­tary recog­ni­tion of union, pro­posed board el­i­gi­bil­ity rules sharply re­strict can­di­dates

Share this

Wikimedia Foundation re­fuses vol­un­tary union recog­ni­tion, hires union-bust­ing law firm

On July 20, Wiki Workers United U.S. de­manded vol­un­tary recog­ni­tion as a union from the Wikimedia Foundation, fol­low­ing a sim­i­lar re­quest for vol­un­tary recog­ni­tion made by WWU-UK, the UK branch of WWU, in June. The re­quest by Wiki Workers United U.S. de­manded a re­sponse from the Wikimedia Foundation by Friday, July 24, i.e. dur­ing the Wikimania con­fer­ence. No re­sponse was re­ceived by that date, though the topic of Wikimedia staffers union­iz­ing was dis­cussed at the con­fer­ence (see video on the right).

On July 27, the WMF pub­lished a state­ment de­clin­ing vol­un­tary recog­ni­tion of Wiki Workers United U.S.

The state­ment said:

[W]e be­lieve a se­cret-bal­lot elec­tion con­ducted by the National Labor Relations Board is the ap­pro­pri­ate path for­ward. This process pro­tects in­di­vid­ual choice and en­sures that any out­come re­flects the col­lec­tive will of those el­i­gi­ble to par­tic­i­pate.

[W]e be­lieve a se­cret-bal­lot elec­tion con­ducted by the National Labor Relations Board is the ap­pro­pri­ate path for­ward. This process pro­tects in­di­vid­ual choice and en­sures that any out­come re­flects the col­lec­tive will of those el­i­gi­ble to par­tic­i­pate.

The com­mu­nity re­sponse to the WMF state­ment has mostly been one of dis­may, with fears that the Foundation will use the time gap be­tween now and the se­cret bal­lot to dis­cour­age em­ploy­ees from union in­volve­ment, us­ing union bust­ing meth­ods as de­scribed hu­mor­ously in an episode of Last Week Tonight with John Oliver. A com­mu­nity pe­ti­tion to the WMF Board to rec­og­nize the union has been started on Meta-Wiki; as we were get­ting ready to pub­lish this is­sue, it had passed 150 sig­na­tures. Two prior com­mu­nity pe­ti­tions in sup­port of the union, started in May 2026 on Meta-Wiki and on English Wikipedia, have at­tracted well over 1,200 sig­na­tures each.

Jimmy Wales said on the Wikimedia-l mail­ing list that he had looked into the process fol­lowed by WWU, which had re­sulted in a su­per­ma­jor­ity of em­ploy­ees sign­ing a union card, and thought it im­per­fect:

One of the prob­lems with the process so far is that it was not se­cret and we have heard from some staff mem­bers that they felt pres­sured be­cause the or­ga­niz­ers would know how they de­cided. That is­n’t a great process and it goes against our move­men­t’s val­ues quite badly to have peo­ple in a sit­u­a­tion where they are pres­sured into some­thing one way or the other. It’s pretty easy to see the prob­lem if we imag­ine it in the other di­rec­tion - imag­ine some com­pany ask­ing staff to sign pledge cards not to join a union, and keep­ing track of who did or did­n’t in or­der to put pres­sure on those who did­n’t. Gross. It does­n’t make it bet­ter for it to be the other way around in my own per­sonal view. I want a process where staff are safe to de­lib­er­ate in the pri­vacy of their own minds and make the de­ci­sion based on all the avail­able ev­i­dence that makes the most sense to them. So I don’t think in­sist­ing on a proper vote is process for the sake of process and I say that with my own es­ti­mate that the staff will vote to sup­port union­iza­tion. I think we’ll be in a bet­ter place if it’s re­ally clear - a clean and clear choice with no chance of pres­sure. In terms of time, en­ergy, and money - I don’t think it should take very long and again speak­ing only for my­self I hope we get it done as quickly and ef­fi­ciently as we can and I hope that every­one - staff, man­age­ment, board, and com­mu­nity can come to­gether to cel­e­brate the out­come. I know I will.

One of the prob­lems with the process so far is that it was not se­cret and we have heard from some staff mem­bers that they felt pres­sured be­cause the or­ga­niz­ers would know how they de­cided. That is­n’t a great process and it goes against our move­men­t’s val­ues quite badly to have peo­ple in a sit­u­a­tion where they are pres­sured into some­thing one way or the other.

It’s pretty easy to see the prob­lem if we imag­ine it in the other di­rec­tion - imag­ine some com­pany ask­ing staff to sign pledge cards not to join a union, and keep­ing track of who did or did­n’t in or­der to put pres­sure on those who did­n’t. Gross. It does­n’t make it bet­ter for it to be the other way around in my own per­sonal view.

I want a process where staff are safe to de­lib­er­ate in the pri­vacy of their own minds and make the de­ci­sion based on all the avail­able ev­i­dence that makes the most sense to them. So I don’t think in­sist­ing on a proper vote is process for the sake of process and I say that with my own es­ti­mate that the staff will vote to sup­port union­iza­tion. I think we’ll be in a bet­ter place if it’s re­ally clear - a clean and clear choice with no chance of pres­sure.

In terms of time, en­ergy, and money - I don’t think it should take very long and again speak­ing only for my­self I hope we get it done as quickly and ef­fi­ciently as we can and I hope that every­one - staff, man­age­ment, board, and com­mu­nity can come to­gether to cel­e­brate the out­come. I know I will.

WWU an­nounced on 28 July that they would file for a union elec­tion with the National Labor Relations Board. The an­nounce­ment also ac­cused the Wikimedia Foundation of be­ing disin­gen­u­ous in their pub­lic com­mu­ni­ca­tions:

Thousands of work­ers across the tech and non­profit sec­tors have achieved vol­un­tary recog­ni­tion through this card check” method. Our de­mand of the Wikimedia Foundation was sim­ply that they live up to their val­ues and be the high-road em­ployer that they pur­port to be. They re­fused. While the Wikimedia Foundation touts to the pub­lic that they plan to take a neu­tral stance in our or­ga­niz­ing ef­forts, they have al­ready proven that not to be the case be­hind the scenes. When the Foundation re­jected our re­quest for vol­un­tary recog­ni­tion this week, they im­me­di­ately sent out to em­ploy­ees and the pub­lic state­ments couched in clas­sic union-bust­ing rhetoric, rhetoric un­doubt­edly pro­vided by out­ra­geously ex­pen­sive union-avoid­ance law firms. This in­sult­ing and waste­ful use of Foundation re­sources is both an in­sult to Foundation em­ploy­ees and to the Free Knowledge Movement as a whole. Insisting that our right to or­ga­nize be ad­ju­di­cated by the National Labor Relations Board is not a neu­tral choice; it has noth­ing to do with elec­tion pro­ce­dures or em­ployee choice. It has every­thing to do with de­lay­ing the process and stalling the vote in or­der to give time to the union busters to launch a po­ten­tially co­er­cive anti-union cam­paign against Foundation em­ploy­ees.

Thousands of work­ers across the tech and non­profit sec­tors have achieved vol­un­tary recog­ni­tion through this card check” method. Our de­mand of the Wikimedia Foundation was sim­ply that they live up to their val­ues and be the high-road em­ployer that they pur­port to be. They re­fused.

While the Wikimedia Foundation touts to the pub­lic that they plan to take a neu­tral stance in our or­ga­niz­ing ef­forts, they have al­ready proven that not to be the case be­hind the scenes. When the Foundation re­jected our re­quest for vol­un­tary recog­ni­tion this week, they im­me­di­ately sent out to em­ploy­ees and the pub­lic state­ments couched in clas­sic union-bust­ing rhetoric, rhetoric un­doubt­edly pro­vided by out­ra­geously ex­pen­sive union-avoid­ance law firms. This in­sult­ing and waste­ful use of Foundation re­sources is both an in­sult to Foundation em­ploy­ees and to the Free Knowledge Movement as a whole.

Insisting that our right to or­ga­nize be ad­ju­di­cated by the National Labor Relations Board is not a neu­tral choice; it has noth­ing to do with elec­tion pro­ce­dures or em­ployee choice. It has every­thing to do with de­lay­ing the process and stalling the vote in or­der to give time to the union busters to launch a po­ten­tially co­er­cive anti-union cam­paign against Foundation em­ploy­ees.

Community mem­bers ex­pressed con­cern about the fact that the Wikimedia Foundation has a busi­ness re­la­tion­ship with the Jones Day law firm, which is par­tic­u­larly well known in the U.S. for ag­gres­sive union bust­ing. In this con­text, it is worth point­ing out that the WMFs re­la­tion­ship with Jones Day dates back over a decade and that Jones Day has pri­mar­ily dealt with the Foundation’s brand and trade­mark man­age­ment. However, it even­tu­ally tran­spired that the Foundation has cho­sen to be rep­re­sented by the law firm Littler Mendelson, which has an equally strong rep­u­ta­tion for union bust­ing.

Relevant links:

June 24 press re­lease from the Communication Workers Union (CWU, UK)

FAQ, Wiki Workers United

Announcements, Wiki Workers United

July 20 press re­lease from Communications Workers of America (CWA)

July 27 WMF re­sponse, in­clud­ing an FAQ

National Labor Relations Board case page (for U.S. users), archive link for users out­side the U.S.

Community pages:

Wiki Workers United/Solidarity Signatures on Meta-Wiki, started 12 May 2026, over 1,250 sig­na­tures

Wikipedia:Wiki Workers United sol­i­dar­ity on English Wikipedia, started 21 May 2026, over 1,200 sig­na­tures

Community pe­ti­tion to the WMF Board to rec­og­nize the union on Meta-Wiki, started 28 July, over 150 sig­na­tures

AK

Eligibility cri­te­ria for board can­di­dates

Following the 2025 se­lec­tion process for the Wikimedia Foundation Board of Trustees, which saw two of the can­di­dates dis­qual­i­fied (see pre­vi­ous Signpost spe­cial re­port and in­ter­view as well as 2025 WMF Board re­form pe­ti­tion), the WMF Board de­cided to re­view the se­lec­tion process of new Trustees.

On 17 July, the board pub­li­cised its pro­posed new, sig­nif­i­cantly more strin­gent el­i­gi­bil­ity cri­te­ria. The main dif­fer­ence is that the pro­posed new cri­te­ria de­mand con­sid­er­ably more board or com­mu­nity ex­pe­ri­ence, with or­di­nary com­mu­nity mem­bers who are not al­ready of­fice hold­ers un­able to stand for elec­tion. The pro­posed new cri­te­ria are as fol­lows:

Minimum re­quire­ments

As of [Date of the ap­pli­ca­tions open­ing], can­di­dates must

Be flu­ent in English

Be at least 18 years old

Have a Wikimedia ac­count that is at least 4 years old

Be el­i­gi­ble to vote (2025 voter el­i­gi­bil­ity cri­te­ria for ref­er­ence)

Have not been re­moved for cause or de­parted af­ter in­ap­pro­pri­ate con­duct as a staff or Board mem­ber of the Wikimedia Foundation, Wikimedia Endowment, or other Wikimedia af­fil­i­ates

Fulfill at least one of the cat­e­gories of gov­er­nance or com­mu­nity ex­pe­ri­ence

Complete the WikiLearn WMF Board of Trustees Candidate Pre-Onboarding mod­ule be­fore pub­lish­ing their ap­pli­ca­tion

Categories of Governance or Community Experience

There are sev­eral cat­e­gories of com­mu­nity or gov­er­nance ex­pe­ri­ence that demon­strate knowl­edge of the Wikimedia pro­jects and trust in one’s abil­ity to ef­fec­tively work with other Wikimedia vol­un­teers.

Candidates must ful­fill at least one of the fol­low­ing cri­te­ria by hav­ing a to­tal of at least 2 years of ex­pe­ri­ence within the last 6 years, as of the [Date of the ap­pli­ca­tions open­ing]:

Served as a mem­ber of the Board of the Wikimedia Foundation or Wikimedia Endowment

Served as a mem­ber of the gov­ern­ing board of an or­ga­ni­za­tion at least 10% of the size of the Wikimedia Foundation (by an­nual bud­get or staff count)

Served in one of the fol­low­ing po­si­tions on a Wikimedia pro­ject: A mem­ber of one of the Arbitration Committees Global Sysop Steward Bureaucrat CheckUser Oversighter

A mem­ber of one of the Arbitration Committees

Global Sysop

Steward

Bureaucrat

CheckUser

Oversighter

Served in one of the fol­low­ing gov­er­nance po­si­tions for a Wikimedia af­fil­i­ate reg­is­tered as a le­gal en­tity and em­ploy­ing full-time staff, that is in good stand­ing (in com­pli­ance with grant and re­port­ing guide­lines and with­out any un­re­solved pro­ceed­ings with the Affiliations Committee dur­ing the can­di­date’s tenure): Chairperson A mem­ber of a Wikimedia af­fil­i­ate’s gov­ern­ing body for two con­sec­u­tive terms A mem­ber of the gov­ern­ing body of a rec­og­nized re­gional or the­matic hub for two con­sec­u­tive terms

Chairperson

A mem­ber of a Wikimedia af­fil­i­ate’s gov­ern­ing body for two con­sec­u­tive terms

A mem­ber of the gov­ern­ing body of a rec­og­nized re­gional or the­matic hub for two con­sec­u­tive terms

Served in one of the fol­low­ing Wikimedia com­mit­tee po­si­tions: An ad­vi­sor to one of the Wikimedia Foundation Board Committees (Currently: Executive, Audit, Governance, and Product & Technology) or the Wikimedia Endowment Board Committees (Currently: Finance, Community & Grantmaking, Audit, and Governance) A mem­ber of the Elections Committee (EC), given that at least 18 months have elapsed since the end of their term (per the EC char­ter) A mem­ber of one of the Wikimedia Movement com­mit­tees (Currently: Language Committee, Product & Technology Advisory Council, the Global Resource Distribution Committee, Affiliations Committee, and Universal Code of Conduct Coordinating Committee) A mem­ber of the Wikimedia Foundation Grant Committees (Regional, Conference, Research Funds)

An ad­vi­sor to one of the Wikimedia Foundation Board Committees (Currently: Executive, Audit, Governance, and Product & Technology) or the Wikimedia Endowment Board Committees (Currently: Finance, Community & Grantmaking, Audit, and Governance)

A mem­ber of the Elections Committee (EC), given that at least 18 months have elapsed since the end of their term (per the EC char­ter)

A mem­ber of one of the Wikimedia Movement com­mit­tees (Currently: Language Committee, Product & Technology Advisory Council, the Global Resource Distribution Committee, Affiliations Committee, and Universal Code of Conduct Coordinating Committee)

A mem­ber of the Wikimedia Foundation Grant Committees (Regional, Conference, Research Funds)

We wel­come peo­ple’s in­ter­est in be­com­ing mem­bers of the Board of Trustees. We en­cour­age those who do not meet the cri­te­ria to ex­press their in­ter­est, con­sider lead­er­ship train­ing and ways to gain rel­e­vant ex­pe­ri­ence in or­der to be el­i­gi­ble in the fu­ture.

Feedback is in­vited on Meta-Wiki. AK, C

Reports of sex­ual ha­rass­ment at Wikimania events

On July 26, Wikimedia Korea re­leased an open let­ter call­ing for an in­ves­ti­ga­tion af­ter al­le­ga­tions a Wikimania par­tic­i­pant ex­pe­ri­enced un­sought phys­i­cal con­tact and sex­ual ha­rass­ment.

Several key ac­tivists from Wikimedia Korea took part in this event. I had hoped that our par­tic­i­pants would re­turn from this event—which brings to­gether Wikimedians from around the world—hav­ing gained a range of valu­able ex­pe­ri­ences, and that they would con­tinue their ac­tiv­i­ties with even greater vigour. However, to­day I heard that one of our mem­bers whilst of­fer­ing well-in­ten­tioned as­sis­tance to an­other par­tic­i­pant, was in­stead sub­jected to un­wanted, forced phys­i­cal con­tact and sex­ual ha­rass­ment. We find this deeply re­gret­table and are deeply dis­mayed. — User:Jjw, pres­i­dent of Wikimedia Korea Wikimedia Korea/Open let­ter to the Wikimania com­mu­nity July 26 (translation)

Several key ac­tivists from Wikimedia Korea took part in this event. I had hoped that our par­tic­i­pants would re­turn from this event—which brings to­gether Wikimedians from around the world—hav­ing gained a range of valu­able ex­pe­ri­ences, and that they would con­tinue their ac­tiv­i­ties with even greater vigour. However, to­day I heard that one of our mem­bers whilst of­fer­ing well-in­ten­tioned as­sis­tance to an­other par­tic­i­pant, was in­stead sub­jected to un­wanted, forced phys­i­cal con­tact and sex­ual ha­rass­ment. We find this deeply re­gret­table and are deeply dis­mayed. — User:Jjw, pres­i­dent of Wikimedia Korea Wikimedia Korea/Open let­ter to the Wikimania com­mu­nity July 26 (translation)

Wikimedia Malaysia re­leased a state­ment the next day, and said that one of their own mem­bers had ex­pe­ri­enced sex­ual ha­rass­ment in a sep­a­rate in­ci­dent.

Their is­sue is not an iso­lated case. Earlier, one of our own com­mu­nity mem­bers who at­tended the con­fer­ence in per­son has filed a Trust and Safety com­plaint to the con­fer­ence team re­gard­ing a sep­a­rate case of sex­ual ha­rass­ment by an­other Wikimedian against an­other Wikimedian from a dif­fer­ent re­gion. Similar to the other case, this case also in­volved phys­i­cal touch and force­ful in­ti­macy against a per­son who has ex­pressed her dis­com­fort at a breach of per­sonal space. — Tofeiku, Chair of Wikimedia CUG Malaysia, on Wikimedia CUG Malaysia’s re­sponse in sup­port of Wikimedia Korea’s state­ment on Wikimania (translation)

Their is­sue is not an iso­lated case. Earlier, one of our own com­mu­nity mem­bers who at­tended the con­fer­ence in per­son has filed a Trust and Safety com­plaint to the con­fer­ence team re­gard­ing a sep­a­rate case of sex­ual ha­rass­ment by an­other Wikimedian against an­other Wikimedian from a dif­fer­ent re­gion. Similar to the other case, this case also in­volved phys­i­cal touch and force­ful in­ti­macy against a per­son who has ex­pressed her dis­com­fort at a breach of per­sonal space. — Tofeiku, Chair of Wikimedia CUG Malaysia, on Wikimedia CUG Malaysia’s re­sponse in sup­port of Wikimedia Korea’s state­ment on Wikimania (translation)

Vice President of the WMF Community Resilience & Sustainability team Maggie Dennis re­sponded to the open let­ter, con­firm­ing com­mu­ni­ca­tion with the in­di­vid­u­als in­volved.

The Foundation is treat­ing this mat­ter se­ri­ously. You may be aware that we do not dis­cuss Trust & Safety in­ci­dents in re­spect to the pri­vacy of all in­di­vid­u­als, but I can con­firm that we are in con­tact with in­di­vid­u­als in­volved in the re­ported in­ci­dent and wit­nesses to other con­cern­ing be­hav­iors. […] While we will not be able to up­date com­mu­nity, in­clud­ing Wikimedia Korea, on the out­comes ac­cord­ing to stan­dard Trust & Safety poli­cies, the per­son who made the re­port to us will be told the out­come di­rectly. — Maggie Dennis at Community Resilience & Sustainability/Response to Open let­ter to the Wikimania com­mu­nity July 26

The Foundation is treat­ing this mat­ter se­ri­ously. You may be aware that we do not dis­cuss Trust & Safety in­ci­dents in re­spect to the pri­vacy of all in­di­vid­u­als, but I can con­firm that we are in con­tact with in­di­vid­u­als in­volved in the re­ported in­ci­dent and wit­nesses to other con­cern­ing be­hav­iors. […] While we will not be able to up­date com­mu­nity, in­clud­ing Wikimedia Korea, on the out­comes ac­cord­ing to stan­dard Trust & Safety poli­cies, the per­son who made the re­port to us will be told the out­come di­rectly. — Maggie Dennis at Community Resilience & Sustainability/Response to Open let­ter to the Wikimania com­mu­nity July 26

–M

The ti­tle of this en­try is from the Abstract Wikipedia ar­ti­cle on it­self.

A Request for com­ment has opened over on Meta Wiki about Abstract Wikipedia. Discussion is on­go­ing about whether rolling out to more lan­guages should be paused, the pro­ject should be closed, or the Foundation should have more transparency” about the pro­ject. Originally ap­proved by the Board of Trustees in 2020, the pro­ject aims to pro­vide a way for smaller lan­guage Wikipedias to ac­cess ar­ti­cles in their lan­guage. The com­mu­nity has raised con­cerns about al­low­ing the in­te­gra­tion of Abstract Wikipedia into small-lan­guage Wikipedias given its cur­rent state. The Wikimedia Foundation has re­sponded on Meta-Wiki, ex­press­ing con­fi­dence in its ap­proach to nat­ural lan­guage gen­er­a­tion and the im­prove­ment of pro­ject qual­ity over time, and ac­knowl­edg­ing the dif­fi­culty of nav­i­gat­ing doc­u­men­ta­tion and re­port­ing on the pro­jec­t’s de­vel­op­ment.

Relevant links:

Request for Comment on Abstract Wikipedia

Response from the pro­ject team to the crit­i­cism

– M

Brief notes

New ad­min­is­tra­tors: The Signpost wel­comes the English Wikipedia’s newest ad­min­is­tra­tors, MCE89 and Staraction, elected through old fash­ioned” re­quests for ad­min­ship. Of note, a hand­ful of ed­i­tors op­posed both RfAs ex­plain­ing they saw open-ended sup­port of the Wikimedia Foundation work­ers’ union (see above and prior Signpost cov­er­age) as po­ten­tially dam­ag­ing to the pro­ject.

Articles for Improvement: This week’s Article for Improvement is Customer ex­pe­ri­ence, and next week’s (starting 3 August) is HDR10. Please be bold in help­ing im­prove these ar­ti­cles!

In this is­sue

GitHub - tom-ilan/cycloidal_gearbox: 3D Printed Cycloidal Gearbox

github.com

This is my cy­cloidal gear­box I built, and the python script I cre­ated to gen­er­ate it! A cy­cloidal gear­box is a type of gear­box that al­lows you to turn ro­ta­tional speed into torque.

Design Process

Version 1

This gear­box was a hand­cranked gear­box specif­i­cally meant to test the va­lid­ity of the python cy­cloidal gen­er­a­tor. It had a gear ra­tio of 1:9.

Version 2

This de­sign was a mi­cro cy­cloidal gear­box with a ra­tio of 1:9, meant to only take up the same foot­print as a NEMA 17. Due to the tight tol­er­ances needed for a small cy­cloidal drive and the lack of pre­ci­sion of­fered by 3D print­ing, this de­sign did not work.

Version 3

This gear­box was the first work­ing ver­sion to run on a NEMA 17. It has a larger foot­print com­pared to Version 2 al­low­ing greater tol­er­ances and a fully func­tional de­sign.

🛠️ The Python Script

This python script was based on the SolidWorks ar­ti­cle Building a Cycloidal Drive with SOLIDWORKS. The two main para­met­ric equa­tions I used were:

$$x = R \cos(t) - E \cos(N t) - r \cos(t + \psi), \quad y = R \sin(t) - E \sin(N t) - r \sin(t + \psi)$$ $$\psi = \text{atan2}\left(\sin((1 - N) t), \frac{R}{E \cdot N} - \cos((1 - N) t)\right)$$ Reduction ra­tio: $1 : (N - 1)$ (rotor ro­tates op­po­site to in­put shaft).

Installation & Execution

Clone the repo

Open Fusion 360 and launch Scripts and Add-Ins (Shift + S).

Under the Scripts tab, click + (Plus) to add a script.

Select the cy­cloidal_­gen­er­a­tor folder and click Run.

Key Parameters

Pins ($N$) & Pitch Radius ($R$): Sets outer sta­tion­ary hous­ing geom­e­try (Rotor has $N-1$ lobes).

Eccentricity ($E$): Input shaft off­set dis­tance. (Constraint: $R > E \cdot N$).

Outer Pin Radius ($r$): Roller pin ra­dius. (Constraint: val­i­dated against un­der­cut limit $r_{\text{max}}$).

Precision / Profile Offset: Angular step size and tol­er­ance off­set ($+$ for 3D print clear­ance).

Output Pins & Bolt Radius: Defines con­cen­tric out­put pins and ro­tor clear­ance holes ($r_{\text{pin}} + E$).

🚀 Version 3 — Detailed Overview & Stats

Note

This sec­tion is ded­i­cated to Version 3, whose CAD files can be found un­der cad_­mod­els/​ver­sion_3.

Key Specifications & Performance Stats

Further room for growth

The hous­ing pins can be re­placed with MR128 bear­ings al­low­ing for less fric­tion and higher ef­fi­ciency in the gear­box.

The hous­ing pins can be re­placed with MR128 bear­ings al­low­ing for less fric­tion and higher ef­fi­ciency in the gear­box.

The out­put pins can be re­placed with M2 screws with metal cov­er­ings to in­crease rigid­ity, max­i­mum torque out­put, and the ef­fi­ciency of the gear­box.

The out­put pins can be re­placed with M2 screws with metal cov­er­ings to in­crease rigid­ity, max­i­mum torque out­put, and the ef­fi­ciency of the gear­box.

A big win for Android interoperability – Open Home Foundation

www.openhomefoundation.org

Something big just hap­pened. As the Open Home Foundation’s Android de­vel­oper for Home Assistant, I was in­vited by the European Commission (EC) to con­sult on Android in­ter­op­er­abil­ity. The call for feed­back was part of the Commission’s work un­der the Digital Markets Act (DMA). For any­one un­fa­mil­iar, the DMA is an EU law that de­fines and reg­u­lates gatekeeper plat­forms” — those that of­fer core” ser­vices like search en­gines, app stores, and mes­sag­ing plat­forms — to make dig­i­tal mar­kets fairer and more open to com­pe­ti­tion. As you might imag­ine, I had plenty to say about Google’s re­stric­tions on Android, es­pe­cially the tech gi­ant lim­it­ing wake word de­tec­tion to its own Gemini as­sis­tant, a con­cern I sur­faced in our Home Assistant 2026.3 Release Party. To put it plainly, Google had no grounds for lim­it­ing Android in­ter­op­er­abil­ity in the first place, other than to give it­self the up­per hand. We knew our com­mu­nity de­served bet­ter, and that’s what we told the Commission.

The re­sult? The EC lis­tened to us and all the other or­ga­ni­za­tions that con­tributed. On July 16, 2026, the European Commission adopted a de­ci­sion un­der the DMA that re­quires Alphabet (Google’s par­ent com­pany) to open up eleven Android fea­tures, in­clud­ing al­ways-on wake word de­tec­tion, am­bi­ent sen­sor ac­cess, and screen au­toma­tion — to all as­sis­tants, on equal terms.

As an EU cit­i­zen, I’m gen­uinely pleased to see this kind of reg­u­la­tion of Big Tech lev­el­ing the dig­i­tal mar­ket play­ing field and rep­re­sent­ing real progress for users. Not only that, but it’s a real win for the Open Home Foundation: we ex­ist to fight for pri­vacy, choice, and sus­tain­abil­ity in smart homes, and this out­come shows what’s pos­si­ble when we ad­vo­cate for our com­mu­nity. We al­ready briefly cov­ered this news in our July newslet­ter, but I want to take some time now to break down how we got here, what this de­ci­sion says, why it mat­ters for our com­mu­nity, and what it could un­lock for Home Assistant and the rest of the in­dus­try.

A bit of back­ground

For three years, our com­mu­nity had tried to ship an al­ways-on wake word de­tec­tion in the Android Home Assistant Companion app. We wanted users to be able to say Okay Nabu,” and have their self-hosted Assist voice as­sis­tant an­swer. Yet our early at­tempts kept break­ing. Most no­tably, af­ter each re­boot the de­vice’s mi­cro­phone no longer picked up the wake word. So we dug into the Android source code, and lo and be­hold, there was a so­lu­tion: but Google was­n’t let­ting us use it.

Android has a well-de­signed mech­a­nism that lets your de­vice lis­ten for Hey Google” all day, with­out drain­ing your bat­tery. Their wake word de­tec­tion runs in two stages. A small model does the first de­tec­tion on a DSP (digital sig­nal proces­sor), which is a ded­i­cated chip that processes au­dio us­ing a frac­tion of the power your de­vice’s main proces­sor (CPU) would need. This first stage runs in an iso­lated process blocked from the net­work, and can’t ex­tract au­dio un­til a po­ten­tial wake word is de­tected. Then the sec­ond stage uses a stronger model via the CPU to con­firm the de­tec­tion.

Most con­tem­po­rary de­vices have DSPs. But Android-based de­vices block ac­cess to it for any­one other than Google and the man­u­fac­turer of the de­vice. Since the wake word mech­a­nism us­ing the DSP sim­ply was­n’t avail­able to third-party apps, and de­vel­oper doc­u­men­ta­tion did­n’t ex­ist pub­licly, we used what we could to build a workaround.

From mi­croWake­Word to macro re­sults

Our so­lu­tion was run­ning a small mi­croWake­Word model on the de­vice’s CPU in­side our app. This worked, but came with some big down­sides:

Battery us­age would jump from roughly 1% to 15% with wake word de­tec­tion en­abled, since the CPU is far less ef­fi­cient for this task.

The mi­cro­phone pri­vacy in­di­ca­tor (the green dot) would stay on per­ma­nently, be­cause we needed full mi­cro­phone ac­cess to run de­tec­tion our­selves. We ac­tu­ally think the in­di­ca­tor is the right de­sign — the prob­lem is that we had no way to of­fer the stronger guar­an­tee Google gives it­self: an iso­lated process that can’t send au­dio any­where. Instead, you had to trust that we were han­dling that ac­cess re­spon­si­bly. And not be­cause a safer ver­sion is­n’t tech­ni­cally avail­able. But be­cause the DSP path is ar­bi­trar­ily blocked by Google for an­ti­com­pet­i­tive rea­sons, forc­ing a less se­cure ap­proach that in­tro­duces pri­vacy risks for the user.

You would have to set Home Assistant as your de­fault as­sis­tant, be­cause that was the only way Android would keep our ser­vice alive across re­boots. That would lock you out of Gemini and every­thing tied to it (and you should­n’t have to choose).

When I was in­vited to share these lim­i­ta­tions (and oth­ers) with the Commission, I did­n’t hold back. Which is why we were thrilled to dis­cover an im­pres­sively pre­cise and tech­ni­cally ac­cu­rate de­ci­sion from the EU: it cor­rectly de­scribes the two-stage wake word ar­chi­tec­ture, the DSP, the iso­lated process, and the role cou­pling. The re­port went down to de­tails we only fig­ured out by read­ing Android’s source code our­selves. Which brings us to what the rul­ing ac­tu­ally says…

A wake-up call for Google

The de­ci­sion re­quires Google to give third par­ties in­ter­op­er­abil­ity that’s equally ef­fec­tive” as what Google’s own as­sis­tant gets across eleven Android fea­tures, free of charge. For wake word de­tec­tion specif­i­cally, Google must pro­vide:

The abil­ity to cre­ate a cus­tom wake word model in Android, with first-stage de­tec­tion run by the DSP (when avail­able) in­stead of the app

The abil­ity to run a sec­ond-stage val­i­da­tion af­ter the DSP has po­ten­tially iden­ti­fied the wake word in first-stage de­tec­tion

Testing tools and com­plete doc­u­men­ta­tion, with­out re­quir­ing a com­mer­cial agree­ment with Google

Two lines de­serve a spe­cial men­tion. First: Google shall not sub­ject ac­cess to fea­tures to the app hold­ing a de­fault role, in­clud­ing the de­fault as­sis­tant role.” That is the de­cou­pling we dis­cussed with the Commission. Second: wake word de­tec­tion from mul­ti­ple ser­vices, in­clud­ing ser­vices be­long­ing to third par­ties and Alphabet, are able to run con­cur­rently.” This would let you say Okay Nabu” to con­trol your home with­out chang­ing any de­faults or hav­ing to give up us­ing Gemini for other pur­poses.

Beyond wake words, the de­ci­sion cov­ers in­vok­ing as­sis­tants from the long-press home ges­ture, ac­cess to am­bi­ent data like the mi­cro­phone and cam­era un­der the same con­di­tions as Google, struc­tured in­te­gra­tion with apps (including Gmail, Calendar, and Maps), sys­tem-level con­trols, ac­cess to on-de­vice AI mod­els, and fair back­ground ex­e­cu­tion rules. Opening up these fea­tures has­n’t been with­out push­back — Google it­self has raised se­cu­rity con­cerns, which we’ll get into be­low. But with all things con­sid­ered, we be­lieve the ben­e­fits to users and the in­dus­try far out­weigh the risks.

Time’s tick­ing

Google must ship these changes in Android 18 (the next ma­jor re­lease), by August 1, 2027. Concurrent hot­word de­tec­tion — let­ting mul­ti­ple ser­vices be trig­gered by voice — must be in place by Android 19, no later than August 1, 2028.

It’s worth not­ing the de­ci­sion still re­lies on Google to de­sign and im­ple­ment the changes, and with that comes a risk of ma­li­cious com­pli­ance: a tech­ni­cally sound so­lu­tion that is un­us­able in re­al­ity (it would­n’t be the first time a gate­keeper wran­gled its way out of a reg­u­la­tion). But the fine print gives grounds for hope: Google must de­liver so­lu­tions that are equally ef­fec­tive” on ease of use, speed, and en­ergy con­sump­tion, pub­lish com­plete doc­u­men­ta­tion and test­ing tools, and re­port progress to the Commission monthly. A real win for de­vel­op­ers, and one that makes ship­ping the bare min­i­mum much harder to get away with. With that in mind, here’s what it could look like for Home Assistant.

Help us make this change stick

We’re al­ways work­ing hard to cre­ate the best pos­si­ble ex­pe­ri­ence for our Android Home Assistant users, though we’re a small team — which is why com­mu­nity con­tri­bu­tions to the Android app mat­ter so much. If you’d like to help (in line with our re­cently re­leased AI pol­icy), we’d love to hear from you. While the ideas be­low are just that, and don’t form part of our roadmap, your in­put could help un­lock them in the fu­ture:

Battery-efficient wake word de­tec­tion

Like we men­tioned ear­lier, mov­ing first-stage de­tec­tion from the CPU to the DSP should in­crease bat­tery ef­fi­ciency sig­nif­i­cantly. Our plan is to sup­port two meth­ods: on newer phones with Android 18, we’ll use the phone’s low-power chip to lis­ten for the wake word. On older phones, or those with­out that chip, de­tec­tion will keep run­ning as it does to­day. Either way, we’ll show you which method your phone is us­ing from within the Companion app.

One phone, two as­sis­tants

Today, choos­ing a third-party wake word means giv­ing up Gemini, along with calls and mes­sages through your de­fault as­sis­tant. Default-role de­cou­pling and con­cur­rent wake word ac­cess would end that: You can talk to Gemini like aways, but also say Okay Nabu” when you want to in­ter­act with your home via Home Assistant.

Imagine if you could set dif­fer­ent wake words for dif­fer­ent as­sis­tants in­side the app it­self, like Hey Jarvis” for your ad­min dash­board and Okay Nabu” for the fam­ily. This won’t even be tech­ni­cally pos­si­ble un­til 2028 when Android 19 is re­leased (and it will take a lot of work), but it’s a nice goal to have look­ing ahead.

Better built-in pri­vacy

This is the part I find most ex­cit­ing. The rul­ing re­quires wake word con­fir­ma­tion to run in a se­cure, iso­lated process (known as sand­box­ing) via the DSP. This means the part of the sys­tem that con­trols this fea­ture is walled off, with no way to send au­dio any­where un­til the wake word is con­firmed. I don’t want to rely on trust when it comes to some­thing as sen­si­tive as in­ter­ac­tions with my voice as­sis­tant. I want to be in con­trol, with a clear ex­pla­na­tion of what the things I en­able ac­tu­ally im­ply. Sandboxing gives us that by de­sign: pri­vacy en­forced by the OS it­self, the same se­cure-by-de­fault pro­tec­tion Google has al­ways had, now fi­nally avail­able to all.

A more ca­pa­ble as­sis­tant, for every­one

Sensor ac­cess is­n’t the only place this equal treat­ment ap­plies. The de­ci­sion also re­quires Google to open struc­tured in­te­gra­tions with its own apps — Gmail, Calendar, Maps, etc — to qual­i­fied as­sis­tants, not just Gemini. In the­ory, that means your as­sis­tant could draft an email, man­age a cal­en­dar event, or send a text and start a call on your be­half: ex­actly the ca­pa­bil­i­ties our users tell us they miss when they leave Gemini, and ones that could gen­uinely boost us­abil­ity, es­pe­cially for users with ac­ces­si­bil­ity needs.

That same ac­cess could ex­pand the range of sen­sors and con­trols the app al­ready re­ports to Home Assistant: sound de­tec­tion (smoke alarm, break­ing glass, door­bell) as au­toma­tion trig­gers, and con­trols like do-not-dis­turb or Bluetooth your as­sis­tant can ac­tu­ally act on, not just ob­serve.

On the se­cu­rity ar­gu­ment

Google has pushed back on the rul­ing, cit­ing se­cu­rity risks. It warns the de­ci­sion grants third par­ties sensitive and pow­er­ful de­vice per­mis­sions,” ex­pos­ing user data without user knowl­edge or con­sent.” This fram­ing over­states the risks in a fa­mil­iar tac­tic: sound­ing the alarm on se­cu­rity con­cerns to cur­tail at­tempts for in­ter­op­er­abil­ity. We’d point out, as one of those third par­ties, that the de­ci­sion al­ready builds in the safe­guards that con­cern calls for: Google can still re­quire user con­sent, show pri­vacy in­di­ca­tors, and let users re­voke ac­cess per ser­vice. For the most sen­si­tive fea­tures like health data ac­cess, it also has a pol­icy in place via the Play Store to check se­cu­rity, pri­vacy, and data min­i­miza­tion be­fore any app gets ac­cess.

And to be clear, these ca­pa­bil­i­ties al­ready ex­ist on your phone, and Google’s own ser­vices al­ready use them, with­out ever ask­ing your ap­proval. The risk did­n’t ap­pear when the EU asked for that ac­cess to be shared more broadly — what changed is who gets to de­cide who has it. Whatever risks re­main, like those in­tro­duced by us­ing any smart de­vice, should be taken se­ri­ously — just not as a veil for Google’s dou­ble-deal­ing.

Our view is that trust with­out ver­i­fi­ca­tion is­n’t a se­cu­rity model, and lim­it­ing these safe­guards to Google alone is­n’t pro­tec­tion. Even ma­jor AI ven­dors have had se­cu­rity in­ci­dents, Hugging Face/OpenAI among them. What does of­fer pro­tec­tion is giv­ing users choice and trans­parency into se­cu­rity processes, along with a se­cure tech­ni­cal ar­chi­tec­ture: sand­box­ing, iso­la­tion, re­vo­ca­ble per­mis­sions — en­forced equally, which is what this de­ci­sion re­quires.

It’s worth watch­ing where Google goes next: from 2027, its de­vel­oper ver­i­fi­ca­tion pro­gram will re­quire every Android de­vel­oper to be cen­trally ver­i­fied be­fore their apps can even be in­stalled — a move con­tested by the Keep Android Open cam­paign, and one we’re also skep­ti­cal about. It’s a re­minder that this fight is­n’t over, and nei­ther is our work.

There every step of the way

Google must re­port its im­ple­men­ta­tion plans to the Commission within two months, and el­i­gi­bil­ity pro­gram terms are due for pub­lic con­sul­ta­tion by February 2027. We’ll be there for it all: to test the be­tas, re­port on whether im­ple­men­ta­tion lives up to the promise, and keep you in­formed. In the mean­time, we’ll con­tinue do­ing all we can to cham­pion smart home tech that’s pri­vate, lo­cal, and con­trolled by you, on your terms.

Is memory the moat? | Wafer

www.wafer.ai

ProductTechnologyCases

Technology

Cases

CompanyTeamCareersManifesto

Team

Careers

Manifesto

Blog

Log in

How we did it

Prefill op­ti­miza­tions

Takeaways

Is mem­ory the moat?

Running Kimi K3 at ~952 tok/​s/​node, AMD con­tin­ues to prove its case as the win­ner in per­for­mance per dol­lar.

Over the past sev­eral months, we’ve seen an ex­plo­sion in the ca­pa­bil­i­ties of open source mod­els. With DeepSeek V4-Pro and GLM5.2 reach­ing near-Opus lev­els of in­tel­li­gence, open source has emerged as a real, cost-ef­fi­cient al­ter­na­tive to the closed source mod­els we’ve been mar­ried to.

But we have yet to see one like Kimi K3. Promising Fable/Sol lev­els of in­tel­li­gence, Kimi K3 marks the start of a new era for open source.

But a smarter model means a big­ger model — and these mod­els are ex­pand­ing in size just as fast as they are in ca­pa­bil­i­ties. GLM5.2 has 753B pa­ra­me­ters, DeepSeek V4-Pro 1.6T, and Kimi K3 weighs in at 2.8T (!!) pa­ra­me­ters. That’s over 1.5TB of VRAM be­fore al­lo­cat­ing a KV cache for 1M to­kens of con­text. Not even a B200 node (8 GPUs) can fit Kimi K3. That leaves you with lim­ited op­tions: serve on a node of B300s, which have 288GB of VRAM per GPU, or com­mit two B200 nodes (TP16) to serv­ing Kimi.

But guess which other non-NVIDIA GPU has 288GB of VRAM? AMDs MI355X. Can you tell we like these chips yet? At around ~2.4× cheaper per GPU on av­er­age ver­sus a B300 and ~1.7× cheaper than a B200, the MI355X is a cost-ef­fi­cient al­ter­na­tive to Blackwells with com­pa­ra­ble hard­ware specs. The only prob­lem with AMD is soft­ware sup­port — slower ker­nels and less day-0 sup­port on in­fer­ence frame­works make serv­ing fron­tier mod­els on AMD a real en­gi­neer­ing ef­fort. Our claim at Wafer is that agents are im­prov­ing at ker­nel and model op­ti­miza­tion, clos­ing this gap as we speak. But with AMD ship­ping day-0 sup­port for Kimi K3, most of the work was al­ready done for us.

The re­sults are great: on a 1,024-token in­put / 400-token out­put bench­mark, the MI355X reaches 952 tok/​s/​node and 118 tok/​s sin­gle stream — over 3.8× the ag­gre­gate through­put per node and over 1.3× the sin­gle-stream de­code of our TP16 B200 de­ploy­ment (whose 498 tok/​s is a 16-GPU, 2-node to­tal — ~249/node). B300 nodes still win ~1.65× on ag­gre­gate through­put over the MI355X, but at 2.4× the price, the MI355X crushes the B300 on per­for­mance per dol­lar.

Perf/dollar at $2.50/GPU-hr for the MI355X, $6.00 for the B300, and $4.25 for the B200.

To the B200s de­fence, its num­bers are some­what de­flated by the fact that it pays a cross-node all-re­duce on the de­code crit­i­cal path (RoCE v2 at ~195 Gb/s) — it’s the only con­fig here that spans two nodes, be­cause Kimi K3 won’t fit weights plus a 1M-token KV pool on a sin­gle 8×192GB node. But that’s ex­actly the point: Kimi K3 at its size is one of the first mod­els we’ve seen where the MI355Xs fo­cus on HBM ca­pac­ity gives it a prac­ti­cal, mea­sur­able edge over the B200.

How we did it

While Kimi K3 served out of the box, there was still work to be done to get it to its cur­rent through­put num­ber.

The main lever was spec­u­la­tive de­code. K3 ships zero draft ten­sors — no MTP, no EAGLE — so the only spec­u­la­tive path is an ex­ter­nal block-dif­fu­sion draft: RadixArk’s Kimi-K3-DSpark. On CUDA it just runs. On ROCm our first real re­quest breaks the sched­uler with this er­ror:

NameError: name top_k_renorm_prob’ is not de­fined. Did you mean: top_p_renorm_prob’?

sglang’s ac­cept-sam­pling ver­i­fier has two ways to build the tar­get dis­tri­b­u­tion: a dense path that calls top_k_renor­m_prob, and a sparse fast path that routes through torch.topk di­rectly. The CUDA build im­ports top_k_renor­m_prob from sgl_k­er­nel; the ROCm build aliases only a Triton top-p ker­nel and leaves top_k_renor­m_prob un­de­fined — there’s no top-k renorm ker­nel for gfx950 to alias. So the mo­ment a re­quest lands on the dense path, the ver­i­fier hits that NameError and takes the sched­uler down with it.

The fix is a sin­gle PyTorch func­tion. Top-k renorm is a small op­er­a­tion: take the mod­el’s prob­a­bil­ity vec­tor, keep the k high­est en­tries, zero the rest, and rescale what’s left to sum to 1. A sort, a masked_­fill, a di­vide — dropped straight into sglang’s ROCm sam­pling branch, the same com­pu­ta­tion the CUDA build gets from sgl_k­er­nel. No cus­tom ker­nel: the re­flex on ROCm is to as­sume you need one, but here it was a miss­ing de­f­i­n­i­tion, not a miss­ing ker­nel.

With spec dec fixed and hard­ened, we gained ~2.2× per­for­mance sin­gle-stream, ~1.7× per-stream at mod­er­ate load, and +18% peak ag­gre­gate. More im­por­tantly, our peak ag­gre­gate through­put landed on much higher con­cur­rency (c64 vs c24 no-spec).

Prefill op­ti­miza­tions

Discussion around model per­for­mance tends to high­light de­code to­kens per sec­ond. But in many cases de­code tok/​s is fool’s gold — de­code is over-glo­ri­fied, while time-to-first-to­ken, the num­ber users feel the most, gets over­looked.

The MI355X strug­gles here: an iden­ti­cal 172k-token cold pre­fill took ~51s on MI355X ver­sus ~23s on a B300. On a 1M-context model, a lot of work­loads have huge pre­fills (sometimes cold), and hav­ing GPUs spin on pre­fill for min­utes can ren­der en­tire fleets of nodes use­less.

The gap was al­most en­tirely one ker­nel. K3 on ROCm was falling back to slow generic Triton at­ten­tion be­cause the fast AITER MLA pre­fill ker­nel would­n’t load. The prob­lem was a shape mis­match, not a miss­ing ker­nel — K3 at TP8 gives 12 at­ten­tion heads per rank, and AITERs MLA path is built for 4, 8, or mul­ti­ples of 16. The fix was triv­ially sim­ple: zero-pad the head count 12→16, run the fast ker­nel, and ex­tract the real 12 heads from the out­put.

The re­sult: on the same 172k cold pre­fill, the AITER MLA pre­fill ASM runs at ~13k tok/​s steady-state vs the Triton fall­back’s ~4 – 7k, speed­ing up pre­fill by ~2 – 3×. It’s a TTFT lever, not an ag­gre­gate-through­put one — de­code is un­changed, so it does­n’t move the num­bers above; it moves the num­ber a user waits on be­fore the first to­ken ap­pears.

Takeaways

Achieving the best per­for­mance-per-dol­lar ra­tio on the MI355X was rel­a­tively out of the box. There were some ex­pected frame­work-re­lated bugs — but fewer than GLM5.2, and this time it cer­tainly did not re­quire cus­tom ker­nels.

SOTA on AMD is im­mi­nent. Is the CUDA moat dead?

Related ar­ti­cles

July 17, 2026Rishiraj Dutta Gupta and Wafer TeamWafer in­te­gra­tion with TrueFoundry AI GatewayHow Wafer’s fast, OpenAI-compatible server­less in­fer­ence in­te­grates with TrueFoundry AI Gateway for uni­fied rout­ing, ob­serv­abil­ity, and zero data re­ten­tion.

Wafer in­te­gra­tion with TrueFoundry AI Gateway

How Wafer’s fast, OpenAI-compatible server­less in­fer­ence in­te­grates with TrueFoundry AI Gateway for uni­fied rout­ing, ob­serv­abil­ity, and zero data re­ten­tion.

July 3, 2026Ian YePerformance per dol­lar is get­ting faster and cheap­er­How we served GLM5.2 on AMD MI355X at 2626 tok/​s/​node and 213 tok/​s sin­gle stream at over 2x lower cost than Blackwell.

Performance per dol­lar is get­ting faster and cheaper

How we served GLM5.2 on AMD MI355X at 2626 tok/​s/​node and 213 tok/​s sin­gle stream at over 2x lower cost than Blackwell.

How the Words We Teach English Language Learners Changed

pudding.cool

Look through the words scat­tered around this page. Every one of them is among the most com­monly used words in the English lan­guage.

They come from a 2023 list of about 2,800 words, shown to cover over 90% of gen­eral English use, in­tended for peo­ple learn­ing the lan­guage.

This 2023 list is an up­date of an ear­lier one, made in 1953, which iden­ti­fied about 2,300 words as the es­sen­tial vo­cab­u­lary to every­day life at the time.

Between the two lists, 70 years apart, about 600 words were dropped, and over 1,100 were added. The rest re­mained as is.

Some of the changes make im­me­di­ate sense: Telegraph dropped out; com­puter was added, along with web­site and blog. Tobacco was re­placed by cig­a­rette. Motherhood be­came mom, and dad was added too, though fa­ther­hood was never on the list to be­gin with. The world changed and vo­cab­u­lary surely fol­lowed.

But also: ap­ple did­n’t make the new list. Neither did fork, soap, um­brella or leaf, for ex­am­ple. It’s not that these things van­ished from every­day life, but many hands-on words be­came less cen­tral to the core vo­cab­u­lary. Dog stayed; goat and don­key did­n’t. Bread stayed; bread­mak­ing in­gre­di­ents—flour and wheat—dropped. Cook is on the new list. Boil, bake, and fry are not.

And many of the words that were added, such as mort­gage, cor­po­ra­tion, ap­pro­pri­ate, analy­sis, fairly, and de­spite, don’t look any­thing like the ones that were dis­carded. In fact, they are mostly ab­stract con­cepts that don’t look like any­thing at all.

A

Added to 2023 list

A

Removed from 1953 list

A

In both lists

From Goat to Despite

How the Words We Teach English Language Learners Changed, and What That Says About Us

By Jasmine Nackash

These essential vo­cab­u­lary” lists are called the General Service List (1953) and the New General Service List (2013, re­vised in 2023).

They were de­signed as teach­ing tools for peo­ple learn­ing English as a sec­ond lan­guage, built from real-world us­age data and ex­ten­sively tested. The aim was a vo­cab­u­lary list with as few words and as much cov­er­age of every­day English us­age. That cov­er­age is high, over 90% for the 2023 list1 and about 84% for the 1953 list.2 To ac­count for that much of the lan­guage, they had to track a sig­nif­i­cant por­tion of what­ever peo­ple were ac­tu­ally read­ing and say­ing. A word earned its place by ap­pear­ing of­ten enough, across enough con­texts, to be hard to avoid for the av­er­age per­son in an English-speaking so­ci­ety. Open the word lists panel on the right to browse through all the en­tries in both lists.

While these were prac­ti­cal tools, built to cap­ture which words peo­ple need most, the an­swer also dou­bles as a snap­shot of or­di­nary life, 70 years apart: what peo­ple were ex­pected to en­gage with, and had to deal with, in their daily lives.

Treating the lists as an in­di­rect record of day-to-day life, I went through the dif­fer­ences be­tween them from a few an­gles: what the words were about, how tan­gi­ble were they, and to which parts of speech they be­longed.

I started by us­ing a com­mon lin­guis­tics re­search tool3 that sorted all of the words by mean­ing. It as­signed each word to one of 21 sub­ject cat­e­gories, based on typ­i­cal us­age: Food and Farming, the Body and the Self, Government and Public, Language and Communication, and so on. Together, they sug­gested what kind of world each list was built for.

Data source: all words run through the UCREL Semantic Analysis System (USAS).

The cat­e­gories that shrank are mostly those that have to do with the im­me­di­ate, phys­i­cal world, while the gains are those fur­thest from it.

To bet­ter see this, the cat­e­gories can be ori­ented spa­tially. Some cat­e­gories de­scribe you: your body and emo­tions. Some de­scribe what’s im­me­di­ately around you: food, ob­jects, and the nat­ural world. Others name sys­tems you par­tic­i­pate in: gov­ern­ment, in­sti­tu­tions, so­ci­ety, and cul­ture. And some have no lo­ca­tion at all: ab­stract con­cepts, rea­son­ing, and processes. When we look at the data grouped by phys­i­cal scope, the pat­tern of change seems to point in a spe­cific di­rec­tion.

The Self: Emotion | The Body and the Individual

Local/Immediate: Substances, Materials, Objects and Equipment | Food and Farming | Life and Living Things | Architecture, Housing and the Home | World and Environment

Institutional: Money and Commerce in Industry | Government and Public | Education | Science and Technology

Social/Communicative: Social Actions, States, and Processes | Movement, Location, Travel and Transport | Language and Communication | Entertainment, Sports and Games | Arts and Crafts

Universal/Abstract: General and Abstract Terms | Psychological Actions, States and Processes | Numbers and Measurement | Names and Grammar | Time

In hind­sight, the shift makes sense. By 1957, four years af­ter the orig­i­nal list was pub­lished, white-col­lar work­ers out­num­bered blue-col­lar for the first time in US his­tory. And by 2000, fewer than one in four work­ers did man­ual la­bor. The stuff peo­ple en­coun­tered in their daily lives, what they needed to talk about, and the sys­tems they had to nav­i­gate all changed.

The vo­cab­u­lary lists, built from the lan­guage of their re­spec­tive eras, tracked those changes. The shifts re­flect a life that moved fur­ther from its own mak­ing: less tied to tools, an­i­mals, food, and the body; more tied to na­tional or global in­sti­tu­tions, cat­e­gories, sys­tems, and ideas.

The new vo­cab­u­lary—mort­gage, leg­is­la­tion, per­spec­tive, in­volve­ment, im­prove­ment, as­sump­tion, eval­u­a­tion—are words you can’t weigh, point to, or hold in your hand. These words shape your life, but they do it with­out oc­cu­py­ing phys­i­cal space.

To bet­ter un­der­stand whether there was a shift in vo­cab­u­lary de­scrib­ing the phys­i­cal world, I com­pared each word to a data­base that rates its tan­gi­bil­ity on a scale of 1 to 5 (called a concreteness rat­ing4”). A rat­ing of 5 means you can ex­pe­ri­ence the word di­rectly with your senses, while a rat­ing of 1 means you can’t.

The highly con­crete end dropped the most: from 21% of the to­tal in 1953 down to 14% in 2023.

Kernel den­sity es­ti­ma­tion, band­width 0.08 · Data source: Brysbaert et al. (2014)

This shift mat­ters be­cause ab­stract and con­crete words are processed by our brains in dif­fer­ent ways. When you read axe, your brain does­n’t just de­code let­ters, it reaches for some­thing: an im­age, a weight, or a ges­ture. The word ac­ti­vates both a ver­bal la­bel and a sen­sory trace. Psychologists call this dual cod­ing:5 Concrete words travel through two chan­nels, ver­bal and sen­sory; ab­stract words travel through one. Two chan­nels mean two re­trieval path­ways, which is why con­crete words are stickier,” eas­ier to hold in a line of thought and faster to re­call. Abstract words, on the other hand, are purely ver­bal, and have to be un­der­stood through lan­guage alone.

To put it an­other way: Concrete words are eas­ier for us to process be­cause they are bun­dled with a web of as­so­ci­a­tions, tac­tile ex­pe­ri­ences, and mem­o­ries that an­chor their mean­ing. Here’s a more de­tailed view of the shift away from con­crete lan­guage:

Data source: Brysbaert Concreteness rat­ings for 40 thou­sand gen­er­ally known English word lem­mas. The dataset pro­vided 99.8% cov­er­age of the words in both lists. 6 words not in the dataset are not in­cluded in this chart: as, di­a­log, eng­lish, gai­ety, mad­den, old-fash­ioned.

While con­crete words have sen­sory ground­ing to carry their mean­ing, ab­stract words rely on other parts of speech to spec­ify, soften, or sharpen what they mean. That help tends to come from one par­tic­u­lar cor­ner of the lan­guage: ad­verbs.

The 2023 list con­tains more words over­all (2,809 vs. 2,284). All changes men­tioned in the text re­flect each cat­e­go­ry’s share of its list, not raw counts. Data source: NLTK (Natural Language Toolkit), with man­ual cor­rec­tion of mis­la­beled words.

Axe does­n’t need an ad­verb to mod­ify it; you know what it is. But ac­cept­able, rel­e­vant, and ad­e­quate come with con­di­tions, qual­i­fi­ca­tions, and de­grees that need to be spelled out. Adverbs do pre­cisely that: lan­guage to cal­i­brate lan­guage. Look through all the ad­verbs that were added:

ab­solutely­ac­tu­allya­longsideany­more­ap­par­entlyap­prox­i­matelyau­to­mat­i­cally­badly­barely­ba­si­cally­briefly­care­ful­lyc­er­tain­ly­clear­ly­close­ly­complete­ly­con­se­quent­ly­con­stant­ly­cur­rent­ly­deeply­def­i­nite­ly­d­if­fer­ent­ly­di­rect­ly­dra­mat­i­cal­lyeasi­ly­ef­fec­tive­lyen­tire­lye­qual­lyeven­tu­al­lyex­act­lyex­treme­ly­fair­ly­faith­ful­ly­fi­nal­ly­firm­ly­first­ly­forever­fre­quent­ly­ful­ly­fur­ther­more­gen­er­al­ly­gent­ly­grad­u­al­ly­great­ly­heav­i­ly­hence­high­ly­hope­ful­ly­im­me­di­ate­ly­in­creas­ing­lyini­tial­ly­large­lylit­er­al­ly­main­ly­mere­ly­month­ly­most­ly­nat­u­ral­lyn­ear­byn­ear­lynec­es­sar­i­lyn­ev­er­the­less­new­ly­nor­mal­ly­ob­vi­ous­ly­oc­ca­sion­al­ly­o­rig­i­nal­ly­over­sea­spar­tic­u­lar­ly­part­lyper­fect­lyper­son­al­ly­pos­si­bly­po­ten­tial­ly­pre­cise­lypre­sum­ablypre­vi­ous­lypri­mar­i­lyprob­a­blyprop­er­lyquick­lyqui­et­lyrapid­lyrarelyre­al­lyrea­son­ablyre­cent­lyre­gard­less­reg­u­lar­lyrel­a­tive­lyre­spec­tive­ly­roughl­y­sec­ondl­y­se­ri­ouslysig­nif­i­cantlysim­i­larlysim­plyslightlyslowlysome­what­specif­i­cally­strongly­sub­se­quently­suc­cess­fully­sud­denly­surely­surpris­ing­ly­to­tal­lytru­lytwice­typ­i­cal­lyul­ti­mate­lyun­for­tu­nate­lyusu­al­lyvir­tu­al­ly­widely

Most of the ad­verbs spec­ify de­gree, fre­quency, cer­tainty, and ex­tent. Some hedge (somewhat, partly, rel­a­tively, pos­si­bly, ap­prox­i­mately). Others as­sert (absolutely, def­i­nitely, en­tirely, ex­actly, pre­cisely). They’re all do­ing the same kind of work: Take a state­ment and tell you how much of it is true, how of­ten, and how cer­tain. It’s as if the world now re­quires you to be more pre­cise about every­thing.

Bread sur­vived both lists. Flour, wheat, har­vest and bake did­n’t. The word for what sus­tains us re­mained es­sen­tial, while the words for how we’d make it weren’t. That might be the most hon­est sum­mary of what hap­pened.

The world that made the 2023 list is more reg­u­lated, more con­nected, and in many ways more ca­pa­ble than the one be­hind the 1953 list. It’s a world fur­ther than our kitchen or home, reach­ing across economies, in­sti­tu­tions, and democ­ra­cies.

Today’s vo­cab­u­lary re­flects a life that is­n’t self-con­tained, but rather more sys­temic. It’s not so much about what’s within ar­m’s reach, but more about the larger world we nav­i­gate through. That sort of long-dis­tance con­nec­tion re­quires a par­tic­u­lar kind of lan­guage: ex­pan­sive, ab­stract, and pre­cise. And lan­guage, it turns out, can’t help it­self. It keeps track.

Methods & Notes

I com­pared two promi­nent vo­cab­u­lary lists for English learn­ers: the General Service List (GSL, 1953; 2,284 words) and the New General Service List (NGSL 1.2, 2023; 2,809 words). I la­beled words ap­pear­ing on both lists as remained” (1,656), words only on the 1953 list as removed” (628), and words only on the 2023 list as added” (1,153).

The GSL words came from the Simple English Wiktionary GSL. The NGSL words came from the of­fi­cial NGSL 1.2 file (“alphabetized and lem­ma­tized for re­search”). The NGSL uses lem­mas (one en­try per word fam­ily); the GSL some­times lists in­flected forms as sep­a­rate head­words. These lists track word forms deemed worth teach­ing based on fre­quency and use­ful­ness, not ab­stract con­cepts. For ex­am­ple, the word be­ing is on the GSL as its own head­word and was not in­cluded in the NGSL, But this does­n’t mean the con­cept of ex­is­tence left the lan­guage. In the NGSL it falls un­der be, which is on both lists.

Both lists were built for teach­ing, but ex­ter­nal re­search sug­gests each cov­ers a large share of every­day lan­guage use. About 84% of gen­eral English for the GSL and about 90% for the NGSL, de­pend­ing on the text and how words are counted. I did not re-run those cor­pus analy­ses my­self. I take the pub­lished ma­te­ri­als as given and rely on cov­er­age fig­ures from the list au­thors and from fol­low-up stud­ies (including an in­de­pen­dent check on American English by Stoeckel, 2019 — see foot­notes). That’s why the dif­fer­ences be­tween the lists felt worth ex­am­in­ing as more than a cur­ricu­lum up­date, with the caveat that nei­ther list is a neu­tral cen­sus of cul­ture.

All tagged words: re­mained, re­moved, and added, with se­man­tic tags, con­crete­ness rat­ings, and part-of-speech la­bels are in this pub­lic spread­sheet. You can also browse the word lists in the word-list panel on the right side of this page.

Each word was tagged with the UCREL Semantic Analysis System (USAS), us­ing the 21 top-level cat­e­gories. USAS also as­signs much finer sub-cat­e­gories (there are hun­dreds), but I stayed at the top level so the charts could show broad shifts with­out split­ting the words into overly gran­u­lar bins.

I chose not to cor­rect mis­la­bels. For ex­am­ple, ham­mer, nail, and wax are all tagged General and Abstract Terms”, but in USASs finer tags, they read as ac­tions (“to ham­mer,” to nail,” to wax”), not ob­jects. Out of con­text, many of these words go mul­ti­ple ways, and it did­n’t feel right to over­ride that case by case; USAS is an es­tab­lished lin­guis­tic frame­work, and swap­ping in my own judg­ment would mix two dif­fer­ent stan­dards.

For the sec­ond chart, I grouped USASs 21 cat­e­gories into five scope” do­mains (self, lo­cal, in­sti­tu­tional, so­cial, ab­stract). That group­ing is my ed­i­to­r­ial choice, not part of USAS. It came from notic­ing a spa­tial qual­ity to the trends seen across the 21 cat­e­gories.

Concreteness rat­ings come from Brysbaert et al. (2014). I used these as-is. Six words weren’t in the data­base and were left out of the con­crete­ness charts: as, di­a­log, eng­lish, gai­ety, mad­den, and old-fash­ioned.

Parts of speech were tagged with NLTK, sim­pli­fied to five cat­e­gories. Here I did in­ter­vene, but only when a word was clearly mis­la­beled (132 words, 3.8% of the list; mostly ad­jec­tives mis­la­beled as nouns). When a word can act as more than one part of speech de­pend­ing on con­text, I left the tag as-is and de­ferred to NLTK as the es­tab­lished frame­work, us­ing the pri­mary, most com­mon la­bel. Here I also used an LLM strictly to help flag po­ten­tial er­rors in NLTKs out­put.

Both lists rank words by fre­quency, then ap­ply learner-fo­cused cu­ra­tion. Michael West’s 1953 list es­pe­cially re­flects pe­riod ped­a­gogy. He fa­vored gen­eral-pur­pose vo­cab­u­lary over emo­tional or highly spe­cific words, not just what­ever ap­peared most of­ten (Therova, 2020, sum­ma­riz­ing West, 1953, pp. ix–x). Some of what looks like 1950s life” may also be how mid-cen­tury ESL teach­ing fil­tered the lan­guage. I still treat the lists as a por­trait of every­day English be­cause both cover a large share of run­ning text and speech that goes well be­yond the class­room.

On NGSLs ~90% cov­er­age: Browne, Culligan & Phillips, NGSL pro­ject. See also: A New General Service List: The Better Mousetrap We’ve Been Looking for?, Browne (2014); and An Examination of the New General Service List, Stoeckel (2019). ⏎

On GSLs ~84% cov­er­age: A gen­eral ser­vice list of English words with se­man­tic fre­quen­cies, West (1953); The New General Service List: A core vo­cab­u­lary for EFL stu­dents and teach­ers, Cambridge ELT (2018). ⏎

UCREL: Semantic Analysis System (USAS). ⏎

Concreteness rat­ings for 40 thou­sand gen­er­ally known English word lem­mas, Brysbaert, M., Warriner, A. B., & Kuperman, V. (2014). Behavior Research Methods, 46, 904 – 911. ⏎

Why are pic­tures eas­ier to re­call than words? Paivio, A., Rogers, T.B. & Smythe, P.C. Psychon Sci 11, 137 – 138 (1968). ⏎

Security Verification

www.ft.com

For help please visit help.ft.com. We apol­o­gise for any in­con­ve­nience.

The fol­low­ing in­for­ma­tion can help our sup­port team to re­solve this is­sue.

Blocked

old.reddit.com

whoa there, pard­ner!

Your re­quest has been blocked due to a net­work pol­icy.

Try log­ging in or cre­at­ing an ac­count here to get back to brows­ing.

If you’re run­ning a script or ap­pli­ca­tion, please reg­is­ter or sign in with your de­vel­oper cre­den­tials here. Additionally make sure your User-Agent is not empty and is some­thing unique and de­scrip­tive and try again. if you’re sup­ply­ing an al­ter­nate User-Agent string, try chang­ing back to de­fault as that can some­times re­sult in a block.

You can read Reddit’s Terms of Service here.

If you think that we’ve in­cor­rectly blocked you or you would like to dis­cuss eas­ier ways to get the data you want, please file a ticket here.

When con­tact­ing us, please in­clude your Reddit ac­count along with the fol­low­ing code:

019fc514 – 607e-7410-ba22 – 9a8313db3b69

Meshdiff — Compare 3D Model Versions

meshdiff.com

Bor v0.8.0 released

getbor.dev

Bor v0.8.0 is out. This re­lease adds three new pol­icy types — Thunderbird, Microsoft Edge for Business, and Firewalld zones — along­side a full web UI over­haul, finer-grained RBAC, and a ded­i­cated se­cu­rity hard­en­ing pass. The com­plete changelog is on the GitHub re­lease page.

Thunderbird pol­icy type

Mozilla Thunderbird can now be man­aged on en­rolled desk­tops with the same mech­a­nism used for Firefox ESR. The agent writes the man­aged poli­cies.json that Thunderbird ex­pects, merged from all bound poli­cies, and re­mov­ing the last pol­icy re­stores the orig­i­nal file. Flatpak in­stal­la­tions are de­tected and en­forced along­side RPM/DEB in­stal­la­tions, and the man­aged file is pro­tected by the tam­per watcher — ex­ter­nal ed­its are de­tected and im­me­di­ately re­stored. The web UI ships a full pol­icy ed­i­tor with the com­plete Thunderbird pol­icy cat­a­logue.

Microsoft Edge for Business pol­icy type

For fleets run­ning Edge on Linux, the agent writes bor_­man­aged.json into each Edge man­aged-pol­icy di­rec­tory and cleans it up from every di­rec­tory when the last bound pol­icy is re­moved. The web UI pro­vides a tree-based ed­i­tor with the Edge pol­icy cat­a­logue, JSON val­i­da­tion, and a set­ting pre­view be­fore en­abling.

Firewalld zone pol­icy type

The new Firewalld pol­icy type man­ages fire­walld zones on en­rolled nodes: ser­vices, ports, for­ward ports, rich rules, mas­quer­ade, in­ter­faces, sources, and the zone tar­get. The agent writes zone XML to /etc/firewalld/zones/, val­i­dates it with fire­wall-cmd –check-config, and re­loads fire­walld. Like all other man­aged files, the zone files are tam­per-pro­tected.

Polkit: vari­able con­di­tions

Polkit rules now sup­port vari­able con­di­tions via ac­tion.lookup(), so a rule can match on ac­tion vari­ables — for ex­am­ple al­low­ing mounts only for re­mov­able dri­ves. Also fixed: mul­ti­ple ac­tion IDs in one rule are now cor­rectly joined with ||.

Per-action RBAC

User and role ad­min­is­tra­tion is now guarded by per-ac­tion per­mis­sions in­stead of a sin­gle blan­ket per­mis­sion, al­low­ing finer-grained del­e­ga­tion of ad­min du­ties.

Web UI over­haul

A full mod­ern­iza­tion pass over the PatternFly 6 in­ter­face, span­ning sev­eral UX sprints. The dash­board shows the new look — grouped side­bar nav­i­ga­tion, a sin­gle left-aligned page ti­tle, and stat tiles that drill down to pre-fil­tered lists: click Offline and you land on the Nodes page al­ready fil­tered to of­fline nodes.

The high­lights:

URL rout­ing — every page has a real URL with work­ing browser back/​for­ward and deep links; ex­pired ses­sions redi­rect to lo­gin; a global er­ror bound­ary pre­vents white-screen crashes.

Full-page pol­icy ed­i­tor — the pol­icy ed­i­tor is now a routed page (/policies/:id/edit) in­stead of nested modals.

Policy safety rails — un­saved-changes guard, con­fir­ma­tion for de­struc­tive type changes, JSON val­i­da­tion for Chrome/Edge val­ues, a read-only Configuration view for re­leased poli­cies, and set­ting pre­views in the tree ed­i­tors.

Scalable lists — server-side pag­i­na­tion, fil­ter­ing, and sort­ing for Nodes and Compliance; search, sort­ing, and empty states across all list pages.

Destructive-action pro­tec­tion — type-to-con­firm di­alogs for all re­source deletes, plus server-side guards that pre­vent delet­ing, dis­abling, or de­mot­ing the last Super Admin.

Accessibility (WCAG 2.2 AA) — ac­ces­si­ble tree roles in the pol­icy ed­i­tors, aria-live sta­tus mes­sages, fo­cus-ring and dark-mode/​high-con­trast cor­rect­ness via PatternFly 6 de­sign to­kens, and an ac­ces­si­bil­ity lint gate in CI.

The pol­icy ed­i­tor is now a routed, full-width page in­stead of stacked modals, with room for the tree-based ed­i­tors be­hind each pol­icy type:

Node and com­pli­ance lists are pag­i­nated, fil­tered, and sorted server-side, so fleets with thou­sands of nodes stay fast:

Plus many qual­ity-of-life changes: poli­cies can be re­leased/​un­re­leased di­rectly from the list view, backup codes for MFA can be copied or down­loaded, the lo­gin form gained a pass­word re­veal tog­gle and Caps Lock hint, and the side­bar is now grouped into Fleet / Policy / System.

Proto-driven pol­icy cat­a­logues

The Firefox, Thunderbird, Chrome, and Edge pol­icy cat­a­logues shown in the web UI are now gen­er­ated from pro­to­buf an­no­ta­tions — one source of truth shared by the server, agent, and fron­tend.

Security hard­en­ing

This re­lease in­cludes a ded­i­cated hard­en­ing pass:

Agent iden­tity is now strictly bound to the mTLS client cer­tifi­cate, and MFA/RBAC en­force­ment paths were hard­ened on the server.

Legacy SHA-256-encrypted TOTP se­crets are trans­par­ently mi­grated to HKDF-derived en­cryp­tion on first read.

The Ubuntu PPA and Fedora COPR repos­i­tory im­port helpers now block redi­rect-based SSRF; only al­lowlisted redi­rect tar­gets are fol­lowed.

Audit log CSV ex­port is guarded against spread­sheet for­mula in­jec­tion.

The auto-gen­er­ated ini­tial ad­min pass­word is no longer printed to the server log (where it would land in jour­nald or cen­tral­ized log­ging); it is writ­ten to a root-only file in­stead.

The server TLS cer­tifi­cate is au­to­mat­i­cally re­gen­er­ated when its SANs no longer match the con­fig­ured host­names.

All open Dependabot alerts were re­solved, in­clud­ing the re­act-router RSC CSRF ad­vi­sory (GHSA-qwww-vcr4-c8h2).

Platform up­dates

The fron­tend moved to React 19.2 and re­act-router 8.3, with TypeScript type­check now en­forced in CI. Server and agent de­pen­den­cies were bumped, in­clud­ing gRPC 1.82.1 and golang.org/​x/​crypto 0.52.0.

Upgrade notes

Agents must be up­graded to v0.8.0 to en­force the new Thunderbird, Edge, and Firewalld pol­icy types; older agents ig­nore pol­icy types they do not un­der­stand.

The pro­to­buf pol­icy schema gained thun­der­bird.proto and fire­walld.proto and ex­tends the polkit and edge mes­sages — re­gen­er­ate any ex­ter­nal tool­ing built against proto/​pol­icy/.

Frontend de­vel­op­ment now re­quires Node.js 22.22+.

Download

Packages for Debian/Ubuntu, RHEL/Fedora/SUSE, Alpine Linux, and Arch Linux across x86_64, aarch64, and ppc64le are avail­able on the Download page.

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.

Visit pancik.com for more.