The topic of the Rust ex­per­i­ment was just dis­cussed at the an­nual

Maintainers Summit. The con­sen­sus among the as­sem­bled de­vel­op­ers is that

Rust in the ker­nel is no longer ex­per­i­men­tal — it is now a core part of the

ker­nel and is here to stay. So the “experimental” tag will be com­ing off.

Congratulations are in or­der for all of the Rust for Linux team.

(Stay tuned for de­tails in our Maintainers Summit cov­er­age.)

Copyright © 2025, Eklektix, Inc.

Comments and pub­lic post­ings are copy­righted by their cre­ators.

Linux is a reg­is­tered trade­mark of Linus Torvalds

I com­plained about this on the so­cials, but I did­n’t get it all out of my sys­tem. So now I write a blog post.

I’ve never liked the phi­los­o­phy of “put an icon in every menu item by de­fault”.

Google Sheets, for ex­am­ple, does this. Go to “File” or “Edit” or “View” and you’ll see a menu with a list of op­tions, every sin­gle one hav­ing an icon (same thing with the right-click con­text menu).

It’s ex­tra noise to me. It’s not that I think menu items should never have icons. I think they can be in­cred­i­bly use­ful (more on that be­low). It’s more that I don’t like the idea of “give each menu item an icon” be­ing the de­fault ap­proach.

This pos­ture lends it­self to a prac­tice where de­sign­ers have an at­ti­tude of “I need an icon to fill up this space” in­stead of an at­ti­tude of “Does the ad­di­tion of a icon here, and the cog­ni­tive load of pars­ing and un­der­stand­ing it, help or hurt how some­one would use this menu sys­tem?”

The for­mer does­n’t re­quire think­ing. It’s just tem­plat­ing — they all have icons, so we need to put some­thing there. The lat­ter re­quires care and thought­ful­ness for each use case and its con­text.

To de­fend my point, one of the ex­am­ples I al­ways pointed to was ma­cOS. For the longest time, Apple’s OS-level menus seemed to avoid this de­fault ap­proach of stick­ing icons in every menu item.

That is, un­til ma­cOS Tahoe shipped.

Tahoe now has icons in menus every­where. For ex­am­ple, here’s the Apple menu:

Let’s look at oth­ers. As I’m writ­ing this I have Safari open. Let’s look at the “Safari” menu:

Hmm. Interesting. Ok so we’ve got an icon for like half the menu items. I won­der why some get icons and oth­ers don’t?

For ex­am­ple, the “Settings” menu item (third from the top) has an icon. But the other item in its group­ing “Privacy Report” does not. I won­der why? Especially when Safari has an icon for Privacy re­port, like if you go to cus­tomize the tool­bar you’ll see it:

Hmm. Who knows? Let’s keep go­ing.

Let’s look at the “File” menu in Safari:

Some group­ings have icons and get in­set, while other group­ings don’t have icons and don’t get in­set. Interesting…again I won­der what the ra­tio­nale is here? How do you choose? It’s not clear to me.

Let’s keep go­ing. Let’s go to the “View” menu:

Oh boy, now we’re re­ally in it. Some of these menu items have the no­tion of a tog­gle (indicated by the check­mark) so now you’ve got all kinds of align­ment things to deal with. The vi­sual sym­bols are dou­bling-up when there’s a tog­gle and an icon.

The “View” menu in Mail is a sim­i­lar mix of:

You know what would be a fun game? Get a bunch of peo­ple in a room, show them menus where the tex­tual la­bels are gone, and see who can get the most right.

In so many of these cases, I hon­estly can’t in­tuit why some menus have icons and oth­ers do not. What are so many of these icons af­ford­ing me at the cost of ex­tra vi­sual and cog­ni­tive pars­ing? I don’t know.

To be fair, there are some menus where these vi­sual sym­bols are in­cred­i­bly use­ful. Take this menu from Finder:

The vi­sual de­pic­tion of how those are go­ing to align is ac­tu­ally in­cred­i­bly use­ful be­cause it’s way eas­ier for my brain to parse the sym­bol and un­der­stand where the win­dow is go­ing to go than it is to read the text and imag­ine in my head what “Top Left” or “Bottom & Top” or “Quarters” will mean. But a vi­sual sym­bol? I in­stantly get it!

Those are good icons in menus. I like those.

What I find re­ally in­ter­est­ing about this change on Apple’s part is how it seem­ingly goes against their own pre­vi­ous hu­man in­ter­face guide­lines (as pointed out to me by Peter Gassner).

They have an en­tire sec­tion in their 2005 guide­lines (and 1992 and 2020) ti­tled “Using Symbols in Menus”:

See what it says?There are a few stan­dard sym­bols you can use to in­di­cate ad­di­tional in­for­ma­tion in menus…Don’t use other, ar­bi­trary sym­bols in menus, be­cause they add vi­sual clut­ter and may con­fuse peo­ple.

They even have an ex­am­ple of what not to do and guess what it looks like? A menu in ma­cOS Tahoe.

It’s pretty ob­vi­ous how I feel. I’m tired of all this vi­sual noise in my menus.

And now that Apple has seem­ingly thrown in with the “stick an icon in every menu by de­fault” crowd, it’s harder than ever for me to con­vince peo­ple oth­er­wise. To per­suade, “Hey, un­less you can ar­tic­u­late a re­ally good rea­son to add this, maybe our de­fault pos­ture should be no icons in menus?”

So I guess this is the world I live in now. Icons in menus. Icons in menus every­where.

On September 14, 2015, our first pub­licly-trusted cer­tifi­cate went live. We were proud that we had is­sued a cer­tifi­cate that a sig­nif­i­cant ma­jor­ity of clients could ac­cept, and had done it us­ing au­to­mated soft­ware. Of course, in ret­ro­spect this was just the first of bil­lions of cer­tifi­cates. Today, Let’s Encrypt is the largest cer­tifi­cate au­thor­ity in the world in terms of cer­tifi­cates is­sued, the ACME pro­to­col we helped cre­ate and stan­dard­ize is in­te­grated through­out the server ecosys­tem, and we’ve be­come a house­hold name among sys­tem ad­min­is­tra­tors. We’re clos­ing in on pro­tect­ing one bil­lion web sites.

In 2023, we marked the tenth an­niver­sary of the cre­ation of our non­profit, Internet Security Research Group, which con­tin­ues to host Let’s Encrypt and other pub­lic ben­e­fit in­fra­struc­ture pro­jects. Now, in honor of the tenth an­niver­sary of Let’s Encrypt’s pub­lic cer­tifi­cate is­suance and the start of the gen­eral avail­abil­ity of our ser­vices, we’re look­ing back at a few mile­stones and fac­tors that con­tributed to our suc­cess.

A con­spic­u­ous part of Let’s Encrypt’s his­tory is how thor­oughly our vi­sion of scal­a­bil­ity through au­toma­tion has suc­ceeded.

In March 2016, we is­sued our one mil­lionth cer­tifi­cate. Just two years later, in September 2018, we were is­su­ing a mil­lion cer­tifi­cates every day. In 2020 we reached a bil­lion to­tal cer­tifi­cates is­sued and as of late 2025 we’re fre­quently is­su­ing ten mil­lion cer­tifi­cates per day. We’re now on track to reach a bil­lion ac­tive sites, prob­a­bly some­time in the com­ing year. (The “certificates is­sued” and “certificates ac­tive” met­rics are quite dif­fer­ent be­cause our cer­tifi­cates reg­u­larly ex­pire and get re­placed.)

The steady growth of our is­suance vol­ume shows the strength of our ar­chi­tec­ture, the va­lid­ity of our vi­sion, and the great ef­forts of our en­gi­neer­ing team to scale up our own in­fra­struc­ture. It also re­minds us of the con­fi­dence that the Internet com­mu­nity is plac­ing in us, mak­ing the use of a Let’s Encrypt cer­tifi­cate a nor­mal and, dare we say, bor­ing choice. But I of­ten point out that our ever-grow­ing is­suance vol­umes are only an in­di­rect mea­sure of value. What ul­ti­mately mat­ters is im­prov­ing the se­cu­rity of peo­ple’s use of the web, which, as far as Let’s Encrypt’s con­tri­bu­tion goes, is not mea­sured by is­suance vol­umes so much as by the preva­lence of HTTPS en­cryp­tion. For that rea­son, we’ve al­ways em­pha­sized the graph of the per­cent­age of en­crypted con­nec­tions that web users make (here rep­re­sented by sta­tis­tics from Firefox).

(These graphs are snap­shots as of the date of this post; a dy­nam­i­cally up­dated ver­sion is found on our stats page.) Our biggest goal was to make a con­crete, mea­sur­able se­cu­rity im­pact on the web by get­ting HTTPS con­nec­tion preva­lence to in­crease—and it’s worked. It took five years or so to get the global per­cent­age from be­low 30% to around 80%, where it’s re­mained ever since. In the U. S. it has been close to 95% for a while now.

A good amount of the re­main­ing un­en­crypted traf­fic prob­a­bly comes from in­ter­nal or pri­vate or­ga­ni­za­tional sites (intranets), but other than that we don’t know much about it; this would be a great topic for Internet se­cu­rity re­searchers to look into.

We be­lieve our pre­sent growth in cer­tifi­cate is­suance vol­ume is es­sen­tially com­ing from growth in the web as a whole. In other words, if we pro­tect 20% more sites over some time pe­riod, it’s be­cause the web it­self grew by 20%.

We’ve blogged about most of Let’s Encrypt’s most sig­nif­i­cant mile­stones as they’ve hap­pened, and I in­vite every­one in our com­mu­nity to look over those blog posts to see how far we’ve come. We’ve also pub­lished an­nual re­ports for the past seven years, which of­fer el­e­gant and con­cise sum­maries of our work.

As I per­son­ally think back on the past decade, just a few of the many events that come to mind in­clude:

Telling the world about the pro­ject in November 2014

Our one mil­lionth cer­tifi­cate in March 2016, then our 100 mil­lionth cer­tifi­cate in June 2017, and then our bil­lionth cer­tifi­cate in 2020

Along the way, first is­su­ing one mil­lion cer­tifi­cates in a sin­gle day (in September 2018), sig­nif­i­cantly con­tributed to by the SquareSpace and Shopify Let’s Encrypt in­te­gra­tions

Just at the end of September 2025, we is­sued more than ten mil­lion cer­tifi­cates in a day for the first time.

We’ve also pe­ri­od­i­cally rolled out new fea­tures such as in­ter­na­tion­al­ized do­main name sup­port (2016), wild­card sup­port (2018), and short-lived and IP ad­dress (2025) cer­tifi­cates. We’re al­ways work­ing on more new fea­tures for the fu­ture.

There are many tech­ni­cal mile­stones like our data­base server up­grades in 2021, where we found we needed a se­ri­ous server in­fra­struc­ture boost be­cause of the tremen­dous vol­umes of data we were deal­ing with. Similarly, our orig­i­nal in­fra­struc­ture was us­ing Gigabit Ethernet in­ter­nally, and, with the growth of our is­suance vol­ume and log­ging, we found that our Gigabit Ethernet net­work even­tu­ally be­came too slow to syn­chro­nize data­base in­stances! (Today we’re us­ing 25-gig Ethernet.) More re­cently, we’ve ex­per­i­mented with ar­chi­tec­tural up­grades to our ever-grow­ing Certificate Transparency logs, and de­cided to go ahead with de­ploy­ing those up­grades—to help us not just keep up with, but get ahead of, our con­tin­u­ing growth.

These kinds of grow­ing pains and suc­cess­ful re­sponses to them are nice to re­mem­ber be­cause they point to the in­ex­orable in­crease in de­mands on our in­fra­struc­ture as we’ve be­come a more and more es­sen­tial part of the Internet. I’m proud of our tech­ni­cal teams which have han­dled those in­creased de­mands ca­pa­bly and pro­fes­sion­ally.

I also re­call the on­go­ing work in­volved in mak­ing sure our cer­tifi­cates would be as widely ac­cepted as pos­si­ble, which has meant man­ag­ing the orig­i­nal cross-sig­na­ture from IdenTrust, and sub­se­quently cre­at­ing and prop­a­gat­ing our own root CA cer­tifi­cates. This process has re­quired PKI en­gi­neer­ing, key cer­e­monies, root pro­gram in­ter­ac­tions, doc­u­men­ta­tion, and com­mu­nity sup­port as­so­ci­ated with cer­tifi­cate mi­gra­tions. Most users never have rea­son to look be­hind the scenes at our chains of trust, but our en­gi­neers up­date it as root and in­ter­me­di­ate cer­tifi­cates have been re­placed. We’ve en­gaged at the CA/B Forum, IETF, and in other venues with the browser root pro­grams to help shape the web PKI as a tech­ni­cal leader.

As I wrote in 2020, our ideal of com­plete au­toma­tion of the web PKI aims at a world where most site own­ers would­n’t even need to think about cer­tifi­cates at all. We con­tinue to get closer and closer to that world, which cre­ates a risk that peo­ple will take us and our ser­vices for granted, as the de­tails of cer­tifi­cate re­newal oc­cupy less of site op­er­a­tors’ men­tal en­ergy. As I said at the time,

When your strat­egy as a non­profit is to get out of the way, to of­fer ser­vices that peo­ple don’t need to think about, you’re run­ning a real risk that you’ll even­tu­ally be taken for granted. There is a ten­sion be­tween want­ing your work to be in­vis­i­ble and the need for recog­ni­tion of its value. If peo­ple aren’t aware of how valu­able our ser­vices are then we may not get the sup­port we need to con­tinue pro­vid­ing them.

I’m also grate­ful to our com­mu­ni­ca­tions and fundrais­ing staff who help make clear what we’re do­ing every day and how we’re mak­ing the Internet safer.

Our com­mu­nity con­tin­u­ally rec­og­nizes our work in tan­gi­ble ways by us­ing our cer­tifi­cates—now by the tens of mil­lions per day—and by spon­sor­ing us.

We were hon­ored to be rec­og­nized with awards in­clud­ing the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the in­di­vid­u­als who got Let’s Encrypt started were hon­ored to re­ceive the IEEE Cybersecurity Award for Practice.

We doc­u­mented the his­tory, de­sign, and goals of the pro­ject in an aca­d­e­mic pa­per at the ACM CCS ’19 con­fer­ence, which has sub­se­quently been cited hun­dreds of times in aca­d­e­mic re­search.

Ten years later, I’m still deeply grate­ful to the five ini­tial spon­sors that got Let’s Encrypt off the ground - Mozilla, EFF, Cisco, Akamai, and IdenTrust. When they com­mit­ted sig­nif­i­cant re­sources to the pro­ject, it was just an am­bi­tious idea. They saw the po­ten­tial and be­lieved in our team, and be­cause of that we were able to build the ser­vice we op­er­ate to­day.

I’d like to par­tic­u­larly rec­og­nize IdenTrust, a PKI com­pany that worked as a part­ner from the out­set and en­abled us to is­sue pub­licly-trusted cer­tifi­cates via a cross-sig­na­ture from one of their roots. We would sim­ply not have been able to launch our pub­licly-trusted cer­tifi­cate ser­vice with­out them. Back when I first told them that we were start­ing a new non­profit cer­tifi­cate au­thor­ity that would give away mil­lions of cer­tifi­cates for free, there was­n’t any prece­dent for this arrange­ment, and there was­n’t nec­es­sar­ily much rea­son for IdenTrust to pay at­ten­tion to our pro­posal. But the com­pany re­ally un­der­stood what we were try­ing to do and was will­ing to en­gage from the be­gin­ning. Ultimately, IdenTrust’s sup­port made our orig­i­nal is­suance model a re­al­ity.

I’m proud of what we have achieved with our staff, part­ners, and donors over the past ten years. I hope to be even more proud of the next ten years, as we use our strong foot­ing to con­tinue to pur­sue our mis­sion to pro­tect Internet users by low­er­ing mon­e­tary, tech­no­log­i­cal, and in­for­ma­tional bar­ri­ers to a more se­cure and pri­vacy-re­spect­ing Internet.

Let’s Encrypt is a pro­ject of the non­profit Internet Security Research Group, a 501(c)(3) non­profit. You can help us make the next ten years great as well by do­nat­ing or be­com­ing a spon­sor.

The stu­dents at America’s elite uni­ver­si­ties are sup­posed to be the smartest, most promis­ing young peo­ple in the coun­try. And yet, shock­ing per­cent­ages of them are claim­ing aca­d­e­mic ac­com­mo­da­tions de­signed for stu­dents with learn­ing dis­abil­i­ties.

In an ar­ti­cle pub­lished this week in The Atlantic, ed­u­ca­tion re­porter Rose Horowitch lays out some shock­ing num­bers. At Brown and Harvard, 20 per­cent of un­der­grad­u­ate stu­dents are dis­abled. At Amherst College, that’s 34 per­cent. At Stanford University, it’s a galling 38 per­cent. Most of these stu­dents are claim­ing men­tal health con­di­tions and learn­ing dis­abil­i­ties, like anx­i­ety, de­pres­sion, and ADHD.

Obviously, some­thing is off here. The idea that some of the most elite, se­lec­tive uni­ver­si­ties in America—schools that re­quire 99th per­centile SATs and ster­ling es­says—would be ed­u­cat­ing large num­bers of gen­uinely learn­ing dis­abled stu­dents is clearly bo­gus. A stu­dent with real cog­ni­tive strug­gles is much more likely to end up in com­mu­nity col­lege, or not in higher ed­u­ca­tion at all, right?

The pro­fes­sors Horowitz in­ter­viewed largely back up this the­ory. “You hear ‘students with dis­abil­i­ties’ and it’s not kids in wheel­chairs,” one pro­fes­sor told Horowitch. “It’s just not. It’s rich kids get­ting ex­tra time on tests.” Talented stu­dents get to col­lege, start strug­gling, and run for a di­ag­no­sis to avoid bad grades. Ironically, the very schools that cog­ni­tively chal­lenged stu­dents are most likely to at­tend—com­mu­nity col­leges—have far lower rates of dis­abled stu­dents, with only three to four per­cent of such stu­dents get­ting ac­com­mo­da­tions.

To be fair, some of the stu­dents re­ceiv­ing these ac­com­mo­da­tions do need them. But the cur­rent lan­guage of the Americans with Disabilities Act (ADA) al­lows stu­dents to get ex­pan­sive ac­com­mo­da­tions with lit­tle more than a doc­tor’s note.

While some stu­dents are no doubt seek­ing these ac­com­mo­da­tions as semi-con­scious cheaters, I think most gen­uinely iden­tify with the men­tal health con­di­tion they’re us­ing to get ex­tra time on tests. Over the past few years, there’s been a ris­ing push to see men­tal health and neu­rode­vel­op­men­tal con­di­tions as not just a med­ical fact, but an iden­tity marker. Will Lindstrom, the di­rec­tor of the Regents’ Center for Learning Disorders at the University of Georgia, told Horowitch that he sees a grow­ing num­ber of stu­dents with this per­spec­tive. “It’s al­most like it’s part of their iden­tity,” Lindstrom told her. “By the time we see them, they’re con­vinced they have a neu­rode­vel­op­men­tal dis­or­der.”

What’s dri­ving this trend? Well, the way con­di­tions like ADHD, autism, and anx­i­ety get talked about on­line—the place where most young peo­ple first learn about these con­di­tions—is prob­a­bly a con­tribut­ing fac­tor. Online cre­ators tend to paint a very broad pic­ture of the con­di­tions they de­scribe. A quick scroll of TikTok re­veals cre­ators la­bel­ing every­thing from al­ways wear­ing head­phones, to be­ing bad at man­ag­ing your time, to doo­dling in class as a sign that some­one may have a di­ag­nos­able con­di­tion. According to these videos, who is­n’t dis­abled?

The re­sult is a deeply dis­torted view of “normal.” If ever strug­gling to fo­cus or ex­pe­ri­enc­ing bore­dom is a sign you have ADHD, the im­pli­ca­tion is that a “normal,” nondis­abled per­son has es­sen­tially no prob­lems. A “neurotypical” per­son, the think­ing goes, can churn out a 15-page pa­per with no hint of pro­cras­ti­na­tion, main­tain per­fect fo­cus dur­ing a bor­ing lec­ture, and never ex­pe­ri­ence so­cial anx­i­ety or awk­ward­ness. This view is buf­feted by the cur­rent way many of these con­di­tions are di­ag­nosed. As Horowitch points out, when the lat­est is­sue of the DSM, the man­ual psy­chi­a­trists use to di­ag­nose pa­tients, was re­leased in 2013, it sig­nif­i­cantly low­ered the bar for an ADHD di­ag­no­sis. When the de­f­i­n­i­tion of these con­di­tions is set so lib­er­ally, it’s easy to imag­ine a highly in­tel­li­gent Stanford stu­dent be­com­ing con­vinced that any sign of aca­d­e­mic strug­gle proves they’re learn­ing dis­abled, and any prob­lems mak­ing friends are a sign they have autism.

Risk-aversion, too, seems like a com­pelling fac­tor dri­ving bright stu­dents to claim learn­ing dis­abil­i­ties. Our na­tion’s most promis­ing stu­dents are also its least as­sured. So afraid of fail­ure—of bad grades, of a poorly-re­ceived es­say—they take any sign of strug­gle as a di­ag­nos­able con­di­tion. A few decades ago, a stu­dent who en­tered col­lege and found the ma­te­r­ial harder to mas­ter and their time less eas­ily man­aged than in high school would have been seen as rel­a­tively nor­mal. Now, every time she picks up her phone, a bar­rage of in­flu­encers is clam­or­ing to tell her this is a sign she has ADHD. Discomfort and dif­fi­culty are no longer per­ceived as typ­i­cal parts of grow­ing up.

In this con­text, it’s easy to read the rise of aca­d­e­mic ac­com­mo­da­tions among the na­tion’s most in­tel­li­gent stu­dents as yet an­other man­i­fes­ta­tion of the risk-aver­sion en­demic in the striv­ing chil­dren of the up­per mid­dle class. For most of the elite-col­lege stu­dents who re­ceive them, aca­d­e­mic ac­com­mo­da­tions are a pro­tec­tion against fail­ure and self-doubt. Unnecessary ac­com­mo­da­tions are a two-front form of cheat­ing—they give you an un­just leg-up on your fel­low stu­dents, but they also al­low you to cheat your­self out of gen­uine in­tel­lec­tual growth. If you mask learn­ing de­fi­cien­cies with ex­tra time on texts, soothe so­cial anx­i­ety by for­go­ing pre­sen­ta­tions, and ne­glect time man­age­ment skills with dead­line ex­ten­sions, you might forge a path to bet­ter grades. But you’ll also find your­self less ca­pa­ble of tack­ling the chal­lenges of adult life.

My name is Bruno Simon, and I’m a cre­ative de­vel­oper (mostly for the web).

This is my port­fo­lio. Please drive around to learn more about me and dis­cover the many se­crets of this world.

Teleports you to the clos­est respawn

Respawn

Server cur­rently of­fline. Scores can’t be saved.

- Everyone can see them

- New whis­pers re­move old ones (max 30)

- One whis­per per user

- Choose a flag

- No slur!

- Max 30 char­ac­ters

Thank you for vis­it­ing my port­fo­lio!

If you are cu­ri­ous about the stack and how I built it, here’s every­thing you need to know.

Three.js is the li­brary I’m us­ing to ren­der this 3D world.

It was cre­ated by mr.doob (X, GitHub), fol­lowed by hun­dreds of awe­some de­vel­op­ers, one of which be­ing Sunag (X, GitHub) who added TSL, en­abling the use of both WebGL and WebGPU, mak­ing this port­fo­lio pos­si­ble.

If you want to learn Three.js, I got you cov­ered with this huge course.

It con­tains every­thing you need to start build­ing awe­some stuff with Three.js (and much more).

I’ve been mak­ing de­vlogs since the very start of this port­fo­lio and you can find them on my Youtube chan­nel.

Even though the port­fo­lio is out, I’m still work­ing on the last videos so that the se­ries is com­plete.

The code is avail­able on GitHub un­der MIT li­cense. Even the Blender files are there, so have fun!

For se­cu­rity rea­sons, I’m not shar­ing the server code, but the port­fo­lio works with­out it.

The mu­sic you hear was made es­pe­cially for this port­fo­lio by the awe­some Kounine (Linktree).

They are now un­der CC0 li­cense, mean­ing you can do what­ever you want with them!

Download them here.

Server cur­rently of­fline. Scores can’t be saved.

Come hang out with the com­mu­nity, show us your pro­jects and ask us any­thing.

Contact me di­rectly.

I have to warn you, I try to an­swer every­one, but it might take a while.

Update 2025/02/04: Oracle asks the USPTO to dis­miss our pe­ti­tion. Read more

Update 2024/11/22: We’ve filed a pe­ti­tion to can­cel with the USPTO. Read more

Update 2025/02/04: Oracle asks the USPTO to dis­miss our pe­ti­tion. Read more

Update 2024/11/22: We’ve filed a pe­ti­tion to can­cel with the USPTO. Read more

You have long ago aban­doned the JavaScript trade­mark, and it is caus­ing

wide­spread, un­war­ranted con­fu­sion and dis­rup­tion.

JavaScript is the world’s most pop­u­lar pro­gram­ming lan­guage, pow­er­ing web­sites every­where. Yet, few of the mil­lions who pro­gram in it re­al­ize that JavaScript is a trade­mark you, Oracle, con­trol. The dis­con­nect is glar­ing: JavaScript has be­come a gen­eral-pur­pose term used by count­less in­di­vid­u­als and com­pa­nies, in­de­pen­dent of any Oracle prod­uct.

Oracle’s hold on the JavaScript trade­mark clearly fits the le­gal de­f­i­n­i­tion of

trade­mark aban­don­ment. A pre­vi­ous

blog post ad­dressed this is­sue, re­quest­ing that you, Oracle, re­lease the trade­mark. Unsurprisingly, the re­quest was met with si­lence. It is there­fore time to take ac­tive steps in or­der to bring the JavaScript trade­mark into the pub­lic do­main, where it be­longs.

A mark shall be deemed to be “abandoned” if ei­ther of the fol­low­ing oc­curs:

When

its use has

been dis­con­tin­ued with in­tent not to re­sume

such use.

Intent not to re­sume may be in­ferred from cir­cum­stances. Nonuse for 3

con­sec­u­tive years shall be prima fa­cie ev­i­dence of aban­don­ment.

“Use”

of

a mark means

the bona

fide use of

such mark made

in the or­di­nary course of trade, and not made merely to re­serve a right in

a mark.

When any course of con­duct of the owner, in­clud­ing acts of omis­sion as well

as com­mis­sion, causes

the mark to

be­come the generic name for the goods or ser­vices on or in con­nec­tion with

which it is used or oth­er­wise to lose its sig­nif­i­cance as

a mark.

Purchaser mo­ti­va­tion shall not be a test for de­ter­min­ing aban­don­ment un­der

this para­graph.

In the case of JavaScript, both cri­te­ria ap­ply.

The JavaScript trade­mark is cur­rently held by Oracle America, Inc. (US Serial Number: 75026640, US Registration Number: 2416017). How did this come to be?

In 1995, Netscape part­nered with Sun Microsystems to cre­ate in­ter­ac­tive web­sites. Brendan Eich fa­mously spent only 10 days cre­at­ing the first ver­sion of JavaScript, a dy­namic pro­gram­ming lan­guage with a rough syn­tac­tic lin­eage from Sun’s Java lan­guage. As a re­sult of this part­ner­ship, Sun held the JavaScript trade­mark. In 2009, Oracle ac­quired Sun Microsystems and the JavaScript trade­mark as a re­sult.

The trade­mark is sim­ply a relic of this ac­qui­si­tion. Neither Sun nor Oracle has ever built a prod­uct us­ing the mark. Legal staff, year af­ter year, have re­newed the trade­mark with­out ques­tion. It’s likely that only a few within Oracle even know they pos­sess the JavaScript trade­mark, and even if they do, they likely don’t un­der­stand the frus­tra­tion it causes within the de­vel­oper com­mu­nity.

Oracle has aban­doned the JavaScript trade­mark through nonuse.

Oracle has never se­ri­ously of­fered a prod­uct called JavaScript. In the 1990s and early 2000s, Netscape Navigator, which sup­ported JavaScript as a browser fea­ture, was a key player. However, Netscape’s us­age and in­flu­ence faded by 2003, and the browser saw its fi­nal re­lease in 2008. JavaScript, mean­while, evolved into a widely used, in­de­pen­dent pro­gram­ming lan­guage, em­bed­ded in mul­ti­ple browsers, en­tirely sep­a­rate from Oracle.

The most re­cent

spec­i­men, filed with the USPTO in 2019, ref­er­ences nodejs.org (a pro­ject cre­ated by Ryan Dahl, the au­thor of this let­ter) and Oracle’s

JavaScript Extension Toolkit (JET). But Node.js is not an Oracle prod­uct, and JET is merely a set of JavaScript li­braries for Oracle ser­vices, par­tic­u­larly Oracle Cloud. There are mil­lions of JavaScript li­braries; JET is not spe­cial.

Oracle also of­fers GraalVM, a JVM that can ex­e­cute JavaScript, among other lan­guages. But GraalVM is far from a canon­i­cal JavaScript im­ple­men­ta­tion; en­gines like V8, JavaScriptCore, and SpiderMonkey hold that role. GraalVM’s prod­uct page does­n’t even men­tion “JavaScript”; you must dig into the doc­u­men­ta­tion to find its sup­port.

Oracle’s use of JavaScript in GraalVM and JET does not re­flect gen­uine use of

the trade­mark. These weak con­nec­tions do not sat­isfy the re­quire­ment for con­sis­tent, real-world use in trade.

A mark can also be con­sid­ered aban­doned if it be­comes a generic term.

In 1996, Netscape

an­nounced

a meet­ing of the ECMA International stan­dards or­ga­ni­za­tion to stan­dard­ize the JavaScript pro­gram­ming lan­guage. Sun (now Oracle), re­fused to give up the “JavaScript” mark for this use though, so it was de­cided that the lan­guage would be called “ECMAScript” in­stead. (Microsoft hap­pily of­fered up “JScript”, but no-one else wanted that.) Brendan Eich, the cre­ator of JavaScript and a co-sig­na­tory of this let­ter,

wrote in 2006

that “ECMAScript was al­ways an un­wanted trade name that sounds like a skin dis­ease.”

Ecma International formed TC39, a tech­ni­cal steer­ing com­mit­tee, which pub­lishes ECMA-262, the spec­i­fi­ca­tion for JavaScript. This com­mit­tee in­cludes par­tic­i­pants from all ma­jor browsers, like Google’s Chrome, Apple’s Safari, and Mozilla’s Firefox, as well as rep­re­sen­ta­tives from server-side JavaScript run­times like Node.js and Deno.

Oracle’s own­er­ship of the JavaScript trade­mark only causes con­fu­sion. The term “JavaScript” is used freely by mil­lions of de­vel­op­ers, com­pa­nies, and or­ga­ni­za­tions around the world, with no in­ter­fer­ence from Oracle. Oracle has done noth­ing to as­sert its rights over the JavaScript name, likely be­cause they do not be­lieve their claim to the mark would hold up in court. Unlike typ­i­cal trade­mark hold­ers who pro­tect their trade­marks by ex­tract­ing li­cens­ing fees or en­forc­ing us­age re­stric­tions, Oracle has al­lowed the JavaScript name to be used by any­one. This in­ac­tion fur­ther sup­ports the ar­gu­ment that the trade­mark has lost its sig­nif­i­cance and has be­come generic.

Programmers work­ing with JavaScript have formed in­nu­mer­able com­mu­nity or­ga­ni­za­tions. These or­ga­ni­za­tions, like the stan­dards bod­ies, have been forced to painstak­ingly avoid nam­ing the pro­gram­ming lan­guage they are built around—for ex­am­ple, JSConf. Sadly, with­out risk­ing a le­gal trade­mark chal­lenge against Oracle, there can be no “JavaScript Conference” nor a “JavaScript Specification.” The world’s most pop­u­lar pro­gram­ming lan­guage can­not even have a con­fer­ence in its name.

There is a vast mis­align­ment be­tween the trade­mark’s own­er­ship and its

wide­spread, generic use.

By law, a trade­mark is aban­doned if it is ei­ther not used or be­comes a generic

term. Both ap­ply to JavaScript.

It’s time for the USPTO to end the JavaScript trade­mark and rec­og­nize it as a generic name for the world’s most pop­u­lar pro­gram­ming lan­guage, which has mul­ti­ple im­ple­men­ta­tions across the in­dus­try.

Oracle, you likely have no real busi­ness in­ter­est in the mark. It’s re­newed sim­ply be­cause le­gal staff are ob­lig­ated to re­new all trade­marks, re­gard­less of their rel­e­vance or use.

We urge you to re­lease the mark into the pub­lic do­main. However, ask­ing nicely has been tried be­fore, and it was met with si­lence. If you do not act, we will chal­lenge your own­er­ship by fil­ing a pe­ti­tion for can­cel­la­tion with the USPTO.

Today, we’re re­leas­ing Devstral 2—our next-gen­er­a­tion cod­ing model fam­ily avail­able in two sizes: Devstral 2 (123B) and Devstral Small 2 (24B). Devstral 2 ships un­der a mod­i­fied MIT li­cense, while Devstral Small 2 uses Apache 2.0. Both are open-source and per­mis­sively li­censed to ac­cel­er­ate dis­trib­uted in­tel­li­gence.

Devstral 2 is cur­rently free to use via our API.

We are also in­tro­duc­ing Mistral Vibe, a na­tive CLI built for Devstral that en­ables end-to-end code au­toma­tion.

Devstral 2: SOTA open model for code agents with a frac­tion of the pa­ra­me­ters of its com­peti­tors and achiev­ing 72.2% on SWE-bench Verified.

Up to 7x more cost-ef­fi­cient than Claude Sonnet at real-world tasks.

Devstral Small 2: 24B pa­ra­me­ter model avail­able via API or de­ploy­able lo­cally on con­sumer hard­ware.

Devstral 2 is a 123B-parameter dense trans­former sup­port­ing a 256K con­text win­dow. It reaches 72.2% on SWE-bench Verified—establishing it as one of the best open-weight mod­els while re­main­ing highly cost ef­fi­cient. Released un­der a mod­i­fied MIT li­cense, Devstral sets the open state-of-the-art for code agents.

Devstral Small 2 scores 68.0% on SWE-bench Verified, and places firmly among mod­els up to five times its size while be­ing ca­pa­ble of run­ning lo­cally on con­sumer hard­ware.

Devstral 2 (123B) and Devstral Small 2 (24B) are 5x and 28x smaller than DeepSeek V3.2, and 8x and 41x smaller than Kimi K2—proving that com­pact mod­els can match or ex­ceed the per­for­mance of much larger com­peti­tors. Their re­duced size makes de­ploy­ment prac­ti­cal on lim­ited hard­ware, low­er­ing bar­ri­ers for de­vel­op­ers, small busi­nesses, and hob­by­ists.hard­ware.

Devstral 2 sup­ports ex­plor­ing code­bases and or­ches­trat­ing changes across mul­ti­ple files while main­tain­ing ar­chi­tec­ture-level con­text. It tracks frame­work de­pen­den­cies, de­tects fail­ures, and re­tries with cor­rec­tions—solv­ing chal­lenges like bug fix­ing and mod­ern­iz­ing legacy sys­tems.

The model can be fine-tuned to pri­or­i­tize spe­cific lan­guages or op­ti­mize for large en­ter­prise code­bases.

We eval­u­ated Devstral 2 against DeepSeek V3.2 and Claude Sonnet 4.5 us­ing hu­man eval­u­a­tions con­ducted by an in­de­pen­dent an­no­ta­tion provider, with tasks scaf­folded through Cline. Devstral 2 shows a clear ad­van­tage over DeepSeek V3.2, with a 42.8% win rate ver­sus 28.6% loss rate. However, Claude Sonnet 4.5 re­mains sig­nif­i­cantly pre­ferred, in­di­cat­ing a gap with closed-source mod­els per­sists.

“Devstral 2 is at the fron­tier of open-source cod­ing mod­els. In Cline, it de­liv­ers a tool-call­ing suc­cess rate on par with the best closed mod­els; it’s a re­mark­ably smooth dri­ver. This is a mas­sive con­tri­bu­tion to the open-source ecosys­tem.” — Cline.

“Devstral 2 was one of our most suc­cess­ful stealth launches yet, sur­pass­ing 17B to­kens in the first 24 hours. Mistral AI is mov­ing at Kilo Speed with a cost-ef­fi­cient model that truly works at scale.” — Kilo Code.

Devstral Small 2, a 24B-parameter model with the same 256K con­text win­dow and re­leased un­der Apache 2.0, brings these ca­pa­bil­i­ties to a com­pact, lo­cally de­ploy­able form. Its size en­ables fast in­fer­ence, tight feed­back loops, and easy cus­tomiza­tion—with fully pri­vate, on-de­vice run­time. It also sup­ports im­age in­puts, and can power mul­ti­modal agents.

Mistral Vibe CLI is an open-source com­mand-line cod­ing as­sis­tant pow­ered by Devstral. It ex­plores, mod­i­fies, and ex­e­cutes changes across your code­base us­ing nat­ural lan­guage—in your ter­mi­nal or in­te­grated into your pre­ferred IDE via the Agent Communication Protocol. It is re­leased un­der the Apache 2.0 li­cense.

Vibe CLI pro­vides an in­ter­ac­tive chat in­ter­face with tools for file ma­nip­u­la­tion, code search­ing, ver­sion con­trol, and com­mand ex­e­cu­tion. Key fea­tures:

Project-aware con­text: Automatically scans your file struc­ture and Git sta­tus to pro­vide rel­e­vant con­text

Smart ref­er­ences: Reference files with @ au­to­com­plete, ex­e­cute shell com­mands with !, and use slash com­mands for con­fig­u­ra­tion changes

Multi-file or­ches­tra­tion: Understands your en­tire code­base—not just the file you’re edit­ing—en­abling ar­chi­tec­ture-level rea­son­ing that can halve your PR cy­cle time

You can run Vibe CLI pro­gram­mat­i­cally for script­ing, tog­gle auto-ap­proval for tool ex­e­cu­tion, con­fig­ure lo­cal mod­els and providers through a sim­ple con­fig.toml, and con­trol tool per­mis­sions to match your work­flow.

Devstral 2 is cur­rently of­fered free via our API. After the free pe­riod, the API pric­ing will be $0.40/$2.00 per mil­lion to­kens (input/output) for Devstral 2 and $0.10/$0.30 for Devstral Small 2.

We’ve part­nered with lead­ing, open agent tools Kilo Code and Cline to bring Devstral 2 to where you al­ready build.

Mistral Vibe CLI is avail­able as an ex­ten­sion in Zed, so you can use it di­rectly in­side your IDE.

Devstral 2 is op­ti­mized for data cen­ter GPUs and re­quires a min­i­mum of 4 H100-class GPUs for de­ploy­ment. You can try it to­day on build.nvidia.com. Devstral Small 2 is built for sin­gle-GPU op­er­a­tion and runs across a broad range of NVIDIA sys­tems, in­clud­ing DGX Spark and GeForce RTX. NVIDIA NIM sup­port will be avail­able soon.

Devstral Small runs on con­sumer-grade GPUs as well as CPU-only con­fig­u­ra­tions with no ded­i­cated GPU re­quired.

For op­ti­mal per­for­mance, we rec­om­mend a tem­per­a­ture of 0.2 and fol­low­ing the best prac­tices de­fined for Mistral Vibe CLI.

We’re ex­cited to see what you will build with Devstral 2, Devstral Small 2, and Vibe CLI!

Share your pro­jects, ques­tions, or dis­cov­er­ies with us on X/Twitter, Discord, or GitHub.

If you’re in­ter­ested in shap­ing open-source re­search and build­ing world-class in­ter­faces that bring truly open, fron­tier AI to users, we wel­come you to ap­ply to join our team.

To use the Mastodon web ap­pli­ca­tion, please en­able JavaScript. Alternatively, try one of the na­tive apps for Mastodon for your plat­form.

While LLMs are adept at read­ing and can be ter­rific at edit­ing, their writ­ing is much more mixed. At best, writ­ing from LLMs is hack­neyed and cliché-rid­den; at worst, it brims with tells that re­veal that the prose is in fact au­to­mat­i­cally gen­er­ated.

What’s so bad about this? First, to those who can rec­og­nize an LLM’s re­veals (an ex­pand­ing de­mo­graphic!), it’s just em­bar­rass­ing — it’s as if the writer is walk­ing around with their

in­tel­lec­tual

fly open. But there are deeper prob­lems: LLM-generated writ­ing un­der­mines the au­then­tic­ity of not just one’s writ­ing but of the think­ing be­hind it as well. If the prose is au­to­mat­i­cally gen­er­ated, might the ideas be too? The reader can’t be sure — and in­creas­ingly, the hall­marks of LLM gen­er­a­tion cause read­ers to turn off (or worse).

Finally, LLM-generated prose un­der­mines a so­cial con­tract of sorts: ab­sent LLMs, it is pre­sumed that of the reader and the writer, it is the writer that has un­der­taken the greater in­tel­lec­tual ex­er­tion. (That is, it is more work to write than to read!) For the reader, this is im­por­tant: should they strug­gle with an idea, they can rea­son­ably as­sume that the writer them­selves un­der­stands it — and it is the least a reader can do to la­bor to make sense of it.

If, how­ever, prose is LLM-generated, this so­cial con­tract be­comes ripped up: a reader can­not as­sume that the writer un­der­stands their ideas be­cause they might not so much have read the prod­uct of the LLM that they tasked to write it. If one is lucky, these are LLM hal­lu­ci­na­tions: ob­vi­ously wrong and quickly dis­carded. If one is un­lucky, how­ever, it will be a kind of LLM-induced cog­ni­tive dis­so­nance: a puz­zle in which pieces don’t fit be­cause there is in fact no puz­zle at all. This can leave a reader frus­trated: why should they spend more time read­ing prose than the writer spent writ­ing it?

This can be nav­i­gated, of course, but it is truly per­ilous: our writ­ing is an im­por­tant ves­sel for build­ing trust — and that trust can be quickly eroded if we are not speak­ing with our own voice. For us at Oxide, there is a more me­chan­i­cal rea­son to be jaun­diced about us­ing LLMs to write: be­cause our hir­ing process very much se­lects for writ­ers, we know that every­one at Oxide can write — and we have the lux­ury of de­mand­ing of our­selves the kind of writ­ing that we know that we are all ca­pa­ble of.

So our guide­line is to gen­er­ally not use LLMs to write, but this should­n’t be thought of as an ab­solute — and it does­n’t mean that an LLM can’t be used as part of the writ­ing process. Just please: con­sider your re­spon­si­bil­ity to your­self, to your own ideas — and to the reader.