10 interesting stories served every morning and every evening.




1 1,261 shares, 69 trendiness

Intel Core Ultra 3 & LPCAMM2

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.

...

Read the original on frame.work »

2 1,008 shares, 44 trendiness

Laws of Software Engineering

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.

...

Read the original on lawsofsoftwareengineering.com »

3 571 shares, 31 trendiness

Claude by Anthropic

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.

...

Read the original on claude.com »

4 571 shares, 48 trendiness

Ed Zitron (@edzitron.com)

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

...

Read the original on bsky.app »

5 553 shares, 34 trendiness

Meta to start capturing employee mouse movements, keystrokes for AI training data

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

...

Read the original on m.economictimes.com »

6 447 shares, 17 trendiness

Changes to GitHub Copilot Individual plans

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.

...

Read the original on github.blog »

7 365 shares, 43 trendiness

The Mystery in the Medicine Cabinet

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 FDAs 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 FDAs 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.

...

Read the original on asteriskmag.com »

8 336 shares, 14 trendiness

i12bp8/TagTinker: Flipper Zero app for ESL research using IR. All based on https://www.furrtek.org/?a=esl

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.

...

Read the original on github.com »

9 329 shares, 14 trendiness

Tim Cook’s Impeccable Timing

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.

...

Read the original on stratechery.com »

10 329 shares, 50 trendiness

- YouTube

...

Read the original on www.youtube.com »

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.

If you like 10HN please leave feedback and share

Visit pancik.com for more.