Web browsers are ubiq­ui­tous, but how do they work? This book ex­plains, build­ing a ba­sic but com­plete web browser, from net­work­ing to JavaScript, in a cou­ple thou­sand lines of Python.

Web Browser Engineering will be pub­lished by Oxford University Press be­fore the end of the year. To get it as soon as it’s out, pre-or­der

now!

Follow this book’s blog or Twitter for up­dates. You can also talk about the book with oth­ers in our dis­cus­sion

fo­rum.

If you are en­joy­ing the book, con­sider sup­port­ing us on Patreon.

Or just send us an

email!

The World Conker Championships is in­ves­ti­gat­ing cheat­ing al­le­ga­tions af­ter the men’s win­ner was found to have a steel chest­nut in his pocket.

David Jakins won the an­nual ti­tle in Southwick, Northamptonshire, on Sunday for the first time af­ter com­pet­ing since 1977.

But the 82-year-old was found to have a metal replica in his pocket when he was searched by or­gan­is­ers af­ter his vic­tory.

The re­tired en­gi­neer has de­nied us­ing the metal va­ri­ety in the tour­na­ment.

Jakins was re­spon­si­ble for drilling and in­sert­ing strings into other com­peti­tors’ chest­nuts as the com­pe­ti­tion’s top judge, known as the “King Conker”.

Alastair Johnson-Ferguson, who lost in the men’s fi­nal against Jakins, said he sus­pected “foul play”, the Telegraph re­ported.

The 23-year-old said: “My conker dis­in­te­grated in one hit, and that just does­n’t hap­pen … I’m sus­pi­cious of foul play and have ex­pressed my sur­prise to or­gan­is­ers.”

Kelci Banschbach, 34, from Indianapolis, de­feated the men’s cham­pion in the grand fi­nal to be­come the first American to win the com­pe­ti­tion. More than 200 peo­ple took part.

Jakins said: “I was found with the steel conker in my pocket, but I only carry [it] around with me for hu­mour value and I did not use it dur­ing the event.

“Yes, I did help pre­pare the conkers be­fore the tour­na­ment. But this is­n’t cheat­ing or a fix, and I did­n’t mark the strings.”

St John Burkett, a spokesper­son for the World Conker Championships, said the cheat­ing claims were be­ing in­ves­ti­gated.

“Allegations of foul play have been re­ceived that some­how King Conker swapped his real conker for the metal one later found in his pocket.

“Players se­lect conkers from a sack be­fore each round.

“There are also sug­ges­tions that King Conker had marked the strings of harder nuts. We can con­firm he was in­volved in drilling and lac­ing the nuts be­fore the event.

More than 2,000 conkers had been pre­pared prior to the event.

Routine den­tal X-rays are not backed by ev­i­dence—ex­perts want it to stop

The ac­tual rec­om­men­da­tions might sur­prise you—along with the state of mod­ern den­tistry.

An ex­pert look­ing at a den­tal X-ray and say­ing “look at that un­nec­es­sary X-ray,” prob­a­bly.

Has your den­tist ever told you that it’s rec­om­mended to get rou­tine den­tal X-rays every year? My (former) den­tist’s of­fice did this year—in writ­ing, even. And they claimed that the rec­om­men­da­tion came from the American Dental Association.

It’s a com­mon re­frain from den­tists, but it’s false. The American Dental Association does not rec­om­mend an­nual rou­tine X-rays. And this is not new; it’s been that way for well over a decade.

The as­so­ci­a­tion’s guide­lines from 2012 rec­om­mended that adults who don’t have an in­creased risk of den­tal caries (myself in­cluded) need only bitew­ing X-rays of the back teeth every two to three years. Even peo­ple with a higher risk of caries can go as long as 18 months be­tween bitew­ings. The guide­lines also note that X-rays should not be pre­emp­tively used to look for prob­lems: “Radiographic screen­ing for the pur­pose of de­tect­ing dis­ease be­fore clin­i­cal ex­am­i­na­tion should not be per­formed,” the guide­lines read. In other words, den­tists are sup­posed to ex­am­ine your teeth be­fore they take any X-rays.

But, of course, the 2012 guide­lines are out­dated—the lat­est ones go fur­ther. In up­dated guid­ance pub­lished in April, the ADA does­n’t rec­om­mend any spe­cific time win­dow for X-rays at all. Rather, it em­pha­sizes that pa­tient ex­po­sure to X-rays should be min­i­mized, and any X-rays should be clin­i­cally jus­ti­fied.

There’s a good chance you’re sur­prised. Dentistry’s overuse of X-rays is a prob­lem den­tists do not ap­pear ea­ger to dis­cuss—and would likely pre­fer to skirt. My for­mer den­tist de­clined to com­ment for this ar­ti­cle, for ex­am­ple. And other den­tists have been do­ing that for years. Nevertheless, the prob­lem is well-es­tab­lished. A New York Times ar­ti­cle from 2016, ti­tled “You Probably Don’t Need Dental X-Rays Every Year,” quoted a den­tal ex­pert not­ing the ex­act prob­lem:

“Many pa­tients of all ages re­ceive bitew­ing X-rays far more fre­quently than nec­es­sary or rec­om­mended. And adults in good den­tal health can go a decade be­tween full-mouth X-rays.”

The prob­lem has bub­bled up again in a se­ries of com­men­tary pieces pub­lished in JAMA Internal Medicine to­day. The pieces were all sparked by a view­point that Ars re­ported on in May, in which three den­tal and health ex­perts high­lighted that many rou­tine as­pects of den­tistry, in­clud­ing bian­nual clean­ings, are not ev­i­dence-based and that the in­dus­try is rife with over­diag­no­sis and overtreat­ment. That view­point, ti­tled “Too Much Dentistry,” also ap­peared in JAMA Internal Medicine.

The new pieces take a more spe­cific aim at den­tal ra­di­og­ra­phy. But, as in the May view­point, ex­perts also blasted den­tistry more gen­er­ally for be­ing out of step with mod­ern med­i­cine in its lack of data to sup­port its prac­tices—prac­tices that con­tinue amid fi­nan­cial in­cen­tives to overtreat and lit­tle over­sight to stop it, they note.

In a piece ti­tled “Too Much Dental Radiography,” Sheila Feit, a re­tired med­ical ex­pert based in New York, pointed out that us­ing X-rays for den­tal screen­ings is not backed by ev­i­dence. “Data are lack­ing about out­comes,” she wrote. If any­thing, the weak data we have makes it look in­ef­fec­tive. For in­stance, a 2021 sys­temic re­view of 77 stud­ies that in­cluded data on a to­tal of 15,518 tooth sites or sur­faces found that us­ing X-rays to de­tect early tooth de­cay led to a high de­gree of false-neg­a­tive re­sults. In other words, it led to missed cases.

Feit called for gold-stan­dard ran­dom­ized clin­i­cal tri­als to eval­u­ate the risks and ben­e­fits of X-ray screen­ings for pa­tients, par­tic­u­larly adults at low risk of caries. “Financial as­pects of den­tal ra­di­og­ra­phy also de­serve fur­ther study,” Feit added. Overall, Feit called the May view­point “a timely call for ev­i­dence to sup­port or re­fute com­mon clin­i­cal den­tal prac­tices.”

In a re­sponse pub­lished si­mul­ta­ne­ously in JAMA Internal Medicine, oral med­i­cine ex­pert Yehuda Zadik cham­pi­oned Feit’s point, call­ing it “an es­sen­tial dis­cus­sion about the ne­ces­sity and risks of rou­tine den­tal ra­di­og­ra­phy, em­pha­siz­ing once again the need for ev­i­dence-based den­tal care.”

Zadik, a pro­fes­sor of den­tal med­i­cine at The Hebrew University of Jerusalem, noted that the overuse of ra­di­og­ra­phy in den­tistry is a global prob­lem, one aided by den­tistry’s unique de­liv­ery:

“Dentistry is among the few re­main­ing health care pro­fes­sions where clin­i­cal ex­am­i­na­tion, di­ag­nos­tic test­ing in­clud­ing ra­di­ographs, di­ag­no­sis, treat­ment plan­ning, and treat­ment are all per­formed in place, of­ten by the same care prac­ti­tioner” Zadik wrote. “This model of care de­liv­ery pre­vents ex­ter­nal over­sight of the en­tire process.”

While rou­tine X-rays con­tinue at short in­ter­vals, Zadik notes that cur­rent data “favor the re­duc­tion of pa­tient ex­po­sure to di­ag­nos­tic ra­di­a­tion in den­tistry,” while ad­vance­ments in den­tistry dic­tate that X-rays should be used at “longer in­ter­vals and based on clin­i­cal sus­pi­cion.”

Though the dig­i­tal den­tal X-rays of­ten used to­day pro­vide smaller doses of ra­di­a­tion than the film X-rays used in the past, ra­di­a­tion’s harms are cu­mu­la­tive. Zadik em­pha­sizes that with the pri­mary tenet of med­i­cine be­ing “First, do no harm,” any un­nec­es­sary X-ray is an un­nec­es­sary harm. Further, other tech­nol­ogy can some­times be used in­stead of ra­di­og­ra­phy, in­clud­ing elec­tronic apex lo­ca­tors for root canal pro­ce­dures.

“Just as it is now unimag­in­able that, in the past, shoe fit­tings for chil­dren were con­ducted us­ing X-rays, in the fu­ture it will be equally as­ton­ish­ing to learn that the fit of den­tal crowns was as­sessed us­ing ra­di­ographic imag­ing,” Zadik wrote.

X-rays do more harm than good in chil­dren

Feit’s com­men­tary also prompted a re­ply from the three au­thors of the orig­i­nal May view­point: Paulo Nadanovsky, Ana Paula Pires dos Santos, and David Nunan. The three fol­lowed up on Feit’s point that data is weak on whether X-rays are use­ful for de­tect­ing early de­cay, specif­i­cally white spot le­sions. The ex­perts raise the damn­ing point that even if den­tal X-rays were shown to be good at do­ing that, there’s still no ev­i­dence that that’s good for pa­tients.

“[T]here is no ev­i­dence that de­tect­ing white spot le­sions, with or with­out ra­di­ographs, ben­e­fits pa­tients,” the re­searchers wrote. “Most of these le­sions do not progress into den­tine cav­i­ties,” and there’s no ev­i­dence that early treat­ments make a dif­fer­ence in the long run.

To bol­ster the point, the three note that data from chil­dren sug­gest that X-ray screen­ing does more harm than good. In a ran­dom­ized clin­i­cal trial pub­lished in 2021, 216 preschool chil­dren were split into two groups: one that re­ceived only a vi­sual-tac­tile den­tal exam, while the oth­ers re­ceived both a vi­sual-tac­tile exam and X-rays. The study found that adding X-rays caused more harm than ben­e­fit be­cause the X-rays led to false pos­i­tives and over­diag­no­sis of cav­i­tated caries need­ing restora­tive treat­ment. The au­thors of the trial con­cluded that “visual in­spec­tion should be con­ducted alone in reg­u­lar clin­i­cal prac­tice.”

Like Zadik, the three re­searchers note that screen­ings for de­cay and cav­i­ties are not the only ques­tion­able use of X-rays in den­tal prac­tice. Other com­mon den­tal and or­tho­don­tic treat­ments in­volv­ing ra­di­og­ra­phy—prac­tices of­ten used in chil­dren and teens—might also be un­nec­es­sary harms. They raise the ar­gu­ment against the pre­ven­tive re­moval of wis­dom teeth, which is also not backed by ev­i­dence.

Like Feit, the three re­searchers re­it­er­ate the call for well-de­signed tri­als to back up or re­fute com­mon den­tal prac­tices.

Beth is Ars Technica’s Senior Health Reporter. Beth has a Ph. D. in mi­cro­bi­ol­ogy from the University of North Carolina at Chapel Hill and at­tended the Science Communication pro­gram at the University of California, Santa Cruz. She spe­cial­izes in cov­er­ing in­fec­tious dis­eases, pub­lic health, and mi­crobes.

Routine den­tal X-rays are not backed by ev­i­dence—ex­perts want it to stop

Expert wit­ness used Copilot to make up fake dam­ages, irk­ing judge

This site is home to the doc­u­men­ta­tion for the SQLite pro­jec­t’s WebAssembly- and JavaScript-related APIs, which en­able the use of

sqlite3 in mod­ern WASM-capable browsers. These com­po­nents were ini­tially re­leased for pub­lic beta with ver­sion 3.40 and will ten­ta­tively be made API-stable with the 3.41 re­lease, pend­ing com­mu­nity feed­back.

Disclaimer: this site re­quires a mod­ern, JavaScript-capable browser for full func­tion­al­ity. This site uses client-side stor­age for stor­ing cer­tain brows­ing pref­er­ences (like the bright/​dark mode tog­gle) but does not store any user in­for­ma­tion server-side, ex­cept for logged-in de­vel­op­ers. The only user-level de­tails this site shares with any other sys­tems are the pub­lic SCM-related de­tails of this site’s own de­vel­op­ers.

Making use of this pro­ject:

Third-party pro­jects known to be us­ing this pro­ject in­clude (in or­der of their ad­di­tion to this list)…

* Evolu Evolu is a lo­cal-first plat­form

de­signed for pri­vacy, ease of use, and no ven­dor lock-in.

* SQLiteNext pro­vides a demo of

in­te­grat­ing this pro­ject with next.js.

* sqlite-wasm-esm demon­strates

how to use this pro­ject with the Vite tool­chain.

* sqlite-wasm-http

pro­vides an SQLite VFS with read-only ac­cess to data­bases which are

served di­rectly over HTTP.

The fol­low­ing links ref­er­ence ar­ti­cles and doc­u­men­ta­tion pub­lished about SQLite WASM by third par­ties:

Zamba2 per­forms ex­cep­tion­ally well on stan­dard lan­guage mod­el­ing eval­u­a­tion sets, es­pe­cially given its la­tency and gen­er­a­tion speed. Among small lan­guage mod­els (≤8B), we lead the pack in both qual­ity and per­for­mance.

Zyphra’s team is com­mit­ted to de­moc­ra­tiz­ing ad­vanced AI sys­tems, ex­plor­ing novel ar­chi­tec­tures on the fron­tier of per­for­mance, and ad­vanc­ing the sci­en­tific study and un­der­stand­ing of pow­er­ful mod­els. We look for­ward to col­lab­o­rat­ing with oth­ers who share our vi­sion.

Zamba2-7B will be re­leased un­der an open source li­cense, al­low­ing re­searchers, de­vel­op­ers, and com­pa­nies to lever­age its ca­pa­bil­i­ties. We in­vite the broader AI com­mu­nity to ex­plore Zamba’s unique ar­chi­tec­ture and con­tinue push­ing the bound­aries of ef­fi­cient foun­da­tion mod­els. A Huggingface in­te­gra­tion is avail­able here, and a pure-py­torch im­ple­men­ta­tion is avail­able here.

Zamba2-7B was trained on 128 H100 GPUS for ap­prox­i­mately 50 days us­ing our in­ter­nal train­ing frame­work de­vel­oped atop Megatron-LM. Zamba2-7B thus demon­strates that at the 7B scale the fron­tier is still reach­able and sur­pass­able with a small team and mod­er­ate bud­get.

Zamba2-7B uti­lizes and ex­tends our orig­i­nal Zamba hy­brid SSM-attention ar­chi­tec­ture. The core Zamba ar­chi­tec­ture con­sists of a back­bone of Mamba lay­ers in­ter­leaved with one or more shared at­ten­tion lay­ers (one shared at­ten­tion in Zamba1, two in Zamba2). This at­ten­tion has shared weights to min­i­mize the pa­ra­me­ter cost of the model. We find that con­cate­nat­ing the orig­i­nal model em­bed­dings of the in­put to this at­ten­tion block im­proves per­for­mance, likely due to bet­ter main­te­nance of in­for­ma­tion across depth. The Zamba2 ar­chi­tec­ture also ap­plies LoRA pro­jec­tion ma­tri­ces to the shared MLP to gain some ad­di­tional ex­pres­siv­ity in each block and al­low each shared block to spe­cial­ize slightly to its own unique po­si­tion while keep­ing the ad­di­tional pa­ra­me­ter over­head small.

Due to the ex­cep­tional qual­ity of our pre­train­ing and an­neal­ing datasets, Zamba2-7B per­forms ex­tremely well on a per-train­ing-to­ken ba­sis, sit­ting com­fort­ably above the curve traced out by com­peti­tor mod­els.

Zyphra’s team is com­mit­ted to de­moc­ra­tiz­ing ad­vanced AI sys­tems, ex­plor­ing novel ar­chi­tec­tures on the fron­tier of per­for­mance, and ad­vanc­ing the sci­en­tific study and un­der­stand­ing of pow­er­ful mod­els. We look for­ward to col­lab­o­rat­ing with oth­ers who share our vi­sion.

Zamba2-7B will be re­leased un­der an open source li­cense, al­low­ing re­searchers, de­vel­op­ers, and com­pa­nies to lever­age its ca­pa­bil­i­ties. We in­vite the broader AI com­mu­nity to ex­plore Zamba’s unique ar­chi­tec­ture and con­tinue push­ing the bound­aries of ef­fi­cient foun­da­tion mod­els. A Huggingface in­te­gra­tion is avail­able here, and a pure-py­torch im­ple­men­ta­tion is avail­able here.

Zamba2-7B was trained on 128 H100 GPUS for ap­prox­i­mately 50 days us­ing our in­ter­nal train­ing frame­work de­vel­oped atop Megatron-LM. Zamba2-7B thus demon­strates that at the 7B scale the fron­tier is still reach­able and sur­pass­able with a small team and mod­er­ate bud­get.

Zamba2-7B uti­lizes and ex­tends our orig­i­nal Zamba hy­brid SSM-attention ar­chi­tec­ture. The core Zamba ar­chi­tec­ture con­sists of a back­bone of Mamba lay­ers in­ter­leaved with one or more shared at­ten­tion lay­ers (one shared at­ten­tion in Zamba1, two in Zamba2). This at­ten­tion has shared weights to min­i­mize the pa­ra­me­ter cost of the model. We find that con­cate­nat­ing the orig­i­nal model em­bed­dings of the in­put to this at­ten­tion block im­proves per­for­mance, likely due to bet­ter main­te­nance of in­for­ma­tion across depth. The Zamba2 ar­chi­tec­ture also ap­plies LoRA pro­jec­tion ma­tri­ces to the shared MLP to gain some ad­di­tional ex­pres­siv­ity in each block and al­low each shared block to spe­cial­ize slightly to its own unique po­si­tion while keep­ing the ad­di­tional pa­ra­me­ter over­head small.

We pre­sent his­tograms de­pict­ing dis­tri­b­u­tion of clus­ter sizes in all the datasets (see Fig. 7-11). Please, note that all the fig­ures are in log-log scale. We see a sig­nif­i­cant drop in the num­ber of clus­ters start­ing from the size of around 100. This drop is pre­sent both in DCLM and FineWeb-Edu2 (see Fig. 8 and 9 re­spec­tively), and most likely is ex­plained by a com­bi­na­tion of  the dedu­pli­ca­tion strat­egy and qual­ity when cre­at­ing both datasets: DCLM dedu­pli­ca­tion was done in­di­vid­u­ally within 10 shards, while FineWeb-Edu2 was dedu­pli­cated within every Common Crawl snap­shot. We find that large clus­ters usu­ally con­tain low qual­ity ma­te­r­ial (repeated ad­ver­tise­ments, li­cense agree­ments tem­plates, etc), so it’s not sur­pris­ing that such doc­u­ments were re­moved. Notably, DCLM still con­tained one clus­ter with the size close to 1 mil­lion doc­u­ments, con­tain­ing low qual­ity doc­u­ments seem­ingly com­ing from the ad­ver­tise­ments (see Appendix).We find both Zyda-1and Dolma-CC con­tain a small amount of du­pli­cates, which is ex­pected, since both datasets were dedu­pli­cated glob­ally by their au­thors. Remaining du­pli­cates are likely false neg­a­tives from the ini­tial dedu­pli­ca­tion pro­ce­dure. Note, that dis­tri­b­u­tion of du­pli­cates clus­ters sizes of these two datasets (Fig. 10 and 11) don’t con­tain any sharp drops, but rather hy­per ex­po­nen­tially de­creases with clus­ter size.

Below is an ex­am­ple of the doc­u­ment from the largest clus­ter (~1M doc­u­ments) of du­pli­cates in DCLM (quality score 0.482627):

‍Is safe? Is scam?

Is safe for your PC?

Is safe or is it scam?

Domain is SafeSafe score: 1

‍The higher the num­ber, the more dan­ger­ous the web­site. Any num­ber higher than 1 means DANGER.

‍Positive votes:

Negative votes:

Vote Up Vote Down re­view

‍Have you had bad ex­pe­ri­ence with Warn us, please!

Below one will find a few doc­u­ments with dif­fer­ent qual­ity scores from DCLM com­ing from the same du­pli­cates clus­ter. Quality score varies from ~0.2 to ~0.04.

The C23 edi­tion of Modern C is now avail­able for free down­load from

The C23 edi­tion of Modern C is now avail­able for free down­load from

This new edi­tion has been the oc­ca­sion to over­haul the pre­sen­ta­tion in many places, but its main pur­pose is the up­date to the new C stan­dard, C23. The goal was to pub­lish this new edi­tion of Modern C at the same time as the new C stan­dard goes through the pro­ce­dure of ISO pub­li­ca­tion. The clos­est ap­prox­i­ma­tion of the con­tents of the new stan­dard in a pub­li­cally avail­able doc­u­ment can be found here. New re­leases of ma­jor com­pil­ers al­ready im­ple­ment most of the new fea­tures that it brings.

Among the most no­tice­able changes and ad­di­tions that we han­dle are those for in­te­gers: there are new bit-pre­cise types coined _BitInt(N), new C li­brary head­ers (for arith­metic with over­flow check) and (for bit ma­nip­u­la­tion), pos­si­bil­i­ties for 128 bit types on mod­ern ar­chi­tec­tures, and sub­stan­tial im­prove­ments for enu­mer­a­tion types. Other new con­cepts in C23 in­clude a nullptr con­stant and its un­der­ly­ing type, syn­tac­tic an­no­ta­tion with at­trib­utes, more tools for type generic pro­gram­ming such as type in­fer­ence with auto and typeof, de­fault ini­tial­iza­tion with {}, even for vari­able length ar­rays, and con­s­t­expr for named con­stants of any type. Furthermore, new ma­te­r­ial has been added, dis­cussing com­pound ex­pres­sions and lamb­das, so-called “internationalization”, a com­pre­hen­sive ap­proach for pro­gram fail­ure.

Also added has been an ap­pen­dix and a tem­po­rary in­clude header for an easy tran­si­tion to C23 on ex­ist­ing plat­forms, that will al­low you to start off with C23 right away.

Manning’s early ac­cess pro­gram (MEAP) for the new edi­tion is still open at

Unfortunately they were not yet able to tell me when their ver­sion of the C23 edi­tion will fi­nally be pub­lished.

Pumpkin is a Minecraft server built en­tirely in Rust, of­fer­ing a fast, ef­fi­cient, and cus­tomiz­able ex­pe­ri­ence. It pri­or­i­tizes per­for­mance and player en­joy­ment while ad­her­ing to the core me­chan­ics of the game.

* Compatibility: Supports the lat­est Minecraft server ver­sion and ad­heres to vanilla game me­chan­ics.

* Flexibility: Highly con­fig­urable with the abil­ity to dis­able un­nec­es­sary fea­tures.

* Be a drop-in re­place­ment for vanilla or other servers

* Be com­pat­i­ble with plu­g­ins or mods for other servers

* Function as a frame­work for build­ing a server from scratch.

Check out our Github Project to see cur­rent progress

See our Quick Start Guide to get Pumpkin run­ning

Contributions are wel­come! See CONTRIBUTING.md

The Documentation of Pumpkin can be found at https://​snowi­iii.github.io/​Pump­kin/

Consider join­ing our dis­cord to stay up-to-date on events, up­dates, and con­nect with other mem­bers.

If you want to fund me and help the pro­ject, Check out my GitHub spon­sors

A big thanks to wiki.vg for pro­vid­ing valu­able in­for­ma­tion used in the de­vel­op­ment of this pro­ject.

Please make sure your browser sup­ports JavaScript and cook­ies and that you are not block­ing them from load­ing. For more in­for­ma­tion you can re­view our Terms of

Service and Cookie Policy.

Last year, I pub­lished an ar­ti­cle on air­ships. The ar­ti­cle was the fruit of a few years’ ex­plo­ration of the in­dus­try. I spoke to mul­ti­ple air­ship man­u­fac­tur­ers un­der NDA. I traded ideas with other cargo air­ship en­thu­si­asts. And ul­ti­mately, along with my friends Ian McKay and Matt Sattler, I hired an en­gi­neer to de­velop new data on a 500-ton cargo air­ship.

My ar­ti­cle ex­plained why air­ships could trans­form the freight mar­ket and of­fered my thoughts on how they should be de­signed and op­er­ated. Airships fea­ture a tan­ta­liz­ing scal­ing prop­erty—the big­ger they get, the bet­ter they per­form. If you want a cargo air­ship that can com­pete in transpa­cific cargo, it needs to be big. No one in the in­dus­try was do­ing what I thought needed to be done—tar­get­ing the in­ter­con­ti­nen­tal cargo mar­ket with a large, rigid-body air­ship as quickly as pos­si­ble us­ing an it­er­a­tive, hard­ware-rich ap­proach.

Perhaps sur­pris­ingly, my air­ship ar­ti­cle res­onated with a lot of peo­ple. Veritasium made a great video based on it that has racked up 3.5 mil­lion views so far. Because so many peo­ple read the post and watched the video, I feel that I now must come clean and ad­mit that I got some­thing wrong. I as­pire to be 100% ac­cu­rate in all my posts, so I re­gret the er­ror.

But I don’t re­gret it that much, be­cause it turned out great.

One of the thou­sands of peo­ple who read my air­ship ar­ti­cle was an en­gi­neer named Jim Coutre. Jim be­gan his ca­reer at SpaceX, where he worked on com­plex mul­ti­dis­ci­pli­nary sys­tems like the stage sep­a­ra­tion sys­tems on Falcon 9 and the so­lar ar­rays on the Dragon cap­sule. He also spent sev­eral years at Hyperloop, where he rose to be­come chief en­gi­neer.

After read­ing the ar­ti­cle, Jim started a spread­sheet in March 2023. He was me­thod­i­cal. He worked through all the sys­tems that would be re­quired to make an un­manned cargo air­ship work, and put cost and per­for­mance bounds around them. He de­vised a fea­ture set to ad­dress cargo load­ing and un­load­ing. He made man­u­fac­tur­ing cost es­ti­mates. He did all the tech­noe­co­nom­ics that were miss­ing in my post.

Jim only found one ma­jor dis­crep­ancy. In my ar­ti­cle, I noted that freight ser­vice op­er­ates in three tiers—ship, truck, and plane, or ba­si­cally, slow, medium, and fast. There are no bridges across oceans, so on transpa­cific routes there is only slow and fast. There was an op­por­tu­nity, I ar­gued, to in­tro­duce a medium-speed mode at truck-like prices. Airships could be that medium-speed mode with truck-like eco­nom­ics.

The prob­lem is that to­day’s air freight ser­vice is not as fast as I had as­sumed. You can cross the Pacific in a plane in less than a day. You can pay for par­cel ser­vice that will get you your pack­age in 2 to 3 days. But for air freight ser­vice, end-to-end de­liv­ery takes a week or more, in­volv­ing mul­ti­ple par­ties: in ad­di­tion to the air car­rier and freight for­warder, at both the ori­gin and des­ti­na­tion, there is a truck­ing com­pany, a ware­house, a cus­toms bro­ker, and an air­port. Each touch­point adds cost, de­lay, and the risk of theft or break­age.

Once you ac­count for all these de­lays and costs, the 4 to 5 days it takes to cross the Pacific on an air­ship starts to look pretty good. If you can pick up goods di­rectly from a cus­tomer on one side and de­liver them di­rectly to a cus­tomer on the other, you can ac­tu­ally beat to­day’s air freight ser­vice on de­liv­ery time.

This changes every­thing. Since air­ships are, af­ter all, com­pet­i­tive with 747s on de­liv­ery time, you can earn the full rev­enue as­so­ci­ated with air freight, not just the lower truck­ing rates I had as­sumed. Cargo air­ship mar­gins, there­fore, can be much higher than I had re­al­ized.

Today’s 747 freighters have al­most no mar­gin. They op­er­ate in an al­most per­fectly com­pet­i­tive mar­ket and are highly sen­si­tive to fuel costs. They sim­ply won’t be able to com­pete with transpa­cific air­ships that are faster end to end, less sub­ject to volatile fuel prices, and op­er­at­ing with cushy mar­gins. A cargo air­ship de­signed to com­pete head to head in the air freight mar­ket could take the li­on’s share of the rev­enue in the air cargo mar­ket while be­ing highly prof­itable.

Last year, Casey Handmer in­tro­duced me to Jim, with and for whom he worked at Hyperloop. I got to know Jim a bit. We met up in per­son at Edge Esmeralda in June—he pre­sented at the Hard Tech Weekend there that Ben Reinhardt and I co-or­ga­nized. We talked about air­ships a lot. We strate­gized. We ini­ti­ated some cus­tomer con­ver­sa­tions. We re­ceived val­i­da­tion.

Over the sum­mer, Jim in­cor­po­rated Airship Industries. He hired a team of cracked ex-SpaceX en­gi­neers. And he raised a large pre-seed round, in which I’m de­lighted to say that my syn­di­cate (which you should pos­si­bly join) is the largest in­vestor.

Airship Industries is de­sign­ing its ve­hi­cle to dom­i­nate transoceanic air freight. It checks all the right boxes. It short­ens end-to-end freight de­liv­ery time. It low­ers freight han­dling costs, de­lays, and break­age. It’s highly prof­itable on a unit ba­sis. It low­ers fuel burn and car­bon emis­sions by 75 per­cent with­out any sus­tain­able fuel break­throughs.

In my last air­ship ar­ti­cle, I ex­pressed some doubt that cargo air­ships were star­tu­pable. Airship de­vel­op­ment and cer­ti­fi­ca­tion is cap­i­tal in­ten­sive. I thought and still be­lieve that air­ships can very likely match the eco­nom­ics of trucks. But even if you suc­ceed at build­ing a great cargo air­ship, if you are lim­ited to charg­ing truck­ing prices, the mar­gins will be very thin. No one wants to in­vest a lot of cap­i­tal in a risky en­deavor for thin mar­gins. But if, as I am now con­vinced, op­er­at­ing mar­gins could be huge by com­pet­ing di­rectly in the air freight mar­ket, then air­ships are def­i­nitely star­tu­pable.

Here’s an­other way to look at it. Many soft­ware in­vestors es­chew hard tech star­tups be­cause of their cap­i­tal in­ten­sity, but it’s hard to deny that huge re­turns are pos­si­ble in hard tech: just con­sider SpaceX. Bring me an­other SpaceX! the re­luc­tant in­vestors might say.

But even SpaceX looks like small pota­toes next to an in­dus­try like global lo­gis­tics. For a Falcon 9-sized in­vest­ment, in­stead of rev­o­lu­tion­iz­ing a $2 bil­lion/​year (10 years ago) com­mer­cial launch mar­ket, you could trans­form a mar­ket that is at least 30 times big­ger, with sim­i­lar unit eco­nom­ics to SpaceX.

I am thrilled to see Airship Industries take shape. It’s hap­pen­ing. There will soon (soon in the grand scheme of things at least) be thou­sands of gi­ant air­ships cross­ing our oceans, trans­form­ing global lo­gis­tics and con­nect­ing economies. Cargo air­ships are go­ing to be big.