When you’re ready for more per­for­mance, you can up­grade in­di­vid­ual com­po­nents in­stead of re­plac­ing your en­tire lap­top. Install a new Mainboard for gen­er­a­tional proces­sor up­grades, add mem­ory to han­dle heav­ier work­loads, or ex­pand your stor­age to in­crease ca­pac­ity or en­able dual boot­ing. The Framework Marketplace makes it easy to find the com­pat­i­ble parts you need.

Organizations de­sign sys­tems that mir­ror their own com­mu­ni­ca­tion struc­ture.

Premature op­ti­miza­tion is the root of all evil.

With a suf­fi­cient num­ber of API users, all ob­serv­able be­hav­iors of your sys­tem will be de­pended on by some­body.

Leave the code bet­ter than you found it.

YAGNI (You Aren’t Gonna Need It)

Don’t add func­tion­al­ity un­til it is nec­es­sary.

Adding man­power to a late soft­ware pro­ject makes it later.

A com­plex sys­tem that works is in­vari­ably found to have evolved from a sim­ple sys­tem that worked.

All non-triv­ial ab­strac­tions, to some de­gree, are leaky.

Every ap­pli­ca­tion has an in­her­ent amount of ir­re­ducible com­plex­ity that can only be shifted, not elim­i­nated.

A dis­trib­uted sys­tem can guar­an­tee only two of: con­sis­tency, avail­abil­ity, and par­ti­tion tol­er­ance.

Small, suc­cess­ful sys­tems tend to be fol­lowed by ov­erengi­neered, bloated re­place­ments.

A set of eight false as­sump­tions that new dis­trib­uted sys­tem de­sign­ers of­ten make.

Every pro­gram at­tempts to ex­pand un­til it can read mail.

There is a cog­ni­tive limit of about 150 sta­ble re­la­tion­ships one per­son can main­tain.

The square root of the to­tal num­ber of par­tic­i­pants does 50% of the work.

Those who un­der­stand tech­nol­ogy don’t man­age it, and those who man­age it don’t un­der­stand it.

In a hi­er­ar­chy, every em­ployee tends to rise to their level of in­com­pe­tence.

The min­i­mum num­ber of team mem­bers whose loss would put the pro­ject in se­ri­ous trou­ble.

Companies tend to pro­mote in­com­pe­tent em­ploy­ees to man­age­ment to limit the dam­age they can do.

Work ex­pands to fill the time avail­able for its com­ple­tion.

The first 90% of the code ac­counts for the first 90% of de­vel­op­ment time; the re­main­ing 10% ac­counts for the other 90%.

It al­ways takes longer than you ex­pect, even when you take into ac­count Hofstadter’s Law.

When a mea­sure be­comes a tar­get, it ceases to be a good mea­sure.

Anything you need to quan­tify can be mea­sured in some way bet­ter than not mea­sur­ing it.

Anything that can go wrong will go wrong.

Be con­ser­v­a­tive in what you do, be lib­eral in what you ac­cept from oth­ers.

Technical Debt is every­thing that slows us down when de­vel­op­ing soft­ware.

Given enough eye­balls, all bugs are shal­low.

Debugging is twice as hard as writ­ing the code in the first place.

A pro­ject should have many fast unit tests, fewer in­te­gra­tion tests, and only a small num­ber of UI tests.

Repeatedly run­ning the same tests be­comes less ef­fec­tive over time.

Software that re­flects the real world must evolve, and that evo­lu­tion has pre­dictable lim­its.

90% of every­thing is crap.

The speedup from par­al­leliza­tion is lim­ited by the frac­tion of work that can­not be par­al­lelized.

It is pos­si­ble to achieve sig­nif­i­cant speedup in par­al­lel pro­cess­ing by in­creas­ing the prob­lem size.

The value of a net­work is pro­por­tional to the square of the num­ber of users.

Every piece of knowl­edge must have a sin­gle, un­am­bigu­ous, au­thor­i­ta­tive rep­re­sen­ta­tion.

Designs and sys­tems should be as sim­ple as pos­si­ble.

Five main guide­lines that en­hance soft­ware de­sign, mak­ing code more main­tain­able and scal­able.

An ob­ject should only in­ter­act with its im­me­di­ate friends, not strangers.

Software and in­ter­faces should be­have in a way that least sur­prises users and other de­vel­op­ers.

The less you know about some­thing, the more con­fi­dent you tend to be.

Never at­tribute to mal­ice that which is ad­e­quately ex­plained by stu­pid­ity or care­less­ness.

The sim­plest ex­pla­na­tion is of­ten the most ac­cu­rate one.

Sticking with a choice be­cause you’ve in­vested time or en­ergy in it, even when walk­ing away helps you.

The Map Is Not the Territory

Our rep­re­sen­ta­tions of re­al­ity are not the same as re­al­ity it­self.

A ten­dency to fa­vor in­for­ma­tion that sup­ports our ex­ist­ing be­liefs or ideas.

We tend to over­es­ti­mate the ef­fect of a tech­nol­ogy in the short run and un­der­es­ti­mate the im­pact in the long run.

The longer some­thing has been in use, the more likely it is to con­tinue be­ing used.

Breaking a com­plex prob­lem into its most ba­sic blocks and then build­ing up from there.

Solving a prob­lem by con­sid­er­ing the op­po­site out­come and work­ing back­ward from it.

80% of the prob­lems re­sult from 20% of the causes.

The best way to get the cor­rect an­swer on the Internet is not to ask a ques­tion, it’s to post the wrong an­swer.

For work­loads that need to run in the US, US-only in­fer­ence is avail­able at 1.1x pric­ing for in­put and out­put to­kens. Learn more.

This is a heav­ily in­ter­ac­tive web ap­pli­ca­tion, and JavaScript is re­quired. Simple HTML in­ter­faces are pos­si­ble, but that is not what this is.

Learn more about Bluesky at bsky.so­cial and at­proto.com. It ap­pears that Anthropic has re­moved Claude Code from its $20-a-month pro sub­scrip­tion based on its pric­ing page. Anyone able to con­firm who has a $20 plan?

claude.com/​pric­ing

Listen to this ar­ti­cle in sum­ma­rized for­mat

Today we’re mak­ing the fol­low­ing changes to GitHub Copilot’s Individual plans to pro­tect the ex­pe­ri­ence for ex­ist­ing cus­tomers: paus­ing new sign-ups, tight­en­ing us­age lim­its, and ad­just­ing model avail­abil­ity. We know these changes are dis­rup­tive, and we want to be clear about why we’re mak­ing them and how they will af­fect you.

Agentic work­flows have fun­da­men­tally changed Copilot’s com­pute de­mands. Long-running, par­al­lelized ses­sions now reg­u­larly con­sume far more re­sources than the orig­i­nal plan struc­ture was built to sup­port. As Copilot’s agen­tic ca­pa­bil­i­ties have ex­panded rapidly, agents are do­ing more work, and more cus­tomers are hit­ting us­age lim­its de­signed to main­tain ser­vice re­li­a­bil­ity. Without fur­ther ac­tion, ser­vice qual­ity de­grades for every­one.

We’ve heard your frus­tra­tions about us­age lim­its and model avail­abil­ity, and we need to do a bet­ter job com­mu­ni­cat­ing the guardrails we are adding—here’s what’s chang­ing and why.

New sign-ups for GitHub Copilot Pro, Pro+, and Student plans are paused. Pausing sign-ups al­lows us to serve ex­ist­ing cus­tomers more ef­fec­tively.

We are tight­en­ing us­age lim­its for in­di­vid­ual plans. Pro+ plans of­fer more than 5X the lim­its of Pro. Users on the Pro plan who need higher lim­its can up­grade to Pro+. Usage lim­its are now dis­played in VS Code and Copilot CLI to make it eas­ier for you to avoid hit­ting these lim­its.

Opus mod­els are no longer avail­able in Pro plans. Opus 4.7 re­mains avail­able in Pro+ plans. As we an­nounced in our changelog, Opus 4.5 and Opus 4.6 will be re­moved from Pro+.

These changes are nec­es­sary to en­sure we can serve ex­ist­ing cus­tomers with a pre­dictable ex­pe­ri­ence. If you hit un­ex­pected lim­its or these changes just don’t work for you, you can can­cel your Pro or Pro+ sub­scrip­tion and re­ceive a re­fund for the time re­main­ing on your cur­rent sub­scrip­tion by vis­it­ing your Billing set­tings be­fore May 20..

GitHub Copilot has two us­age lim­its to­day: ses­sion and weekly (7 day) lim­its. Both lim­its de­pend on two dis­tinct fac­tors—to­ken con­sump­tion and the mod­el’s mul­ti­plier.

The ses­sion lim­its ex­ist pri­mar­ily to en­sure that the ser­vice is not over­loaded dur­ing pe­ri­ods of peak us­age. They’re set so most users should­n’t be im­pacted. Over time, these lim­its will be ad­justed to bal­ance re­li­a­bil­ity and de­mand. If you do en­counter a ses­sion limit, you must wait un­til the us­age win­dow re­sets to re­sume us­ing Copilot.

Weekly lim­its rep­re­sent a cap on the to­tal num­ber of to­kens a user can con­sume dur­ing the week. We in­tro­duced weekly lim­its re­cently to con­trol for par­al­lelized, long-tra­jec­tory re­quests that of­ten run for ex­tended pe­ri­ods of time and re­sult in pro­hib­i­tively high costs.

The weekly lim­its for each plan are also set so that most users will not be im­pacted. If you hit a weekly limit and have pre­mium re­quests re­main­ing, you can con­tinue to use Copilot with Auto model se­lec­tion. Model choice will be reen­abled when the weekly pe­riod re­sets. If you are a Pro user, you can up­grade to Pro+ to in­crease your weekly lim­its. Pro+ in­cludes over 5X the lim­its of Pro.

Usage lim­its are sep­a­rate from your pre­mium re­quest en­ti­tle­ments. Premium re­quests de­ter­mine which mod­els you can ac­cess and how many re­quests you can make. Usage lim­its, by con­trast, are to­ken-based guardrails that cap how many to­kens you can con­sume within a given time win­dow. You can have pre­mium re­quests re­main­ing and still hit a us­age limit.

Starting to­day, VS Code and Copilot CLI both dis­play your avail­able us­age when you’re ap­proach­ing a limit. These changes are meant to help you avoid a sur­prise limit.

If you are ap­proach­ing a limit, there are a few things you can do to help re­duce the chances of hit­ting it:

Use a model with a smaller mul­ti­plier for sim­pler tasks. The larger the mul­ti­plier, the faster you will hit the limit.

Consider up­grad­ing to Pro+ if you are on a Pro plan to raise your limit by over 5X.

Use plan mode (VS Code, Copilot CLI) to im­prove task ef­fi­ciency. Plan mode also im­proves task suc­cess.

Reduce par­al­lel work­flows. Tools such as /fleet will re­sult in higher to­ken con­sump­tion and should be used spar­ingly if you are near­ing your lim­its.

Why we’re do­ing this

We’ve seen us­age in­ten­sify for all users as they re­al­ize the value of agents and sub­agents in tack­ling com­plex cod­ing prob­lems. These long-run­ning, par­al­lelized work­flows can yield great value, but they have also chal­lenged our in­fra­struc­ture and pric­ing struc­ture: it’s now com­mon for a hand­ful of re­quests to in­cur costs that ex­ceed the plan price! These are our prob­lems to solve. The ac­tions we are tak­ing to­day en­able us to pro­vide the best pos­si­ble ex­pe­ri­ence for ex­ist­ing users while we de­velop a more sus­tain­able so­lu­tion.

Everything you need to mas­ter GitHub, all in one place.

Build what’s next on GitHub, the place for any­one from any­where to build any­thing.

Meet the com­pa­nies and en­gi­neer­ing teams that build with GitHub.

Catch up on the GitHub pod­cast, a show ded­i­cated to the top­ics, trends, sto­ries and cul­ture in and around the open source de­vel­oper com­mu­nity on GitHub.

We do newslet­ters, tooD­is­cover tips, tech­ni­cal guides, and best prac­tices in our bi­weekly newslet­ter just for devs.

Yes please, I’d like GitHub and af­fil­i­ates to use my in­for­ma­tion for per­son­al­ized com­mu­ni­ca­tions, tar­geted ad­ver­tis­ing and cam­paign ef­fec­tive­ness. See the GitHub Privacy Statement for more de­tails.

Acetaminophen, ibupro­fen, and what doc­tors prob­a­bly want you to know.

Lots of peo­ple die af­ter over­dos­ing on ac­eta­minophen (paracetamol, of­ten sold as Tylenol or Panadol). In the U. S., it’s es­ti­mated to cause 56,000 emer­gency de­part­ment vis­its, 2,600 hos­pi­tal­iza­tions, and 500 deaths per year. Acetaminophen has a scar­ily nar­row ther­a­peu­tic win­dow. The in­struc­tions on the pack­age say it’s okay to take up to four grams per day. If you take eight grams, your liver could fail and you could die. Mean­while, it seems to be re­ally hard to kill your­self by over­dos­ing on ibupro­fen (Advil, Nurofen, Motrin, Brufen). In 2006, Wood et al. searched the med­ical lit­er­a­ture and found 10 doc­u­mented cases in his­tory. Nine of those cases in­volved com­pli­cat­ing fac­tors, and in the 10th, a woman took the equiv­a­lent of more than 500 stan­dard (200mg) pills. So, for many years, if I needed a painkiller, I’d try to take ibupro­fen rather than ac­eta­minophen. My logic was that if eight grams of ac­eta­minophen could kill my liver, then one gram was prob­a­bly still hard on it. I’m fond of my liver and did­n’t want to cause it any un­nec­es­sary in­con­ve­nience. But guess what? My logic was wrong and what I was do­ing was stu­pid. I’m now con­vinced that for most peo­ple in most cir­cum­stances, ac­eta­minophen is safer than ibupro­fen, pro­vided you use it as di­rected. I think most doc­tors agree with this. In fact, I think many doc­tors think it’s ob­vi­ous. (Source: I asked some doc­tors; they said it was ob­vi­ous.) Should this have been ob­vi­ous to me? I fig­ured it out by ob­ses­sively re­search­ing how those drugs work and mak­ing up a story about meta­bolic path­ways and blood flow, and amino acid re­serves. It’s a good story, one that re­vealed that my logic stemmed from an egre­gious lack of re­spect for bi­ol­ogy and that I’m a big dummy (always a fa­vorite sub­ject). But if the clear­est road to some piece of knowl­edge runs through meta­bolic path­ways, then I don’t think that knowl­edge counts as ob­vi­ous. So how is a nor­mal per­son meant to fig­ure it out? Why does­n’t the fact that ac­eta­minophen is typ­i­cally safer than ibupro­fen ap­pear on drug la­bels or gov­ern­ment web­sites or WebMD? Are nor­mal peo­ple sup­posed to fig­ure it out, or has so­ci­ety de­cided that this is the kind of thing best left il­leg­i­ble? Note: You should not switch med­ica­tions based on the un­in­formed ram­blings of non-trust­wor­thy pseu­do­ny­mous in­ter­net peo­ple.

Ibuprofen in­hibits the body’s pro­duc­tion of the Cyclooxygenase (COX) en­zyme. This in turn in­hibits the for­ma­tion of mes­sen­ger mol­e­cules in­volved in in­flam­ma­tion, which leads to less phys­i­cal in­flam­ma­tion and thus less pain. The same story is true for al­most all over-the-counter painkillers, which is why they’re al­most all con­sid­ered “non-steroidal anti-in­flam­ma­tory drugs,” or NSAIDs. This in­cludes ibupro­fen, as­pirin, naproxen (Aleve), and a long list of re­lated drugs. But it does not in­clude ac­eta­minophen.

Like ibupro­fen, ac­eta­minophen in­hibits some COX en­zymes. But it does so in a weird way that barely af­fects in­flam­ma­tion or mes­sen­ger mol­e­cules, so it’s un­clear if this mat­ters for pain re­duc­tion. In the brain,  ac­eta­minophen is me­tab­o­lized into a mys­te­ri­ous chem­i­cal called AM404. This ac­ti­vates the cannabi­noid re­cep­tors and in­creases en­do­cannabi­noid sig­nal­ing, which seems to re­duce the sub­jec­tive ex­pe­ri­ence of pain. AM404 also ac­ti­vates the cap­saicin re­cep­tor, which is as­so­ci­ated with burn­ing sen­sa­tions that you’d nor­mally ex­pect to in­crease pain, but maybe some de­sen­si­ti­za­tion thing hap­pens down­stream? And maybe ac­eta­minophen also in­ter­acts with sero­tonin or ni­tric ox­ide or does other stuff? How this all comes to­gether to re­duce pain is still some­what a sci­en­tific mys­tery. Aside: When try­ing to un­der­stand painkillers, it’s nat­ural to fo­cus on chem­istry and mol­e­c­u­lar bi­ol­ogy. But the un­known phys­i­cal ori­gins of con­scious­ness are al­ways nearby, loom­ing omi­nously.

In an ideal world, the only thing ibupro­fen would do is re­duce in­flam­ma­tion in the part of your body that hurts. But that is not our world. When ibupro­fen in­hibits the COX en­zymes, it does so through­out the body. And mostly, that is bad. For one, ibupro­fen re­duces pro­duc­tion of mu­cus in the stom­ach. That might sound okay or even good. But stom­ach mu­cus is im­por­tant. You need it to shield the lin­ing of your stom­ach from your ex­tremely acidic gas­tric juice.

Having less mu­cus can lead to gas­troin­testi­nal prob­lems or even ul­cers. Ibupro­fen also af­fects the heart. When ibupro­fen in­hibits the COX en­zymes there, this in turn in­hibits one chem­i­cal that pre­vents clot­ting and an­other that causes clot­ting. In bal­ance, this seems to lead to more clot­ting, and an in­creased sta­tis­ti­cal risk of heart at­tacks

. If you’re healthy, the risk of a heart at­tack from an oc­ca­sional low dose of ibupro­fen is prob­a­bly zero. But if you have heart is­sues and take medium to large doses reg­u­larly for as lit­tle as a few days, this might  be a se­ri­ous con­cern. Ibupro­fen also af­fects the kid­neys. If you’re stressed, or cold, or de­hy­drated, or take stim­u­lants, your body will con­strict your blood ves­sels. That squeezes your kid­neys’ in­take tube, de­priv­ing them of blood. Your kid­neys don’t like that, so they re­lease sig­nal­ing mol­e­cules to lo­cally re-di­late the blood ves­sels. Trou­ble is, when ibupro­fen in­hibits COX en­zymes in the kid­neys, it in­hibits those sig­nal­ing mol­e­cules. If every­thing is nor­mal, that’s okay, be­cause the kid­neys would­n’t try to use those mol­e­cules any­way. But if your body has clamped down on the blood ves­sels, then the kid­neys don’t have the tool they use to keep blood flow­ing, mean­ing they don’t get as much blood as they want. This is bad.

There are many other less com­mon side ef­fects, in­clud­ing al­ler­gies, res­pi­ra­tory re­ac­tions in asth­mat­ics, in­duced menin­gi­tis, and sup­pressed ovu­la­tion. If you take a lot of ibupro­fen, this could hurt your liver. But the ma­jor con­cerns seem to be the stom­ach, the heart, and the kid­neys.

Acetaminophen also in­hibits some COX en­zymes. But un­like ibupro­fen, the ef­fect is min­i­mal out­side the cen­tral ner­vous sys­tem. Thus, ac­eta­minophen has lit­tle ef­fect on stom­ach mu­cus, blood clots, or blood flow, and so pre­sents al­most none of the risks that ibupro­fen does. Even so, if you take too much ac­eta­minophen at once, you could eas­ily die. How does this hap­pen? Well, when ac­eta­minophen is me­tab­o­lized by the liver, it’s mostly bro­ken down into harm­less stuff. But a small frac­tion (5-15%) is bro­ken down by the P450 sys­tem into an ex­tremely toxic chem­i­cal called NAPQI. Ordinarily this is fine; your body cre­ates and neu­tral­izes toxic stuff all the time. For ex­am­ple, if you drank 20 grams of formalde­hyde, you’d likely die. But did you know that your body it­self makes and processes ~50 grams of formalde­hyde every day? When liver cells sense NAPQI, they im­me­di­ately re­lease glu­tathione, which binds to NAPQI and ren­ders it harm­less. But there’s a prob­lem. If you take too much ac­eta­minophen at once, the path­ways that break it down into harm­less stuff get sat­u­rated, but the P450 sys­tem does­n’t get sat­u­rated. This means that not only is there more ac­eta­minophen, but also that a much larger frac­tion of it is bro­ken down into NAPQI. Soon your liver cells will run out of glu­tathione to neu­tral­ize it. Then, NAPQI will build up and bind to var­i­ous pro­teins in the liver cells (especially in mi­to­chon­dria) caus­ing them to mal­func­tion and/​or com­mit sui­cide. This can cause to­tal liver fail­ure. So you should never take more than the rec­om­mended dose of  ac­eta­minophen.

If you do take too much, you should go to a hos­pi­tal im­me­di­ately. They will give you NAC, which will re­plen­ish your glu­tathione and neu­tral­ize the NAPQI. Your prospects are good as long as you get to the hos­pi­tal within a few hours.

Acetaminophen has lots of other pos­si­ble side ef­fects, like skin is­sues and blood dis­or­ders. But these all seem to be quite rare.

Sign up for our newslet­ter to get Asterisk’s lat­est in­ter­views, es­says, and more.

What if you have liver is­sues?

The pri­mary con­cern with ac­eta­minophen  is liver dam­age. So if you have liver dis­ease, then surely you’d want to avoid ac­eta­minophen and take ibupro­fen in­stead, right? Nope. It’s the op­po­site. Liver dis­ease shifts the bal­ance of risk in fa­vor of ac­eta­minophen. With liver dis­ease, it’s hard for blood to flow into the liver, mean­ing that blood tends to pool in the ab­domen. To counter this, blood ves­sels else­where in the body con­tract. This in­cludes blood ves­sels around the kid­neys. Re­mem­ber the kid­neys? Again, when blood ves­sels are con­stricted, the kid­neys send out sig­nal­ing mol­e­cules to lo­cally re-di­late the blood ves­sels. But those sig­nal­ing mol­e­cules are blocked by ibupro­fen. So if you have liver dis­ease, tak­ing ibupro­fen risks starv­ing your kid­neys of blood just like if you were de­hy­drated.Mean­while, peo­ple with mod­er­ate liver dis­ease are usu­ally still able to process ac­eta­minophen with­out is­sue, as long as it’s in smaller amounts. So doc­tors usu­ally tell pa­tients with liver dis­ease to avoid ibupro­fen and take  ac­eta­minophen in­stead, just with a max­i­mum of two grams per day in­stead of four.

The main take­away from all this is that the risks of both drugs emerge from the mad­house of com­plex­ity that is your body. Surely there are some sit­u­a­tions where ac­eta­minophen is more dan­ger­ous than ibupro­fen?I tried to cap­ture the most com­mon sit­u­a­tions in this table:

It’s ac­tu­ally fairly hard to find sit­u­a­tions where ibupro­fen is safer than ac­eta­minophen. Possibly this is true if you’re hun­gover, but I would be very care­ful, be­cause you tend to be de­hy­drated when hun­gover, rais­ing the risk of kid­ney dam­age. (It’s prob­a­bly op­ti­mal, from a health per­spec­tive, to avoid tak­ing recre­ational drugs at doses that leave you phys­i­cally ill the next day.) Aside from hang­overs, the only sit­u­a­tions I could find where ibupro­fen might be safer than ac­eta­minophen  are if you’re tak­ing cer­tain anti-seizure or tu­ber­cu­lo­sis drugs or maybe if you have a cer­tain en­zyme de­fi­ciency (G6PDD).

What have we learned so far? 1. The body is re­ally com­pli­cated! 2. The main risk of ac­eta­minophen is liver dam­age by cre­at­ing too much NAPQI. Taking too much at once can eas­ily kill you. However, as long as you don’t take too much at once and your liver is­n’t de­pleted, then your liver will main­tain NAPQI lev­els at zero and it will be com­pletely fine. And there are very few other risks. 3. Meanwhile, ibupro­fen poses a risk of gas­troin­testi­nal is­sues, heart at­tacks, or kid­ney dam­age. The risk varies based on lots of fac­tors like whether you’ve eaten food, whether you’re de­hy­drated, your blood pres­sure, and your heart health.

4. Therefore, ac­eta­minophen is prob­a­bly safer, pro­vided you never take too much.

I don’t want to be alarmist. If you’re healthy, the risk from tak­ing an oc­ca­sional dose of ibupro­fen as di­rected is ex­tremely low. Given that so many peo­ple find that ibupro­fen is more ef­fec­tive for many kinds of pain, it’s to­tally rea­son­able to use it. I do so my­self. Still, it seems to be the case that in the vast ma­jor­ity of sit­u­a­tions, ac­eta­minophen is safer. Personally, if I have pain, I first take ac­eta­minophen, and then add ibupro­fen if nec­es­sary. I’m pretty sure many ex­perts think this is some­where be­tween “sensible” and “obvious.” But if ac­eta­minophen is safer, then why don’t of­fi­cial sources tell you that?

I can get doc­tors to ad­mit this off-the-record. I can find ran­dom com­ment threads with sup­port from peo­ple who seem to know what they’re talk­ing about. But why does this fact never ap­pear on gov­ern­ment web­sites or drug la­bels?

Let’s look at those drug la­bels

In the U.S., the Food and Drug Administration (FDA) cre­ates

a “drug facts” la­bel for over-the-counter drugs.  Here’s what that looks like for ibupro­fen:

And here’s what it looks like for ac­eta­minophen (acetaminophen):

I feel dumb say­ing this, but when I saw those la­bels in the past, I thought of them as a bunch of ran­dom in­for­ma­tion thrown to­gether for le­gal rea­sons. But af­ter spend­ing a lot of time try­ing to un­der­stand these drugs my­self, I now re­al­ize that these la­bels are… re­ally good? Imag­ine you work at the FDA and it’s your job to write a safety la­bel. You need to syn­the­size a vast and murky sci­en­tific land­scape. Your la­bel will be read by peo­ple with min­i­mal sci­en­tific back­ground who are likely cur­rently in pain, and who could die if they take the drug in the wrong sit­u­a­tion. If I were in that sit­u­a­tion, I’d think about all the dif­fer­ent sit­u­a­tions in which tak­ing one of these drugs could lit­er­ally kill some­one, and then — af­ter a quick panic at­tack — I’d write a la­bel that screamed, HEY, IF YOU ARE IN ANY OF THESE SITUATIONS, TAKING THIS DRUG COULD LITERALLY KILL YOU. Then I’d think about all the other sit­u­a­tions where tak­ing the drug might be okay de­pend­ing on a set of com­plex sci­ence stuff and tell peo­ple in those sit­u­a­tions to PLEASE TALK TO A DOCTOR FOR THE LOVE OF GOD be­cause I DON’T KNOW IF YOU’VE HEARD BUT SCIENCE IS COMPLICATED. Everything else would be a mi­nor con­cern.From that per­spec­tive, these la­bels are a tri­umph. This is­n’t ran­dom in­for­ma­tion — every word is a syn­the­sis of a moun­tain of re­search, care­fully op­ti­mized to save lives.

How did those drug la­bels come to be? If you want a taste for the FDA’s process, I en­cour­age you to skim the 2002 Federal Register doc­u­ment in which the FDA pro­posed to up­date ibupro­fen’s safety la­bel and to for­mally clas­sify it as Generally Recognized as Safe. It’s more than 21,000 words long and — I think — as­ton­ish­ingly good. It not only sum­ma­rizes the en­tire med­ical lit­er­a­ture on ibupro­fen, it sum­ma­rizes it well. Here is onerep­re­sen­ta­tive bit:

Bradley et al. (Ref. 42) con­ducted a 4-week, dou­ble-blind, ran­dom­ized trial in 184 sub­jects com­par­ing the ef­fec­tive­ness and safety of the max­i­mum ap­proved OTC daily dose of 1,200 mg of ibupro­fen (number of sub­jects (n) = 62) to that of a pre­scrip­tion dose of 2,400 mg/​day (n = 61), and to 4,000 mg/​day of ac­eta­minophen (n = 59) for the treat­ment of os­teoarthri­tis. While there were no sig­nif­i­cant dif­fer­ences in the num­ber of side ef­fects re­ported dur­ing this study, the study demon­strated a trend to­wards a dose de­pen­dent in­crease in mi­nor GI ad­verse events (nausea and dys­pep­sia) as­so­ci­ated with higher doses of ibupro­fen (1,200 mg/​day: 7/62 or 11.3 per­cent; ver­sus 2,400 mg/​day: 14/61 or 23 per­cent). In ad­di­tion, two sub­jects treated with 2,400 mg/​day of ibupro­fen be­came pos­i­tive for oc­cult blood while par­tic­i­pat­ing in the study.

I spend a lot of time com­plain­ing about bad sta­tis­ti­cal writ­ing. A lot. Probably too much. But I’m here to tell you, that para­graph is gor­geous. The writ­ing is clear and pen­e­trat­ing. It con­tains all the im­por­tant de­tails, but no other de­tails. Compared to the ab­stract of the orig­i­nal pa­per, the above is shorter and eas­ier to un­der­stand yet si­mul­ta­ne­ously more in­for­ma­tive. Five stars. The rest of the doc­u­ment is equally good, with clear and sen­si­ble ex­pla­na­tions for var­i­ous rec­om­men­da­tions. For ex­am­ple, they dis­cuss a pro­posal from the National Kidney Foundation for ad­di­tional warn­ing about risks to kid­neys, ex­plain why they think that pro­posal has merit, and then rec­om­mend a shorter ver­sion, which ap­pears on every pack­age of ibupro­fen sold to­day. As far as I can tell, this level of qual­ity is typ­i­cal. For ex­am­ple, the FDA’s 2019 pro­posed rule on sun­screens is sim­i­larly mas­ter­ful.

This leaves us with this con­stel­la­tion of facts: 1. Acetaminophen is, in gen­eral, safer than ibupro­fen. 2. The FDA does­n’t tell you that. Neither do other re­spectable au­thor­i­ties. So what’s hap­pen­ing here? Have the ex­perts con­spired to keep this knowl­edge se­cret? I don’t think so. Mostly, I think this is down to two fac­tors. First, the FDA does­n’t re­ally have a mis­sion of de­ter­min­ing “in what cir­cum­stances is drug A safer than drug B?” Their goal is to take in­di­vid­ual drugs and de­ter­mine how peo­ple can use them safely. They seem to be quite good at this. Sec­ond, every­one is mor­tally afraid of giv­ing “medical ad­vice.” It varies by ju­ris­dic­tion, but in gen­eral, giv­ing “wellness ad­vice” is OK, but if you give per­son­al­ized ad­vice, you risk go­ing to prison. The more cred­i­ble you are, the higher that risk is.

Stepping back, how should we think about this sit­u­a­tion? The body is com­pli­cated. When ex­perts give the pub­lic ad­vice on drugs, they are try­ing to in­su­late us from that com­plex­ity. But there is no way to do that with­out mak­ing trade-offs. Society has im­plic­itly cho­sen trade­offs that mean cer­tain “less im­por­tant” facts are de-pri­or­i­tized. It’s not ob­vi­ous that this is the wrong choice. I feel fool­ish for not hav­ing more re­spect for the body’s com­plex­ity and for the dif­fi­culty of the task all the ex­perts are try­ing to ac­com­plish. This is not med­ical ad­vice.

It is in­tended only for pro­to­col study, sig­nal analy­sis, and con­trolled ex­per­i­ments on hard­ware you per­son­ally own or are ex­plic­itly au­tho­rized to test.

This repos­i­tory does not au­tho­rize ac­cess to, mod­i­fi­ca­tion of, or in­ter­fer­ence with any third-party de­ploy­ment, com­mer­cial in­stal­la­tion, or re­tail en­vi­ron­ment.

TagTinker is a Flipper Zero app for ed­u­ca­tional re­search into in­frared elec­tronic shelf-la­bel pro­to­cols and re­lated dis­play be­hav­ior on au­tho­rized test hard­ware.

It is fo­cused on:

This README in­ten­tion­ally avoids de­ploy­ment-ori­ented in­struc­tions and ex­cludes guid­ance for in­ter­act­ing with live com­mer­cial sys­tems.

Where is the .fap re­lease?

The Flipper app is source-first. Build the .fap your­self from this repos­i­tory with ufbt so it matches your firmware and lo­cal tool­chain.

What if it crashes or be­haves oddly?

The main­tainer pri­mar­ily uses TagTinker on Momentum firmware with as­set packs dis­abled and has not had is­sues in that setup. If you are us­ing a dif­fer­ent firmware branch, cus­tom as­set packs, or a heav­ily mod­i­fied de­vice setup, start by test­ing from a clean base­line.

What hap­pens if I pull the bat­tery out of the tag?

Many in­frared ESL tags store their firmware, ad­dress, and dis­play data in volatile RAM (not flash mem­ory) to save cost and en­ergy.

If you re­move the bat­tery or let it fully dis­charge, the tag will lose all pro­gram­ming and be­come un­re­spon­sive (“dead”). It usu­ally can­not be re­cov­ered with­out the orig­i­nal base sta­tion.

I found a bug or want to con­tribute — how can I get in touch?

You can con­tact me on:

I’m cur­rently trav­el­ing, so re­sponse times may be slower than usual. Feel free to open is­sues or Pull Requests any­way — con­tri­bu­tions (bug fixes, im­prove­ments, doc­u­men­ta­tion, etc.) are very wel­come and will help keep the pro­ject alive while I’m away.

TagTinker is built around the study of in­frared elec­tronic shelf-la­bel com­mu­ni­ca­tion used by fixed-trans­mit­ter la­bel­ing sys­tems.

* com­mu­ni­ca­tion is based on ad­dressed pro­to­col frames con­tain­ing com­mand, pa­ra­me­ter, and in­tegrity fields

* dis­play up­dates are car­ried as pre­pared pay­loads for sup­ported mono­chrome graph­ics for­mats

* lo­cal tool­ing in this pro­ject helps re­searchers pre­pare as­sets and per­form con­trolled ex­per­i­ments on au­tho­rized hard­ware

This pro­ject is in­tended to help re­searchers un­der­stand:

For the un­der­ly­ing re­verse-en­gi­neer­ing back­ground and deeper pro­to­col re­search, see:

TagTinker is lim­ited to home-lab and au­tho­rized re­search use, in­clud­ing:

It is not a re­tail tool, op­er­a­tional tool, or field-use util­ity.

You are solely re­spon­si­ble for en­sur­ing that any use of this soft­ware is law­ful, au­tho­rized, and ap­pro­pri­ate for your en­vi­ron­ment.

The main­tainer does not au­tho­rize, ap­prove, or par­tic­i­pate in any unau­tho­rized use of this pro­ject, and dis­claims re­spon­si­bil­ity for mis­use, dam­age, dis­rup­tion, le­gal vi­o­la­tions, or any con­se­quences aris­ing from such use.

If you do not own the hard­ware, or do not have ex­plicit writ­ten per­mis­sion to test it, do not use this pro­ject on it.

Any unau­tho­rized use is out­side the in­tended scope of this repos­i­tory and is un­der­taken en­tirely at the user’s own risk.

This is an in­de­pen­dent re­search pro­ject.

It is not af­fil­i­ated with, en­dorsed by, au­tho­rized by, or spon­sored by any elec­tronic shelf-la­bel ven­dor, re­tailer, in­fra­struc­ture provider, or sys­tem op­er­a­tor.

Any ref­er­ences to ex­ter­nal re­search, pub­lic doc­u­men­ta­tion, or re­verse-en­gi­neer­ing work are in­cluded strictly for ed­u­ca­tional and re­search con­text.

This pro­ject is a port and adap­ta­tion of the ex­cel­lent pub­lic re­verse-en­gi­neer­ing work by fur­rtek / PrecIR and re­lated com­mu­nity re­search.

Licensed un­der the GNU General Public License v3.0 (GPL-3.0).

See the LICENSE file for de­tails.

This soft­ware is pro­vided “AS IS”, with­out war­ranty of any kind, ex­press or im­plied.

In no event shall the au­thors or copy­right hold­ers be li­able for any claim, dam­ages, or other li­a­bil­ity aris­ing from the use of this soft­ware.

This repos­i­tory is main­tained as a nar­rowly scoped ed­u­ca­tional re­search pro­ject.

The main­tainer does not au­tho­rize, en­cour­age, con­done, or ac­cept re­spon­si­bil­ity for use against third-party de­vices, de­ployed com­mer­cial sys­tems, re­tail in­fra­struc­ture, or any en­vi­ron­ment where the user lacks ex­plicit per­mis­sion.

It’s the na­ture of busi­ness that the eu­logy for a chief ex­ec­u­tive does­n’t hap­pen when they die, but when they re­tire, or, in the case of Apple CEO Tim Cook, an­nounce that they will step up to the role of Executive Chairman on September 1. The one mor­bid ex­cep­tion is when a CEO dies on the job — or quits be­cause they are dy­ing — and the truth of the mat­ter is that that is where any hon­est re­count­ing of Cook’s in­cred­i­bly suc­cess­ful tenure as Apple CEO, par­tic­u­larly from a fi­nan­cial per­spec­tive, has to be­gin.

The num­bers, to be clear, are ex­tra­or­di­nary. Cook be­came CEO of Apple on August 24, 2011, and in the in­ter­ven­ing 15 years rev­enue has in­creased 303%, profit 354%, and the value of Apple has gone from $297 bil­lion to $4 tril­lion, a stag­ger­ing 1,251% in­crease.

The rea­son for Cook’s ac­ces­sion in 2011 be­came clear a mere six weeks later, when Steve Jobs passed away from can­cer on October 5, 2011. Jobs’ death is­n’t the rea­son Cook was cho­sen — Cook had al­ready served as in­terim CEO while Jobs un­der­went treat­ment in 2009 — but I think the tim­ing played a ma­jor role in mak­ing Cook ar­guably the great­est non-founder CEO of all time.

Peter Thiel in­tro­duced the con­cept of Zero To One thusly:

When we think about the fu­ture, we hope for a fu­ture of progress. That progress can take one of two forms. Horizontal or ex­ten­sive progress means copy­ing things that work — go­ing from 1 to n. Horizontal progress is easy to imag­ine be­cause we al­ready know what it looks like. Vertical or in­ten­sive progress means do­ing new things — go­ing from 0 to 1. Vertical progress is harder to imag­ine be­cause it re­quires do­ing some­thing no­body else has ever done. If you take one type­writer and build 100, you have made hor­i­zon­tal progress. If you have a type­writer and build a word proces­sor, you have made ver­ti­cal progress.

Steve Jobs made 0 to 1 prod­ucts, as he re­minded the au­di­ence in the in­tro­duc­tion to his most fa­mous keynote:

Every once in a while, a rev­o­lu­tion­ary prod­uct comes along that changes every­thing. First of all, one’s very for­tu­nate if one gets to work on one of these in your ca­reer. Apple’s been very for­tu­nate: it’s been able to in­tro­duce a few of these into the world.

In 1984, we in­tro­duced the Macintosh. It did­n’t just change Apple, it changed the whole com­puter in­dus­try. In 2001, we in­tro­duced the first iPod. It did­n’t just change the way we all lis­ten to mu­sic, it changed the en­tire mu­sic in­dus­try.

Well, to­day we’re in­tro­duc­ing three rev­o­lu­tion­ary prod­ucts of this class. The first one: a widescreen iPod with touch con­trols. The sec­ond: a rev­o­lu­tion­ary mo­bile phone. And the third is a break­through Internet com­mu­ni­ca­tions de­vice. Three things…are you get­ting it? These are not three sep­a­rate de­vices. This is one de­vice, and we are call­ing it iPhone.

Steve Jobs would, three years later, also in­tro­duce the iPad, which makes four dis­tinct prod­uct cat­e­gories if you’re count­ing. Perhaps the most im­por­tant 0 to 1 prod­uct Jobs cre­ated, how­ever, was Apple it­self, which raises the ques­tion: what makes Apple Apple?

“What Makes Apple Apple” is­n’t a new ques­tion; it was the cen­tral ques­tion of Apple University, the in­ter­nal train­ing pro­gram the com­pany launched in 2008. Apple University was hailed on the out­side as a Steve Jobs cre­ation, but while I’m sure he green lit the con­cept, it was clear to me as an in­tern on the Apple University team in 2010, that the pro­gram’s dri­ving force was Tim Cook.

The core of the pro­gram, at least when I was there, was what be­came known as The Cook Doctrine:

We be­lieve that we’re on the face of the Earth to make great prod­ucts, and that’s not chang­ing.

We be­lieve in the sim­ple, not the com­plex.

We be­lieve that we need to own and con­trol the pri­mary tech­nolo­gies be­hind the prod­ucts we make, and par­tic­i­pate only in mar­kets where we can make a sig­nif­i­cant con­tri­bu­tion.

We be­lieve in say­ing no to thou­sands of pro­jects so that we can re­ally fo­cus on the few that are truly im­por­tant and mean­ing­ful to us.

We be­lieve in deep col­lab­o­ra­tion and cross-pol­li­na­tion of our groups, which al­low us to in­no­vate in a way that oth­ers can­not.

And frankly, we don’t set­tle for any­thing less than ex­cel­lence in every group in the com­pany, and we have the self-hon­esty to ad­mit when we’re wrong and the courage to change.

And I think, re­gard­less of who is in what job, those val­ues are so em­bed­ded in this com­pany that Apple will do ex­tremely well.

Cook ex­plained this on Apple’s January 2009 earn­ings call, dur­ing Jobs’ first leave of ab­sence, in re­sponse to a ques­tion about how Apple would fare with­out its founder. It’s a bril­liant state­ment, but it is — as the last para­graph makes clear — ul­ti­mately about main­tain­ing, nur­tur­ing, and grow­ing what Jobs built.

That is why I started this Article by high­light­ing the tim­ing of Cook’s as­cent to the CEO role. The chal­lenge for CEOs fol­low­ing iconic founders is that the per­son who took the com­pany from 0 to 1 usu­ally sticks around for 2, 3, 4, etc.; by the time they step down the only way for­ward is of­ten down. Jobs, how­ever, by virtue of leav­ing the world too soon, left Apple only a few years af­ter its most im­por­tant 0 to 1 prod­uct ever, mean­ing it was Cook who was in charge of grow­ing and ex­pand­ing Apple’s most rev­o­lu­tion­ary de­vice yet.

Cook, to be clear, man­aged this bril­liantly. Under his watch the iPhone not only got bet­ter every year, but ex­panded its mar­ket to every car­rier in ba­si­cally every coun­try, and ex­panded the line from one model in two col­ors to five mod­els in a plethora of col­ors sold at the scale of hun­dreds of mil­lions of units a year.

Cook was, with­out ques­tion, an op­er­a­tional ge­nius. Moreover, this was clearly the case even be­fore he scaled the iPhone to unimag­in­able scale. When Cook joined Apple in 1998 the com­pa­ny’s op­er­a­tions — cen­tered on Apple’s own fac­to­ries and ware­houses — were a mas­sive drag on the com­pany; Cook me­thod­i­cally shut them down and shifted Apple’s man­u­fac­tur­ing base to China, cre­at­ing a just-in-time sup­ply chain that year-af­ter-year co­or­di­nated a world­wide net­work of sup­pli­ers to de­liver Apple’s ever-ex­pand­ing prod­uct line to cus­tomers’ doorsteps and a fleet of beau­ti­ful and brand-ex­pand­ing stores. There was not, un­der Cook’s lead­er­ship, a sin­gle sig­nif­i­cant prod­uct is­sue or re­call.

Cook also over­saw the in­tro­duc­tion of ma­jor new prod­ucts, most no­tably AirPods and Apple Watch; the “Wearables, Home, and Accessories” cat­e­gory de­liv­ered $35.4 bil­lion in rev­enue last year, which would rank 128 on the Fortune 500. Still, both prod­ucts are de­riv­a­tive of the iPhone; Cook’s sig­na­ture 0 to 1 prod­uct, the Apple Vision Pro, is more of a 0.5.

Cook’s more mo­men­tous con­tri­bu­tion to Apple’s top line was the el­e­va­tion of Services. The Google search deal ac­tu­ally orig­i­nated in 2002 with an agree­ment to make Google the de­fault search ser­vice for Safari on the Mac, and was ex­tended to the iPhone in 2007; Google’s mo­ti­va­tion was to en­sure that Apple never com­peted for their core busi­ness, and Cook was happy to take an ever in­creas­ing amount of pure profit.

The App Store also pre­dated Cook; Steve Jobs said dur­ing the App Store’s in­tro­duc­tion that “we keep 30 [percent] to pay for run­ning the App Store”, and called it “the best deal go­ing to dis­trib­ute ap­pli­ca­tions to mo­bile plat­forms”. It’s im­por­tant to note that, in 2008, this was true! The App Store re­ally was a great deal.

Three years later, in a July 28, 2011 email — less than a month be­fore Cook of­fi­cially be­came CEO — Phil Schiller won­dered if Apple should lower its take once they were mak­ing $1 bil­lion a year in profit from the App Store. John Gruber, writ­ing on Daring Fireball in 2021, won­dered what might have been had Cook fol­lowed Schiller’s ad­vice:

In my imag­i­na­tion, a world where Apple had used Phil Schiller’s memo above as a game plan for the App Store over the last decade is a bet­ter place for every­one to­day: de­vel­op­ers for sure, but also users, and, yes, Apple it­self. I’ve of­ten said that Apple’s pri­or­i­ties are con­sis­tent: Apple’s own needs first, users’ sec­ond, de­vel­op­ers’ third. Apple, for ob­vi­ous rea­sons, does not like to talk about the Apple-first part of those pri­or­i­ties, but Cook made ex­plicit dur­ing his tes­ti­mony dur­ing the Epic trial that when user and de­vel­oper needs con­flict, Apple sides with users. (Hence App Tracking Transparency, for ex­am­ple.)

These pri­or­i­ties are as they should be. I’m not com­plain­ing about their or­der. But putting de­vel­oper needs third does­n’t mean they should be ne­glected or over­looked. A large base of de­vel­op­ers who are ex­perts on de­vel­op­ing and de­sign­ing for Apple’s pro­pri­etary plat­forms is an in­cred­i­ble as­set. Making those de­vel­op­ers happy — happy enough to keep them want­ing to work and fo­cus on Apple’s plat­forms — is good for Apple it­self.

I want to agree with Gruber — I was crit­i­ciz­ing Apple’s App Store poli­cies within weeks of start­ing Stratechery, years be­fore it be­came a ma­jor is­sue — but from a share­holder per­spec­tive, i.e. Cook’s ul­ti­mate bosses, it’s hard to ar­gue with Apple’s un­com­pro­mis­ing ap­proach. Last year Apple Services gen­er­ated 26% of Apple’s rev­enue and 41% of the com­pa­ny’s profit; more im­por­tantly, Services con­tin­ues to grow year-over-year, even as iPhone growth has slowed from the go-go years.

Another way to frame the Services ques­tion is to say that Gruber is con­cerned about the long-term im­por­tance of some­thing that is some­what in­ef­fa­ble — de­vel­oper will­ing­ness and de­sire to sup­port Apple’s plat­forms — which is, at least in Gruber’s mind, es­sen­tial for Apple’s long-term health. Cook, in this cri­tique, pri­or­i­tized Apple’s fi­nan­cial re­sults and share­holder re­turns over what was best for Apple in the long run.

This is­n’t the only part of Apple’s busi­ness where this cri­tique has va­lid­ity. Cook’s great­est tri­umph was, as I noted above, com­pletely over­haul­ing and sub­se­quently scal­ing Apple’s op­er­a­tions, which first and fore­most meant de­vel­op­ing a heavy de­pen­dence on China. This de­pen­dence was not in­evitable: Patrick McGee ex­plained in Apple In China, which I con­sider one of the all-time great books about the tech in­dus­try, how Apple made China into the man­u­fac­tur­ing be­he­moth it be­came. McGee added in a Stratechery Interview:

Let me just re­fer back to some­thing that you wrote I think a few months ago when you called the last 20, 25 years, like the golden age for com­pa­nies like Apple and Silicon Valley fo­cused on soft­ware and Chinese tak­ing care of the hard­ware man­u­fac­tur­ing. That is a per­fect part­ner­ship, and if we were liv­ing in a sim­u­la­tion and it ended to­mor­row, you’d give props for Apple to tak­ing ad­van­tage of the sit­u­a­tion bet­ter than any­body else.

The prob­lem is we’re prob­a­bly not liv­ing in the sim­u­la­tion and things go on, and I’ve got this rather dis­qui­et­ing con­clu­sion where, look, Apple’s still re­ally good prob­a­bly, they’re not as good as they once were un­der Jony Ive, but they’re still good at in­dus­trial de­sign and prod­uct de­sign, but they don’t do any op­er­a­tions in our own coun­try. That’s all de­pen­dent on China. You’ve called this in fact the biggest vi­o­la­tion of the Tim Cook doc­trine to own and con­trol your des­tiny, but the Chinese aren’t just do­ing the op­er­a­tions any­more, they also have in­dus­trial de­sign, prod­uct de­sign, man­u­fac­tur­ing de­sign.

It re­ally is ironic: Tim Cook built what is ar­guably Apple’s most im­por­tant tech­nol­ogy — its abil­ity to build the world’s best per­sonal com­puter prod­ucts at as­tro­nom­i­cal scale — and did so in a way that leaves Apple more vul­ner­a­ble than any­one to the de­te­ri­o­rat­ing re­la­tion­ship be­tween the United States and China. China was cer­tainly good for the bot­tom line, but was it good for Apple’s long-run sus­tain­abil­ity?

This same cri­tique — of fa­vor­ing a fi­nan­cially op­ti­mal strat­egy over long-term sus­tain­abil­ity — may also one day be levied on the biggest ques­tion Cook leaves his suc­ces­sor: what im­pact will AI have on Apple? Apple has, to date, avoided spend­ing hun­dreds of bil­lions of dol­lars on the AI build­out, and there is one po­ten­tial fu­ture where the com­pany prof­its from AI by sell­ing the de­vices every­one uses to ac­cess com­modi­tized mod­els; there is an­other fu­ture where AI be­comes the means by which Apple’s 50 Years of Integration is fi­nally dis­rupted by com­pa­nies that ac­tu­ally in­vested in the tech­nol­ogy of the fu­ture.

If Tim Cook’s tim­ing was for­tu­nate in terms of when in Apple’s life­cy­cle he took the reins, then I would call his tim­ing in terms of when in Apple’s life­cy­cle he is step­ping down as be­ing pru­dent, both for his legacy and for Apple’s fu­ture.

Apple is, in terms of its tra­di­tional busi­ness model, in a bet­ter place than it has ever been. The iPhone line is fan­tas­tic, and sell­ing at a record pace; the Mac, mean­while, is poised to mas­sively ex­pand its mar­ket share as Apple Silicon — an­other Jobs ini­tia­tive, ap­pro­pri­ately in­vested in and nur­tured by Cook — makes the Mac the com­puter of choice for both the high end (thanks to Apple Silicon’s per­for­mance and uni­fied mem­ory ar­chi­tec­ture) and the low end (the iPhone chip-based MacBook Neo sig­nif­i­cantly ex­pands Apple’s ad­dress­able mar­ket). Meanwhile, the Services busi­ness con­tin­ues to grow. Cook is step­ping down af­ter Apple’s best-ever quar­ter, a mile­stone that very much cap­tures his tenure, for bet­ter and for worse.

At the same time, the AI ques­tion looms — and it sug­gests that Something Is Rotten in the State of Cupertino. The new Siri still has­n’t launched, and when it does, it will be with Google’s tech­nol­ogy at the core. That was, as I wrote in an Update, a mo­men­tous de­ci­sion for Apple’s fu­ture:

Apple’s plans are a bit like the al­co­holic who ad­mits that they have a drink­ing prob­lem, but promises to limit their in­take to so­cial oc­ca­sions. Namely, how ex­actly does Apple plan on re­plac­ing Gemini with its own mod­els when (1) Google has more tal­ent, (2) Google spends far more on in­fra­struc­ture, and (3) Gemini will be con­tin­u­ally in­creas­ing from the cur­rent level, where it is far ahead of Apple’s ef­forts? Moreover, there is now a new fac­tor work­ing against Apple: if this white-la­bel­ing ef­fort works, then the bar for “good enough” will be much higher than it is cur­rently. Will Apple, af­ter all of the trou­ble they are go­ing through to fix Siri, ac­tu­ally be will­ing to tear out a model that works so that they can once again roll their own so­lu­tion, par­tic­u­larly when that so­lu­tion has­n’t faced the mar­ket pres­sure of ac­tu­ally work­ing, while Gemini has?

In short, I think Apple has made a good de­ci­sion here for short term rea­sons, but I don’t think it’s a short-term de­ci­sion: I strongly sus­pect that Apple, whether it has ad­mit­ted it to it­self or not, has just com­mit­ted it­self to de­pend­ing on 3rd-parties for AI for the long run.

As I noted above and in that Update, this de­ci­sion may work out; if it does­n’t, how­ever, the sting will be felt long af­ter Cook is gone. To that end, I cer­tainly hope that John Ternus, the new CEO, was heav­ily in­volved in the de­ci­sion; truth­fully, he should have made it.

To that end, it’s right that Cook is step­ping down now. Jobs might have been re­spon­si­ble for tak­ing Apple from 0 to 1, but it was Cook that took Apple from 1 to $436 bil­lion in rev­enue and $118 bil­lion in profit last year. It’s a tes­ta­ment to his ca­pa­bil­i­ties and ex­e­cu­tion that Apple did­n’t suf­fer any sort of post-founder hang­over; only time will tell if, along the way, Cook cre­ated the con­di­tions for a crash out, by virtue of he him­self for­get­ting The Cook Doctrine and what makes Apple Apple.