10 interesting stories served every morning and every evening.

Apple sues OpenAI, accuses ex-employees of stealing trade secrets

9to5mac.com

Apple has filed a law­suit against OpenAI to­day, ac­cus­ing the com­pany of trade se­cret theft. Specifically, Apple al­leges that its for­mer em­ploy­ees have stolen trade se­crets for the ben­e­fit of OpenAI.”

This case is about Apple’s for­mer em­ploy­ees steal­ing Apple’s trade se­crets for the ben­e­fit of OpenAI. Apple brings this suit to put a stop to it,” the law­suit says.

Apple state­ment

In a state­ment to 9to5Mac, an Apple spokesper­son said:

At Apple, our teams are con­stantly de­vel­op­ing break­through tech­nolo­gies to cre­ate the best prod­ucts and ser­vices in the world, and pro­tect­ing their work and in­tel­lec­tual prop­erty is some­thing we take very se­ri­ously. Recently, sig­nif­i­cant ev­i­dence has emerged sug­gest­ing in­di­vid­u­als em­ployed by OpenAI wrong­fully took Apple’s se­cret and con­fi­den­tial in­for­ma­tion re­gard­ing our un­re­leased tech­nolo­gies, processes, and prod­ucts. We will al­ways de­fend our teams’ hard work and in­no­va­tions, and we are tak­ing all ap­pro­pri­ate steps to do so.”

At Apple, our teams are con­stantly de­vel­op­ing break­through tech­nolo­gies to cre­ate the best prod­ucts and ser­vices in the world, and pro­tect­ing their work and in­tel­lec­tual prop­erty is some­thing we take very se­ri­ously. Recently, sig­nif­i­cant ev­i­dence has emerged sug­gest­ing in­di­vid­u­als em­ployed by OpenAI wrong­fully took Apple’s se­cret and con­fi­den­tial in­for­ma­tion re­gard­ing our un­re­leased tech­nolo­gies, processes, and prod­ucts. We will al­ways de­fend our teams’ hard work and in­no­va­tions, and we are tak­ing all ap­pro­pri­ate steps to do so.”

Update: Read OpenAI’s re­sponse here.

Apple ac­cuses OpenAI of trade se­cret theft

The law­suit names Chang Liu and Tang Tan as two of the de­fen­dants. Tang Tan served as VP of prod­uct de­sign at Apple, lead­ing iPhone and Apple Watch prod­uct de­sign. He de­parted the com­pany in February 2024 to work with Jony Ive. Chang Liu, mean­while, worked at Apple for eight years and was a se­nior sys­tem elec­tri­cal en­gi­neer be­fore de­part­ing to join OpenAI in January 2026.

Apple’s law­suit also names OpenAI and io Products as de­fen­dants.

OpenAI’s hard­ware ef­forts are be­ing led by Jony Ive, Apple’s for­mer chief de­sign of­fi­cer. OpenAI ac­quired Ive’s startup io as part of a $6.5 bil­lion deal last year. OpenAI’s takeover of the com­pany in­cluded more than 50 en­gi­neers, de­vel­op­ers, and other em­ploy­ees. In its orig­i­nal an­nounce­ment, OpenAI touted that Ive founded io in col­lab­o­ra­tion with Scott Cannon, Evans Hankey, and Tan.

Hankey led Apple’s de­sign team for sev­eral years af­ter Ive de­parted the com­pany. She de­parted in 2022 be­fore re­unit­ing with Ive as part of io. Cannon also pre­vi­ously worked at Apple.

Ive, Hankey, and Cannon are not per­son­ally men­tioned any­where in Apple’s ini­tial fil­ing to­day.

The com­plaint

Apple says it first raised con­cerns with OpenAI di­rectly in February, ask­ing the com­pany to in­ves­ti­gate and ad­dress the is­sue. OpenAI, how­ever, never re­sponded. Apple says the con­duct de­tailed in the fil­ing is the tip of the ice­berg.”

This is the tip of the ice­berg. Apple lacks vis­i­bil­ity into what’s been hap­pen­ing be­hind closed doors at OpenAI, where such mis­con­duct is nor­mal­ized and ex­em­pli­fied by lead­er­ship. This much is clear, how­ever: at every level, from mem­bers of its Technical Staff to its Chief Hardware Officer, and in co­or­di­na­tion with busi­ness part­ners, OpenAI has been steal­ing Apple’s trade se­crets and con­fi­den­tial in­for­ma­tion. As a nat­ural re­sult, OpenAI’s nascent hard­ware busi­ness now rests.

This is the tip of the ice­berg. Apple lacks vis­i­bil­ity into what’s been hap­pen­ing be­hind closed doors at OpenAI, where such mis­con­duct is nor­mal­ized and ex­em­pli­fied by lead­er­ship. This much is clear, how­ever: at every level, from mem­bers of its Technical Staff to its Chief Hardware Officer, and in co­or­di­na­tion with busi­ness part­ners, OpenAI has been steal­ing Apple’s trade se­crets and con­fi­den­tial in­for­ma­tion. As a nat­ural re­sult, OpenAI’s nascent hard­ware busi­ness now rests.

The com­plaint, filed in the U.S. District Court for the Northern District of California, al­leges that Tan used in­sider knowl­edge of Apple’s con­fi­den­tial pro­jects to grill job can­di­dates in in­ter­views and learn more con­fi­den­tial in­for­ma­tion. Additionally, Tan di­rected job can­di­dates still work­ing at Apple to bring ac­tual Apple hard­ware com­po­nents and sam­ples for show and tell” ses­sions.

When in­ter­view­ing Apple em­ploy­ees for jobs at OpenAI, Mr. Tan uses Apple’s con­fi­den­tial in­for­ma­tion to gain ac­cess to even more in­sider knowl­edge. He has used an Apple in­ter­nal pro­ject co­de­name to ask, What’s the plan[?]” for an unan­nounced Apple prod­uct.

He has di­rected job can­di­dates still work­ing for Apple to bring Actual parts” from Apple to their in­ter­views for show and tell” ses­sions in which he and his team at OpenAI can elicit still more Apple con­fi­den­tial in­for­ma­tion. These di­rec­tions to bring Apple’s parts to OpenAI job in­ter­views sur­prised at least one of the can­di­dates, who com­mented that he didn’t even know we could take those from the of­fice.”

OpenAI has been in­struct­ing Apple em­ploy­ees to bring CAD/design ar­ti­facts” and prototypes” to their in­ter­views and to di­vulge de­tails about their work such as subsystem and com­po­nent se­lec­tion,” the tools or method­olo­gies you use for sys­tem in­te­gra­tion, such as CAD soft­ware, sim­u­la­tion tools,” and Vendor se­lec­tion and com­mu­ni­ca­tion/​col­lab­o­ra­tion with ven­dors.”

When in­ter­view­ing Apple em­ploy­ees for jobs at OpenAI, Mr. Tan uses Apple’s con­fi­den­tial in­for­ma­tion to gain ac­cess to even more in­sider knowl­edge. He has used an Apple in­ter­nal pro­ject co­de­name to ask, What’s the plan[?]” for an unan­nounced Apple prod­uct.

He has di­rected job can­di­dates still work­ing for Apple to bring Actual parts” from Apple to their in­ter­views for show and tell” ses­sions in which he and his team at OpenAI can elicit still more Apple con­fi­den­tial in­for­ma­tion. These di­rec­tions to bring Apple’s parts to OpenAI job in­ter­views sur­prised at least one of the can­di­dates, who com­mented that he didn’t even know we could take those from the of­fice.”

OpenAI has been in­struct­ing Apple em­ploy­ees to bring CAD/design ar­ti­facts” and prototypes” to their in­ter­views and to di­vulge de­tails about their work such as subsystem and com­po­nent se­lec­tion,” the tools or method­olo­gies you use for sys­tem in­te­gra­tion, such as CAD soft­ware, sim­u­la­tion tools,” and Vendor se­lec­tion and com­mu­ni­ca­tion/​col­lab­o­ra­tion with ven­dors.”

Furthermore, Apple says a can­di­date be­gan screenshotting and down­load­ing files re­lat­ing to a highly con­fi­den­tial Apple pro­ject” hours be­fore in­ter­view­ing with Tan, who then solicited more in­for­ma­tion about that same Apple pro­ject” once the in­ter­view started. This be­came an established pat­tern,” Apple says.

Tan also al­legedly pos­sessed and dis­trib­uted an in­ter­nal Apple Need to Know” doc­u­ment to new OpenAI hires be­fore they gave their no­tice to Apple. The doc­u­ment in­cluded Apple’s de­par­ture se­cu­rity pro­to­cols. As part of its in­ves­ti­ga­tion, Apple found a pattern by em­ploy­ees who de­part for OpenAI of tak­ing steps to evade the se­cu­rity processes in­tended to pro­tect Apple’s con­fi­den­tial in­for­ma­tion.”

Meanwhile, Apple also claims for­mer en­gi­neer Liu ex­ploited a se­cu­rity bug to down­load con­fi­den­tial en­gi­neer­ing files af­ter leav­ing the com­pany. Rather than re­port the ex­ploit, Liu al­legedly joked about it in mes­sages (“LOL,” so funny”). Liu also failed to re­turn an Apple-issued lap­top af­ter his de­par­ture.

Apple al­leges that Liu down­loaded a compilation of tech­ni­cal files with over a thou­sand pages” with de­tails of work he did at Apple. This in­cluded de­tailed man­u­fac­tur­ing doc­u­ments cov­er­ing the com­plex cir­cuit boards used in Apple hard­ware prod­ucts.

Liu also al­legedly coached an­other Apple em­ployee at the time, whom he was re­cruit­ing to OpenAI, on which con­fi­den­tial ma­te­ri­als to study be­fore her own OpenAI in­ter­view.

Finally, Apple al­leges that OpenAI had a trusted Apple part­ner carry out Apple’s pro­pri­etary metal-fin­ish­ing tech­nique, mis­lead­ing the part­ner into be­liev­ing it had Apple’s per­mis­sion to do so. Apple also says OpenAI ap­proached a sec­ond long­time Apple sup­plier that works on power and bat­tery man­u­fac­tur­ing, us­ing in­sider ter­mi­nol­ogy to ask targeted ques­tions” about spe­cific Apple com­po­nents.

The suit seeks in­junc­tive re­lief and dam­ages, and comes as OpenAI works to bring its first con­sumer hard­ware de­vice to mar­ket.

Apple’s law­suit also comes af­ter Bloomberg re­ported that OpenAI was prepar­ing legal ac­tion” against Apple over how its part­ner­ship to in­te­grate ChatGPT into Siri played out. Today’s law­suit from Apple, how­ever, says that agree­ment is not at is­sue here.

Tan and Liu are just two of many Apple em­ploy­ees who have de­parted for OpenAI. Today’s fil­ing says that there are over 400 for­mer Apple em­ploy­ees now work­ing at OpenAI.

There have been var­i­ous ru­mors about OpenAI’s hard­ware ef­forts so far. In April, Ming-Chi Kuo re­ported that OpenAI is de­vel­op­ing its own smart­phone, which could launch in 2028. The Information has also re­ported on OpenAI’s work on a HomePod-style smart speaker.

You can read the full fil­ing be­low and find the PDF linked here.

Chance’s fa­vorites:

Bring wire­less CarPlay to any car

Apple: The First 50 Years” by David Pogue

Logitech MX Master 4

Belkin 3-in-1 MagSafe Charger

Beats Woven USB-C Charging Cables

AirPods Pro 3: $222 (Reg. $249)

Follow Chance: Threads, Bluesky, Instagram, and Mastodon.

FTC: We use in­come earn­ing auto af­fil­i­ate links. More.

QuadRF can spot drones and see WiFi through my wall

www.jeffgeerling.com

The QuadRF (pictured above) a phased-ar­ray ra­dio built around a Raspberry Pi 5 and an FPGA board with pi­cosec­ond-level tim­ing. It does ad­vanced sig­nal pro­cess­ing and beam­form­ing.

It can see WiFi through walls and track drones in flight.

If the open source com­mu­nity can come up with some­thing like this, just imag­ine what gov­ern­ments are ca­pa­ble of.

When you plug a com­puter into a net­work, tools like Wireshark can show all the hid­den traf­fic you might not even know is there. WiFi pack­ets are the same, but those travel through the air, al­low­ing snoop­ing with­out phys­i­cal ac­cess.

The QuadRF has built-in soft­ware that can stream and de­code RF, and you can pipe it out to a more pow­er­ful com­puter for things like WiFi traf­fic analy­sis.

I men­tion this not to scare you—gov­ern­ments have had tools like these for years. It’s just bet­ter to know what’s pos­si­ble and ex­pose bad se­cu­rity prac­tices than to ban use­ful tools like these. So if you’re in the CIA, don’t get any ideas.

To the Moon

After spot­ting QuadRF on Hackaday, I reached out to Martin McCormick, who’s been work­ing on QuadRF as part of a big­ger pro­ject: a Moon-scale an­tenna ar­ray, ca­pa­ble of EME (Earth-Moon-Earth) ra­dio ex­per­i­ments and ra­dio as­tron­omy.

I think Martin took in­spi­ra­tion from Dishy, SpaceX’s orig­i­nal Starlink ter­mi­nal. (Makes sense, since Martin worked at SpaceX on the team that built Dishy!)

Instead of lock­ing this phased ar­ray an­tenna sys­tem into a pro­pri­etary satel­lite sys­tem, li­censed op­er­a­tors will ide­ally be able to chain mul­ti­ple QuadRF mod­ules to­gether for in­ter­est­ing ra­dio ex­per­i­ments, with up to 1.15 MW EIRP—basically, a mas­sive amount of di­rec­tional an­tenna gain, for high power RF fun.

But QuadRF is scaled down to hand­held-size, and while it is­n’t pow­er­ful enough to send a sig­nal to the moon, it’s still quite use­ful in lo­cal SDR ap­pli­ca­tions and vi­su­al­iz­ing the RF en­vi­ron­ment—at least in its fre­quency range of 4.9 – 6 GHz.

Testing QuadRF

But I specif­i­cally asked Martin if he’d be will­ing to send over a pro­to­type QuadRF for my Dad (a re­tired broad­cast ra­dio en­gi­neer) and I to test.

I had al­ready placed a pre-or­der on Crowd Supply (where a ba­sic kit is $499), but I wanted to see if QuadRF was re­ally as use­ful or in­tu­itive as it seemed from the videos ScaleRF posted.

Spoilers: it’s still a lit­tle rough in the UI de­part­ment, but I was blown away by how well it works. Especially con­sid­er­ing every­thing’s run­ning on a Raspberry Pi 5.

When you turn it on, the Pi boots up and cre­ates a WiFi hotspot. You con­nect to that, and visit http://​quadrf/. That page runs a VNC ses­sion in your browser, where you can launch apps from GNU Radio to SDR soft­ware, and even their cus­tom AR (Augmented Reality) RF vi­su­al­izer.

The AR vi­su­al­izer is the most in­ter­est­ing in­cluded soft­ware, de­spite be­ing less use­ful for real-world SDR ap­pli­ca­tions.

The UI is a lit­tle rough, but you can ad­just the align­ment be­tween your cam­era and the phased ar­ray, and the gain of the re­ceiver.

Then it will vi­su­al­ize fre­quen­cies from 4.9 – 6 GHz as col­or­ful blobs’. The scale is not shown on the dis­play in this early ver­sion, but from my test­ing around the stu­dio, my 5 GHz WiFi net­work (which was run­ning on Channel 100, or around 5.5 GHz) showed up light blue. Neighboring WiFi net­works were show­ing up red or green.

If you or­der the Mobile Expansion Pack, it in­cor­po­rates a bat­tery power pack, and a hand­held phone mount, so you can walk around an­a­lyz­ing part of the C-band in real-time.

My Dad and I flew his DJI Mini Pro 4 be­hind the stu­dio, and the QuadRF had no trou­ble pick­ing it out of the sky. As it flew away, I had to in­crease the gain to keep see­ing it; it would be nice to have AGC or an eas­ier gain con­trol as the UI was a lit­tle clunky when car­ry­ing around the con­trap­tion.

It sounds like the crowd­fund­ing cam­paign is al­ready be­yond ex­pec­ta­tions, and they’ll be switch­ing the en­clo­sure to an in­jec­tion mold (the ver­sion I have is 3D printed).

Raspberry Pi 5 MIPI for high-band­width RF

One as­pect that in­trigued me was the use of the Raspberry Pi’s MIPI lanes for low la­tency SDR stream­ing I/Q (In-phase/Quadrature) at data rates over 5 Gbps. From the QuadRF Documentation:

The novel ap­proach of stream­ing I/Q over the Pi’s cam­era and dis­play FFC MIPI con­nec­tors has many ben­e­fits. MIPI can han­dle >5 Gbps, low-la­tency, full-du­plex data trans­fer through the Pi’s RP1 chip. It is sim­pler and more re­li­able than USB, adds al­most zero hard­ware cost to the RF board, and can sus­tain hun­dreds of MSPS of I/Q with no hic­cups or sam­ple loss. Considering cam­eras and dis­plays are the ul­ti­mate form of high-band­width sig­nal stream­ing, it makes sense their stan­dard dig­i­tal in­ter­face is a great match for SDR! We think the in­dus­try should adopt it more widely!

The novel ap­proach of stream­ing I/Q over the Pi’s cam­era and dis­play FFC MIPI con­nec­tors has many ben­e­fits. MIPI can han­dle >5 Gbps, low-la­tency, full-du­plex data trans­fer through the Pi’s RP1 chip. It is sim­pler and more re­li­able than USB, adds al­most zero hard­ware cost to the RF board, and can sus­tain hun­dreds of MSPS of I/Q with no hic­cups or sam­ple loss. Considering cam­eras and dis­plays are the ul­ti­mate form of high-band­width sig­nal stream­ing, it makes sense their stan­dard dig­i­tal in­ter­face is a great match for SDR! We think the in­dus­try should adopt it more widely!

It sounds like they had to re­verse-en­gi­neer the MIPI pro­to­col used on the Pi 5 to do this (since it goes through the RP1 chip), and the way it’s ar­chi­tected, you can daisy-chain mul­ti­ple QuadRF mod­ules to­gether, let­ting each mod­ule cal­cu­late its own phase shift.

I’m not sure how that will work in prac­tice, but it sounds pretty neat. PCIe could prob­a­bly work in a pinch, too, but this im­ple­men­ta­tion frees up the PCIe con­nec­tor in case you want high speed stor­age or even higher speed net­work­ing than the Pi of­fers.

Conclusion

As with all pre-pro­duc­tion gear I test, take every­thing I’ve shown with a grain of salt. And with any crowd­fund­ing cam­paign, if you back it, don’t ex­pect the QuadRF to show up on your doorstep overnight.

I was ini­tially skep­ti­cal about how use­ful and fun this lit­tle hand­held phased ar­ray could be, but af­ter us­ing it for a week, I can’t wait un­til the one I pre-or­dered ships!

New York City becomes first in the US to ban deceptive subscription practices

www.theguardian.com

New York City has adopted a new rule that bans com­pa­nies from us­ing de­cep­tive sub­scrip­tions to trap cus­tomers into pay­ing for gym mem­ber­ships, stream­ing ser­vices and other re­cur­ring charges, the city’s con­sumer pro­tec­tion of­fice said.

The new rule, which will start on 1 October, promises hefty fines and ag­gres­sive en­force­ment for vi­o­la­tors. Companies that do not pro­vide a sim­ple way to can­cel could pay $525 per user sub­scrip­tion, back fees and ad­di­tional fines.

The city is also tar­get­ing so-called junk fees” that raise the fi­nal price of every­thing from apart­ments to sport­ing events, with a pro­posed rule that re­quires sell­ers to advertise the to­tal price for any good or ser­vice, in­clud­ing all manda­tory ad­di­tional charges and fees, up front”, ac­cord­ing to a re­lease shared with the Guardian.

New York would be the first US city to im­ple­ment such a ban.

People should­n’t have to wait on hold for half an hour or send a cer­ti­fied let­ter or show up to a store in per­son in or­der to can­cel” a sub­scrip­tion, said Samuel AA Levine, the city’s com­mis­sioner of con­sumer and worker pro­tec­tion, in an in­ter­view.

The new mea­sures were an­nounced in a press con­fer­ence on Friday.

The pro­posed fee rule could have an es­pe­cially wide ef­fect, send­ing rip­ples through New York’s ex­pen­sive hous­ing mar­ket, where about 70% of res­i­dents rent.

Apartment renters in the US face a ris­ing tide of add-on fees such as boiler man­age­ment” and lifestyle” charges from man­age­ment com­pa­nies, which make true rental costs hun­dreds of dol­lars higher than the price stated on real-es­tate com­pany web­sites.

If the pro­posed renters rule passes af­ter pub­lic com­ment and hear­ing, any manda­tory fees, in­clud­ing an­nual ones, would need to be in­cluded in the stated monthly rental price, Levine said.

The cur­rent sit­u­a­tion cre­ates a sce­nario where rather than com­pet­ing on price, com­pa­nies are com­pet­ing on their abil­ity to hide the true price. That’s the worst kind of in­cen­tive” — and one that deeply dis­torts the mar­ket, Levine said.

The moves are part of an ag­gres­sive push by Zohran Mamdani and Levine, a for­mer head of con­sumer pro­tec­tion in the Federal Trade Commission (FTC), to rein in what they see as preda­tory cor­po­rate mal­prac­tice na­tion­wide.

In the dawn of the [Ronald] Reagan era, the FTC and oth­ers in Washington said ex­pressly that … mar­kets could cor­rect them­selves, reg­u­late them­selves, they were go­ing to stop writ­ing rules,” and al­low com­pa­nies to po­lice their own be­hav­ior, Levine said. What it has got­ten us is 40 years of de­cep­tive pric­ing,” he said.

Bans on junk fees and sub­scrip­tion traps are gen­er­ally pop­u­lar with con­sumers, but have been fought ag­gres­sively by in­dus­try groups. When the Biden ad­min­is­tra­tion in­tro­duced a junk fee rule in 2024, the US Chamber of Commerce ar­gued it was an at­tempt to mi­cro­man­age busi­ness­es’ pric­ing struc­tures”, and apart­ment fees were cut from that fed­eral rule af­ter lob­by­ing by the real-es­tate in­dus­try.

A na­tional click-to-can­cel rule in­tro­duced by the Biden ad­min­is­tra­tion was struck down by a fed­eral judge in 2025, days be­fore it was set to go into ef­fect, over a pro­ce­dural rule. Donald Trump’s FTC plans to pass a sim­i­lar rule in com­ing months.

Companies make bil­lions a year in au­to­matic sub­scrip­tion re­newals that con­sumers do not want or do not know they have. The sub­scrip­tion rule could save New Yorkers alone as much as $162.5m per year, the Roosevelt Institute think­tank es­ti­mates.

While the sub­scrip­tion rule would only ap­ply to New York City res­i­dents, the pro­posed junk fee rule af­fects com­pa­nies such as ho­tels and rental car agen­cies that cater to vis­i­tors. If you are stay­ing in a ho­tel in the city that hits you with undis­closed fees upon check-in, you should com­plain to us”, Levine said.

The new rule is the Mamdani ad­min­is­tra­tion’s lat­est at­tempt to ad­dress the af­ford­abil­ity cri­sis af­ter heav­ily cam­paign­ing on mak­ing the city cheaper for res­i­dents. Members of Mamdani’s de­mo­c­ra­tic so­cial­ist group that were en­dorsed by the mayor won a flurry of pri­mary elec­tions in re­cent weeks, as some vot­ers em­brace left­wing pop­ulism that promises to em­power work­ing-class Americans, sim­i­lar to pledges by Trump in the past three pres­i­den­tial elec­tions.

The New York city coun­cil has also pro­posed a rule ban­ning surveillance pric­ing”, in which com­pa­nies charge con­sumers dif­fer­ent prices for the same good or ser­vice, based on al­go­rith­mic in­for­ma­tion from their spend­ing and other per­sonal habits.

Maryland banned the prac­tice in April. Colorado’s gov­er­nor ve­toed a ban last month.

The city will take pub­lic com­ments on the junk fee rule and then hold a hear­ing, Levine said. I cer­tainly hope that we can get this rule done by the end of the year.”

Good Tools Are Invisible

www.gingerbill.org

2026 – 07-10

TL;DR: A good tool is and ought to be in­vis­i­ble—striv­ing to make such tools is the goal of a tool­maker.

One habit I see a lot, and have to push back on, is tak­ing a tool’s short­com­ings and re­selling them as a puzzle game” which is fun” to solve.

I don’t want my tools to be fun”. I want my tools to be in­vis­i­ble.

Text Editor Wars

Let’s take vim as an ex­am­ple

This is just an ex­am­ple, and ap­plies to other ed­i­tors too.. I con­stantly see some peo­ple praise it not for what ac­tu­ally makes it good, but by tak­ing the things it’s bad at and turn­ing them into a puz­zle to have fun” solv­ing.

I’ve had peo­ple tell me how fun” it was to build a macro to han­dle some one-off text-refac­tor­ing prob­lem. But when I looked at what they were do­ing and how long it took, my hon­est re­ac­tion was: I could have done that in Sublime in a minute with mul­ti­ple cur­sors, or just writ­ten a quick script.

To be clear, I’m not say­ing text ed­i­tors don’t mat­ter to your work­flow. I’m ques­tion­ing the near-re­li­gious de­vo­tion peo­ple have to a tool be­cause it gives them a hacker vibe”—which is ba­si­cally the whole ap­peal for new­com­ers to vim or emacs.

That’s what I mean by invisible tools”. When you’re pro­fi­cient with your ed­i­tor of choice—what­ever it is—it dis­ap­pears into the back­ground. But the mo­ment it can­not han­dle some­thing eas­ily, it stops be­ing in­vis­i­ble. What baf­fles me is that so many peo­ple treat that fric­tion—the ef­fort of work­ing around a tool’s lim­i­ta­tions—as the fun” part, and then ad­ver­tise it as ev­i­dence that the tool is great.

I know plenty of things wrong with my own ed­i­tor of choice: Sublime. I don’t dress those flaws up as fun lit­tle puz­zles to solve. I just get an­noyed that it lacks the tools I ac­tu­ally need, forc­ing me to write a plu­gin or reach for a sep­a­rate pro­gram to write to trans­form text the way I want.

I’ve been us­ing Sublime for 15 years now. It’s my ed­i­tor of choice for a few rea­sons: its short­cuts are a su­per­set of the graph­i­cal OS en­vi­ron­ment (which min­i­mizes the men­tal con­text-switch when mov­ing be­tween ap­pli­ca­tions), mul­ti­ple cur­sors re­ally are bet­ter than macros 99.999% of the time

I think I’ve only needed” a macro in Sublime twice in the past decade, and in both cases, set­ting up the macro took longer than if I just wrote a script to do the same thing. (since they give di­rect vi­sual feed­back), and it leaves me with the fewest puzzles” to solve in my text-edit­ing work­flow. I’ve found some­thing like vim to be bet­ter at ba­sic edit­ing but worse at bulk op­er­a­tions—and I don’t mean grep-like op­er­a­tions—which is why I’ve stuck with Sublime for so long. I never found vim mo­tions to be that much more pro­duc­tive than my Sublime work­flow ei­ther, and that was­n’t just down to lack of try­ing or fa­mil­iar­ity

To be hon­est, I have for­got­ten most of my vim mo­tions” knowl­edge over the years, be­cause I don’t reg­u­larly ex­er­cise it, nor do I need to.. And since I vir­tu­ally never write code in a ter­mi­nal, my need for a ter­mi­nal-ori­ented ed­i­tor is ef­fec­tively nonex­is­tent.

If peo­ple find vim, emacs, or what­ever gen­uinely good and pro­duc­tive, I’m not go­ing to crit­i­cize them for us­ing it. People are most com­fort­able with what they know. But for the peo­ple I am dis­cussing, that same fa­mil­iar­ity blinds them to their tools’ flaws, and leads them to cel­e­brate those flaws, flaunt­ing them as games.

Tools as an Identity

Part of why these de­bates turn re­li­gious is that a tool choice be­comes a flag you plant—it says some­thing about who you are. The hacker vibe” is­n’t a mere aes­thetic; it’s tribal sig­nal­ing, and that’s the real trap. Once your iden­tity is in­vested in a tool, ad­mit­ting its flaws starts to feel like ad­mit­ting some­thing about your­self. So peo­ple don’t just tol­er­ate the flaws—they de­fend them, and even­tu­ally flaunt them. You can­not have an hon­est con­ver­sa­tion about a tool with some­one who’s de­cided the tool is part of their per­son­al­ity.

Feeling Productive ver­sus be­ing Productive

The text-ed­i­tor-macro anec­dote I men­tioned is re­ally about a gap be­tween feel­ing pro­duc­tive ver­sus be­ing pro­duc­tive. There’s a sen­sa­tion of clev­er­ness that comes from solv­ing a fid­dly prob­lem, and it’s easy to mis­take that feel­ing for ac­tual out­put. A tool that makes hard things feel heroic and clever feel like an achieve­ment can reg­is­ter as powerful” while qui­etly be­ing slow. The hon­est test is­n’t how en­gaged or clever you felt, it’s wall-clock time and how many mis­takes you made get­ting there. A lot of the tools peo­ple evan­ge­lize would lose that test.

If pro­duc­tiv­ity is ac­tu­ally the goal, ac­tu­ally ques­tion your own views on this, and try to see what makes you more pro­duc­tive. You will be sur­prised when you do.

Terminal UIs vs GUIs

Another ex­am­ple in this same vein is when peo­ple ad­vo­cate for ter­mi­nal apps over GUIs. If you’re stuck in a ter­mi­nal all day, then I com­pletely get the ob­vi­ous ad­van­tage, but most pro­gram­mers aren’t stuck in a ter­mi­nal all day.

From those peo­ple who gen­er­ally ad­vo­cate for a TUI over a GUI, one of the crit­i­cisms of GUI apps tends to be: I can­not nav­i­gate them with the key­board alone”.

Okay? That does­n’t make GUI apps in­her­ently bad. It just means the GUIs peo­ple build aren’t good enough to be key­board-nav­i­ga­ble. There’s noth­ing in­her­ently im­pos­si­ble about mak­ing a GUI nav­i­ga­ble with a key­board, rather it’s just that most tool­mak­ers never bother to im­ple­ment, and usu­ally be­cause they don’t re­al­ize how much more pro­duc­tive key­board nav­i­ga­tion is than reach­ing for the mouse a lot of the time. If the ar­gu­ment was that a spe­cific TUI app is bet­ter than the other al­ter­na­tives which are GUI based, then that is a fair ar­gu­ment, but ar­gu­ing that TUIs are in­her­ently bet­ter than GUIs is very mis­in­formed.

And this is the com­mon mis­take: peo­ple look at the cur­rent state of a cat­e­gory of tools and as­sume its cur­rent lim­i­ta­tions are in­her­ent/​es­sen­tial, when re­ally no one has put in the work to make those tools bet­ter.

Linux’s (Lack of) Popularity as a Desktop

The year of the Linux

I know I am go­ing to get peo­ple say­ing Linux is the Kernel, the OS is the [insert dis­tro name]”. I’m sorry but that’s not how most peo­ple talk about Linux, and I don’t re­ally care too much for your pen­dantry which aids noth­ing. Especially since to cri­tique it, you clearly had to un­der­stand what was be­ing said about it. desk­top still is­n’t upon us (in 2026), and part of the rea­son why it has taken so long to get to that point is fun­da­men­tal: a lot of the peo­ple who use Linux love fid­dling with con­fig­u­ra­tion files to re­shape their sys­tem—it’s their idea of fun”, their puz­zle game.

I went through that phase my­self. But af­ter a while, I just wanted things to work. Spending hours (if not days) con­fig­ur­ing every­thing is­n’t some­thing I want to do any more. I want the de­faults to be good and just work, and when I do need to tweak some­thing mi­nor, it should take sec­onds.

Maximal con­fig­ura­bil­ity should­n’t be a tool’s goal, it should be an op­tion for when it’s ac­tu­ally nec­es­sary. Designing an er­gonomic tool is fun­da­men­tally about hav­ing good de­faults, while still al­low­ing es­cape hatches where they’re pos­si­ble/​needed.

The ap­peal of ac­ci­den­tal

Characteristics that an ob­ject has con­tin­gently and can change with­out al­ter­ing the ob­jec­t’s es­sen­tial iden­tity. com­plex­ity is some­thing a lot of pro­gram­mers/​techy-folk love, giv­ing them a weird sense of se­cu­rity.

Having good de­faults is fun­da­men­tally a tool­mak­er’s re­spon­si­bil­ity. We as tool­mak­ers have a ten­dency to put the bur­den on the user: to con­fig­ure it, to tweak it, to learn it. A lot of that bur­den is re­ally a de­signer de­clin­ing to make a de­ci­sion. Highly con­fig­urable” is of­ten just an ex­cuse for ship­ping no opin­ion at all and call­ing the re­sult­ing work your prob­lem. Good de­faults are a form of re­spect for the user’s time: the tool­maker does the think­ing once so a thou­sand users don’t each have to. And part of de­sign­ing a tool is to al­low for some es­cape hatches tool; those es­cape hatches are there for the gen­uine mi­nor­ity who need some­thing un­usual; they should not be a sub­sti­tute for get­ting the com­mon case right.

Steep Learning Curve as a Feature”?

Another de­fence I’ve seen is that the dif­fi­culty is the whole point, it fil­ters out the un­com­mit­ted, and once you’re over the hump you’re re­warded for life. But a learn­ing curve is a cost, not a virtue. It could hy­po­thet­i­cally be ab­solutely a cost worth pay­ing, but the pay­off has to be gen­uine pro­duc­tiv­ity, not the sat­is­fac­tion of hav­ing paid it. Too of­ten the rea­son­ing is just sunk-cost dressed up as merit: I spent months learn­ing this, so it must be worth it, and you should copy in my foot­steps too”. That’s the puz­zle game again, only now the puz­zle is the tool it­self.

Conclusion

None of this is an ar­gu­ment against any par­tic­u­lar tool. It’s an ar­gu­ment against a way of think­ing. Use vim, use emacs, use Sublime, but use what­ever dis­ap­pears into the back­ground and lets you get on with the work. That is the whole test, and it’s a per­sonal one. What I’m push­ing back on is­n’t the choice, it’s the sto­ry­telling that grows up around the choice: the re­fram­ing of lim­i­ta­tions as fea­tures, the ef­fort of work­ing around a flaw sold as the re­ward, the tool qui­etly pro­moted from the thing-you-use to the part-of-who-you-are.

The clear­est sign a tool is serv­ing you is that you stop notic­ing it—it be­comes in­vis­i­ble. You don’t cel­e­brate its flaws be­cause you’re not turn­ing them into a hobby, rather you just get mildly an­noyed and route around them. You don’t de­fend it be­cause noth­ing about your iden­tity is rid­ing on it. And you don’t mis­take the feel­ing of clev­er­ness for the fact of pro­duc­tiv­ity, be­cause you’ve both­ered to check the dif­fer­ence.

So by all means, en­joy your tools, for the joy of pro­gram­ming it­self. Just be hon­est about which parts are gen­uinely good and which parts you’ve talked your­self into lov­ing. The best tool is­n’t the one with the best story. It’s the one you for­get you’re us­ing.

A good tool is and ought to be in­vis­i­ble—striv­ing to make such tools is the goal of a tool­maker.

Collections: The Late Bronze Age Collapse, A Very Brief Introduction

acoup.blog

This week, by or­der of the ACOUP Senate, we’re talk­ing about the Late Bronze Age Collapse (commonly ab­bre­vi­ated LBAC), the shock­ing col­lapse of the Late Bronze Age state sys­tem across the Eastern Mediterranean and Middle East dur­ing the 12th cen­tury (that is, the 1100s) BC. In the broader Mediterranean world, the Late Bronze Age Collapse is the event that prob­a­bly comes clos­est to a true end of civ­i­liza­tion’ event — mean­ing­fully more se­vere than the col­lapse of the Roman Empire in the West (although as we’ll see LBAC is also not as total’ of a col­lapse as was some­times sup­posed).

This is go­ing to be, by our stan­dards here, some­thing of a brief overview, roughly the equiv­a­lent to the lec­ture I give to my stu­dents when we cover this pe­riod (with a bit more de­tail, be­cause text is more com­pressed). A full deep di­ve’ of all of the de­bates and open ques­tions of this pe­riod would no doubt run quite a few posts and more im­por­tantly re­ally ought to be writ­ten by spe­cial­ists in the bronze age. This is also a very ar­chae­o­log­i­cally dri­ven topic, which makes it more sen­si­tive than most to new ev­i­dence — ar­chae­o­log­i­cal site work, but also epi­graphic ev­i­dence (mostly on clay tablets) — that can change our un­der­stand­ing of events. As we’ll see, our un­der­stand­ing has changed a fair bit.

So what we’ll do is run through what we know about what hap­pened in the col­lapse (which is the most vis­i­ble part of it) and then we’ll loop back to the ques­tion of causes (which re­main sub­stan­tially un­cer­tain) and then fi­nally look at the long-term im­pacts of the col­lapse, which are con­sid­er­able.

But first, as al­ways, if you like what you are read­ing here, please share it; if you re­ally like it, you can sup­port me on Patreon; mem­bers at the Patres et Matres Conscripti level get to vote on the top­ics for post-se­ries like this one! If you want up­dates when­ever a new post ap­pears or want to hear my more bite-sized mus­ings on his­tory, se­cu­rity af­fairs and cur­rent events, you can fol­low me on Bluesky (@bretdevereaux.bsky.social). I am also ac­tive on Threads (bretdevereaux) and main­tain a de min­imis pres­ence on Twitter (@bretdevereaux).

The (Partial?) Collapse

We need to be clear, to be­gin with, that while we have scat­tered frag­ments of epi­graphic ev­i­dence (that is, in­scrip­tions), al­most all of our ev­i­dence for the Late Bronze Age Collapse is ar­chae­o­log­i­cal. Without ar­chae­ol­ogy, we would re­main largely in the dark about this event. But ar­chae­o­log­i­cal ev­i­dence also brings with it chal­lenges: it can tell you what is hap­pen­ing (sometimes) but of­ten not why and dat­ing with pre­ci­sion can be chal­leng­ing. Most of what we’re track­ing in un­der­stand­ing LBAC is site de­struc­tion, iden­ti­fied by the de­mo­li­tion of key build­ings or destruction lay­ers’ (often a thin layer of ash or rub­ble in­di­cat­ing the site was burned or de­mol­ished), but dat­ing these pre­cisely can be dif­fi­cult and there are al­ways chal­lenges of in­ter­pre­ta­tion.

With that said, the Late Bronze Age Collapse is a se­quence of site de­struc­tions vis­i­ble ar­chae­o­log­i­cally from c. 1220 BC to c. 1170 BC, which are as­so­ci­ated with the col­lapse or se­vere de­cline of the ma­jor states of the re­gion (the Eastern Mediterranean and Middle East). We gen­er­ally con­cep­tu­al­ize these de­stric­tions as a wave’ mov­ing in se­quence be­gin­ning in the Aegean, mov­ing over Anatolia, sweep­ing down the Levant and ar­riv­ing in Egypt but in many cases my sense is the chronol­ogy is more com­plex than that. Many sites in the path of this wave’ were not de­stroyed, with some de­clin­ing slowly and oth­ers de­clin­ing not much at all; other sites (I have in mind Tiryns) see the de­struc­tion of their po­lit­i­cal cen­ter but the de­cline of the ur­ban set­tle­ment around it hap­pens slowly or later.

First, we ought to set the stage of the Late Bronze Age. What re­ally marks out the Late Bronze Age (c. 1500 BC to c. 1200 BC) from ear­lier pe­ri­ods is that the emerg­ing state sys­tems in Mesopotamia, Syria, Anatolia and Egypt had ex­panded to the point of com­ing quite fully into con­tact with each other, with a sig­nif­i­cant de­gree of diplo­matic, eco­nomic and cul­tural in­ter­con­nect­ed­ness, to the point that we some­times re­fer to the Late Bronze Age Concert of Powers’ (evoking 19th cen­tury European bal­ance of power pol­i­tics) when talk­ing in­for­mally about them.

Now I should cau­tion, we of­ten pro­vide these nice neat maps of the Late Bronze Age pow­ers (and they’re use­ful to a de­gree) but the bor­ders of these states were quite fuzzy — their outer possessions’ were of­ten trib­u­taries un­der the rule of lo­cal kings which might be weakly at­tached to the im­pe­r­ial cen­ter. Nevertheless, go­ing from East to West: south­ern Mesopotamia was dom­i­nated by the Middle Babylonian’ Empire, ruled by the Kassite dy­nasty (the Kassites be­ing an eth­nic group who had taken power around 1530 BC) while north­ern Mesopotamia was dom­i­nated by the Middle Assyrian Empire (from about c. 1350 BC). Anatolia and the Northern Levant was con­trolled by the multi-eth­nic Hittite Empire, which seems to have sparred reg­u­larly with the New Kingdom of Egypt which con­trolled Egypt and the south­ern Levant. Basically all of these pow­ers had less set­tled, of­ten pas­toral peo­ples in their hin­ter­lands which pre­sented on-go­ing se­cu­rity chal­lenges for them.

These larger im­pe­r­ial states were more eco­nom­i­cally com­plex as well. In par­tic­u­lar, their large armies re­quired sig­nif­i­cant amount of bronze which — be­cause its core in­gre­di­ents of tin and cop­per ef­fec­tively never oc­cur in the same place — de­manded sub­stan­tial long-dis­tance trade, though trade was hardly only in cop­per and tin, but also in­cluded other high value goods and even (where fea­si­ble) bulk sta­ples. So while these pow­ers clashed reg­u­larly, at the elite level (if not at the level of the sub­sis­tence econ­omy) they were also re­liant on each other to some de­gree.

Finally, at the edge of this state sys­tem is the Mediterranean and es­pe­cially the Aegean. In the Aegean — in Greece and Crete es­pe­cially — we see ef­fec­tively minia­ture ver­sions of these state struc­tures, com­plete with (by Near Eastern Standards) itty-bitty palaces (the Minoan ur­ban cen­ters on Crete had come un­der Mycenean (=Greek) rule in c. 1450, the palaces there largely aban­doned). Cyprus shifted be­tween be­ing nom­i­nally sub­or­di­nate to ei­ther the Hitties of the Egyptians but seems to have mostly run its own af­fairs and was in­te­grated through trade into the state sys­tem.

As noted above, LBAC starts per­haps as early as 1220 or so, and what we see in very rough se­quence is as fol­lows.

As far as I know, we still gen­er­ally think the ear­li­est rum­blings are in­sta­bil­ity in the Mycenean Greek palace states. Things had been un­sta­ble in this area for a few decades and we have some scat­tered de­struc­tions (Thebes) and in­ten­si­fied for­ti­fi­ca­tions around 1250, sug­gest­ing things were not go­ing great in Greece. Then from c. 1200 to c. 1180 we see the de­struc­tion or col­lapse of ba­si­cally all of the palace cen­ters in Greece. In some cases the ur­ban core con­tin­ues for a while, in other cases it does­n’t — in a num­ber of cases, once the site is aban­doned, it is not rein­hab­ited (e.g. Mycenae it­self, the largest of the palace cen­ters).

As we’ll see be­low, the im­pact in Greece is greater than ba­si­cally any­where else be­cause the col­lapse of the LBAC is more se­vere in Greece than ba­si­cally any­where else.

Meanwhite, the Hittite Empire was it­self not in good shape when this started. As far as we know, the Hittites were very much on the back foot’ in the late 1200s, pres­sured by the Assyrians and Egypt and so po­ten­tially al­ready short on re­sources when their neigh­bors to the West be­gan im­plod­ing. As far as I know, pre­cise dates are hard to nail down for this, but the Hittite Empire in the early 1100s comes apart un­der pres­sure and by 1170 or so it is gone. That col­lapse of im­pe­r­ial power is matched by a sig­nif­i­cant num­ber of site de­struc­tions across Anatolia, in­clud­ing the Hittite cap­i­tal at Hattusas and the large set­tle­ment at mod­ern Hisarlik, now fairly se­curely iden­ti­fied as an­cient Troy. Some (like Troy) were re­built, oth­ers (like Hattusas) were not, but cen­tral­ized Hittite power was gone and there’s a marked re­duc­tion in ur­ban­iza­tion and prob­a­bly pop­u­la­tion.

Moving into the Northern Levant, Syria and Northern Mesopotamia, we see Assyrian power — which had been ad­vanc­ing be­fore, you’ll re­call — con­tract sharply along­side more site de­struc­tions, though again chronol­ogy is tricky. One of the key sites here is Ugarit, a ma­jor Bronze Age Levantine coastal city which was de­stroyed c. 1190 — be­fore the last of the Mycenean palaces (but af­ter the first of them). The city’s de­struc­tion in fire pre­served clay tablets with diplo­matic mes­sages from the lo­cal king of Ugarit (a Hittite vas­sal) fran­ti­cally writ­ing to his Hittite su­pe­ri­ors for re­in­force­ments in the face of sig­nif­i­cant (but frus­trat­ingly un­named) threats prior to the de­struc­tion of the city.

That said, de­struc­tion in the Fertile Crescent is very un­even. The Middle Assyrian Empire con­tracts, but does not col­lapse, while the Kassite Dynasty in Babylon clearly suf­fers some de­cline, but largely sta­bi­lizes by the 1160s be­fore be­ing run over by the Elamites in the 1150s. Site de­stric­tions in the Levant are un­even and some key Bronze Age cen­ters like Sidon and Byblos were not de­stroyed and re­mained ma­jor cen­ters into the Iron Age.1 My un­der­stand­ing is that while there was sig­nif­i­cant de­cline in the south­ern Levant, it is hard to pin any spe­cific large-scale site de­struc­tion to the 1220 – 1170 pe­riod.

Finally we reach Egypt in a pe­riod we re­fer to as the New Kingdom’ (1570 – 1069); we can trace pol­i­tics more clearly here due to sur­viv­ing Egyptian in­scrip­tions. Egypt was also in a weak­ened po­si­tion go­ing into this cri­sis, fac­ing pres­sure from Libyan raiders com­ing over­land from the West and also some in­ter­nal in­sta­bil­ity. In c. 1188, civil war broke out as the last queen of the reign­ing 19th dy­nasty was un­able to re­tain con­trol, lead­ing to re­volt and the seizure of power by Setnakhte and the 20th dy­nasty; his son Ramesses III took power in c. 1185. Things did­n’t get eas­ier from there as we hear re­ports of re­newed Libyan in­cur­sions in c. 1180 (coming from the west) fol­lowed al­most im­me­di­ately by an in­va­sion by the sea peo­ples’ (see be­low) who were ev­i­dently fended off in at least two ma­jor bat­tles, the Battle of the Delta (c. 1179ish?) and the Battle of Djahy (c. 1178ish?).

Egypt holds to­gether, but there’s a fair bit of ev­i­dence eco­nomic strain (likely cli­mate based, see be­low) and the abil­ity of Egypt to pro­ject power out­side of Egypt seems largely spent by the end of the reign of Ramesses III; his suc­ces­sors do not ap­pear to have been able to right the ship and Egyptian power con­tin­ued to frag­ment and de­cline, with the dy­nasty stum­bling on un­til it col­lapsed in 1077 lead­ing to the Third Intermediate Period (‘Intermediate Periods’ are the term for pe­ri­ods of frag­men­ta­tion within Egypt).

I should note in this overview that our un­der­stand­ing of this se­quence of col­lapses and de­clines has changed sig­nif­i­cantly. The idea of the Late Bronze Age Collapse has been around since the early 1800s when his­to­ri­ans first no­ticed that the end of the Greek Age of Heroes’ (linked by them to the Fall of Troy, which the (Classical) Greeks be­lieved hap­pened in 1184) seemed to map neatly on to the fail­ure of the Egyptian 19th Dynasty. As ar­chae­ol­o­gists in the later 1800s and early 1900s started ac­tu­ally ex­ca­vat­ing the Greek Age of Heroes’ (thus dis­cov­er­ing the (Mycenaean) Greek Late Bronze Age, which we term the Late Helladic’ pe­riod (c. 1700-c. 1040 BC)) and then find­ing site de­struc­tions date­able within a band of per­haps 1250 to 1150 BC in Greece, Anatolia, Syria and the Levant the idea of a gen­eral col­lapse around the leg­endary date for the Fall of Troy picked up a lot of steam.

My sense of the schol­ar­ship is that this civilizational col­lapse’ nar­ra­tive has been drawn back a bit as it be­comes clear that some sites were not de­stroyed and also that some site de­struc­tions or aban­don­ments hap­pened sig­nif­i­cantly later or ear­lier than the rel­a­tively tight 1220 – 1170 BC time frame that emerged for the core of the col­lapse. No one (that I know of) is ar­gu­ing there was no LBAC — there was clearly an LBAC — but the scale of the col­lapse re­mains some­thing of a mov­ing tar­get as we ex­ca­vate more sites, adding them to lists of sites that were de­stroyed, de­clined or (sometimes seem­ingly ran­domly) were spared.

And the list of sites that were not de­stroyed is sig­nif­i­cant. Of note, Athens very clearly has a Mycenaean citadel on the Acropolis (which can’t be ex­ca­vated be­cause the Acropolis is in the way, but it is very ob­vi­ously there) but there’s no break in set­tle­ment in Athens. Already men­tioned, Byblos and Sidon re­mained very promi­nent cen­ters be­fore and af­ter, while Jerusalem and Tyre, both ap­par­ently mi­nor set­tle­ments be­fore LBAC (and not de­stroyed) will be­come in­creas­ingly promi­nent in the Iron Age Levant. Likewise the great cities of Egypt and Mesopotamia re­main, few to no site de­struc­tions in ei­ther re­gions. At the same time, many set­tle­ments that es­cape de­struc­tion do not es­cape de­cline: in many cases these cities con­tinue to shrink (and some places that es­cape de­struc­tion, like Tiryns, shrink slowly rather than van­ish­ing all at once) or grow vis­i­bly poorer in a longer process. So the mo­ment of de­struc­tion comes with a long tail’ of de­cline stretch­ing out decades.

So to sum­ma­rize, the Late Bronze Age Collapse is a se­ries of site de­struc­tions, aban­don­ments and de­clines run­ning from roughly 1220 to roughly 1170 (though de­cline con­tin­ues af­ter this point) dis­trib­uted quite un­evenly through the in­ter­con­nected Late Bronze Age Mesopotamian-and-Eastern-Mediterranean world. Greece and Anatolia are se­verely im­pacted, the Levant some­what less but still fairly strongly, while the states of Egypt and Mesopotamia do not col­lapse but en­ter long pe­ri­ods of de­cline.

What that de­scrip­tion leaves out, of course, are causes and ef­fects.

Bad Theories

While the what’ of LBAC can be pinned down fairly con­clu­sively with ar­chae­ol­ogy, the why’ is tougher — a lot of po­ten­tial causes (wars, armies, civil un­rest) don’t nec­es­sar­ily leave a lot of clues in our source ma­te­r­ial.

There are a few the­o­ries we can largely dis­count at the out­set though. The older of these were the­o­ries that as­sumed that the cause of at least some of the Late Bronze Age Collapse were large-scale mi­gra­tions of peo­ple into (rather than within) the set­tled, ur­ban zone we’ve been talk­ing about, in par­tic­u­lar the idea of a Dorian Invasion’ of Greece as the spark of the col­lapse. Proposed in the 1800s, the idea here was that the Dorians’ — the an­ces­tors of the Greeks — would have mi­grated into Greece, de­stroy­ing the Mycenaean cities and palaces and dis­plac­ing or dom­i­nat­ing the pre­vi­ous (non-Greek) in­hab­i­tants. This no­tion was based on mixed and com­pet­ing ideas within (Classical) Greek lit­er­a­ture: Greek au­thors both ex­pressed the idea of the Greeks be­ing au­tochtho­nous (indigenous to their ter­ri­tory, lit­er­ally [arising] on their own from the earth’) and also be­ing in­vaders, ar­riv­ing at some point forty to eighty years af­ter the Trojan War (e.g. Thuc. 1.12; Hdt. 1.56 – 58). That idea got picked up by 19th cen­tury European schol­ars who, to be frank, of­ten thought un­crit­i­cally in terms of pop­u­la­tion mi­gra­tion and re­place­ment, through an of­ten ex­plic­itly racist lens of superior stock’ dri­ving out inferior stock.’ And so they imag­ined a Dorian in­va­sion’ of the (racially) superior’ Greek-speaking Dorians2 dri­ving out the pre-Greek Mycenaean pop­u­la­tion, par­tic­u­larly in the Peloponnese.

As an aside, it is not un­com­mon for a sin­gle so­ci­ety to uti­lize both leg­endary myths of au­tochthony and ar­rival-by-con­quest, choos­ing whichever is more use­ful in the mo­ment, even though they are ob­vi­ously, from a log­i­cal stand­point, mu­tu­ally in­com­pat­i­ble.

Archaeology has fun­da­men­tally un­der­mined this the­ory — nuked it from or­bit, re­ally — in two key ways. First, we have Mycenaean writ­ing, which was dis­cov­ered in a strange script called Linear B (Minoan writ­ing is Linear A). Originally un­read­able to us, in 1952 Michael Ventris suc­cess­fully demon­strated that Linear B was, in fact, Greek (rendered in a dif­fer­ent, older script) and so the Mycenaeans were Greeks. Meanwhile a wide range of ar­chae­ol­o­gists and ma­te­r­ial cul­ture schol­ars, as more late Helladic and early Archaic pot­tery and art­work emerged, were able to demon­strate there sim­ply was no dis­con­ti­nu­ity in ma­te­r­ial cul­ture. The Greeks could not be ar­riv­ing at the end of the Bronze Age be­cause they were al­ready there and had been for cen­turies at least. Migrations within the Eastern Mediterranean might still play a role, but the idea that the col­lapse was caused by the ar­rival of the Greeks has been de­ci­sively aban­doned. There was no Dorian Invasion.

The other cause we can prob­a­bly dis­miss is a sin­gle, sud­den nat­ural calamity. There are two can­di­dates here to note. The first is sim­ply peo­ple con­fus­ing the ma­jor erup­tion of Thera (c. 1600) which is some­times as­so­ci­ated with the de­cline of the Minoan Palaces (though the chronol­ogy does­n’t re­ally work well there ei­ther) with LBAC. The sec­ond is ef­fort to con­nect the erup­tion of Hekla in Iceland with LBAC. The prob­lem again is that the chronol­ogy does not ap­pear to work out — es­ti­mates for the dat­ing of the Hekla erup­tion range from 1159 to 929 with the con­sen­sus be­ing, as I un­der­stand it, closer to 1000 BC. For our part, the range does­n’t mat­ter much — even that ear­li­est 1159 date would mean that Hekla’s mas­sive erup­tion could hardly ex­plain the col­lapse of Mycenean palaces hap­pen­ing at least forty years ear­lier. Climate played a role in LBAC, but it is not clear that vol­canic cli­mate in­flu­ence did and it is very clear that Hekla did not (though per­haps it con­tributed to make a bad de­cline worse.

So no Dorian Invasions’ and no vol­ca­noes, so what did cause it?

Causes of LBAC

We have no firm an­swers, but a num­ber of plau­si­ble the­o­ries and at this point my sense is that just about every­one work­ing on this pe­riod adopts some vari­a­tion of all of the above’ from this list.

We can start with cli­mate. For rea­sons there’s been quite a lot of re­search into his­tor­i­cal cli­mate con­di­tions and we can ac­tu­ally get a sense of those con­di­tions to a de­gree ar­chae­ol­ogy from things like tree rings (where very nar­row rings can in­di­cate dry years or oth­er­wise un­fa­vor­able con­di­tions). I don’t work on his­tor­i­cal cli­mate, but my un­der­stand­ing is there is quite a lot of com­pelling ev­i­dence that pe­riod of LBAC, es­pe­cially the 1190s, was un­usu­ally dry in the Eastern Mediterranean, which would have caused re­duced agri­cul­tural out­put (crop fail­ures). Interestingly, this would be most im­me­di­ately im­pact­ful in ar­eas en­gaged pri­mar­ily in rain­fall agri­cul­ture (Greece, Anatolia, the Levant) and less im­pact­ful in ar­eas en­gaged more in ir­ri­ga­tion agri­cul­ture (Egypt, Mesopotamia).3 And, oh look, the ar­eas where LBAC was more se­vere are in the rain­fall zone and the ar­eas where it was less se­vere are in the ir­ri­ga­tion zone.

Crop fail­ures may have been par­tic­u­larly po­lit­i­cally volatile be­cause of the struc­ture and val­ues of the kind of Near Eastern states (to in­clude Anatolia and Greece here) that we’re deal­ing with. We haven’t dis­cussed early bronze age states very much but the ev­i­dence we have sug­gests that these were sig­nif­i­cantly cen­tral­ized states, with a lot — not all, but a lot — of the re­sources mov­ing through ei­ther state (read: royal) struc­tures or through tem­ple in­sti­tu­tions which might as well have been state struc­tures. Which is to say these are so­ci­eties where the king and the tem­ples (which re­port to the king) own most of the land and so har­ness most of the agri­cul­tural sur­plus through rents and then em­ploy the li­on’s share of non-agri­cul­tural la­bor, re­dis­trib­ut­ing their pro­duc­tion. Again, I don’t want to over­state this — there is a private sec­tor’ in these economies — but it seems (our ev­i­dence is lim­ited!) to be com­par­a­tively small.

Meanwhile, the clearly at­tested re­li­gious role of the king in a lot of these so­ci­eties in­cludes a re­spon­si­bil­ity — of­ten the para­mount re­spon­si­bil­ity — to main­tain the good re­la­tions of the com­mu­nity with the gods (who pro­vide the rain and make the plants grow).

Repeated crop fail­ures are thus go­ing to be seen as a sign that the King is falling down on the job. Worse yet, they’ll have come at the same time as the King found him­self strained to main­tain his bu­reau­crats and sol­diers, be­cause the en­tire top-heavy royal ad­min­is­tra­tion this sys­tem re­lies on is fed off of the sur­plus it ex­tracts.

It is not hard to see how this is a recipe for po­lit­i­cal in­sta­bil­ity if large states do not have the re­sources to fall back on to re­spond to the cri­sis.

To which some schol­ars have noted that the pe­riod di­rectly lead­ing up to LBAC seems to have been a pe­riod of in­ten­si­fy­ing war­fare: we hear of larger armies op­er­at­ing in the wars in Mesopotamia, Egypt and the Levant and we see mas­sively greater in­vest­ment in for­ti­fi­ca­tion in the Aegean all sug­gest­ing that the states are pour­ing re­sources into war­fare. That may have left these states with fewer re­sources (idle la­bor, stored grain, money-covertable valu­ables or sim­ply re­serves of pub­lic good­will since long years of high taxes in long wars tends to tire peo­ple out) with which to con­front a sud­den wave of com­bined po­lit­i­cal un­rest and food short­age.

What is clear is that once the col­lapse started, it was con­ta­gious, likely for two rea­sons: first that col­laps­ing ar­eas pro­duced in­vad­ing forces and refugee flows that desta­bi­lized their neigh­bors and sec­ond be­cause as you will re­call above, these states are in­ter­linked and their rulers rely on trade to fur­nish the key mil­i­tary re­source (bronze) as well as to ac­quire key pres­tige goods nec­es­sary to main­tain the loy­alty of the aris­toc­racy.

The clear­est ev­i­dence of this are the re­ports in Egyptian in­scrip­tions of peo­ples grouped un­der the mod­ern head­ing of Sea Peoples’ be­cause they are of­ten de­scribed as be­ing of the sea’ in one way or an­other. The ev­i­dence here is tricky: what we have are a set of in­scrip­tions, span­ning from 1210 through to the mid-1100s de­scrib­ing fight­ing against — and, this be­ing Egyptian royal writ­ing, in­vari­ably the vic­tory of a Pharaoh over — a range of in­vad­ing peo­ples. What is tricky is these re­ports cover mul­ti­ple pe­ri­ods of fight­ing and they’re us­ing Egyptian names for these peo­ple mean­ing we’re not al­ways en­tirely con­fi­dent that we can tell who ex­actly the Egyptians meant to iden­tify.

Generally, how­ever, what we seem to be see­ing is in­creased pres­sure on Egypt from c. 1205 to c. 1170 from multi-eth­nic coali­tions of peo­ples drawn from the Aegean, Anatolia and the Levant. In par­tic­u­lar, in­scrip­tions from the reign of Merneptah (r. 1213 – 1203) re­port at­tacks by the Ekwesh (possibly an Egyptian ren­der­ing of Achaioi, Achaean,’ mean­ing Greek) along with the Lukka (an Anatolian peo­ple), the Sherden (probably a Levantine peo­ple, per­haps the Philistines) and oth­ers even harder to pin down like the Shekelesh (more Anatolians? Sicels? other peo­ple on boats?). Later in­scrip­tions from the reign of Ramesses III (r. 1185 – 1154) re­port rel­a­tively early in his reign vic­to­ries against coali­tions that in­clude the Denyen (possibly an Egyptian ren­der­ing of Danaioi,’ mean­ing Greek), the Sherden (again), the Shekelesh (again), the Peleset (Levantine peo­ple, prob­a­bly Philistines) and oth­ers.

The way this ev­i­dence is gen­er­ally read — and this seems the most plau­si­ble ex­pla­na­tion — is that the dis­rup­tions in the Aegean, Anatolia and Levant may have them­selves pro­duced armed mass-mi­gra­tions, mov­ing by sea (these were all sea-far­ing peo­ples), per­haps look­ing for safe har­bor. Or per­haps quite lit­eral bands of raiders — the col­lapse of state struc­tures in Greece and Anatolia might well have left a lot of full-time vi­o­lence-do­ers with­out steady em­ploy­ment and go­ing raid­ing may have been a nat­ural re­course for some. There is some sense in Hittite doc­u­ments, for in­stance that the Ahhiyawa’ (Hittite ren­der­ing for Achaioi, mean­ing Greek) might have been an hos­tile neigh­bors to the Hittites and given how heav­ily mil­i­ta­rized elite Mycenaean cul­ture seems to have been, it would­n’t be shock­ing if they reg­u­larly went on seaborne raids (though, again, the ev­i­dence here is very thin).

Meanwhile, while trade does not com­pletely stop, it cer­tainly seems to be re­duced by the col­lapse of these states, pos­si­bly in­ter­rupt­ing the sup­ply of key goods — the most ob­vi­ous be­ing bronze — and any state rev­enues de­rived from tax­ing trade (which they did).

Consequently the consensus’ vi­sion — which re­mains to a de­gree con­jec­tural, al­though it is the best fit’ for the ev­i­dence — runs roughly like this:

Intensifying war­fare in the E. Mediterranean and Mesopotamia may have re­duced the re­sources avail­able for ma­jor states to con­front a cri­sis and per­haps were al­ready as­so­ci­ated with some kind of un­rest.

A shift to a drier cli­mate causes har­vest fail­ures which be­gin to push the tee­ter­ing states over the edge into col­lapse.

In Greece, the palace states be­gin to col­lapse one by one — prob­a­bly from in­ter­nal strains (e.g. an op­pressed peas­antry) rather than ex­ter­nal in­va­sion.

Because the palace econ­o­my’ was so cen­tral (and em­ployed a lot of peo­ple, in­clud­ing a lot of war­riors), col­lapse within Greece may have been con­ta­gious as raids and refugees spawned by col­laps­ing palace sys­tems fa­tally strained oth­ers.

Because the palace econ­o­my’ was so cen­tral (and em­ployed a lot of peo­ple, in­clud­ing a lot of war­riors), col­lapse within Greece may have been con­ta­gious as raids and refugees spawned by col­laps­ing palace sys­tems fa­tally strained oth­ers.

Those col­lapses in turn be­gin to dis­rupt trade but also pro­duce out­ward move­ments of refugees and/​or raiders, which may in part be what is be­ing remembered’ in Homer’s ac­count of the Trojan War or the broader Greek mytho­log­i­cal as­sump­tion that the Trojan War marks the end of the Age of Heroes’ (which is how the Classical Greeks un­der­stood this pe­riod).

That same strain hits the al­ready ail­ing Hittite Empire, strained by wars and de­feats in the Levant against the Egyptians and Assyrians. Battered by har­vest fail­ures and in­creas­ing raids (such as those Ugarit is cry­ing for help from), Hittite power col­lapses.

The states of the Northern Levant, un­der pres­sure al­ready now lose their pro­tec­tor, while the other ma­jor states of the re­gion (Egypt, Assyria, Kassite Babylon) lose a key trade part­ner and at least some ac­cess to tin in par­tic­u­lar (required for bronze).

The re­sult­ing eco­nomic con­trac­tion pro­duces in­ter­nal in­sta­bil­ity (Nineteenth dy­nasty re­placed by Twentieth in Egypt) and com­bined with fur­ther raid­ing/​refugee pres­sures, all of these im­pe­r­ial pow­ers con­tract into their home­lands, no longer able to pro­ject power far afield.

In Babylon, the Kassites more or less sta­bi­lize by the 1160s, but in a weak­ened state, are over­run by the Elamites — a per­pet­ual lo­cal threat — in the 1150s. In Egypt there’s a mo­ment of re­cov­ery and sta­bil­ity un­der Ramesses III of the new Twentieth Dynasty, but fur­ther suc­ces­sion dis­putes — per­haps in part mo­ti­vated by bad eco­nomic con­di­tions — lead to power frag­ment­ing un­til cen­tral rule col­lapses in the early 1070s. Assyrian power con­tracts back to the Assyrian home­land in Northern Mesopotamia, but the state sur­vives, to reemerge as a stag­ger­ingly ma­jor power in the early Iron Age.

You will of course note that we can ob­serve all of these stages only very im­per­fectly: we’re work­ing with frag­men­tary let­ters, in­scrip­tions that are of­ten un­re­li­able and of­ten very good ar­chae­ol­ogy that can tell us what hap­pened (‘this palace was burned and all of the fin­ery was dumped in a well’) but not why.

The Effects of the Collapse

Just as the col­lapse it­self was un­even — some states and set­tle­ments de­stroyed, oth­ers largely spared — so too its ef­fects were un­even, so we might do a brief run­down by re­gion.

But first I want to note the ef­fect the col­lapse has on our ev­i­dence. In many places, I com­pare it to a light­ning bolt at night that takes out the power. Immediately be­fore the col­lapse, it was dim, but there was some light: though deep in the past, we have large states that are cre­at­ing records and in­scrib­ing things on stone some small por­tion of which sur­vive; we can’t see any­where near as well as we can dur­ing the last mil­len­nium BC, but we can see some things. Then the col­lapse hits like that bolt of light­ning and we sud­denly get a lot of ev­i­dence at once. Destruction lay­ers are of­ten ar­chae­o­log­i­cally rich (things get de­posited that would­n’t nor­mally) and when, for in­stance, some­one burns an archive full of clay tablets, that fires the clay tablets in ce­ramic, which can sur­vive. Meanwhile it is eas­ier to ex­ca­vate sites that were aban­doned and not re-in­hab­ited: they prob­a­bly don’t have ma­jor mod­ern cities on them and you don’t have to ex­ca­vate care­fully through cen­turies of dense, con­tin­u­ous habi­ta­tion to get down to the bronze age level.

But then in many ar­eas — es­pe­cially Greece — we are plunged into a lot of dark­ness. The states that were pro­duc­ing writ­ten records are ei­ther much smaller or gone en­tirely. Reduced at the same time is trade in goods that we can use to see long-dis­tance cul­tural con­nec­tions. And in many cases poorer so­ci­eties build in wood and mud­brick rather than stone; the lat­ter sur­vives far bet­ter than the for­mer to be ob­served ar­chae­o­log­i­cally.

The Aegean and main­land Greece — that is, the Mycenaean Greeks — were ev­i­dently hit hard­est by the col­lapse. Much like Britain when the Roman Empire col­lapsed in the West, be­ing on the very edge of the state sys­tem as it came apart left them ev­i­dently far more iso­lated with a much more se­vere de­cline. Large-scale stone build­ing ef­fec­tively van­ishes in Greece and won’t reap­pear un­til the Archaic pe­riod (750 – 480), which in turn makes it much harder to ob­serve things like set­tle­ment pat­terns dur­ing the in­ter­ven­ing pe­riod, some­times termed the Greek Dark Age (1100 – 750; many ar­chae­ol­o­gists of the pe­riod dis­like this term for ob­vi­ous rea­sons). But from what we can see, Greece seems to largely deur­ban­ize in this pe­riod, al­though at least one Mycenaean cen­ter sur­vives — Athens. That may in turn ex­plain to some de­gree why Athens is such a big po­lis in terms of its ter­ri­tory by the time we can see it clearly in the Archaic.

Perhaps most shock­ingly, main­land Greece loses writ­ing. The Mycenaean palaces had de­vel­oped a syl­labic script, which we call Linear B, to rep­re­sent their spo­ken Greek. This form of writ­ing is en­tirely lost. In the 8th cen­tury, the Greeks will adopt an en­tirely new script — bor­row­ing the one the Phoenicians are us­ing — to rep­re­sent their lan­guage and we (and they) will be un­able to read Linear B un­til 1953.

The to­tal­ity of the col­lapse of cen­tral state in­sti­tu­tions in Mycenaean Greece may in part ex­plain the emer­gence of a po­lit­i­cal in­sti­tu­tion as strange as the po­lis. It is clear that through the Greek Dark Ages’ and the sub­se­quent Archaic pe­riod, though Greek com­mu­ni­ties have kings’ — though called basileis (a word that in the Mycenaean Linear B tablets would mean village chief,’ a sub­or­di­nate to the ac­tual king in the palace, the wanax, a term Homer uses for Agamemnon and Priam only) — they lack the cen­tral­ized eco­nomic en­gine of the palace econ­omy and in­stead have much weaker cen­tral gov­ern­ing sys­tems. It is some­thing not quite but per­haps close to a clean slate’ from which to de­velop new sys­tems of gov­er­nance that will look very dif­fer­ent from what so­ci­eties to their East had de­vel­oped.

No other part of the Eastern Mediterranean suf­fers a civ­i­liza­tional set­back quite as in­tense as in Greece, but per­haps the most sig­nif­i­cant ef­fect is a pe­riod of pro­longed po­lit­i­cal frag­men­ta­tion in Anatolia and the Levant. These re­gions had been, over the Late Bronze Age, largely un­der the con­trol of ma­jor im­pe­r­ial pow­ers (Egypt, Assyria, the Hittites), but with those pow­ers re­moved they have a chance to de­velop some­what in­de­pen­dently. That pe­riod of rel­a­tive in­de­pen­dence is go­ing to slam shut when the Neo-Assyrian Empire — it­self a con­tin­u­a­tion of the Middle Assyrian Empire, re­cov­ered from LBAC — re­asserts it­self in the ninth cen­tury, dom­i­nat­ing the Levant and even Egypt.

But in the in­ter­ven­ing time a num­ber of dif­fer­ent smaller so­ci­eties have a chance to make their own way in the Levant, two of which are go­ing to leave a very large mark. In the north­ern Levant, this pe­riod of frag­men­ta­tion cre­ates space for the rise of the ma­jor Phoenician cen­ters — Byblos, Sidon and Tyre (of which the lat­ter will even­tu­ally be­come the most im­por­tant). As we’ve dis­cussed, those are go­ing to be the start­ing point for a wave of Phoenician col­o­niza­tion in the Mediterranean, as Phoenician traders steadily knit Mediterranean trade net­works (back) to­gether. They are also, as noted above, us­ing their own pho­netic script, the Phoenician al­pha­bet, which is in turn go­ing to form the ba­sic of many other re­gional scripts. Perhaps most rel­e­vant for us, the Greeks will adopt and mod­i­fy­ing the Phoenician al­pha­bet to rep­re­sent their own lan­guage and then peo­ples of pre-Ro­man Italy will adopt and mod­ify that to make the Old Italic al­pha­bet which in turn be­comes the Latin al­pha­bet which is the al­pha­bet in which I am typ­ing right now.

Meanwhile in the south­ern Levant this pe­riod of frag­men­ta­tion cre­ates the space for the emer­gence of two small king­doms whose peo­ple are de­vel­op­ing a very his­tor­i­cally im­por­tant re­li­gion cen­tered on the wor­ship of their God Yahweh. These are, of course, the king­doms of Israel and Judah. We are un­usu­ally well in­formed about the his­tory of these king­doms be­cause their his­tory was pre­served as part of Jewish scrip­ture, al­though ver­i­fy­ing el­e­ments of that scrip­ture as his­tor­i­cal fact is quite hard — schol­ars re­main di­vided, for in­stance, about the ex­is­tence of an ac­tual united monar­chy’ (in scrip­ture un­der Saul, David and Solomon) which would have ex­isted c. 1000 BC (by con­trast the later split king­doms are at­tested in Assyrian records). The de­vel­op­ment of these two king­doms — and thus the de­vel­op­ment of all of the Abrahamic faiths — is greatly in­flu­enced by this pe­riod of frag­men­ta­tion. Readers who know their Kings and Chronicles may have al­ready pieced to­gether that it is that re-ex­pan­sion of Assyrian power which will lead to the de­struc­tion of the north­ern king­dom of Israel in the 720s, while the south­ern king­dom of Judah per­sists as a quasi-de­pen­dency of Assyria be­fore be­ing dis­mem­bered and de­stroyed fi­nally by the Neo-Babylonian Empire (which re­places the Neo-Assyrian Empire, how­ever briefly) in 597 BC.

Of course the dif­fi­cult thing in all of this is that it is this ini­tial pe­riod, where a lot is clearly form­ing and brew­ing in the Eastern Mediterranean that our ev­i­dence is sig­nif­i­cantly weaker than we’d like (again, es­pe­cially in Greece, but note how much un­cer­tainty we have even in the Levant). The first few cen­turies of the Iron Age, im­me­di­ately fol­low­ing the Late Bronze Age Collapse are clearly a very im­por­tant for­ma­tive pe­riod which are go­ing to set some of the key pat­terns for events to play out in the rest of an­tiq­uity as the cur­tain goes up’ as it were and we start be­ing able to see those events clearly.

All that said, I have to stress this is re­ally a very ba­sic overview. I am doubt­less miss­ing out on some of the lat­est work in this field (because I am a late/​post Iron Age scholar) and in any case a lot of this can­not help but be a fairly ba­sic sum­mary. Perhaps one of these days I can get a Late Bronze Age or early Near Eastern Iron Age spe­cial­ist to guest-write some­thing more de­tailed on spe­cific facets of the col­lapse and its im­pact.

Sidon and Byblos, along­side Tyre (settled in the Bronze Age, but only promi­nent in the Iron Age) would be the most pow­er­ful and promi­nent Phoenician cities in the early Iron Age.

That is, speak­ers of the Doric di­alect of Greek

Reduced rain­fall in the Armenian high­lands could, of course, neg­a­tively ef­fect the Tigris and Euphrates, but that’s a less wa­ter’ prob­lem as op­posed to a no wa­ter’ prob­lem.

Write code like a human will maintain it

unstack.io

One of the best things about LLMs is that they’ll write code for you, all day long. Who cares about DRY? You don’t have to be the one up­dat­ing the same long con­di­tional in four dif­fer­ent files - the AI will just do it for you! Right?

I’ve no­ticed my­self let­ting it slide re­cently on a pro­ject I’d been build­ing with AI. I needed the same ac­cess check in a hand­ful of places: a route han­dler, a back­ground job, an API end­point, a web­hook, etc. Each time, I’d de­scribe what I needed, the model would gen­er­ate some­thing that worked, and I’d merge it.

Each ver­sion looked roughly like this:

if (user.isActive && user.hasPer­mis­sion(‘read’) && !user.isSuspended && ac­count.sta­tus === open’) { // do a thing }

Essentially the same con­di­tion­als every time. Four con­di­tions, maybe slightly dif­fer­ent vari­able names, copy-pasted logic with a word or two changed. There’s a much cleaner way to do this - a shared helper, for ex­am­ple, like some­thing I’d ex­tract if I were writ­ing this my­self. But I did­n’t. The code worked! The tests passed and I was­n’t the one who’d have to touch it again.

That’s the lazi­ness here: if it does­n’t fol­low best prac­tices, or I know a piece of code will be a pain to main­tain, what dif­fer­ence does it make? When I need to change some­thing later, the LLM deals with it, not me.

Except the LLM does­n’t write in a vac­uum. It reads your code­base. The files you have open, the pat­terns that are al­ready there, and the re­cent changes you’ve made. Every short­cut you merge into your code­base is a sig­nal about how things are done here. The next time you ask the LLM for an­other end­point with the same ac­cess rules, the model won’t start from first prin­ci­ples. It’ll start from the other four copies al­ready sit­ting in your repo.

So you ask for a fifth end­point, and you get a fifth con­di­tional, with the same copied code. You ask for a refac­tor, and the model pre­serves all five, be­cause that’s what your code looks like. The bad pat­tern is­n’t a one-off any­more, it’s con­sid­ered to be your style.

If you let things go on like this, can you re­ally trust that the LLM will catch every in­stance if you try to fix it later?

Sure, a few of these aren’t cat­a­strophic. That’s how it al­ways starts, but code smells do stack up. Each du­pli­cated con­di­tional, each god” func­tion, each I’ll clean this up later” merge adds an­other layer of sig­nal­ing to the next prompt. Eventually you can’t eas­ily prompt your way out of it. At least not with­out get­ting your hands dirty and rolling up your sleeves.

The most frus­trat­ing part: I thought I was out­sourc­ing main­te­nance to the LLM, but the slip­pery slope I found my­self on was ac­tu­ally train­ing it to have ever-wors­en­ing habits.

Write code like a hu­man will main­tain it. LLMs are sponges that soak up every­thing you do and re­peat it back to you. So make sure it’s good.

Neural-Guided Evolutionary Video Synthesis

nevo-project.epfl.ch

In Emacs, Everything Looks Like a Service

yummymelon.com

A com­mon re­frain is that Emacs is an op­er­at­ing sys­tem (OS). This is­n’t true, but what in­vites com­par­i­son to an OS is its abil­ity to or­ches­trate ap­pli­ca­tions and util­i­ties above the OS ker­nel level. The di­a­gram be­low sug­gests a truer pic­ture of how Emacs’ re­lates to an OS and its ca­pa­bil­i­ties.

Emacs’ built-in ac­cess to OS sys­tem ser­vices (file sys­tem, net­work, etc.) cou­pled with the abil­ity to run other pro­grams makes it rou­tine to im­pro­vise client be­hav­ior within it. Because of this, Emacs users are able to ac­com­plish many of their com­put­ing needs from the dif­fer­ent client modes that have been made for it. This gives cre­dence to the no­tion of living only in Emacs.”

In this post, we’ll ex­am­ine some of the ways Emacs lets you build a client. By the end of this post, you’ll hope­fully be con­vinced that from within Emacs, every­thing looks like a ser­vice.

Client-Server Model

Let’s first pro­vide some de­f­i­n­i­tions.

The Client–Server model is a com­mon com­puter in­ter­ac­tion pat­tern where a task is par­ti­tioned be­tween the provider of a re­source (the ser­vice) and the re­quester of that re­source (the client). The client is­sues a re­quest to the server, and the server in turn re­turns a re­sponse as shown in the di­a­gram be­low.

Depending on the im­ple­men­ta­tion, the trans­ac­tion (request + re­sponse) can oc­cur over a net­work or be lo­cal to a sys­tem. Client-server mod­els us­ing a net­work has been most elab­o­rated upon with REST-style soft­ware ar­chi­tec­tures. Shown in the se­quence di­a­gram be­low is a com­mon im­ple­men­ta­tion pat­tern for REST-style client server ar­chi­tec­ture.

Emacs as a Client

From the di­a­gram above, there are three con­cerns the client is typ­i­cally re­spon­si­ble for:

UI: User in­ter­face (if any).

Client Edge: Sub-system con­cerned with com­mu­ni­ca­tion with the ser­vice. For net­worked clients, this is the net­work sub-sys­tem.

Local Database: Representation of data that is ex­changed or syn­chro­nized with the server. How this data is man­aged is up to the im­ple­men­ta­tion re­quire­ments.

For the above con­cerns, Emacs pro­vides nu­mer­ous li­braries both built-in and third-party which can im­ple­ment a client. Listed be­low are some built-in li­braries with their re­spec­tive links for fur­ther read­ing:

UI

Minibuffers Buffers Completion Tabulated List Mode Variable Pitch Table (vtable) Transient

UI

Minibuffers

Buffers

Completion

Tabulated List Mode

Variable Pitch Table (vtable)

Transient

Client Edge

URL Socket (TCP/UDP) SMTP Serialization/Deserialization JSON XML

Client Edge

URL

Socket (TCP/UDP)

SMTP

Serialization/Deserialization JSON XML

JSON

XML

Local Database

Collections Association Lists Property Lists Hash Tables

SQLite

Local Database

Collections Association Lists Property Lists Hash Tables

Association Lists

Property Lists

Hash Tables

SQLite

Requirements dic­tate the amount of com­plex­ity re­quired to im­ple­ment the Emacs client. If there is an ex­ist­ing com­mand line util­ity that can do the heavy lift­ing”, said util­ity can be re­framed as a service” that can be ac­cessed via a shell call.

Elisp

All the li­braries men­tioned above are ac­cessed through the Emacs Lisp (Elisp) pro­gram­ming lan­guage. Elisp is a dy­namic pro­gram­ming lan­guage which al­lows for a high de­gree of im­pro­vi­sa­tion dur­ing run-time. This ca­pa­bil­ity al­lows for com­plex or­ches­tra­tion of any be­hav­ior that is avail­able to Emacs, from Elisp func­tions to shell com­mands.

Example wttr.in client

wttr.in is a con­sole-ori­ented weather fore­cast web-ser­vice. It sup­ports JSON out­put so we can build an Emacs wttr com­mand which will prompt for a lo­ca­tion, make the HTTP re­quest, process the JSON re­sponse and dis­play the re­sult in the mini-buffer.

The top-level com­mand wttr is shown be­low.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

(defun wttr (location) Show weather con­di­tions for LOCATION from `https://​wttr.in in mini-buffer.

Result is also stored in `kill-ring’.” (interactive sWhere (default: lo­cal): )

(condition-case err (let* ((url (wttr–request-url lo­ca­tion)) (jsondb (fetch-json-as-hash-table url)) (msg (wttr–report-message jsondb))) (kill-new msg) (message %s” msg))

(error (message ERROR: %s” (cdr err)))))

The wttr.in URL is con­structed by the func­tion wttr–re­quest-url shown be­low.

1 2 3 4 5 6 7

(defun wttr–re­quest-url (location) Construct wttr.in URL with LOCATION.” (let* ((base-url (url-generic-parse-url https://​wttr.in)) (encoded-location (string-replace +” lo­ca­tion)) (query (format /%s?0&format=j1″ en­coded-lo­ca­tion)) (_dummy (setf (url-filename base-url) query))) (url-recreate-url base-url)))

We can sub­se­quently pass that URL into fetch-json-as-hash-table which does the heavy lift­ing of re­triev­ing the URL and pars­ing the JSON re­sponse into an Elisp hash-table.

1 2 3 4 5 6 7 8 9 10 11 12 13

(defun fetch-json-as-hash-table (url) Fetch URL with ex­pected JSON re­sponse and re­turn a `hash-table’.” (let ((data-buffer (url-retrieve-synchronously url))) (if (not data-buffer) (error Failed to fetch data from %s” url) (unwind-protect (with-current-buffer data-buffer ;; Move point past the HTTP meta­data head­ers (goto-char url-http-end-of-head­ers) ;; Parse the re­main­ing JSON buffer into a hash-table (json-parse-buffer :object-type hash-table)) ;; Always kill the down­loaded net­work buffer to pre­vent mem­ory leaks (kill-buffer data-buffer)))))

Finally we can ex­tract the de­sired val­ues from the JSON re­sponse (jsondb) to pop­u­late the mes­sage that will sent to the mini-buffer.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

(defun wttr–re­port-mes­sage (jsondb) Generate weather re­port mes­sage from JSONDB.” (let* ((area-buflist ()) (nearest-area (wttr–get-first jsondb nearest_area”)) (area-name (map-elt (wttr–get-first near­est-area areaName”) value”)) (region (map-elt (wttr–get-first near­est-area region”) value”)) (country (map-elt (wttr–get-first near­est-area country”) value”))

(current-condition (wttr–get-first jsondb current_condition”)) (temp_c (map-elt cur­rent-con­di­tion temp_C”)) (temp_f (map-elt cur­rent-con­di­tion temp_F”))

(weather-description (map-elt (wttr–get-first cur­rent-con­di­tion weatherDesc”) value”)))

(mapc (lambda (x) (if (and x (not (string-equal x ”))) (push x area-bu­flist))) (list area-name re­gion coun­try))

(format %s: %s°C, %s°F %s” (string-join (reverse area-bu­flist) , ) tem­p_c tem­p_f weather-de­scrip­tion)))

wttr.el source

Closing Thoughts

At this point, hope­fully you are con­vinced of the ti­tle as­ser­tion that from Emacs, every­thing looks like a ser­vice. Furthermore, many of the APIs of­fered by Emacs work at a high-level of ab­strac­tion. Consider that the lines of code for wttr.el weighs in at 67. (Result us­ing the cloc util­ity.)

If that’s too much, then imag­ine an al­ter­nate im­ple­men­ta­tion where the ac­tual net­work re­quest and JSON pro­cess­ing is done in a Python script called weather. Then the Elisp com­mand to in­voke it is just the code shown be­low.

1 2 3 4 5 6 7 8 9

(defun weather (location) Call weather script with LOCATION and show re­sult in minibuffer.” (interactive sWhere (default: lo­cal): )

(let* ((weather-cmd weather”) (cmd (if lo­ca­tion (format %s %s” weather-cmd lo­ca­tion) weather-cmd)) (result (shell-command-to-string cmd))) (kill-new re­sult) (message re­sult)))

With the above im­ple­men­ta­tion, the shell com­mand be­comes ef­fec­tively the service” to make a re­quest to.

As Elisp is a dy­namic pro­gram­ming lan­guage, it can al­low for in­te­gra­tion of Elisp li­braries with com­mand line util­i­ties in an im­pro­vised fash­ion.

This ca­pa­bil­ity is com­pelling to users who rec­og­nize the op­por­tu­ni­ties it can of­fer.

emacs

How Successful Companies Go Blind

ianreppel.org

The Mexican cave­fish kept its eye genes for over a mil­lion years af­ter the eyes them­selves dis­ap­peared. Something sim­i­lar hap­pens to com­pa­nies once they achieve suc­cess.

The cave is the vari­able

The Mexican cave­fish (Astyanax mex­i­canus) ex­ists in two forms only kilo­me­tres apart. In the rivers along the Sierra del Abra, the fish has eyes and be­haves the way or­di­nary fish be­have. In the lime­stone caves un­der the same moun­tains, mem­bers of the same species are blind, de­pig­mented, and translu­cent. The genome is vir­tu­ally iden­ti­cal.

Within hours of fer­til­iza­tion in cave con­di­tions, the lens-build­ing pro­gramme trig­gers early apop­to­sis (i.e. pro­grammed cell death), and the en­ergy that would have gone to op­tic tis­sue is redi­rected to traits the cave ac­tu­ally re­wards: bet­ter ol­fac­tion, deeper feed­ing, and fat re­serves against the next lean year. Sight is no longer ex­pressed. The same fish, hatched in the river, would see.

Competence blind­ness

Companies who have for­got­ten what it took to be­come suc­cess­ful are sim­i­lar: they stop rec­og­niz­ing com­pe­tence, be­cause the en­vi­ron­ment has stopped ex­press­ing the trait in any­one the com­pany hires. Call it com­pe­tence blind­ness, which is dif­fer­ent from in­cum­bents who fail be­cause they cling to the cus­tomers and mar­gins of yes­ter­day’s mar­ket. Firms with com­pe­tence blind­ness do not dis­ap­pear. In fact, they can sur­vive for decades.

When a startup hits rapid growth, it hires at speed. Headcount tar­gets bend the bar un­til the bar dis­ap­pears al­to­gether. Engineers who have never worked else­where learn the house style, and within a year find them­selves on hir­ing pan­els. They se­lect for com­fort with the pre­vail­ing mess, be­cause they have no other frame of ref­er­ence. After a few cy­cles the com­pany has a pop­u­la­tion of well-mean­ing peo­ple who do not sus­pect any­thing is off. They have only ever known the cave, and life in­side the cave is good.

The view from out­side is en­cour­ag­ing: strong brand, de­cent mar­gins, head­count up. From within, the view is not so flat­ter­ing. Build pipelines only the orig­i­nal au­thor can run, de­ploy­ments so frag­ile that they re­quire a se­nior en­gi­neer to be on call at all times, and a wiki so out of date it might as well be writ­ten in hi­ero­glyph­ics. Because the com­pa­ny’s num­bers still look fine, lead­er­ship be­lieves the foun­da­tions are sound.

In this cli­mate, care­ful en­gi­neer­ing be­comes a ves­ti­gial trait: the ca­pac­ity ex­ists, but the ex­pres­sion has been sup­pressed by an en­vi­ron­ment that does not re­turn the en­ergy spent on it. An en­gi­neer who in­sists on ex­press­ing the trait is in­vest­ing in an or­gan the cave will not feed. After the first round of over­ruled pro­pos­als, the apop­to­sis be­gins.

Arrive with sight and the prob­lems are im­me­di­ately vis­i­ble. You pro­pose some­thing the wider in­dus­try has al­ready moved past, and you are told the sug­ges­tion is over-en­gi­neered, aca­d­e­mic, and not aligned with pri­or­i­ties. What you in­tended as over­due main­te­nance reads as an at­tack on the iden­tity of the en­gi­neers who sta­pled to­gether the ex­ist­ing in­fra­struc­ture.

Centres of ex­cel­lence

The re­sponse is pre­dictable: the com­pany as­sem­bles a cen­tre of ex­cel­lence. Due to the cen­tre’s ob­ses­sion with con­trol, in­trin­sic mo­ti­va­tion at­ro­phies un­til the peo­ple do­ing the work feel that none of it is theirs any­more. In healthy com­pa­nies, ex­cel­lence is am­bi­ent and dis­trib­uted. In cave dwellers, it is ex­tracted into a process shop, charged with writ­ing the stan­dards, en­forc­ing the tem­plates, and run­ning manda­tory rit­u­als. The cen­tre is de­signed to sup­press the very trait its name claims to cul­ti­vate.

The cave is ge­o­log­i­cally sta­ble

When a mar­ket’s bar­ri­ers to en­try are pro­hib­i­tive, in­cum­bents can ac­cu­mu­late bu­reau­cracy and tol­er­ate waste, be­cause no cred­i­ble en­trant forces dis­ci­pline. The cave is ge­o­log­i­cally sta­ble, so they do not need to grow new eyes. That is how self-pro­claimed tech­nol­ogy com­pa­nies end up sound­ing like the tech gi­ants on the con­fer­ence stage yet ship like re­gional util­i­ties from the nineties.

Brand and cash still at­tract a steady sup­ply of sighted en­gi­neers. They ar­rive, re­al­ize the place is run­ning on stored fat from ear­lier sea­sons, and feel their skills re­gress­ing in the dark. Some leave within a year, for they refuse to go blind. Management ex­plains the ex­its in terms of gen­er­a­tional fick­le­ness, cul­ture fit, the labour mar­ket, any­thing but the ob­vi­ous.

The ones who stay are com­fort­able. The work is pre­dictable, the salary ad­e­quate, the in­ter­nal game fa­mil­iar, and the pol­i­tics re­ward­ing to who­ever learns to play the game. Over time the com­fort switches off their sight. What re­mains is flu­ency in cave rules and a steadily di­min­ish­ing abil­ity to imag­ine them­selves out­side.

Staying as apop­to­sis

The con­ven­tional story about smart peo­ple in dys­func­tional com­pa­nies treats stay­ing as ac­qui­es­cence. Hirschman gave us three op­tions (exit, voice, loy­alty), and they re­main ac­cu­rate. The cave­fish anal­ogy adds a fourth: the peo­ple who stay adapt to the cave’s pres­sures, mostly out­side their aware­ness, un­til the adap­ta­tion is in­dis­tin­guish­able from loy­alty. Staying is apop­to­sis.

Surface pop­u­la­tions

The Mexican cave­fish has not lost its eye genes in any de­fin­i­tive sense. Nearby sur­face pop­u­la­tions still see per­fectly well. What switches sight back on is the next wa­ter the fish swims into. Swim else­where, and your sight may re­turn.

CASP — Cambridge Programme on AI Science & Policy

casp.ac

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.