Welcome! Glad you could join us for an­other Sunday edi­tion of the Animation Obsessive newslet­ter. This is our slate:

With that, let’s go!

Toy Story used to look dif­fer­ent. It’s a lit­tle tricky to ex­plain.

Back in 1995, CG an­i­ma­tion was the topic in the in­dus­try, and Pixar was cen­tral to the hype. The stu­dio had al­ready shifted Disney to com­put­ers and won the first Oscar for a CG short (Tin Toy). Giant movies like Jurassic Park in­cor­po­rated Pixar’s soft­ware.

The next step was Toy Story, billed as the first an­i­mated fea­ture to go all-CG. Even af­ter Pixar’s suc­cesses, that was a risk. Would a fully dig­i­tal movie sell tick­ets?

It clearly worked out. Toy Story ap­peared 30 years ago this month — and its pop­u­lar­ity cre­ated the an­i­ma­tion world that ex­ists now. A new process took over the busi­ness.

But not en­tirely new — not at first. There was some­thing old about Toy Story’s tech, too, back in 1995. Pixar made the thing with com­put­ers, but it still needed to screen in the­aters. And com­put­ers could­n’t re­ally do that yet. From its early years, Pixar had re­lied on phys­i­cal film stock. According to au­thors Bill Kinder and Bobbie O’Steen:

[Pixar’s Ed] Catmull rec­og­nized that his stu­dio’s pix­els needed to merge with that world-stan­dard dis­tri­b­u­tion free­way, 35 mm film. Computer chips were not fast enough, nor disks large enough, nor com­pres­sion so­phis­ti­cated enough to dis­play even 30 min­utes of stan­dard-de­f­i­n­i­tion mo­tion pic­tures. It was ax­iomatic that for a film­go­ing au­di­ence to be go­ing to a film, it would be a… film.

Toy Story was a tran­si­tional pro­ject. Since Pixar could­n’t send dig­i­tal data to the­aters, every one of the movie’s frames was printed on ana­log film. When Toy Story orig­i­nally hit home video, that 35 mm ver­sion was its source. Only years later, af­ter tech­nol­ogy ad­vanced, did Pixar start do­ing dig­i­tal trans­fers — cut­ting out the mid­dle­man. And Toy Story’s look changed with the era.

While mak­ing Toy Story, Pixar’s team knew that the grain, soft­ness, col­ors and con­trasts of ana­log film weren’t vis­i­ble on its mon­i­tors. They were dif­fer­ent medi­ums.

So, to get the right look, the stu­dio had to keep that fi­nal, phys­i­cal out­put in mind. The dig­i­tal col­ors were tai­lored with an aware­ness that they would change af­ter print­ing. “Greens go dark re­ally fast, while the reds stay pretty true,” said Toy Story’s art di­rec­tor, Ralph Eggleston. “Blues have to be less sat­u­rated to look fully sat­u­rated on film, while the or­anges look re­ally bad on com­puter screens, but look re­ally great on film.”

The team checked its work along the way. In the words of Pixar’s William Reeves:

During pro­duc­tion, we’re work­ing mostly from com­puter mon­i­tors. We’re rarely see­ing the im­ages on film. So, we have five or six ex­tremely high-res­o­lu­tion mon­i­tors that have bet­ter color and pic­ture qual­ity. We put those in gen­eral work ar­eas, so peo­ple can go and see how their work looks. Then, when we record, we try to cal­i­brate to the film stock, so the im­age we have on the mon­i­tor looks the same as what we’ll get on film.

Behind the fi­nal im­ages was a “painstaking trans­fer process,” ac­cord­ing to the press. Leading it was David DiFrancesco, one of Pixar’s early MVPs, who be­gan work­ing with Ed Catmull be­fore Pixar even ex­isted. He broke ground in film print­ing — specif­i­cally, in putting dig­i­tal im­ages on ana­log film.

He and his team in Pixar’s pho­to­science de­part­ment used their ex­per­tise here. Their tools were “commercial grade” film print­ers, DiFrancesco noted: mod­i­fied Solitaire Cine II ma­chines. He’d in­vented more ad­vanced stuff, but it was­n’t vi­able for a pro­ject of Toy Story’s size. Using the best equip­ment would’ve taken “several ter­abytes of data,” he said.

Their sys­tem was fairly straight­for­ward. Every frame of Toy Story’s neg­a­tive was ex­posed, three times, in front of a CRT screen that dis­played the movie. “Since all film and video im­ages are com­posed of com­bi­na­tions of red, green and blue light, the frame is sep­a­rated into its dis­crete red, green and blue el­e­ments,” noted the stu­dio. Exposures, fil­tered through each color, were lay­ered to cre­ate each frame.

It re­port­edly took nine hours to print 30 sec­onds of Toy Story. But it had to be done: it was the only way to screen the film.

Its sec­ond fea­ture, A Bug’s Life, reached the­aters in 1998. Once more, the stu­dio de­signed its vi­su­als for ana­log film (see the trailer on 35 mm). Its peo­ple knew the ins-and-outs of this process, down to the amount of de­tail that film stock could ac­cept and a pro­jec­tor could show. That’s partly how they got away with the movie’s tiny 2048×862 res­o­lu­tion, for ex­am­ple.

Still, the team strug­gled with one thing: the dip in im­age qual­ity when film got con­verted to home video. That’s how Toy Story was re­leased, but there had to be a bet­ter way.

For the home ver­sion of A Bug’s Life, Pixar de­vised a method of “go[ing] from our dig­i­tal im­age within our sys­tem … straight to video,” John Lasseter said. He called it “a real pure ver­sion of our movie straight from our com­put­ers.” A Bug’s Life be­came the first dig­i­tal-to-dig­i­tal trans­fer on DVD. Compared to the the­atri­cal re­lease, the look had changed. It was sharp and grain­less, and the col­ors were kind of dif­fer­ent.

A dig­i­tal trans­fer of Toy Story fol­lowed in the early 2000s. And it was­n’t quite the same movie that view­ers had seen in the ’90s. “The col­ors are vivid and life­like, [and] not a hint of grain or ar­ti­facts can be found,” raved one re­viewer. It was a crisp, blaz­ingly bright, dig­i­tal im­age now — to­tally dif­fer­ent from the soft­ness, tex­ture and deep, muted warmth of phys­i­cal film, on which Toy Story was cre­ated to be seen.

Quickly, dig­i­tal trans­fers be­came a stan­dard thing. Among oth­ers by Pixar, The Incredibles puts off a very dif­fer­ent vibe be­tween its the­atri­cal and later re­leases (see the 35 mm trailer for ref­er­ence).

Pixar was­n’t the only stu­dio to make the leap, ei­ther. Disney did as well.

Like Toy Story, the Disney re­nais­sance work of the ’90s was tran­si­tional. The Lion King, Mulan and the rest ex­isted as files in com­puter sys­tems — and the idea was al­ways to record them on ana­log film at the end. Early home re­leases were based on those 35 mm ver­sions. Later re­leases, like the ones Disney streams to­day, were di­rect trans­fers of the dig­i­tal data.

At times, es­pe­cially in the col­ors, they’re al­most un­rec­og­niz­able. And the im­ages feel less co­he­sive — like some­thing’s miss­ing that was sup­posed to bring all the el­e­ments to­gether. These aren’t quite the same films that ruled the ’90s.

For a num­ber of years, there’s been talk in film-preser­va­tion cir­cles about Toy Story and the Disney re­nais­sance. This work sits in an odd place. The world was still pretty ana­log when the com­puter an­i­ma­tion boom ar­rived: out of ne­ces­sity, these pro­jects be­came hy­brids of new and old. What’s the right way to see dig­i­tal movies that were de­signed for 35 mm film?

The stu­dios them­selves haven’t quite fig­ured it out. On Disney+, the col­ors of Toy Story feel a bit raw — sear­ing greens that were meant to darken on film, for ex­am­ple. Meanwhile, the newer Toy Story Blu-ray shares more in com­mon with the orig­i­nal col­ors, but it’s still an al­tered, colder look.

When dig­i­tal trans­fers first showed up, peo­ple were thrilled, in­clud­ing at Pixar. Movies be­came “crisper, clearer and more stun­ning on home video sys­tems” than in the­aters, some claimed. Even so, it’s a lit­tle dis­qui­et­ing to think that Toy Story, the film that built our cur­rent world, is barely avail­able in the form that wowed au­di­ences of the ’90s. The same goes for many other movies from the tran­si­tional era.

The good news is that this con­ver­sa­tion gets big­ger all the time. In those film-preser­va­tion cir­cles, a ded­i­cated few are try­ing to save the old work. More and more com­par­i­son videos are pop­ping up on YouTube. If you get the chance to see one of the old Disney or Pixar films on 35 mm, it’s al­ways worth­while.

These com­pa­nies, ul­ti­mately, de­cide how Toy Story looks to­day. Still, for some, it’s nice to see the orig­i­nal ver­sion of the film again — the ver­sion Pixar orig­i­nally in­tended to make. It’s ev­i­dence that the film did feel dif­fer­ent back then. The mem­o­ries were real.

Introducing iPhone Pocket: a beau­ti­ful way to wear and carry iPhone

Born out of a col­lab­o­ra­tion be­tween ISSEY MIYAKE and Apple, iPhone Pocket fea­tures a sin­gu­lar 3D-knitted con­struc­tion de­signed to fit any iPhone

ISSEY MIYAKE and Apple to­day un­veiled iPhone Pocket. Inspired by the con­cept of “a piece of cloth,” its sin­gu­lar 3D-knitted con­struc­tion is de­signed to fit any iPhone as well as all pock­etable items. Beginning Friday, November 14, it will be avail­able at se­lect Apple Store lo­ca­tions and on ap­ple.com in France, Greater China, Italy, Japan, Singapore, South Korea, the UK, and the U. S.

iPhone Pocket fea­tures a ribbed open struc­ture with the qual­i­ties of the orig­i­nal pleats by ISSEY MIYAKE. Born from the idea of cre­at­ing an ad­di­tional pocket, its un­der­stated de­sign fully en­closes iPhone, ex­pand­ing to fit more of a user’s every­day items. When stretched, the open tex­tile sub­tly re­veals its con­tents and al­lows users to peek at their iPhone dis­play. iPhone Pocket can be worn in a va­ri­ety of ways — hand­held, tied onto bags, or worn di­rectly on the body. Featuring a play­ful color palette, the short strap de­sign is avail­able in eight col­ors, and the long strap de­sign in three col­ors.

“The de­sign of iPhone Pocket speaks to the bond be­tween iPhone and its user, while keep­ing in mind that an Apple prod­uct is de­signed to be uni­ver­sal in aes­thetic and ver­sa­tile in use,” shared Yoshiyuki Miyamae, de­sign di­rec­tor of MIYAKE DESIGN STUDIO. “iPhone Pocket ex­plores the con­cept of ‘the joy of wear­ing iPhone in your own way.’ The sim­plic­ity of its de­sign echoes what we prac­tice at ISSEY MIYAKE — the idea of leav­ing things less de­fined to al­low for pos­si­bil­i­ties and per­sonal in­ter­pre­ta­tion.”

“Apple and ISSEY MIYAKE share a de­sign ap­proach that cel­e­brates crafts­man­ship, sim­plic­ity, and de­light,” said Molly Anderson, Apple’s vice pres­i­dent of Industrial Design. “This clever ex­tra pocket ex­em­pli­fies those ideas and is a nat­ural ac­com­pa­ni­ment to our prod­ucts. The color palette of iPhone Pocket was in­ten­tion­ally de­signed to mix and match with all our iPhone mod­els and col­ors — al­low­ing users to cre­ate their own per­son­al­ized com­bi­na­tion. Its rec­og­niz­able sil­hou­ette of­fers a beau­ti­ful new way to carry your iPhone, AirPods, and fa­vorite every­day items.”

Crafted in Japan, iPhone Pocket fea­tures a sin­gu­lar 3D-knitted con­struc­tion that is the re­sult of re­search and de­vel­op­ment car­ried out at ISSEY MIYAKE. The de­sign drew in­spi­ra­tion from the con­cept of “a piece of cloth” and rein­ter­preted the every­day util­ity of the brand’s iconic pleated cloth­ing. The de­vel­op­ment and de­sign of iPhone Pocket un­folded in close col­lab­o­ra­tion with the Apple Design Studio, which pro­vided in­sight into de­sign and pro­duc­tion through­out.

iPhone Pocket is a spe­cial-edi­tion re­lease. The short strap de­sign is avail­able in lemon, man­darin, pur­ple, pink, pea­cock, sap­phire, cin­na­mon, and black; the long strap de­sign is avail­able in sap­phire, cin­na­mon, and black. iPhone Pocket in the short strap de­sign re­tails at $149.95 (U. S.), and the long strap de­sign at $229.95 (U.S.).

Customers can pur­chase iPhone Pocket be­gin­ning Friday, November 14, at se­lect Apple Store lo­ca­tions and ap­ple.com in France, Greater China, Italy, Japan, Singapore, South Korea, the UK, and the U. S. Just in time for the hol­i­days, Apple Specialists in stores and on­line can help cus­tomers mix and match dif­fer­ent lengths and col­ors with their iPhone, style iPhone Pocket, and pur­chase their new fa­vorite ac­ces­sory.

ISSEY MIYAKE was founded in 1971 by the name­sake de­signer, one year af­ter the es­tab­lish­ment of MIYAKE DESIGN STUDIO. The com­pany op­er­ates through an in­te­grated process for cloth­ing and re­lated items, en­com­pass­ing cre­ative con­cep­tion, de­vel­op­ment, man­u­fac­tur­ing, and re­tail op­er­a­tions. Guided by the phi­los­o­phy of “bringing un­prece­dented orig­i­nal­ity for ease in every­day life,” ISSEY MIYAKE prac­tices this com­mit­ment through prod­ucts con­ceived with so­ci­ety and the fu­ture in mind, thus en­sur­ing a last­ing cul­ture of in­no­v­a­tive de­sign and mak­ing.

Apple rev­o­lu­tion­ized per­sonal tech­nol­ogy with the in­tro­duc­tion of the Macintosh in 1984. Today, Apple leads the world in in­no­va­tion with iPhone, iPad, Mac, AirPods, Apple Watch, and Apple Vision Pro. Apple’s six soft­ware plat­forms — iOS, iPa­dOS, ma­cOS, watchOS, vi­sionOS, and tvOS — pro­vide seam­less ex­pe­ri­ences across all Apple de­vices and em­power peo­ple with break­through ser­vices in­clud­ing the App Store, Apple Music, Apple Pay, iCloud, and Apple TV. Apple’s more than 150,000 em­ploy­ees are ded­i­cated to mak­ing the best prod­ucts on earth and to leav­ing the world bet­ter than we found it.

I was eight years old when I first tried to hack the in­tro screens of Commodore-64 games. I found a BASIC pro­gram­ming book and opened it with all the en­thu­si­asm of a kid who thought he was about to un­lock the se­crets of the uni­verse. Page af­ter page of mys­te­ri­ous com­mands, strange sym­bols, promises of power.

And then I saw it:

10 X = 5

20 X = X + 1

30 PRINT X

X equals X plus one? That’s not math. That’s a lie. Zero can’t equal one. This was non­sense, and I wanted noth­ing to do with it.

Little did I know that this mo­ment of con­fu­sion would de­fine the next two decades of my life.

Years passed. I played games, broke things, learned just enough to be dan­ger­ous.

Then uni­ver­sity hap­pened. First year, sit­ting in the li­brary, and there it was: The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie. The fa­mous K&R book. The Bible.

void swap(int *a, int *b) {

int temp = *a;

*a = *b;

*b = temp;

What is `a? Why the as­ter­isks? What doesvoid` mean? Why are there two stars?*

But some­thing was dif­fer­ent this time. Instead of clos­ing the book, I started cook­ing. I did­n’t un­der­stand the recipe, but I started mix­ing in­gre­di­ents any­way.

This led to what I now call my “Linux for­mat­ting era.” I had two par­ti­tions on my home com­puter:

I for­mat­ted Linux so many times that I could do it in my sleep. Every ex­per­i­ment, every com­pi­la­tion er­ror, every seg­men­ta­tion fault was a les­son. I was learn­ing by de­stroy­ing and re­build­ing, over and over.

X = X + 1 was start­ing to make sense, but only in the most me­chan­i­cal way. I could write loops. I could in­cre­ment coun­ters. But I still did­n’t feel it.

During those years, while I was for­mat­ting Linux par­ti­tions and de­bug­ging seg­faults, I had an­other life: com­pet­i­tive bridge. I was good enough to make the na­tional team, spend­ing week­ends at tour­na­ments, play­ing hands with peo­ple who could cal­cu­late odds in their sleep.

One of my part­ners was an older en­gi­neer. Between games, af­ter a par­tic­u­larly bru­tal hand, he asked me a sim­ple ques­tion:

“How can you sum the num­bers from 1 to 10 with­out us­ing a loop?”

“Without a loop? I just learned x = x + 1. Are you kid­ding?”

Not long af­ter, I found a Prolog book. And there it was: re­cur­sion.

sum(0, 0).

sum(N, Result) :-

N > 0,

N1 is N - 1,

sum(N1, Sum1),

Result is N + Sum1.

?- sum(10, X).

X = 55.

This was­n’t X = X + 1. This was Y = X + 1. This was a re­la­tion­ship. This was math telling the truth again.

Suddenly, that en­gi­neer’s ques­tion made sense. You don’t need loops. You don’t need mu­ta­tion. You just need to de­scribe what some­thing is, not how to com­pute it step by step.

For the first time since that Commodore-64 book, I felt like some­one was talk­ing to me in a lan­guage I could un­der­stand.

Bridge tour­na­ments are funny places. You’re com­pet­ing against peo­ple one mo­ment, shar­ing sto­ries the next. During a break at one tour­na­ment, I got to talk­ing with a player from Sweden. The usual stuff at first—tough hands, bad luck, that feel­ing when you know your part­ner’s about to make a mis­take and you can’t stop them.

Then, some­how, we got to pro­gram­ming.

“Have you heard of Erlang?” he asked.

“Erlang? No. What is it?”

“It’s from Sweden. From Ericsson. It’s for tele­com sys­tems. You can build dis­trib­uted, fault-tol­er­ant sys­tems. It’s func­tional, like Prolog.”

Those were the days when we fi­nally had in­ter­net at home. I was try­ing to write a mul­ti­player socket-based bridge game for our home net­work—some­thing so my friends and I could play with­out be­ing in the same room.

Let me show you what blew my mind. What made me stay up un­til 4am, what made me skip bridge prac­tice, what made me re­al­ize I’d found some­thing spe­cial.

-module(ping).

-export([start/0, ping/​1]).

start() ->

reg­is­ter(ping, spawn(fun() -> ping(0) end)).

ping(Count) ->

re­ceive

{pong, Pong_PID} ->

io:for­mat(“Ping re­ceived pong (~p)~n”, [Count]),

Pong_PID ! {ping, self()},

ping(Count + 1)

end.

-module(pong).

-export([start/0, pong/​0]).

start() ->

reg­is­ter(pong, spawn(fun pong/​0)).

pong() ->

re­ceive

{ping, Ping_PID} ->

io:for­mat(“Pong re­ceived ping~n”),

Ping_PID ! {pong, self()},

pong()

end.

% Terminal 1

erl -sname ping -setcookie se­cret

(ping@localhost)1> c(ping).

(ping@localhost)2> ping:start().

% Terminal 2

erl -sname pong -setcookie se­cret

(pong@localhost)1> c(pong).

(pong@localhost)2> pong:start().

(pong@localhost)3> {ping, ‘ping@localhost’} ! {pong, self()}.

% Watch them talk to each other across nodes!

Two sep­a­rate Erlang nodes. On dif­fer­ent ma­chines, dif­fer­ent net­works, dif­fer­ent con­ti­nents if I wanted. And they could just… talk. No HTTP. No REST API. No se­ri­al­iza­tion headaches. Just mes­sage pass­ing. Just ac­tors do­ing their thing.

This was func­tional (no mu­ta­tion, just re­cur­sion and pat­tern match­ing) and dis­trib­uted (processes on dif­fer­ent nodes) and fault-tol­er­ant (if one crashes, the other keeps run­ning).

This was every­thing I’d been search­ing for since I was eight years old and could­n’t un­der­stand why X could equal X plus one.

I was good at bridge. National team level. But when I found Erlang, the choice was easy.

I stopped go­ing to tour­na­ments. Stopped spend­ing week­ends cal­cu­lat­ing card prob­a­bil­i­ties. This strange, beau­ti­ful lan­guage from Sweden had shown me some­thing more in­ter­est­ing than any hand of cards ever could.

Erlang was­n’t just a pro­gram­ming lan­guage. It was a phi­los­o­phy:

Let it crash (don’t try to han­dle every er­ror)

Processes are cheap (spawn mil­lions if you want)

It was func­tional pro­gram­ming and dis­trib­uted sys­tems and fault tol­er­ance all in one el­e­gant pack­age.

If you want to un­der­stand why Erlang cap­tured my imag­i­na­tion, why it changed the way I think about build­ing sys­tems, watch this:

This video, made by the peo­ple who cre­ated Erlang at Ericsson, cap­tures the spirit of what made me fall in love. The phi­los­o­phy. The el­e­gance. The sheer fun of build­ing sys­tems that don’t fall apart.

This is where I’ll share what I’ve learned over 30+ years of build­ing soft­ware sys­tems. From that con­fused 8-year-old clos­ing a BASIC book to now.

I’ll write about Erlang, Elixir, func­tional pro­gram­ming, dis­trib­uted sys­tems, and all the things I wish some­one had ex­plained to me when I was young.

P. S.: Next posts will cover Clojure (JVM—you know why), then Scala, F#, and back to Elixir/Erlang with prac­ti­cal pat­terns and war sto­ries. Stay tuned.

During the course of a reg­u­lar work­ing day, I re­ceive a lot of screen­shots like this from well-mean­ing col­leagues:

It’s al­most al­ways in a chat about some is­sue that oc­curred in the code, or per­haps code that’s some­how re­lated to the code in the screen­shot, or… well, how am I sup­posed to even know? Upon see­ing this code, I might think, “How is slug de­fined? Is slug be­ing used to cre­ate the baseUrl? Why is the do­main name hard-coded in that URL? What hap­pens if an ex­cep­tion is thrown? What mod­ule is this code even in?”

I have to ei­ther very care­fully type some of the code into a search box or (these days) get my cod­ing agent to find the rel­e­vant mod­ule for me.

Why could­n’t my col­league have just used copy & paste? I could have seen a bit more of the con­text, even if the same lines were se­lected, and I could copy-and-paste that text into my IDE’s search func­tion so much more eas­ily.

In fact, why could­n’t they just send me the file, or even a link to the file (since every­body and their dog use GitHub, any­way).

It gets worse. Sometimes, I’ll get a screen­shot of an er­ror log. “Hey, Paul, the build is fail­ing. Can you look at this?”

What were you build­ing? What line did it fail on? What even was the er­ror?

Of course, if I do a full re­build of every­thing on my work­sta­tion, it’ll suc­ceed.

It would have been SO easy to just copy all of the er­ror log, or even dump the log into a file, and just send me that.

Please, don’t take screen­shots of text un­less it’s to demon­strate a cos­metic is­sue re­lated to the dis­play of the text, or there is truly some­thing rel­e­vant about the con­tent of the screen­shot that would be lost in a purely tex­tual con­text.

SoftBank said Tuesday it has sold its en­tire stake in U. S. chip­maker Nvidia for $5.83 bil­lion as the Japanese gi­ant looks to cap­i­tal­ize on its “all in” bet on ChatGPT maker OpenAI.

The firm said in its earn­ings state­ment that it sold 32.1 mil­lion Nvidia shares in October. It also dis­closed that it sold part of its T-Mobile stake for $9.17 bil­lion.

“We want to pro­vide a lot of in­vest­ment op­por­tu­ni­ties for in­vestors, while we can still main­tain fi­nan­cial strength,” said SoftBank’s chief fi­nan­cial of­fi­cer, Yoshimitsu Goto, dur­ing an in­vestor pre­sen­ta­tion.

“So through those op­tions and tools we make sure that we are ready for fund­ing in a very safe man­ner,” he said in com­ments trans­lated by the com­pany, adding that the stake sales were part of the fir­m’s strat­egy for “asset mon­e­ti­za­tion.”

The sale of Nvidia shares, par­tial sale of T-Mobile shares and the mar­gin loan on SoftBank’s hold­ing in Arm, are all “sources of cash that will be used to fund the $22.5 bil­lion in­vest­ment in OpenAI,” a per­son fa­mil­iar with the mat­ter told CNBC. They added that this cash will fund other pro­jects the firm is work­ing on such as its ac­qui­si­tion of ABB’s ro­bot­ics unit.

The of­fload­ing of the Nvidia stake had noth­ing to do with con­cerns about ar­ti­fi­cial in­tel­li­gence val­u­a­tions, the per­son said.

While the Nvidia exit may come as a sur­prise to some in­vestors, it’s not the first time SoftBank has cashed out of the American AI chip dar­ling.

SoftBank’s Vision Fund was an early backer of Nvidia, re­port­edly amass­ing a $4 bil­lion stake in 2017 be­fore sell­ing all of its hold­ings in January 2019. Despite its lat­est sale, SoftBank’s busi­ness in­ter­ests re­main heav­ily in­ter­twined with Nvidia’s.

With Firefox 145, we’re rolling out ma­jor pri­vacy up­grades that take on browser fin­ger­print­ing — a per­va­sive and hid­den track­ing tech­nique that lets web­sites iden­tify you even when cook­ies are blocked or you’re in pri­vate brows­ing. These pro­tec­tions build on Mozilla’s long-term goal of build­ing a health­ier, trans­par­ent and pri­vacy-pre­serv­ing web ecosys­tem.

Fingerprinting builds a se­cret dig­i­tal ID of you by col­lect­ing sub­tle de­tails of your setup — rang­ing from your time zone to your op­er­at­ing sys­tem set­tings — that to­gether cre­ate a “fingerprint” iden­ti­fi­able across web­sites and across browser ses­sions. Having a unique fin­ger­print means fin­ger­print­ers can con­tin­u­ously iden­tify you in­vis­i­bly, al­low­ing bad ac­tors to track you with­out your knowl­edge or con­sent. Online fin­ger­print­ing is able to track you for months, even when you use any browser’s pri­vate brows­ing mode.

Protecting peo­ple’s pri­vacy has al­ways been core to Firefox. Since 2020, Firefox’s built-in Enhanced Tracking Protection (ETP) has blocked known track­ers and other in­va­sive prac­tices, while fea­tures like Total Cookie Protection and now ex­panded fin­ger­print­ing de­fenses demon­strate a broader goal: pri­or­i­tiz­ing your on­line free­dom through in­no­v­a­tive pri­vacy-by-de­sign. Since 2021, Firefox has been in­cre­men­tally en­hanc­ing anti-fin­ger­print­ing pro­tec­tions tar­get­ing the most com­mon pieces of in­for­ma­tion col­lected for sus­pected fin­ger­print­ing uses.

Today, we are ex­cited to an­nounce the com­ple­tion of the sec­ond phase of de­fenses against fin­ger­print­ers that linger across all your brows­ing but aren’t in the known tracker lists. With these fin­ger­print­ing pro­tec­tions, the amount of Firefox users track­able by fin­ger­print­ers is re­duced by half.

Drawing from a global analy­sis of how real peo­ple’s browsers can be fin­ger­printed, Mozilla has de­vel­oped new, unique and pow­er­ful de­fenses against real-world fin­ger­print­ing tech­niques. Firefox is the first browser with this level of in­sight into fin­ger­print­ing and the most ef­fec­tive de­ployed de­fenses to re­duce it. Like Total Cookie Protection, one of our most in­no­v­a­tive pri­vacy fea­tures, these new de­fenses are de­but­ing in Private Browsing Mode and ETP Strict mode ini­tially, while we work to en­able them by de­fault.

These fin­ger­print­ing pro­tec­tions work on mul­ti­ple lay­ers, build­ing on Firefox’s al­ready ro­bust pri­vacy fea­tures. For ex­am­ple, Firefox has long blocked known track­ing and fin­ger­print­ing scripts as part of its Enhanced Tracking Protection.

Beyond block­ing track­ers, Firefox also lim­its the in­for­ma­tion it makes avail­able to web­sites — a pri­vacy-by-de­sign ap­proach — that pre­emp­tively shrinks your fin­ger­print. Browsers pro­vide a way for web­sites to ask for in­for­ma­tion that en­ables le­git­i­mate web­site fea­tures, e.g. your graph­ics hard­ware in­for­ma­tion, which al­lows sites to op­ti­mize games for your com­puter.  But track­ers can also ask for that in­for­ma­tion, for no other rea­son than to help build a fin­ger­print of your browser and track you across the web.

Since 2021, Firefox has been in­cre­men­tally ad­vanc­ing fin­ger­print­ing pro­tec­tions, cov­er­ing the most per­va­sive fin­ger­print­ing tech­niques. These in­clude things like how your graph­ics card draws im­ages, which fonts your com­puter has, and even tiny dif­fer­ences in how it per­forms math. The first phase plugged the biggest and most-com­mon leaks of fin­ger­print­ing in­for­ma­tion.

Recent Firefox re­leases have tack­led the next-largest leaks of user in­for­ma­tion used by on­line fin­ger­print­ers. This ranges from strength­en­ing the font pro­tec­tions to pre­vent­ing web­sites from get­ting to know your hard­ware de­tails like the num­ber of cores your proces­sor has, the num­ber of si­mul­ta­ne­ous fin­gers your touch­screen sup­ports, and the di­men­sions of your dock or taskbar. The full list of de­tailed pro­tec­tions is avail­able in our doc­u­men­ta­tion.

Our re­search shows these im­prove­ments cut the per­cent­age of users seen as unique by al­most half.

Firefox’s new pro­tec­tions are a bal­ance of dis­rupt­ing fin­ger­print­ers while main­tain­ing web us­abil­ity. More ag­gres­sive fin­ger­print­ing block­ing might sound bet­ter, but is guar­an­teed to break le­git­i­mate web­site fea­tures. For in­stance, cal­en­dar, sched­ul­ing, and con­fer­enc­ing tools le­git­i­mately need your real time zone. Firefox’s ap­proach is to tar­get the most leaky fin­ger­print­ing vec­tors (the tricks and scripts used by track­ers) while pre­serv­ing func­tion­al­ity many sites need to work nor­mally. The end re­sult is a set of lay­ered de­fenses that sig­nif­i­cantly re­duce track­ing with­out down­grad­ing your brows­ing ex­pe­ri­ence. More de­tails are avail­able about both the spe­cific be­hav­iors and how to rec­og­nize a prob­lem on a site and dis­able pro­tec­tions for that site alone, so you al­ways stay in con­trol. The goal: strong pri­vacy pro­tec­tions that don’t get in your way.

If you open a Private Browsing win­dow or use ETP Strict mode, Firefox is al­ready work­ing be­hind the scenes to make you harder to track. The lat­est phase of Firefox’s fin­ger­print­ing pro­tec­tions marks an im­por­tant mile­stone in our mis­sion to de­liver: smart pri­vacy pro­tec­tions that work au­to­mat­i­cally — no fur­ther ex­ten­sions or con­fig­u­ra­tions needed. As we head into the fu­ture, Firefox re­mains com­mit­ted to fight­ing for your pri­vacy, so you get to en­joy the web on your terms. Upgrade to the lat­est Firefox and take back con­trol of your pri­vacy.

Take con­trol of your in­ter­net

“If you want to go fast, go alone; if you want to go far, go to­gether”

This phrase will slowly kill your com­pany and I’m here to prove it.

Imagine you are dri­ving a car. It’s of­ten use­ful to have some­one give you di­rec­tions, point out gas sta­tions, and rec­om­mend stops for snacks. This is a help­ful amount of col­lab­o­ra­tion.

An un­help­ful amount of col­lab­o­ra­tion is get­ting out of your car to ask pedes­tri­ans if they like your car, swap­ping dri­vers every 10 min­utes, or hav­ing some­one con­stantly com­ment­ing on your dri­ving.

In the first sce­nario, you get the right amount of feed­back to get to your des­ti­na­tion as fast as pos­si­ble. In the sec­ond, you get more feed­back, but it slows you down. You run the risk of not mak­ing it to the place you want to go.

The sec­ond sce­nario is also the one most star­tups (or com­pa­nies, re­ally) end up in be­cause of ✨ col­lab­o­ra­tion ✨.

As PostHog grows, I’ve seen more and more col­lab­o­ra­tion that does­n’t add value or adds far too lit­tle value for the time lost col­lab­o­rat­ing. So much so we made “collaboration sucks” the topic of the week dur­ing a re­cent com­pany all hands.

“You’re the dri­ver” is a key value for us at PostHog. We aim to hire peo­ple who are great at their jobs and get out of their way. No dead­lines, min­i­mal co­or­di­na­tion, and no man­agers telling you what to do.

In re­turn, we ask for ex­tra­or­di­nar­ily high own­er­ship and the abil­ity to get a lot done by your­self. Marketers ship code, sales­peo­ple an­swer tech­ni­cal ques­tions with­out backup, and prod­uct en­gi­neers work across the stack.

This means there is al­most al­ways some­one bet­ter at what you are do­ing than you are. It is tempt­ing to get them, or any­body re­ally, in­volved and ✨ col­lab­o­rate ✨, but col­lab­o­ra­tion forces the dri­ver to slow down and ex­plain stuff (background, con­text, their think­ing).

This ten­dency re­veals it­self in a few key phrases:

* “Would love to hear Y’s take on this”

* “We should work with Z on this”

This some­times leads to valu­able in­sights, but al­ways slows the dri­ver down. It erodes their mo­ti­va­tion, con­fi­dence, and ef­fec­tive­ness, and ul­ti­mately leads us to ship less.

Everyone is to blame.

* People want to be help­ful. For ex­am­ple, when some­one posts their work-in-progress in Slack, oth­ers feel obliged to give feed­back be­cause we have a cul­ture of feed­back.

* On the flip side, peo­ple don’t ask for feed­back from spe­cific peo­ple be­cause it does­n’t feel in­clu­sive, even though it would help.

* People aren’t spe­cific enough about what feed­back they need. This cre­ates more space for col­lab­o­ra­tion to sneak in. A dis­cus­sion about build­ing a spe­cific fea­ture can de­volve into reeval­u­at­ing the en­tire prod­uct roadmap if you let it.

* When some­one has a good idea, the re­sponse of­ten de­faults to “let’s dis­cuss” rather than “ok, do it.” As proof, we have 175 men­tions of “let’s dis­cuss” in Slack.

* People just want to talk about stuff be­cause they can’t be both­ered to act on it. We drift from our ideal of a pull re­quest to an is­sue/​RFC to Slack (we are mostly here) to “let’s dis­cuss”.

* It’s not clear who the owner is (or no one wants to own what’s be­ing dis­cussed).

* It is an­noy­ing, but some­times a sin­gle per­son can’t ship cer­tain things front to back to a high-enough qual­ity and we can’t just ship and it­er­ate. We can fix bro­ken code, but we can’t re­send a newslet­ter.

So if col­lab­o­ra­tion is your en­emy, how do you de­feat it? Here’s what we say:

* Every time you see ✨ col­lab­o­ra­tion ✨ hap­pen­ing, speak up and de­stroy it. Say “there are too many peo­ple in­volved. X, you are the dri­ver, you de­cide.” (This is a great way to make friends btw).

* Tag who you specif­i­cally want in­put from and what you want from them, not just throw things out there into the void.

* Prefer to give feed­back af­ter some­thing has shipped (but be­fore the next it­er­a­tion) rather than re­view­ing it be­fore it ships. Front-loading your feed­back can turn it into a quasi-ap­proval process.

* If you are a team lead, or leader of leads, who has been asked for feed­back, con­sider be­ing more you can just do stuff.

* When it’s your thing, you are the “informed cap­tain.” Listen to feed­back, but know it’s ul­ti­mately up to you to de­cide what to do, not the peo­ple giv­ing feed­back.

Unfortunately for me, not all col­lab­o­ra­tion can be rooted out, and even I will ad­mit that some col­lab­o­ra­tion is use­ful. Ian and Andy edited this newslet­ter af­ter all.

The point is, if you aren’t ac­tively at­tempt­ing to col­lab­o­rate less, you are prob­a­bly col­lab­o­rat­ing too much by de­fault and hurt­ing your abil­ity to go far, fast.

Words by Charles Cook, who also hates sparkling wa­ter, pre­sum­ably be­cause the bub­bles are too col­lab­o­ra­tive.

Canada’s out­break be­gan last October, with health of­fi­cials at­tribut­ing it to fewer peo­ple be­ing vac­ci­nated against measles.

The US, how­ever, risks los­ing its sta­tus as well if it does not stop an on­go­ing out­break by January. Related cases have now been re­ported in Utah, Arizona and South Carolina.

Because Canada is no longer deemed measles-free, the Americas re­gion as a whole has lost its elim­i­na­tion sta­tus, al­though in­di­vid­u­ally the other coun­tries are still con­sid­ered to have stamped out the dis­ease.

Canada has lost its measles elim­i­na­tion sta­tus, said the Pan American Health Organization (Paho) on Monday, af­ter fail­ing to curb an out­break of the virus for 12 con­sec­u­tive months.

Canada’s out­break be­gan last October, with health of­fi­cials at­tribut­ing it to fewer peo­ple be­ing vac­ci­nated against measles.

The US, how­ever, risks los­ing its sta­tus as well if it does not stop an on­go­ing out­break by January. Related cases have now been re­ported in Utah, Arizona and South Carolina.

Because Canada is no longer deemed measles-free, the Americas re­gion as a whole has lost its elim­i­na­tion sta­tus, al­though in­di­vid­u­ally the other coun­tries are still con­sid­ered to have stamped out the dis­ease.

Canada has lost its measles elim­i­na­tion sta­tus, said the Pan American Health Organization (Paho) on Monday, af­ter fail­ing to curb an out­break of the virus for 12 con­sec­u­tive months.

At a news con­fer­ence on Monday, Paho of­fi­cials ap­pealed to Canadian gov­ern­ments and the pub­lic to ramp up vac­ci­na­tions, not­ing that 95% of the pop­u­la­tion needs to be im­mu­nised to stop the spread of measles.

“This loss rep­re­sents a set­back, but it is also re­versible,” said Dr Jarbas Barbosa, the health or­gan­i­sa­tion’s di­rec­tor.

The Public Health Agency of Canada said in its own state­ment that it is col­lab­o­rat­ing with Paho and re­gional health au­thor­i­ties to im­prove vac­cine rates and strengthen data shar­ing.

Prior to Monday, Canada had been de­clared measles-free for three decades. It can re­gain its elim­i­na­tion sta­tus if it can curb spread of the measles strain as­so­ci­ated with the cur­rent out­break for at least 12 months.

The coun­try has re­ported more than 5,000 measles cases in 2025, with most of them in the provinces of Ontario and Alberta. That is three times the 1,681 cases re­ported in the US, de­spite Canada’s much smaller pop­u­la­tion.

The bulk of the out­break has been in “under-vaccinated com­mu­ni­ties”, Canadian health of­fi­cials have said.

Vaccination rates in Alberta, one of the provinces hit hard by the out­break, are lower than the 95% thresh­old, ac­cord­ing to provin­cial data.

One re­gion, the South Zone, lo­cated south of the province’s largest city Calgary, re­ported only 68% of chil­dren un­der the age of two were im­mu­nised against measles as of 2024.

The MMR vac­cine is the most ef­fec­tive way to fight off the dan­ger­ous virus, which can lead to pneu­mo­nia, brain swelling and death. The jabs are 97% ef­fec­tive and also im­mu­nise against mumps and rubella.

Canadian im­mu­nol­o­gist Dawn Bowdish told the BBC that there are many rea­sons be­hind the low vac­ci­na­tion rates, in­clud­ing lack of ac­cess to gen­eral prac­ti­tion­ers, the ab­sence of a na­tional vac­ci­na­tion reg­istry that Canadians could use to check their im­mu­ni­sa­tion sta­tus, and the spread of mis­in­for­ma­tion.

She also noted a lack of pub­lic health out­reach to com­mu­ni­ties that have been hes­i­tant or dis­trust­ful of vac­cines.

“It high­lights how many of our sys­tems broke down to get us to this point,” said Prof Bowdish of McMaster University in Hamilton, Ontario.

“I hope that it will be a wake-up call to pol­i­cy­mak­ers, and that it will be enough of a na­tional em­bar­rass­ment that we rem­edy some of those sys­temic is­sues,” she added

The Americas is the first and only re­gion in the world to have been de­clared measles-free, start­ing in 2016. That sta­tus was then briefly lifted af­ter out­breaks in Venezuela and Brazil. The two coun­tries re­gained elim­i­na­tion sta­tus in 2024, in part through co­or­di­nated vac­cine ef­forts where mil­lions were im­mu­nised.

But measles has since spread again, now in North America.

Along with Canada and the United States, Mexico has also seen a surge in cases and now ranks among the top 10 coun­tries with the largest out­breaks, ac­cord­ing to the US Centers for Disease Control and Prevention.

The R47 is a pow­er­ful, RPN-based pro­gram­ma­ble sci­en­tific cal­cu­la­tor with an ex­ten­sive fea­ture set. Its soft­ware has been re­fined over many years, born from the vi­sion of a dream cal­cu­la­tor de­vel­oped by a team of en­gi­neers and math­e­mati­cians, all ded­i­cated cal­cu­la­tor en­thu­si­asts.

Community-developed and man­u­fac­tured by SwissMicros, the R47 runs firmware that is func­tion­ally iden­ti­cal to that of the C47, which of­fers a way to trans­form a DM42n into a fea­ture-rich RPN cal­cu­la­tor us­ing a ded­i­cated key­pad over­lay.

The C47/R47 firmware orig­i­nated as a fork of the WP43 pro­ject, it­self de­rived from the WP34S. A core com­po­nent car­ried through this lin­eage is the dec­Num­ber li­brary by Mike Cowlishaw, also used in GCC for pre­cise dec­i­mal arith­metic.

Inspired by the HP‑41C and HP‑42S, the R47 builds on this foun­da­tion with a re­designed key­pad fea­tur­ing two shift keys, pre­serv­ing a fa­mil­iar feel while be­ing en­tirely new in ex­e­cu­tion.

* Advanced Math Capabilities:Provides 34 dig­its of pre­ci­sion; ex­po­nents to ±6144; up to 1000 named vari­ables.

* Provides 34 dig­its of pre­ci­sion; ex­po­nents to ±6144; up to 1000 named vari­ables.

* Programming and Editing:

* Engineering and Utilities:Conduct fi­nan­cial and date-based cal­cu­la­tions, in­clud­ing time value of money op­er­a­tions.Per­form date and time math as well as built-in clock.Equa­tion writer with sup­port for solv­ing, nu­meric in­te­gra­tion and de­riv­a­tives, and ba­sic plot­ting.

* Conduct fi­nan­cial and date-based cal­cu­la­tions, in­clud­ing time value of money op­er­a­tions.

* Perform date and time math as well as built-in clock.

* Equation writer with sup­port for solv­ing, nu­meric in­te­gra­tion and de­riv­a­tives, and ba­sic plot­ting.

* Display and User Interface:Features a high-res­o­lu­tion dis­play with 4 stack lev­els, 3 rows of menus, and sta­tus bar al­ways shown.

* Features a high-res­o­lu­tion dis­play with 4 stack lev­els, 3 rows of menus, and sta­tus bar al­ways shown.

* Data Management:I/O to built-in flash mem­ory or via USB for back­ing up and restor­ing states, pro­grams, and con­fig­u­ra­tion.

* I/O to built-in flash mem­ory or via USB for back­ing up and restor­ing states, pro­grams, and con­fig­u­ra­tion.

AutoGPT is the vi­sion of ac­ces­si­ble AI for every­one, to use and to build on. Our mis­sion is to pro­vide the tools, so that you can fo­cus on what mat­ters.