I’ve used Windows for as long as I’ve been alive. At 6 years old, my first com­puter was a Windows 98 ma­chine, with an Athlon XP 1900+ (Palomino core) and a GeForce 440 MX, blessed with a gen­er­ous 256 megabytes of RAM.

Looking back, I kinda got scammed with that graph­ics card, but what could I do? I was a silly kid. (The miss­ing shader sup­port came back to bite me in the ass)

Also, is it weird that I still re­mem­ber the specs of my first com­puter, 22 years later?

Anyway, Windows has been fa­mil­iar and com­fort­able. I knew all the workarounds and how to ex­tract max­i­mum ef­fi­ciency from it.

I was a happy user, for over 20 years, and Windows has been my go-to for every­thing com­puter-re­lated.

Even af­ter be­com­ing a soft­ware de­vel­oper and us­ing a mac­book, I’d still find my­self reach­ing for Windows at times.

That is, un­til Microsoft de­cided to turn it into some­thing com­pletely un­rec­og­niz­able and un­us­able.

I think it started with the Windows 10 full-screen ads.

You know, those friendly sug­ges­tions telling you to try OneDrive or to “use the rec­om­mended browser set­tings” (reads as “please try Edge and OneDrive, we’re des­per­ate”).

Actually, scratch that, I think it re­ally started with the non-con­sen­sual up­dates:

Oh you’re do­ing work? That’s so cute… we’re gonna close what­ever apps you had open, be­cause we’re up­dat­ing now. We own your com­puter.

You had un­saved work? Too bad, it’s gone, get bent.

At first I ig­nored it, and car­ried on as nor­mal. Sure, I’d get mad from time to time and I’d com­plain.

But hey, noth­ing beats the con­ve­nience of be­ing able to have all of your ap­pli­ca­tions in one place

My break­ing point came with the 24H2 up­date. It in­stalled on my sys­tem with­out my con­sent, like any other ma­jor up­date. I knew there were prob­lems with it, peo­ple were al­ready com­plain­ing on Reddit, so I just post­poned it, and kept post­pon­ing it.

All it took was for me to leave my com­puter on and un­at­tended for a while, and BOOM, just like that - the ma­jor OS up­date that no­body wanted, it was on my com­puter.

As soon as 24H2 landed on my ma­chine, I en­coun­tered a bug so bizarre I thought I was los­ing my mar­bles.

If Chrome was po­si­tioned un­der any other win­dow, it would start hav­ing what I can only de­scribe as a vi­sual seizure.

Here’s Ableton Live with Chrome (Reddit) un­der it:

Worse, there was a de­cent chance this would trig­ger a full sys­tem lock, leav­ing me smash­ing my desk in im­po­tent rage. I shit you not.

I tried to roll­back. The roll­back failed with an er­ror. I re­in­stalled Windows. The bug per­sisted.

Like dig­i­tal her­pes, I just could­n’t get rid of it.

The so­lu­tion? Installing an Insider build. Yes, the so­lu­tion to Microsoft’s bro­ken sta­ble re­lease was to use their un­sta­ble re­lease.

For the Windows Defenders (see what I did there?), I tried unin­stalling the dis­play dri­vers with DDU, and test­ing other ver­sions. It did­n’t help.

Either I stayed for­ever on the older build, or I’d have to deal with this. And don’t tell me to for­ever dis­able up­dates, I’ll com­pletely lose it.

The Insider build worked…sort of. But now I had a new bug: Chrome would ran­domly lock up for about 30 sec­onds when a video was play­ing. My op­tions were to wait it out or press Ctrl+Alt+Delete and Esc to force my way back to a work­ing browser. After some dig­ging, I dis­cov­ered this was caused by an NVIDIA-Microsoft dri­ver in­com­pat­i­bil­ity.

I’ve found out that the flick­ers and the chrome lock-up is­sues are likely caused by the Multiplane Overlay (MPO) pipeline. Microsoft blamed NVIDIA for not cor­rectly im­ple­ment­ing it in their dri­vers. NVIDIA blamed Microsoft. What’s clear is that if you were fac­ing this is­sue, you were es­sen­tially screwed be­cause these 2 com­pa­nies would just pass the hot potato to each other.

I should men­tion that this bug per­sisted even af­ter I went off the Insider build and on 25H2. And when I posted on r/​Mi­crosoft, they just deleted it.

The lat­est and great­est OS surely can­not be bro­ken be­yond re­pair, surely I’m us­ing my PC wrong.

So there I was, fi­nally grasp­ing the re­al­ity of what you’re up against, as a Windows user:

* Updates that in­stall with­out per­mis­sion and brick my sys­tem

* Copilot and OneDrive ads ap­pear­ing in every cor­ner of the OS

* Copilot but­tons every­where, com­ing for every ap­pli­ca­tion

* Can’t even make a lo­cal ac­count with­out hack­ing the setup with Rufus (they even re­moved the ter­mi­nal workaround)

* Zero ac­tion­able fixes or even an aknowl­edg­ment of their fuck­ups

People of­ten say Linux is “too much work.”.

And I agree. They’re com­pletely jus­ti­fied to com­plain. There’s the doc­u­men­ta­tion page div­ing, the fo­rums, the red­dit threads. And, most im­por­tantly, you have to ba­si­cally rewire your brain and stop ex­pect­ing it to be­have like Windows used to.

But I looked at the list above and re­al­ized: Windows is now also too much work.

And the dif­fer­ence with Windows is that you’re go­ing to do all that work while ac­tively fight­ing your com­puter only for it to be un­done when the next sur­prise up­date comes and ru­ins every­thing.

You might be think­ing “just dis­able up­dates, man” or “just in­stall LTSC”, or “just run some ran­dom de­bloat script off of GitHub”.

Why? Why would I jump through all these hoops? I’d rather put in the ef­fort for an OS that knows what con­sent is and re­spects me as a user.

To set the stage: I’m a soft­ware de­vel­oper and a mu­si­cian.

As you can imag­ine, I was le­git­i­mately wor­ried about app sup­port on Linux, and how it would dis­trupt my work­flow.

But af­ter Chrome crash­ing for the 10000th time, I said “enough is enough”, and de­cided to go big. I in­stalled CachyOS, a per­for­mance-fo­cused Arch-based dis­tri­b­u­tion, on my main ma­chine (9800X3D, RTX 5080).

It was­n’t a pain­less process. In fact, sleep mode was bro­ken from the start, and my sys­tem would fail to de­tect the mon­i­tor af­ter wak­ing up.

What’s more, Ableton Live does not have a na­tive Linux build, only Windows and ma­cOS. So I could­n’t use it any­more, at least not with­out fuck­ing around with Wine (which does­n’t fully sup­port it), or with­out keep­ing a Windows VM and tak­ing an L on au­dio la­tency.

But un­like Windows, on CachyOS I could ac­tu­ally fix my NVIDIA woes by fol­low­ing this thread on their fo­rum.

All I had to do was add the NVIDIA mod­ules to mkinitc­pio. One con­fig change, a com­mand to re­build the initramfs, and prob­lem solved.

I also found a good na­tive al­ter­na­tive to Ableton Live - Bitwig Studio, which both­ered to re­lease a na­tive Linux Build.

Thanks to the con­stant progress that was made with Pipewire, I’m get­ting au­dio la­tency on par with Mac OS, and lower than Windows. And my work­flow did­n’t even change that much, since Bitwig is made by ex-Able­ton de­vel­op­ers that seem to give a shit.

As for my de­vel­op­ment tools, on Windows you al­ready ac­cept the fact that you WILL use WSL or docker, so re­al­is­ti­cally I just cut the bro­ken mid­dle­man.

Now com­pare that to the Windows fuck­ery above.

If 3 years ago you would have told me that Microsoft would sin­gle­hand­edly sab­o­tage their own OS, do­ing more Linux mar­ket­ing than the most neck­bearded Linux fan­boy (or the most fem­boy Thinkpad en­joyer), I’d have laughed in your face, called you delu­sional, and then hurled some more in­sults your way.

Yet here we are, I’ve been dual-boot­ing CachyOS for over a year, and in the last month I’ve been us­ing it ex­clu­sively.

If you’re think­ing about mak­ing the switch, I’d rec­om­mend you do a lit­tle re­search first.

Look up the trade­offs be­tween a rolling re­lease dis­tro and a sta­ble re­lease, it might just save you a headache.

For me, the fast up­dates of Cachy/Arch are a good thing, but you can imag­ine that you are ef­fec­tively trad­ing sta­bil­ity for new fea­tures.

So what is the ac­tual state of Linux in 2026, from my hon­est per­spec­tive?

All ma­jor browsers (Chrome, Firefox, Edge, Brave) have na­tive Linux builds. Full sup­port. No com­pro­mises.

Video play­back works flaw­lessly, with hard­ware ac­cel­er­a­tion even. On AMD, on NVidia and yes, on Intel too.

Linux is the pre­ferred plat­form for de­vel­op­ment.

Better ter­mi­nal sup­port, na­tive pack­age man­agers, Docker runs na­tively with­out the WSL over­head, and your pro­duc­tion servers are prob­a­bly run­ning Linux any­way.

Hell, even Microsoft has their own Linux dis­tro, Azure Linux (Formerly CBL-Mariner).

This is where peo­ple as­sume Linux falls short. And they’re right, but not com­pletely:

* Adobe Suite: Runs via Winboat. Far from per­fect (no video ac­cel­er­a­tion, laggy at times), but func­tional

So while con­tent cre­ation is vi­able, the com­pro­mises might be deal­break­ers.

* Audio la­tency: Thanks to PipeWire, Linux au­dio la­tency is ac­tu­ally lower than Windows

Here’s where things get in­ter­est­ing. The per­cep­tion is that gam­ing on Linux is a no-go. In 2026, that’s in­creas­ingly un­true:

* Proton/Wine: Pretty much all games with­out ker­nel-level anti-cheat work out of the box through Steam’s Proton com­pat­i­bil­ity layer

* Performance: For AMD GPUs, gam­ing per­for­mance is on par with Windows, on av­er­age

* NVIDIA: There was a 10-30% per­for­mance penalty on Intel/NVIDIA GPU se­tups, but re­cent Vulkan ex­ten­sions are tak­ing care of that.

NVIDIA has re­leased beta dri­vers mak­ing use of these im­prove­ments, and once Wine/DXVK/Proton are up­dated to make use of the ex­ten­sions, the per­for­mance delta should be es­sen­tially gone

The only real lim­i­ta­tion is that some games with anti-cheat like Valorant, Call of Duty or League of Legends won’t run. But hon­estly I think not be­ing able to launch League of Legends is ac­tu­ally a fea­ture - one fi­nal rea­son to in­stall Linux.

It’s not all bad, though. Arc Raiders makes use of Easy Anti-Cheat, yet runs flaw­lessly. In fact, I’ve been play­ing it like a mad­man. It goes to show that if the de­vel­op­ers want to, it’s pos­si­ble.

Still falls short com­pared to Windows and Mac OS (Autodesk, I’m look­ing at you).

The sil­ver lin­ing is that Blender has a na­tive build. So if it’s your main ap­pli­ca­tion, you’re good to go.

Basic op­er­a­tions are so much faster on Linux. Opening di­rec­to­ries, launch­ing ap­pli­ca­tions, sys­tem re­spon­sive­ness. It’s like your com­puter took a line of coke, and is now ready to work.

No more wait­ing for the Start menu to de­cide it wants to open. No more File Explorer hang­ing when you need it the most.

Since we’re on the topic of Linux im­prove­ments, I want to ad­dress the ele­phant in the room - peo­ple who keep say­ing “I want to switch”, but keep mov­ing the goal­posts:

“Okay, but what about Y?”

If you’re al­ways find­ing the next rea­son not to switch, you’re not look­ing for so­lu­tions, you’re look­ing for ex­cuses to stay com­pla­cent.

I was that per­son, so I would know.

At the same time, I want to take it down a notch and say that there are still plenty of use cases (Especially cre­ative work, and like stated pre­vi­ously, 3D mod­el­ling and also Game Dev) where it sim­ply does­n’t make sense to switch.

So if you’re in that sce­nario, don’t feel pres­sured, just wait for things to im­prove.

And if you don’t plan on ever switch­ing, more power to you.

I’m not here to judge, just here to vent my Microsoft frus­tra­tions.

And I did­n’t re­ally want to switch ei­ther, be­cause who wants to re-learn how their com­puter should be op­er­ated from scratch? What I re­ally wanted was for Windows to work, but Microsoft did­n’t.

While I’m en­joy­ing my new Linux setup, Windows 11 is hav­ing a mis­er­able year, and we’re only a month in!

According to Windows Latest, there were over 20 ma­jor up­date prob­lems in 2025 alone, and 2026 is start­ing off strong, with the January up­date caus­ing black screens and Outlook crashes.

Here’s a quick 2025 Spotify Wrapped of the bugs Windows users dealt with:

* The Copilot app ac­ci­den­tally get­ting deleted (okay, this is ac­tu­ally a good change for once)

And the com­pa­ny’s re­sponse? Crickets. They’re busy boast­ing that 30% of their code is cur­rently be­ing writ­ten by AI. Don’t worry, Microsoft, we can def­i­nitely tell.

For the re­main­der of 2026, Microsoft is cook­ing up a big one: re­plac­ing more and more na­tive apps with React Native. But don’t let the name fool you, it’s never go­ing to be as close to na­tive as the real thing. These are pro­jects de­signed to be eas­ily ported across any ma­chine and ar­chi­tec­ture by mak­ing use of JavaScript.

And each one spawns its own Chromium process, gob­bling up your RAM so you can en­joy the priv­i­lege of open­ing the Settings app. And each one of these apps cre­ates an in­stance of V8 or Hermes per app, which adds ad­di­tional over­head (RAM + CPU). I’d ar­gue you do not need that over­head just to open a Settings app.

I could maybe un­der­stand this for a weather wid­get. But when it’s com­ing for core sys­tem apps, I think it’s just lazy.

I’m gonna go full con­spir­acy nut here, but I bet it’s be­cause it’s eas­ier for LLMs to write JavaScript, and Microsoft can’t be asked to pay ac­tual hu­mans to write (and test) proper na­tive code.

Meanwhile, en­tire gov­ern­ments are aban­don­ing Windows for Linux, the term “Microslop” is trend­ing on so­cial me­dia, and Windows 11′s rep­u­ta­tion is at its low­est point ever.

So here I am. Fully switched to Linux.

Not be­cause I’m some open-source ide­al­ist or com­mand-line war­rior (I’m just some guy), but be­cause Microsoft turned into Microslop.

Recently, Microsoft CEO Satya Nadella wrote a blog post ask­ing peo­ple to stop call­ing AI-generated con­tent “slop” and to think of AI as “bicycles for the mind.”

“[Nvidia CEO] Jensen Huang Is Begging You to Stop Being So Negative About AI” — Headline from Gizmodo

Guys, enough is enough. Bullying is a se­ri­ous is­sue, and it’s time for me to speak out. There’s an ex­tremely hurt­ful nar­ra­tive go­ing around that my prod­uct, a rev­o­lu­tion­ary new tech­nol­ogy that ex­ists to scam the el­derly and make you dis­trust any­thing you see on­line, is harm­ful to so­ci­ety. This slan­der is to­tally un­war­ranted, and I would re­ally ap­pre­ci­ate it if every­one would stop be­ing so mean about this thing I just in­vested a bil­lion dol­lars in.

As some­one who des­per­ately needs this tech­nol­ogy to work out, I can hon­estly say it is the most es­sen­tial tool ever cre­ated in all of hu­man his­tory. Don’t mer­ci­lessly ridicule it just be­cause it steals the joy out of your hob­bies and cre­ates sex­u­ally ex­plicit im­ages of women with­out their con­sent. Seriously, please stop! It re­ally hurts my feel­ings.

It’s easy to throw stones if you think about the job dis­place­ment and eco­log­i­cal de­struc­tion caused by this point­less tech­nol­ogy. But such black-and-white, not-want­ing-bil­lion­aires-to-get-richer think­ing is, quite frankly, cruel. You can’t just mea­sure the value of some­thing in terms of “whether or not it makes every­thing worse for every­one.” The world is much more com­pli­cated than that.

This tech­nol­ogy is go­ing to fuel in­no­va­tion across in­dus­tries and solve all prob­lems of fem­i­nism and equal rights. Yes, it’s ex­pand­ing the sur­veil­lance state, and yes, it’s de­stroy­ing the ed­u­ca­tion sys­tem, and yes, it’s be­ing trained on copy­righted work with­out per­mis­sion, and yes, it’s be­ing used to cre­ate lethal au­tonomous weapons sys­tems that can iden­tify, tar­get, and kill with­out hu­man in­put, but… I for­get my point, but ul­ti­mately, I think you should em­brace it.

Lately, I feel like I just can’t win with you guys. Please, just use my evil tech­nol­ogy. What’s so wrong with that? Just use it. I’m beg­ging you. I want to con­tinue liv­ing my im­moral tech­no­fas­cist life with­out any crit­i­cism.

This, if it is still vis­i­ble:

Next up, age ver­i­fi­ca­tion for ADSB?

Earlier to­day, as ref­er­enced in our FY 2025 re­sults re­lease, the ASML Board of Management shared the fol­low­ing in­ter­nal mes­sage with em­ploy­ees.

Dear ASML col­leagues –

Today we shared our full-year fi­nan­cial re­sults for 2025, as well as our out­look for the year ahead. The semi­con­duc­tor ecosys­tem is poised to ex­pe­ri­ence sig­nif­i­cant growth in the com­ing years, and ASML is well po­si­tioned to lever­age this pos­i­tive de­vel­op­ment. On be­half of the Board of Management, I want to thank every­one for their con­tri­bu­tion to this suc­cess.

We can at­tribute our suc­cess to our cus­tomer ded­i­ca­tion, en­gi­neer­ing tal­ent and col­lab­o­ra­tive ap­proach to the ecosys­tem. Our abil­ity to in­no­vate and ex­e­cute has gen­er­ated sub­stan­tial ben­e­fits for our cus­tomers and sup­pli­ers, our col­leagues, and our in­vestors. We in­tend to con­tinue to grow our work­force and foot­print, in­clud­ing at our planned sec­ond cam­pus in Eindhoven, in line with cus­tomer de­mand.

As with any com­pany that grows rapidly, how­ever, we need to be mind­ful that the way we have grown does not slow us down. The feed­back from our col­leagues, our sup­pli­ers and our cus­tomers shows that our ways of work­ing have, in some cases, be­come less ag­ile. Engineers in par­tic­u­lar have ex­pressed their de­sire to fo­cus their time on en­gi­neer­ing, with­out be­ing ham­pered by slow process flows, and re­store the fast-mov­ing cul­ture that has made us so suc­cess­ful.

We be­lieve it is im­por­tant to ad­dress these is­sues so that we are well pre­pared for fu­ture growth and well po­si­tioned to con­tinue to de­liver for our cus­tomers. As a re­sult, we are an­nounc­ing to­day that we in­tend to strengthen our fo­cus on en­gi­neer­ing and in­no­va­tion in crit­i­cal ar­eas of our com­pany through the stream­lin­ing of the Technology and the IT or­ga­ni­za­tions.

In the Technology or­ga­ni­za­tion, we are propos­ing to shift from a pro­ject/​ma­trix setup to one where most of our en­gi­neers will be ded­i­cated to a spe­cific prod­uct and mod­ule. This will al­low us to sim­plify processes and de­ci­sion-mak­ing. This need for sim­pli­fi­ca­tion is some­thing that we have heard con­sis­tently from all lev­els of the or­ga­ni­za­tion.

We are safe­guard­ing what makes us strong: a ded­i­cated foun­da­tional team which will en­sure that we con­tinue to de­velop our deep tech­ni­cal com­pe­tence, and drive fit-for-pur­pose com­mon­al­ity and stan­dards across all en­gi­neer­ing do­mains.

As a re­sult of these pro­posed changes, some roles — mainly at the lead­er­ship level — may no longer be re­quired. At the same time, to re­tain our en­gi­neer­ing ca­pa­bil­ity, we will cre­ate new en­gi­neer­ing jobs to strengthen ex­ist­ing tech­nol­ogy pro­jects and em­bark on new ones to sup­port our own and our cus­tomers’ growth plans. While this will al­low some of our im­pacted col­leagues to move to new roles, we have to ac­knowl­edge that some will leave ASML as a re­sult.

In ad­di­tion to the Technology changes, we will also look at the setup of the IT & Data or­ga­ni­za­tion, sim­i­larly seek­ing ways to stream­line its struc­ture to op­ti­mize its de­liv­ery ca­pa­bil­i­ties.

In the com­ing weeks we will be work­ing closely with our so­cial part­ners in the Netherlands to dis­cuss the in­tent and ex­tent of these changes. At this stage, we be­lieve the pro­posed changes could ul­ti­mately re­sult in a net re­duc­tion of around 1,700 po­si­tions, mostly in the Netherlands, with some in the United States.

The fo­cus of these changes is on the Technology and the IT or­ga­ni­za­tions. ASML con­tin­ues to grow and will need to cre­ate roles as re­quired to meet cus­tomer de­mand for new ma­chines and ser­vic­ing, in­clud­ing in Manufacturing, Customer Support and Sales.

Of course, every col­league is some­one that we value and ap­pre­ci­ate: We are com­mit­ted to act­ing re­spon­si­bly - with care, speed, trans­parency, and fair­ness - and to sup­port­ing them through this change.

We rec­og­nize that this news may cre­ate un­cer­tainty and raise ques­tions for many of you, but we be­lieve strongly that it is im­por­tant to be trans­par­ent in our ap­proach. We will host all-em­ployee meet­ings to­day to share more about the pro­posed changes. Further in­for­ma­tion ses­sions will be held for teams af­fected, and we com­mit to con­tin­u­ing to in­form you all about what we can, when we can.

As our FY 2025 fi­nan­cial re­sults demon­strate, we are choos­ing to make these changes at a mo­ment of strength for the com­pany. Improving our processes and sys­tems will al­low us to in­no­vate more and in­no­vate bet­ter, gen­er­at­ing fur­ther re­spon­si­ble growth for ASML and our stake­hold­ers.

With best wishes

Christophe, on be­half of the ASML Board of Management

We’re ex­cited to an­nounce the re­lease of pan­das 3.0.0. This ma­jor long-awaited re­lease brings sig­nif­i­cant im­prove­ments to pan­das, but also fea­tures some po­ten­tially break­ing changes.

Dedicated string data type by de­fault: string columns are now in­ferred as

the new str dtype in­stead of ob­ject, pro­vid­ing bet­ter per­for­mance and type

safety

Consistent copy/​view be­hav­iour with Copy-on-Write (CoW) (a.k.a. get­ting

rid of the SettingWithCopyWarning): more pre­dictable and con­sis­tent be­hav­ior

for all op­er­a­tions, with im­proved per­for­mance through avoid­ing un­nec­es­sary

copies

New de­fault res­o­lu­tion for date­time-like data: no longer de­fault­ing to

nanosec­onds, but gen­er­ally mi­crosec­onds (or the res­o­lu­tion of the in­put), when

con­struct­ing date­time or timedelta data (avoiding out-of-bounds er­rors

for dates with a year be­fore 1678 or af­ter 2262)

New pd.col syn­tax: ini­tial sup­port for pd.col() as a sim­pli­fied syn­tax

for cre­at­ing callables in DataFrame.assign

Further, pan­das 3.0 in­cludes a lot of other im­prove­ments and bug fixes. You can find the com­plete list of changes in the

re­lease notes.

The pan­das 3.0 re­lease re­moved func­tion­al­ity that was dep­re­cated in pre­vi­ous re­leases (see here

for an overview). It is rec­om­mended to first up­grade to pan­das 2.3 and to en­sure your code is work­ing with­out warn­ings, be­fore up­grad­ing to pan­das 3.0.

Further, as a ma­jor re­lease, pan­das 3.0 in­cludes some break­ing changes that may re­quire up­dates to your code. The two most sig­nif­i­cant changes are the new string dtype and the copy/​view be­hav­iour changes, de­tailed be­low. An overview of all po­ten­tially break­ing changes can be found in the Backwards in­com­pat­i­ble API

changes

sec­tion of the re­lease notes.

Starting with pan­das 3.0, string columns are au­to­mat­i­cally in­ferred as str

dtype in­stead of the numpy ob­ject (which can store any Python ob­ject).

This change im­proves per­for­mance and type safety, but may re­quire code up­dates, es­pe­cially for li­brary code that cur­rently looks for “object” dtype when ex­pect­ing string data.

For more de­tails, see the

mi­gra­tion guide for the new string data type.

This new data type will use the pyarrow li­brary un­der the hood, if in­stalled, to pro­vide the per­for­mance im­prove­ments. Therefore we strongly rec­om­mend to in­stall pyarrow along­side pan­das (but pyarrow is not a re­quired de­pen­dency in­stalled by de­fault).

Copy-on-Write is now the de­fault and only mode in pan­das 3.0. This makes be­hav­ior more con­sis­tent and pre­dictable, and avoids a lot of de­fen­sive copy­ing (improving per­for­mance), but re­quires up­dates to cer­tain cod­ing pat­terns.

The most im­pact­full change is that chained as­sign­ment will no longer work. As a re­sult, the SettingWithCopyWarning is also re­moved (since there is no longer am­bi­gu­ity whether it would work or not), and de­fen­sive .copy() calls to si­lence the warn­ing are no longer needed.

# Old be­hav­ior (pandas < 3.0) - chained as­sign­ment

df[“foo”][df[“bar”] > 5] = # This might mod­ify df (unpredictable)

# New be­hav­ior (pandas 3.0) - must do the mod­i­fi­ca­tion in one step (e.g. with .loc)

df.loc[df[“bar”] > 5, “foo”] = 100

In gen­eral, any re­sult of an in­dex­ing op­er­a­tion or method now al­ways be­haves as if it were a copy, so mod­i­fi­ca­tions of the re­sult won’t af­fect the orig­i­nal DataFrame.

For more de­tails, see the

Copy-on-Write mi­gra­tion guide.

You can in­stall the lat­est pan­das 3.0 re­lease from PyPI:

Or from conda-forge us­ing conda/​mamba:

Running into an is­sue or re­gres­sion? #

Please re­port any prob­lem you en­counter with the re­lease on the pan­das is­sue tracker.

Thanks to all the con­trib­u­tors who made this re­lease pos­si­ble!

The UK Government re­cently un­veiled its ‘AI Skills Hub’, which wants to pro­vide 10 mil­lion work­ers with AI skills by 2030. The main site was de­liv­ered by PwC for the low, low price of.. £4.1 mil­lion (~$5,657,000).

It is not good. Like, at all - the UI is in­sanely bad and it’s clear that this was just a vibecoded site (to be fair, this is the AI Skills Hub, but c’­mon, where is the pride in your work? I would be ashamed to even re­lease this as a pro­to­type!)

PwC did­n’t even write any of the course con­tent! The only thing the Skills Hub does is link out to ex­ter­nal pages, like Salesforce’s free Trailhead learn­ing plat­form:

Note that I’m fairly cer­tain this course al­ready ex­isted be­fore the con­tract was even awarded, so all the site does is.. link out to other sites?

PwC it­self also ad­mits that the site does not prop­erly meet ac­ces­si­bil­ity stan­dards:

Even for those with­out a dis­abil­ity, the lack of here in this re­gard means that the site can be very con­fus­ing and buggy as a re­sult.

The site has a course on “AI and in­tel­lec­tual prop­erty”. One thing it men­tions is fair use:

Except that fair use is not a thing in the UK - that’s a US con­cept! The UK uses what’s known as “fair deal­ing”, which is more re­stric­tive than fair use, so the de­tails here are plain wrong.

The in­ter­face for this web­site has also not been clearly thought out - one glar­ing ex­am­ple is the process of ac­tu­ally en­rolling in a course.

On the course page, the “Enroll Now” but­ton is tiny, and if you don’t see it and try scrolling down to the bot­tom, you will find your­self noth­ing but a com­ment sec­tion!

Then you have other bugs too, like the “Skills & Training Gap Analysis” - which is linked at the top of the site! - ap­par­ently be­ing closed off to the pub­lic for no rea­son:

To be hon­est, see­ing this made me an­gry.

I’m an­gry at the sheer waste­ful­ness of the UK Government here. Our pub­lic ser­vices are col­laps­ing - while £4 mil­lion is ad­mit­tedly chump change for the UK gov­ern­ment, there are real peo­ple be­hind these num­bers - fam­i­lies wait­ing months for NHS ap­point­ments, chil­dren in crum­bling schools, vul­ner­a­ble peo­ple not get­ting the care they need. The waste feels par­tic­u­larly galling when you re­alise that al­most no one will ac­tu­ally use this site!

I’m also an­gry that the small web­dev busi­nesses we have here in the UK were left out of this - for less than 5% of the cost, we’d have a bet­ter web­site and help out small busi­nesses who ac­tu­ally care about their work, in­stead of hand­ing the pro­ject to a multi­na­tional com­pany that made nearly $60 bil­lion in rev­enue in a year and has zero qualms about rip­ping off the British tax­payer.

* WhatsApp has adopted and rolled out a new layer of se­cu­rity for users — built with Rust — as part of its ef­fort to harden de­fenses against mal­ware threats.

* WhatsApp’s ex­pe­ri­ence cre­at­ing and dis­trib­ut­ing our me­dia con­sis­tency li­brary in Rust to bil­lions of de­vices and browsers proves Rust is pro­duc­tion ready at a global scale.

WhatsApp pro­vides de­fault end-to-end en­cryp­tion for over 3 bil­lion peo­ple to mes­sage se­curely each and every day. Online se­cu­rity is an ad­ver­sar­ial space, and to con­tinue en­sur­ing users can keep mes­sag­ing se­curely, we’re con­stantly adapt­ing and evolv­ing our strat­egy against cy­ber-se­cu­rity threats — all while sup­port­ing the WhatsApp in­fra­struc­ture to help peo­ple con­nect.

For ex­am­ple, WhatsApp, like many other ap­pli­ca­tions, al­lows users to share me­dia and other types of doc­u­ments. WhatsApp helps pro­tect users by warn­ing about dan­ger­ous at­tach­ments like APKs, yet rare and so­phis­ti­cated mal­ware could be hid­den within a seem­ingly be­nign file like an im­age or video. These ma­li­ciously crafted files might tar­get un­patched vul­ner­a­bil­i­ties in the op­er­at­ing sys­tem, li­braries dis­trib­uted by the op­er­at­ing sys­tem, or the ap­pli­ca­tion it­self.

To help pro­tect against such po­ten­tial threads, WhatsApp is in­creas­ingly us­ing the Rust pro­gram­ming lan­guage, in­clud­ing in our me­dia shar­ing func­tion­al­ity. Rust is a mem­ory safe lan­guage of­fer­ing nu­mer­ous se­cu­rity ben­e­fits. We be­lieve that this is the largest roll­out glob­ally of any li­brary writ­ten in Rust.

To help ex­plain why and how we rolled this out, we should first look back at a key OS-level vul­ner­a­bil­ity that sent an im­por­tant sig­nal to WhatsApp around hard­en­ing me­dia-shar­ing de­fenses.

In 2015, Android de­vices, and the ap­pli­ca­tions that ran on them, be­came vul­ner­a­ble to the “Stagefright” vul­ner­a­bil­ity. The bug lay in the pro­cess­ing of me­dia files by op­er­at­ing sys­tem-pro­vided li­braries, so WhatsApp and other ap­pli­ca­tions could not patch the un­der­ly­ing vul­ner­a­bil­ity. Because it could of­ten take months for peo­ple to up­date to the lat­est ver­sion of their soft­ware, we set out to find so­lu­tions that would keep WhatsApp users safe, even in the event of an op­er­at­ing sys­tem vul­ner­a­bil­ity.

At that time, we re­al­ized that a cross-plat­form C++ li­brary al­ready de­vel­oped by WhatsApp to send and con­sis­tently for­mat MP4 files (called “wamedia”) could be mod­i­fied to de­tect files which do not ad­here to the MP4 stan­dard and might trig­ger bugs in a vul­ner­a­ble OS li­brary on the re­ceiver side — hence putting a tar­get’s se­cu­rity at risk. We rolled out this check and were able to pro­tect WhatsApp users from the Stagefright vul­ner­a­bil­ity much more rapidly than by de­pend­ing on users to up­date the OS it­self.

But be­cause me­dia checks run au­to­mat­i­cally on down­load and process un­trusted in­puts, we iden­ti­fied early on that wa­me­dia was a prime can­di­date for us­ing a mem­ory safe lan­guage.

Rather than an in­cre­men­tal rewrite, we de­vel­oped the Rust ver­sion of wa­me­dia in par­al­lel with the orig­i­nal C++ ver­sion. We used dif­fer­en­tial fuzzing and ex­ten­sive in­te­gra­tion and unit tests to en­sure com­pat­i­bil­ity be­tween the two im­ple­men­ta­tions.

Two ma­jor hur­dles were the ini­tial bi­nary size in­crease due to bring­ing in the Rust stan­dard li­brary and the build sys­tem sup­port re­quired for the di­verse plat­forms sup­ported by WhatsApp. WhatsApp made a long-term bet to build that sup­port. In the end, we re­placed 160,000 lines of C++ (excluding tests) with 90,000 lines of Rust (including tests). The Rust ver­sion showed per­for­mance and run­time mem­ory us­age ad­van­tages over the C++. Given this suc­cess, Rust was fully rolled out to all WhatsApp users and many plat­forms: Android, iOS, Mac, Web, Wearables, and more. With this pos­i­tive ev­i­dence in hand, mem­ory safe lan­guages will play an ever in­creas­ing part in WhatsApp’s over­all ap­proach to ap­pli­ca­tion and user se­cu­rity.

Over time, we’ve added more checks for non-con­for­mant struc­tures within cer­tain file types to help pro­tect down­stream li­braries from parser dif­fer­en­tial ex­ploit at­tempts. Additionally, we check higher risk file types, even if struc­turally con­for­mant, for risk in­di­ca­tors. For in­stance, PDFs are of­ten a ve­hi­cle for mal­ware, and more specif­i­cally, the pres­ence of em­bed­ded files and script­ing el­e­ments within a PDF fur­ther raise risks. We also de­tect when one file type mas­quer­ades as an­other, through a spoofed ex­ten­sion or MIME type. Finally, we uni­formly flag known dan­ger­ous file types, such as ex­e­cuta­bles or ap­pli­ca­tions, for spe­cial han­dling in the ap­pli­ca­tion UX. Altogether, we call this en­sem­ble of checks “Kaleidoscope.” This sys­tem pro­tects peo­ple on WhatsApp from po­ten­tially ma­li­cious un­of­fi­cial clients and at­tach­ments. Although for­mat checks will not stop every at­tack, this layer of de­fense helps mit­i­gate many of them.

Each month, these li­braries are dis­trib­uted to bil­lions of phones, lap­tops, desk­tops, watches, and browsers run­ning on mul­ti­ple op­er­at­ing sys­tems for peo­ple on WhatsApp, Messenger, and Instagram. This is the largest ever de­ploy­ment of Rust code to a di­verse set of end-user plat­forms and prod­ucts that we are aware of. Our ex­pe­ri­ence speaks to the pro­duc­tion-readi­ness and unique value propo­si­tion of Rust on the client-side.

This is just one ex­am­ple of WhatsApp’s many in­vest­ments in se­cu­rity. It’s why we built de­fault end-to-end en­cryp­tion for per­sonal mes­sages and calls, of­fer end-to-end en­crypted back­ups, and use key trans­parency tech­nol­ogy to ver­ify a se­cure con­nec­tion, pro­vide ad­di­tional call­ing pro­tec­tions, and more.

WhatsApp has a strong track record of be­ing loud when we find is­sues and work­ing to hold bad ac­tors ac­count­able. For ex­am­ple, WhatsApp re­ports CVEs for im­por­tant is­sues we find in our ap­pli­ca­tions, even if we do not find ev­i­dence of ex­ploita­tion. We do this to give peo­ple on WhatsApp the best chance of pro­tect­ing them­selves by see­ing a se­cu­rity ad­vi­sory and up­dat­ing quickly.

To en­sure ap­pli­ca­tion se­cu­rity, we first must iden­tify and quan­tify the sources of risk. We do this through in­ter­nal and ex­ter­nal au­dits like NCC Group’s pub­lic as­sess­ment of WhatsApp’s end-to-end en­crypted back­ups, fuzzing, sta­tic analy­sis, sup­ply chain man­age­ment, and au­to­mated at­tack sur­face analy­sis. We also re­cently ex­panded our Bug Bounty pro­gram to in­tro­duce the WhatsApp Research Proxy — a tool that makes re­search into WhatsApp’s net­work pro­to­col more ef­fec­tive.

Next, we re­duce the iden­ti­fied risk. Like many oth­ers in the in­dus­try, we found that the ma­jor­ity of the high sever­ity vul­ner­a­bil­i­ties we pub­lished were due to mem­ory safety is­sues in code writ­ten in the C and C++ pro­gram­ming lan­guages. To com­bat this we in­vest in three par­al­lel strate­gies:

Invest in se­cu­rity as­sur­ance for the re­main­ing C and C++ code.

Default the choice of mem­ory safe lan­guages, and not C and C++, for new code.

WhatsApp has added pro­tec­tions like CFI, hard­ened mem­ory al­lo­ca­tors, safer buffer han­dling APIs, and more. C and C++ de­vel­op­ers have spe­cial­ized se­cu­rity train­ing, de­vel­op­ment guide­lines, and au­to­mated se­cu­rity analy­sis on their changes. We also have strict SLAs for fix­ing is­sues un­cov­ered by the risk iden­ti­fi­ca­tion process.

Rust en­abled WhatsApp’s se­cu­rity team to de­velop a se­cure, high per­for­mance, cross-plat­form li­brary to en­sure me­dia shared on the plat­form is con­sis­tent and safe across de­vices. This is an im­por­tant step for­ward in adding ad­di­tional se­cu­rity be­hind the scenes for users and part of our on­go­ing de­fense-in-depth ap­proach. Security teams at WhatsApp and Meta are high­light­ing op­por­tu­ni­ties for high im­pact adop­tion of Rust to in­ter­ested teams, and we an­tic­i­pate ac­cel­er­at­ing adop­tion of Rust over the com­ing years.

Projects

I have a credit card with HSBC. It does­n’t see much use, but I still get a monthly state­ment from them, and an email to say it’s avail­able.

Not long ago I re­ceived a let­ter from them telling me that emails to me were be­ing “returned un­de­liv­ered” and they needed me to up­date the email ad­dress on my ac­count.

I don’t know what emails are be­ing “returned un­de­liv­ered” to HSBC, but it is­n’t any of the ones sit­ting, read, in my email client.

I logged into my ac­count, per the in­struc­tions in the let­ter, and dis­cov­ered my cor­rect email ad­dress al­ready right there, much to my… lack of sur­prise.

So I kicked off a live chat via their app, with an agent called Ankitha. Over the course of a drawn-out hour-long con­ver­sa­tion, they re­peat­edly told to tell me how to up­date my email ad­dress (which was never my ques­tion). Eventually, when they un­der­stood that my email ad­dress was al­ready cor­rect, then they con­cluded the call, say­ing (emphasis mine):

I can un­der­stand your frus­tra­tion, but if the bank has sent the let­ter, you will have to up­date the e-mail ad­dress.

This is the point at which a nor­mal per­son would prob­a­bly just change the email ad­dress in their on­line bank­ing to a “spare” email ad­dress.

But aside from the fact that I’d rather not, by this point I’d caught the scent of a deeper un­der­ly­ing is­sue. After all, did­n’t I have a con­ver­sa­tion a lit­tle like this one but with a dif­fer­ent bank, about four years ago?

Perhaps I should be grate­ful that they did­n’t say that I have to change my name, which can some­times  be sig­nif­i­cantly more awk­ward than my email

ad­dress…

So I called Customer Services di­rectly, who told me that if my email ad­dress is al­ready cor­rect then I can ig­nore their let­ter.

I sug­gested that per­haps their let­ter tem­plate might need up­dat­ing so it does­n’t say “action re­quired” if ac­tion is not re­quired. Or that per­haps what they mean to say is “action re­quired: check your email ad­dress is cor­rect”.

Say what you mean, HSBC! I’ve sug­gested an im­prove­ment to your let­ter tem­plate.

So any­way, ap­par­ently every­thing’s fine… al­though I re­served fi­nal judge­ment un­til I’d seen that they were still send­ing me emails!

I think I can place a solid guess about what went wrong here. But it makes me feel like we’re liv­ing in the Darkest Timeline.

You know the one I mean. Somebody rolled a ‘1’, did­n’t they…

I dis­sected HSBC’s lat­est email to me: it was of the “your lat­est state­ment is avail­able” va­ri­ety. Deep within the email, down at the bot­tom, is this code:

What you’re see­ing are two track­ing pix­els: tiny 1×1 pixel im­ages, usu­ally trans­par­ent or white-on-white to make them even-more in­vis­i­ble, used to sur­rep­ti­tiously track when some­body reads an email. When you open an email from HSBC — po­ten­tially every time you open an email from them — your email client con­nects to those web ad­dresses to get the nec­es­sary im­ages. The code at the end of each iden­ti­fies the email they were con­tained within, which in turn can be linked back to the re­cip­i­ent.

You know how in­va­sive a read-re­ceipt feels? Tracking pix­els are like those… but turned up to eleven. While a read-re­ceipt only says “the re­cip­i­ent read this email” (usually only af­ter the re­cip­i­ent gives con­sent for it to do so), a track­ing pixel can of­ten track when and how of­ten you re­fer to an email.

If I re-read a year-old email from HSBC, they’re say­ing that they want to know about it.

But it gets worse. Because HSBC are us­ing http://, rather than https:// URLs for their track­ing pix­els, they’re also say­ing that every time you read an email from them, they’d like every­body on the same net­work as you to be able to know that you did so, too. If you’re at my house, on my WiFi, and you open an email from HSBC, not only might HSBC know about it, but I might know about it too.

An eas­ily-avoid­able se­cu­rity fail­ure there, HSBC… which is­n’t the kind of thing one hopes to hear about a bank!

Tracking pix­els are usu­ally in­vis­i­ble, so I turned these ones vis­i­ble so you can see where they hide.

But… track­ing pix­els don’t ac­tu­ally work. At least, they does­n’t work on me. Like many pri­vacy-con­scious in­di­vid­u­als, my de­vices are con­fig­ured to block track­ing pix­els (and a va­ri­ety of other in­stru­ments of sur­veil­lance cap­i­tal­ism) right out of the gate.

This means that even though I do read most of the non-spam email that lands in my Inbox, the sender does­n’t get to know that I did so un­less I choose to tell them. This is the way that email was de­signed to work, and is the only way that a sender can be con­fi­dent that it will work.

But we’re in the Darkest Timeline. Tracking pix­els have be­come so en­demic that HSBC have clearly come to the opin­ion

that if they can’t track when I open their emails, I must not be re­ceiv­ing their emails. So they wrote me a let­ter to tell me that my emails have been “returned un­de­liv­ered” (which seems to be an out­right lie).

Surveillance cap­i­tal­ism has be­come so ubiq­ui­tous that it’s be­come trans­par­ent. Transparent like the in­vis­i­ble spies at the bot­tom of your bank’s emails.

I’ve changed my mind. Maybe this is what HSBC’s let­ter should have said.

So in sum­mary, with only a lit­tle spec­u­la­tion:

Surveillance cap­i­tal­ism be­came wide­spread enough that HSBC came to as­sume that track­ing pix­els have bul­let­proof re­li­a­bil­ity.

HSBC started us­ing track­ing pix­els them to check whether emails are be­ing re­ceived (even though that’s not what they do when they are re­li­able, which

they’re not).

Eventually, HSBC as­sumed their track­ing was bul­let­proof. Because HSBC could­n’t track how of­ten, when, and where I was read­ing their emails… they posted me a let­ter to

tell me I needed to change my email ad­dress.

What do I think HSBC should do?

Instead of send­ing me a mis­lead­ing let­ter about un­de­liv­ered emails, per­haps a bet­ter ap­proach for HSBC could be:

At an ab­solute min­i­mum, stop us­ing un­en­crypted con­nec­tions for track­ing pix­els. I do not want to open a bank email on a cafe’s pub­lic WiFi and have

every­body in the cafe po­ten­tially know who I bank with… and that I just opened an email from them! I cer­tainly don’t want at­tack­ers in­ject­ing con­tent into the bot­tom of

le­git­i­mate emails.

Stop as­sum­ing that if some­body blocks your at­tempts to spy on them via your emails, it means they’re not get­ting your emails. It does­n’t mean that. It’s never meant

that. There are all kinds of rea­sons that your track­ing pix­els might not work, and they’re not even all pri­vacy-re­lated rea­sons!

Or, bet­ter yet: just stop try­ing to sur­veil your cus­tomers’ email habits in the first place? You al­ready sit on a wealth of per­sonal and fi­nan­cial in­for­ma­tion which

you can, and prob­a­bly do, data-mine for your own ben­e­fit. Can you at least try to pay lip ser­vice to your own pub­lished prin­ci­ples on the

eth­i­cal use of data and, if I may quote them, “use only that data which is ap­pro­pri­ate for the pur­pose” and “embed pri­vacy con­sid­er­a­tions into de­sign and ap­proval processes”.

If you need to check that an email ad­dress is valid, do that, not an un­re­li­able proxy for it. Instead of this let­ter, you could have sent an email that

said “We need to check that you’re re­ceiv­ing our emails. Please click this link to con­firm that you are.” This not only achieves in­formed con­sent for your track­ing, but it can be

more-se­cure too be­cause you can au­then­ti­cate the user dur­ing the process.

Also, to quote your own prin­ci­ples once more: when you make a mis­take like as­sum­ing your spy­ing is a flaw­less way to de­tect the va­lid­ity of email ad­dresses, per­haps you should “be trans­par­ent with our cus­tomers and other stake­hold­ers about how we use their data”.

Wouldn’t that be bet­ter than writ­ing to a cus­tomer to say that their emails are be­ing re­turned un­de­liv­ered (when they’re not)… and then hav­ing your staff tell them that hav­ing re­ceived such an email they have no choice but to change the email ad­dress they use (which is then dis­puted by your other staff)?

No time to com­ment? Send an emoji with just one click!