DEV Community: Mahmud Hasan

How to Fix npm install Errors: The 3 Codes That Matter

Mahmud Hasan — Sat, 14 Nov 2026 17:38:55 +0000

npm install failed again? How to fix npm install error: read the error code first, then run the one fix that matches it — ERESOLVE, EACCES, and ENOENT, tested.

In this guide

How to fix npm install error: read the code first
ERESOLVE: two packages want different versions of the same thing
EACCES: npm can't write where it's trying to install
ENOENT: npm can't find the file it's looking for
The order that actually works
References

Your npm install just failed, and the terminal is showing you a wall of red. Before you copy the error into a search box, do one thing: scroll up to the line that starts with npm error code. That code is the diagnosis, and it already tells you which of three problems you have. This is how to fix npm install error the fast way — read the code, run the one fix that matches it.

👉 Read the full guide: How to Fix npm install Errors: The 3 Codes That Matter

This is a condensed version — the complete guide, with all the steps, code samples and screenshots, lives on Byte by Mahmud.

GitLab's Second 10.0 RCE This Month. Your October 12 Patch Doesn't Cover It.

Mahmud Hasan — Sat, 24 Oct 2026 02:33:05 +0000

On October 12, GitLab told every self-managed admin to patch a 10.0 regex RCE, and the responsible ones did it that day. On October 21, GitLab told them to patch again — because a second 10.0 had landed in the same regex compiler, and the first patch sits exactly one version below the new fix. If your status report says "patched October 12," you are not done — you are the target audience for this post.

The bug, in plain terms

CVE-2026-110264 is an integer overflow that triggers when GitLab's server compiles a specially crafted regular expression. Under "certain conditions" — GitLab's phrase, not mine, and the company has declined to say what those conditions are — an unauthenticated user can execute arbitrary code on the GitLab server.

The CVSS 3.1 vector reads like a worst case assembled from spare parts: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The attack arrives over the network, complexity is low, no privileges are required, no user interaction is needed, and the impact on confidentiality, integrity, and availability is maximal. That is how you land on a flat 10.0, the ceiling of the scale.

The component is the interesting part. The vulnerable code is not in GitLab's application logic — it is in Onigmo, the regular-expression library that lives inside the Ruby runtime GitLab bundles into its own packages. SOC Prime's public reporting points to GitLab's rendering of Org mode as the likely path into the flawed compiler, though GitLab has deliberately held back the precise trigger while operators patch. The researcher credited with finding it goes by "joaxcar" and reported through GitLab's HackerOne bug bounty program.

Why it reaches back to 2014

A flaw in a "regex compiler" sounds like it should be a recent piece of GitLab code. It isn't. GitLab ships its own Ruby in every release, and that Ruby carries Onigmo. So the weakness exists everywhere GitLab has shipped that engine — which is every release since GitLab 7.0, published in 2014. Roughly twelve years of installs, all in range.

The fix list reads like a confession of that history. On the newer branches the patches are titled "Ruby regexp repeat ID overflow" for Ruby 3.3, 3.4, and 4.0; on the older branches they are "repeat-range double-free" patches for Ruby 3.3 and 3.4. The engine is old, the packaging is old, and the bug is old. No "old stable release" position exists here — old branches are where the exposure is widest.

Censys, which scanned for exposed GitLab instances on disclosure day, found roughly 82,000 hosts and about 209,000 web properties running GitLab — and since every release from 7.0 up to the October 21 fixes was affected, that was effectively the entire population. More than half run release lines over seven months old with no fix of their own; over a quarter are three or more majors behind and must step through GitLab's required upgrade stops.

The October 12 patch is the trap

Nine days before this disclosure, GitLab patched CVE-2026-97229 — the same CVSS vector, the same 10.0 ceiling, the same regex compiler. That round shipped as 19.4.2, 19.3.5, and 19.2.8, and it covered only versions 19.2 and later. The new fixes are 19.4.3, 19.3.6, and 19.2.9.

Read those pairs again. 19.3.5 became 19.3.6. 19.4.2 became 19.4.3. Each new fixed version sits exactly one patch above the October 12 build on its branch. A server you upgraded last week to close the first regex RCE is still exposed to the second. As the Suriq advisory put it: patching is not a one-time event here.

That is also the pattern that should worry you more than the CVE itself. Two maximum-severity integer overflows in the same compiler, nine days apart, in a component that has been shipping since 2014. Either GitLab or the researchers are combing that compiler now — and a third find would not surprise anyone. It was also a crowded week for infrastructure software: Amazon confirmed PHP2Shell exploitation attempts four days before that disclosure.

Who has to act — and the version table

First, the people who can stop reading: if you run GitLab.com, the fixed version is already live, and GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later already include the fixes. There is no workaround — upgrade is the only remediation.

Everyone on a self-managed GitLab Community or Enterprise Edition instance, on any deployment type, has work to do:

If you run 19.5 before 19.5.1 — upgrade to 19.5.1
If you run 19.4 before 19.4.3 — upgrade to 19.4.3
If you run 19.3 before 19.3.6 — upgrade to 19.3.6
If you run 19.2 before 19.2.9 — upgrade to 19.2.9
If you run 19.1 before 19.1.9 — upgrade to 19.1.9
If you run 19.0 before 19.0.10 — upgrade to 19.0.10
If you run 7.0 through 18.11 — upgrade to 18.11.13

Three quirks worth knowing. GitLab normally patches only the three newest minor versions; shipping four backports (19.2, 19.1, 19.0, 18.11) is unusual and a decent signal of how seriously the company takes this. But those backports carry only the critical fix — the other eleven fixes in the same release, including a high-severity LDAP account-takeover (CVE-2026-15723) and an OAuth/OIDC cache poisoning (CVE-2026-112212), require 19.3.6, 19.4.3, or 19.5.1. And the 19.4.3 and 19.3.6 builds include database migrations: a single-node server stays down until they finish, while multi-node installations can use the zero-downtime upgrade procedure.

What to do this week

Start with the inventory, because the forgotten instance is the breach. List every GitLab server you run — Geo secondaries, staging, disaster recovery, test environments. Check the running version on each host (the /help page while signed in, or the version command for your install type) rather than assuming last week's upgrade carried over.

Then patch to the fixed build on your line — a 19.4.2-to-19.4.3 upgrade needs no extra stops, which is the point of the backport table. If you are on a branch older than 18.11, there is no fixed release on your line — plan the stepped upgrade now, because every version in the table is reachable but the path goes through GitLab's required stops.

After patching, treat the instance as potentially compromised and rotate the secrets it held. Censys's advisory is explicit: a breached GitLab server exposes source code, CI/CD secrets, and deploy credentials — the keys to shipping software to production. Run GitLab's two published detection rules over your recent logs while you are at it.

One objection you will hear, and I will answer it now: "but it hasn't been exploited." Correct — GitLab reports no sign of exploitation, it is not in CISA's Known Exploited Vulnerabilities catalog as of October 22, and no public proof of concept existed by then (two GitHub repositories appeared that day; one implemented the sibling CVE by its own author's admission, the other was emptied). But Amazon's disclosure this same week showed PHP2Shell being probed four days before its embargo lifted, because AI-assisted analysis has made turning a patch into a working exploit much cheaper. Patch timelines for critical internet-facing systems are now measured in hours. That is also the honest counterpoint to the headline's comfort: the researchers found this one privately. The next one may not wait.

And one housekeeping note for anyone keeping score: this is a different bug from the GitLab AI Gateway sandbox escape I covered earlier in October. Two 10.0-class flaws, two components, same month. The regex compiler is the one that affects twelve years of your servers. Start there.

References

The iPhone Duo Cracked Along Its Hinge on Launch Day. What We Actually Know

Mahmud Hasan — Fri, 23 Oct 2026 18:33:27 +0000

What happened on launch day

Apple's first foldable, the iPhone Duo, went on sale Friday morning in more than 70 countries. It starts at $1,999 for 256GB and tops out at $3,199 for the 2TB model. By the afternoon, at least one owner was walking back into an Apple Store with a screen split along the fold.

The clearest report came from an Australian buyer posting on Reddit as u/Midnight_Slump. Six hours after unboxing, fewer than 20 opens, they felt something give underneath the display near the hinge while showing the phone to a friend, then heard an audible crack. The inner screen broke right along the fold. There were no marks on the display surface or the external hinge to suggest a drop or something trapped inside.

The post drew around 1,300 upvotes and nearly 800 comments on r/iPhoneDuo. Apple support initially offered an express replacement — with the full price of the phone held on the card, no delivery date promised — so the owner walked into a physical Apple Store instead. The store swapped the unit on the spot. The lead tech called it a "day one manufacturing error," and said the broken unit would be returned to California for testing.

It wasn't the only report. MacRumors collected photos from Reddit and its own forums showing broadly similar damage: cracks concentrated along the hinge, and in several cases a line of bright pixels across one side of the screen. More surfaced from demo devices in China, which got the phone hours before the US. The confirmed cases are still a handful against millions of units in the wild, with no evidence yet of a widespread defect. Apple hasn't publicly commented.

That caveat matters. But the interesting part of this story isn't the crack count. It's everything around the cracks.

The hinge is the part that has to survive being wrong

The iPhone Duo's hinge is built from more than 100 components and exists to support the exact center of a 7.6-inch Super Retina XDR panel — the largest screen Apple has ever shipped on an iPhone. The inner display is a layered stack: a scratch-resistant coating, a nano-textured cover layer made from a custom polymer, high-strength glass above and below the folding panel, and a titanium plate underneath. The whole thing sits in a Grade 5 titanium frame with an IP68 rating, which is genuinely impressive for a foldable.

None of that makes the crease optional. A foldable's center fold is a stress concentration by definition — every open and close loads the same line of material, and the glass and polymer layers all have to survive bending to a tight radius thousands of times. When a screen fails "along the hinge" with no visible trauma, the failure is almost always in that stack: a particle, a void, or a bonding flaw that becomes the first fracture point the moment the layers flex.

This is why the store tech's "day one manufacturing error" comment rings true even without knowing the full diagnosis. Early-life hinge failures in foldables are a manufacturing-defect signature, not a design verdict. The physics doesn't need a systemic flaw — a small population of units with a bad bond in the stack will fail on the first dozen folds, and then the curve flattens.

Apple wrote the hinge-troubleshooting guide before the phones shipped

Here's the part that made me laugh, and it's documented: alongside the launch, Apple published a batch of iPhone Duo support documents. One of them is titled, in essence, "iPhone Duo Troubleshooting Hinge Issues." It tells you what to do if you're having any of the following problems with your brand-new $1,999 phone's hinge:

Device won't open or close completely
Unexpected noise while opening or closing the device
Loose hinge
Bent or broken hinge
Enclosure damage that affects hinge operation

Every foldable launch includes care guidance; that part is standard. But there's something quietly telling about a company shipping hinge troubleshooting on day one that includes the words "bent or broken hinge." Apple knew this mechanism was the part customers would come back about. It pre-wrote the script.

Also conspicuously missing from Apple's launch materials: a fold-cycle rating. Samsung publishes one. Most foldable makers publish one. Apple's spec page says nothing about how many folds the Duo is rated for. That's the number that would turn "is my hinge okay?" from anxiety into information, and its absence means every crack report gets read against a vacuum.

Seven years ago, Samsung lived this exact week

The 2019 parallel is unavoidable because it's nearly beat-for-beat. Samsung unveiled the Galaxy Fold in February 2019, priced it at $1,980, and planned to start selling April 26. Review units broke within days — Bloomberg's Mark Gurman called his "unusable just two days in"; The Verge's Dieter Bohn found a bulge right on the crease after one day; CNBC's unit flickered and died in two. Some reviewers had peeled off a protective polymer layer that wasn't meant to be removed, but other units failed on their own. Samsung's early findings pointed to "impact on exposed areas of the hinge" and mysterious "substances" found inside devices.

Samsung delayed the launch, spent five months "refining" the device, and only put it on sale in South Korea in September 2019 — with a program covering 70% of screen-repair costs within the first year. The Fold eventually sold, the category survived, and Samsung is now on its eighth generation of book-style foldables.

That history cuts both ways for the Duo. The optimistic read: Samsung's first foldable survived far worse than a handful of early unit failures, and early-life failures were the dominant failure mode then too. The pessimistic read: Samsung had the luxury of delaying before the public got involved. Apple's failures are happening in customers' hands on day one, which is the harder version of the same story to manage.

What to do if you're holding one

If you already have an iPhone Duo: nothing in the current evidence says you should panic. The reports describe manufacturing-early failures, and the store swapped the most detailed case immediately — exactly how a manufacturing-defect signature should be handled. Hinge failures from normal use are covered under Apple's one-year warranty, and anyone who bought this week also has the standard two-week return window.

What I'd actually do, owning one: use it the way you intend to use it, soon. Manufacturing defects show up in the first weeks, and you want any crack to happen while the return window is open and Apple is actively collecting failure data — not in month eight, when the story is a repair bill instead of a swap. Keep the box.

If you're thinking about buying one: wait. Not forever. The returned units are going back to California for a reason, and whatever Apple learns from the first batch will quietly show up in the second. Every foldable has this curve; the 2019 one ended fine.

References

Flapping Airplanes Raised $1B at $6B. It Has No Product.

Mahmud Hasan — Fri, 23 Oct 2026 12:31:40 +0000

Flapping Airplanes Raised $1B at $6B. It Has No Product.

A year-old AI lab with roughly two dozen people, no product, and no revenue just raised a billion dollars. The reported valuation: six billion. The investors include Nvidia, two quant trading firms, and four of Silicon Valley's biggest venture brands. I spent today reading the coverage, the investor posts, and the skeptical engineers. Here's the honest version.

$1 billion buys a thesis, not a company

On October 21, 2026, Flapping Airplanes announced a $1 billion Series A at a reported $6 billion valuation, co-led by Index Ventures and Lux Capital. Sequoia, GV, and Kleiner Perkins came back from the seed round. Nvidia, Valor, Atreides, A*, and quant firms Jump Trading and XTX joined. Index partner Mark Xu takes a board seat.

The valuation math is the part that should make you pause. Nine months ago the company raised a $180 million seed at $1.5 billion. The valuation quadrupled with nothing shipped in between. Dealroom puts the round in the top 1% of 3,497 comparable early-stage deep-tech rounds by size.

But "no product" is not quite the right frame, because that is not what anyone is buying. The company is one of a new species: research-first labs that raise frontier-lab money before anything exists. Dealroom counts 29 of these "neolabs" founded in two years, raising a combined $23 billion. Fewer than 35% have shipped a commercial product. Safe Superintelligence is worth a reported $32 billion with about 50 people and an explicit promise to ship nothing before superintelligence arrives. The valuation is not a price on output. It is a price on the team plus the thesis. Understand the thesis and you understand the check.

The megakernel bet, in plain English

Here is the thesis. A training run today is thousands of small GPU programs — kernels — launched one after another, with idle gaps between each. A megakernel fuses them into one continuous program that runs the whole job.

Flapping Airplanes claims it has built "the world's most complete megakernel framework" — one program that can do an entire training run, serve inference, and even play a video game, all at the same time. The specific trick is overlap: run memory-bound inference (mostly waiting on data) alongside compute-bound training (mostly doing math), so the chip is rarely idle. The company's LinkedIn statement claims internal evidence "at trillion-parameter pretraining scale." Asher Spector's pitch line: "A model that's a million times more data efficient is probably a million times easier to put into the economy."

The pedigree is real, and this matters more than the pitch. The founders — Aidan Smith (Thiel fellow, ex-Neuralink), Asher Spector (Stanford statistics PhD), and Ben Spector (the CEO) — come with receipts: Ben was the 2024 lead author on ThunderKittens, an open-source toolkit for writing fast GPU kernels that working kernel engineers know and use. Sequoia's David Cahn called the founders' student accelerator Prod "one of the most powerful talent incubators in Silicon Valley." This is not three founders with a slide deck. It is three founders with a track record of doing the specific hard thing they claim they will do next.

Why the efficiency bet is suddenly worth $6 billion

For a decade, AI money flowed one way: bigger. More data, more chips, more data centers. That regime is now visibly straining. Goldman Sachs has hyperscalers spending roughly $800 billion in capex this year, rising to $1.2 trillion in 2027 and $1.4 trillion in 2028 — $7.6 trillion cumulative through 2031, needing about $300 billion a year in AI revenue just to break even. Earlier this month the Philadelphia Semiconductor Index lost more than $1.6 trillion in under two weeks as investors questioned the debt behind the data-center boom.

Meanwhile the canonical data-efficiency result keeps getting quoted for a reason. DeepMind's 2022 Chinchilla study found that GPT-3 was oversized and under-trained: a 70-billion-parameter model trained on far more data beat a 280-billion-parameter one at the same compute cost. The industry's instinct since has been "train bigger." The neolab investors are betting the next phase is "waste less." Index's post says it outright: the winners will be whoever gets the most out of every dollar, every megawatt, and every byte.

That is what $6 billion is buying: a hedge against the assumption that scale is free. If the efficiency gains are real, they compound across every data center on Earth — including the ones Nvidia sells chips into, which is presumably why Nvidia keeps showing up on these cap tables.

The skeptic's case is stronger than the press release

Now the part the announcement did not lead with. On Latent Space's AI News podcast in August, inference engineers laid out why megakernels keep failing in production: with tensor parallelism across GPUs, nonlinear steps like softmax force communication between chips no matter how fused your kernel is. Companies that tried megakernels, one engineer said, often revert to modular kernels "because you can optimize each individual component." And Nvidia's upcoming Rubin GPU design includes "dependency triggers" that, in one tech lead's public words, "kills mega kernels" — hardware evolving to remove the bottleneck fusion was solving.

Then there is the evidence gap. The $6 billion number is Bloomberg-reported, never company-confirmed. There are no published benchmarks, no papers, no speedups measured on chips anyone can buy. In February, Asher Spector could not give TechCrunch a commercialization timeline. Tech Funding News put it precisely: "The proof will be measured speed-ups on chips customers already own. Until the lab publishes them, the $6 billion rests on who is building it."

The honest counter-signal: megakernel work is not dead, just contested. Cursor open-sourced MoK, a training megakernel for NVL72 systems, claiming a 41% increase in tokens per second. The debate is whether the extreme version — one kernel for training plus inference plus a game, all at once — generalizes beyond demos, and whether production stacks keep it instead of modular kernels.

The neolab is the new biotech — without the milestones

Zoom out and the pattern is the story. Thinking Machines Lab raised $2 billion at $12 billion and already reports more than $200 million in annualized revenue. Nvidia has made 32 investments in startup model-makers, more than anyone else.

Dealroom's warning is worth reading twice: unlike biotech, neolabs "have no milestones and need to show results more often." Biotech has a ritual of proof — clinical trials. A neolab has the founders' word, the investors' conviction, and a clock that only ticks when someone publishes a benchmark.

What to actually watch

Ignore the valuation. Watch for one thing: the lab's first measured speedups on hardware customers already own. Tokens per second, memory saved, training runs shortened — against TensorRT-LLM and vLLM baselines. Until that exists, every number in this story is a bet, not a result.

To understand the technique rather than the money, start with ThunderKittens — Ben Spector's open-source kernel toolkit is the closest public window into how this team thinks. And if you are budgeting GPU capacity for next year: the smart money is betting efficiency, not more racks, is the binding constraint. Plan accordingly.

References

A Certificate Authority's Private Keys Were Smaller Than 256. It Just Quit the Business.

Mahmud Hasan — Fri, 23 Oct 2026 06:32:03 +0000

Here's the entire business model of a certificate authority in one sentence: it generates numbers so random that nobody on Earth can guess them, and then vouches that everyone else's numbers came from the same process. The randomness is the product.

So imagine what happens when one of the companies selling that product turns out to have generated keys of 4, 56, 66, 115, 155, 156, 230, and 237. Numbers a laptop can recover from the public certificates in under a second. A three-digit bike lock has more combinations.

That's what happened at eMudhra, a publicly listed Indian certificate authority. On October 22, its board voted to shut down the company's entire global SSL/TLS business. The stock had already fallen 36% in two trading sessions. The remarkable part isn't the failure — it's how fast the internet's immune system worked: a researcher reported the weak keys at 18:05 UTC on October 17, and by 19:45 Chrome had already blocked them worldwide, no browser update required.

What a certificate authority actually does

Your browser doesn't actually know who yourbank.com is. It trusts a chain. At the top sit roughly 150 root certificates baked into your operating system and browser — the "root store." Those roots delegate the daily work to intermediate CAs, which sign the actual certificates websites present to you.

Whoever holds an intermediate CA's private key can issue a certificate that browsers will accept for any domain. That's not a metaphor: with eMudhra's compromised keys, someone could have minted a certificate for your bank, your email provider, or your company's login page, and your browser would have shown the reassuring padlock. Two of the eight intermediates were also code-signing CAs — the kind whose keys let software installers claim "this came from a verified publisher." Same trick, different target: malware wearing a legitimate name tag.

The single most important object in the whole system is the private key, and a private key on the P-384 elliptic curve is supposed to be a randomly generated 384-bit number — roughly 10115 possibilities, more than the number of atoms in the observable universe. Guessing one should take longer than the universe will exist. eMudhra's keys were all smaller than 256.

A safety test introduced the flaw

The story starts on April 30, 2025, at a key-generation ceremony — the formal, audited event where a CA creates its most important keys on locked-down hardware with witnesses watching. eMudhra added an approved extra step that day: a test of how keys are wrapped and unwrapped.

A flaw in that step, by the company's own account, produced a second, weaker set of keys alongside the strong ones. Similar labels meant staff picked the wrong set for the certificate signing requests. The extra safety test is what broke the safety.

What should worry you more is what happened next. The weak keys survived two independent audit cycles. Audits verify that you followed a process — they don't sanity-check whether the output was a sane key. Nobody looked at the master key and noticed it was labeled "4." The company's co-founder later called it a "one-off human and script error... on a bad day," and admitted that an earlier mishap — a certificate revocation list error in May 2025 — should have triggered a closer investigation. It didn't.

The internet ejected it in 100 minutes

The system did work, though — just not at the CA. A researcher going by "Wayne" ran a check against the public CA database, realized the keys were recoverable, and reported them to Google's Chrome Root Program at 18:05 UTC on October 17, signing his message "We have a problem here – Wayne" with each of the eight keys to prove he held them. Mozilla independently recovered the keys within about two hours.

What followed was the trust system's emergency procedure executing at speed:

19:45 UTC, October 17 — 100 minutes after the report — Chrome pushed a CRLSet update blocking the six website-issuing intermediates. No user update or restart needed; every Chrome user was protected at once.
20:06–22:59 UTC — Mozilla pushed a OneCRL block to Firefox users with standard settings.
October 18 — eMudhra revoked all eight intermediates for "CA compromise" (09:24–09:38 UTC).
October 19 — Apple blocked the certificates; Sectigo revoked its cross-signatures.
October 20 — Microsoft blocked them; Mozilla removed the emSign ECC Root CA – G3 from its trusted root list; Go shipped fixes on its rarely-used URGENT track.
October 21 — India's CERT-In issued advisory CIAD-2026-0050: update browsers and operating systems, replace affected certificates.

Google's security teams noted the detail that matters in retrospect: the keys never had to be stolen. They were generated with too little randomness, so anyone could compute them from the public certificates. And because no certificates chaining to the weak intermediates had ever been logged to Certificate Transparency — the public ledger browsers require — no fraudulent certificate could have been silently trusted in Chrome or other CT-enforcing browsers. The exposure was real; the damage was contained.

Why quitting the business is the rational move

eMudhra's board concluded that "withdrawing from global SSL/TLS is the right decision for eMudhra and its shareholders." The business contributed about 1% of global revenue; the chairman cited rising compliance costs and free-certificate competition — then added that "the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS's place in our business."

He's not wrong about the economics, but the framing undersells what happened. For most certificate authorities, SSL/TLS is the entire business. eMudhra is quitting a business where its core competency — generating unguessable numbers — failed in public, in front of every browser vendor on Earth. Roughly 30,000 certificates need replacing, free through partners; its RSA roots keep serving customers during the transition; and an independent audit of its key inventories will be published. Its other businesses — digital signatures, eSign, enterprise PKI — run on separate infrastructure and are, per the company and India's IT ministry, completely unaffected. That separation is now the most valuable sentence in its press release.

What this means for you

If you run websites: check whether any of your certificates chain to eMudhra's emSign ECC Root CA – G3 or the G3B/G3C intermediates. If they do, replace them — free replacements are offered through partners, and Chrome's Root Store v43 (around October 27) will distrust the remaining root entirely. Browsers already did their part automatically; Go developers should be on the October 20 security release.

The eMudhra incident had no breach, no intruder, no stolen data. Nothing was "hacked." The failure was in the one process the entire certificate system is built on, and the two audits that certified it. Key generation is the least glamorous part of cryptography — and the only part that matters, because everything above it assumes the numbers were random.

And the part worth remembering the next time someone tells you a process is safe because it was audited: two auditors signed off on private keys smaller than 256. The check that caught it was one researcher with a laptop and less than a second of compute.

References

How to Deal With Burnout: Why Rest Alone Won't Fix It

Mahmud Hasan — Fri, 23 Oct 2026 02:31:56 +0000

Here's an uncomfortable statistic: in a Dutch study that tracked 96 workers across a winter-sports vacation, every health and mood gain they felt on holiday had evaporated within the first week back at work. And a 13-study meta-analysis confirmed it — the restorative effect fades to essentially zero after that first week. Rest didn't fix burnout, because burnout was never a rest problem.

Burnout isn't rare: BCG's June 2024 survey of 11,000+ workers in eight countries put it at 48%; Eagle Hill put the U.S. figure at 55% in November 2025, a six-year high. So what actually works? The research points somewhere most advice columns don't: the fix isn't more rest, it's less mismatch.

First, what burnout actually is

The ICD-11 definition (adopted 2019, code QD85): burnout is "a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed." Its three dimensions: feelings of exhaustion, mental distance or cynicism toward the job, and reduced professional efficacy — and one scope rule: it "refers specifically to phenomena in the occupational context," classified as an occupational phenomenon, not a disease.

Christina Maslach, the Berkeley researcher behind most burnout measurement tools, argues this framing misses something: treating burnout as the worker's diagnosis turns the worker into the problem, instead of examining the organization that produced the stress. Her framework, developed with Michael Leiter in the late 1990s, says burnout comes from chronic mismatch between a person and their job in six areas: workload, control, reward, community, fairness, and values. Bigger mismatch, more burnout; more alignment, more engagement.

Why the vacation won't save you

The fade-out finding is one of the most replicated in this literature. De Bloom's team tracked 96 Dutch workers over seven weeks around a winter-sports vacation: well-being rose during the trip on five of seven indicators, then sank back to pre-vacation levels within a week of return. A follow-up on 54 employees taking 23-day vacations found well-being peaked on day eight and hit baseline within a week back. And Etzion showed 7–10-day vacations and 10+ day vacations produced essentially the same burnout effects — length doesn't buy durability.

The 2022 meta-analysis (13 studies, 1,428 workers) put a number on it: vacations improve well-being modestly, but there's no significant difference from pre-vacation levels after the first week back. Duration didn't change the result. The authors' recommendation: plan regular short vacations throughout the year instead of one long one.

Fritz and Sonnentag found the benefits erode fastest for people returning to heavy workloads; the 2025 review puts it bluntly: return to a high-stress environment, and benefits erode faster. The vacation removes you from the stressor; it doesn't change the stressor. Returning to the same workload at the same pace reconstructs the same problem.

The myth to retire: burnout is not a rest deficit, so rest can't cure it. Rest buys you about a week.

What actually recovers people: detachment

The most evidence-backed recovery lever isn't more sleep — it's psychological detachment: mentally leaving work while you're away from it. Sonnentag and Fritz's 2015 review found heavy demands make detachment harder, and low detachment predicts more burnout. A 12-month study of 309 human-service employees found detachment predicted lower emotional exhaustion and buffered the damage job demands did to health and engagement.

That isn't just correlation: two 2020 experiments had people detach on instruction — think of a hobby, follow a script — and negative affect dropped, most for those who felt worst at day's end. And Sonnentag's 2012 work found evening detach-ers reported higher life satisfaction and fewer strain symptoms without being any less engaged at work. Detachment doesn't make you care less on the job; it makes the off-hours actually count.

Detachment is one of four recovery experiences Sonnentag and Fritz identified (detachment, relaxation, mastery, control over leisure time). The practical version, from Heidi Grant's 2022 synthesis for Harvard Business Review:

Move your body. Exercise is one of the most consistently supported recovery strategies — any kind you enjoy. (Koch's 2024 diary study of 93 employees found a "recovery paradox": people exercise less after stressful workdays — exactly when they need it most — and detachment right after work is the prerequisite for the exercise.)
Do something hard that isn't work. Mastery experiences — learning a language, an instrument, volunteering, anything that demands focus — replenish resources through effort, not rest. Counterintuitive, but the spending restores the supply.
Get outside, even briefly. A lunchtime park walk helps in as little as ten minutes; daylight, window views, and desk plants measurably improve sleep and perceived stress.
Decide what your evenings are for. Choosing what you do after hours, instead of defaulting into the couch, is its own recovery dimension.

Build an end-of-workday ritual that switches your brain out of job mode. A shutdown checklist, the commute, a run, a walk around the block — the form matters less than the consistency. The people who recover aren't the ones with the lightest loads. They're the ones whose evenings don't belong to their inbox.

The mismatch that no amount of jogging fixes

Detachment handles the exhaustion dimension. But Gallup's research (~7,500 U.S. employees: 76% experience burnout at least sometimes, 28% "very often" or "always") points at the structural part. The five factors most correlated with burnout are nearly all about management: unfair treatment (2.3× the burnout), unmanageable workload (2.2×), unclear expectations (knowing what's expected means 47% less burnout), lack of support (~70% less burnout with support), and unreasonable time pressure (70% less with enough time). Managers who genuinely listen: 62% less burnout.

Gallup's own summary is the quote worth pinning: "It's not just the number of hours you work; it's how you're managed and how you experience work during those hours." Risk climbs past 50 hours a week — but how people experience their workload predicts burnout more strongly than hours alone.

Do the six-area audit. Which mismatch is yours? If it's workload or control, you can often redesign your own work: say no to something, demand a clearer definition of done, negotiate which fires are actually yours. If it's fairness or values, no recovery ritual fixes it — that's a change-the-job or leave-the-job problem, and naming it is the honest first step.

Know when it isn't (only) burnout

One finding changes the advice. In a study of 5,575 teachers, 90% of those classified as burned out met diagnostic criteria for depression, and 92% scored at or above the PHQ-9 treatment threshold. A 2021 meta-analysis of 12,417 people put the exhaustion–depression correlation at r = .80 — stronger than with the other burnout dimensions. The researchers' recommendation was direct: clinicians should systematically assess depressive symptoms in anyone presenting with "burnout."

Burnout lives in the occupational context. If the exhaustion follows you out of work — covering weekends, relationships, everything — or there's hopelessness, worthlessness, or any suicidal thoughts, no detachment ritual fixes it. Talk to a professional. At PHQ-9's threshold of 15, the researchers recommend active treatment with therapy and/or medication.

Self-care advice that never mentions this boundary isn't evidence-based. It's just reassuring.

What to do this week

One: build an end-of-workday ritual — the same five minutes, every day, that moves your brain off the job. Two: pick one recovery experience you're getting zero of and schedule it like a meeting. Three: write down which of the six mismatches is driving yours, and name the one conversation that could change it. Four: if rest and time off change nothing, and the hopelessness doesn't respect work's boundary — get professional help.

The vacation will feel good — just don't expect it to do the job it can't do. The fix was never more time away from the machine — it was changing what the machine asks of you, and leaving it behind when you log off.

References

WHO, "Burn-out an 'occupational phenomenon': International Classification of Diseases" — departmental news, May 28, 2019 (ICD-11 code QD85) — pennsylvania.gov (reprints WHO statement)
Leiter, M.P. Maslach, C. (2005), "Areas of Worklife: A Structured Approach to Organizational Predictors of Job Burnout" — researchgate.net
Sonnentag, S. Fritz, C. (2015), "Recovery from job stress: The stressor-detachment model as an integrative framework," Journal of Organizational Behavior — summary
Sonnentag, S., Binnewies, C. Mojza, E. J. (2010), "Staying well and engaged when demands are high," Journal of Applied Psychology, 95(5), 965–976 — PubMed 20718528
Sonnentag, S. (2012), "Psychological detachment from work during leisure time," Current Directions in Psychological Science, 21(2), 114–118 — APA PsycNet
Sonnentag, S. Niessen, C. (2020), "To Detach or Not to Detach," Frontiers in Psychology — APA PsycNet
De Bloom, J. et al. (2010), "How do vacations affect workers' health and well-being?" Work Stress, 24, 196–216 — researchgate.net
European Psychologist (2022) meta-analysis of vacation effects, 28(4), 274–287 (13 studies, N=1,428) — APA PsycNet
Grant, H. (2022), "How to Recover from Work Stress, According to Science," Harvard Business Review — hbr.org
Gallup, "Employee Burnout: The Biggest Myth" Employee Burnout: Causes and Cures (~7,500 U.S. full-time employees) — gallup.com
Gallup, "Employee Burnout, Part 1: The 5 Main Causes" — gallup.com
Bianchi, R., Schonfeld, I. S. Laurent, E. (2014), "Is burnout a depressive condition?" — CUNY Academic Works
Bianchi, R. et al. (2021), meta-analysis, Clinical Psychological Science, 9(4), 579–597 — APA PsycNet
Boston Consulting Group (June 2024), global burnout survey (11,000+ workers, 8 countries); APA, Work in America Survey 2025 (44% "often/always"); Eagle Hill Consulting (Nov 2025), 55% U.S. workforce

How to Give Feedback at Work That People Actually Use

Mahmud Hasan — Thu, 22 Oct 2026 19:19:51 +0000

How to Give Feedback at Work That People Actually Use

A landmark meta-analysis found over a third of feedback interventions made performance worse — not because feedback is useless, but because most of it aims at the person instead of the task. Here is the research-backed way to give it.

You won't hear this at the average management training: a lot of feedback makes people worse at their jobs.

In 1996, Avraham Kluger and Angelo DeNisi published a Psychological Bulletin meta-analysis covering 607 effect sizes from 23,663 observations. Average effect: a moderate improvement (d = 0.41) — but buried in the results: over one-third of the feedback interventions decreased performance. Not "failed to help." Made things worse.

Their explanation is the whole post in one line: feedback works when it keeps the listener's attention on the task, and backfires when it pushes attention up a level, onto the self — onto what it says about who they are. "This section needs restructuring" keeps the spotlight on the work; "You're careless" moves it to the person, and performance drops. The skill in how to give feedback at work is not volume. It is aim.

People want the critique you are afraid to give

Zenger and Folkman's 2014 research (an HBR blog post, 2,700 survey respondents) exposes a mismatch. Leaders are twice as likely to give positive feedback as corrective feedback: generous with praise, stingy with the critique that would actually change something. In two related surveys of nearly 8,000 managers, 44% said giving negative feedback felt stressful and difficult; a fifth avoided it entirely.

But the recipients want the opposite. The people who preferred corrective feedback over praise also rated their managers highest for being honest and straightforward. Your team doesn't need you to be nicer. It needs you to be straighter.

That mismatch is why the default management style is Kim Scott's "ruinous empathy": withholding feedback to spare feelings, which feels safe while the fixable problem quietly gets worse. Scott, a former Google and Apple executive, built her 2017 framework Radical Candor on two axes: Care Personally and Challenge Directly. High on both is radical candor; challenge without care is obnoxious aggression; care without challenge is ruinous empathy; low on both is manipulative insincerity. Her line worth memorizing: "Candor is measured at the listener's ear, not at the speaker's mouth."

The three sentences that do the work

The most mechanical model comes from the Center for Creative Leadership's Feedback That Works (2000): Situation–Behavior–Impact, or SBI. Three sentences:

Situation: anchor to a specific time and place. "In yesterday's client review…" — not "Lately you've been…"
Behavior: describe what happened the way a camera would record it. "You interrupted Priya twice while she was presenting the timeline" — not "You were rude."
Impact: say what happened as a result. "She stopped contributing, and we left without an owner for the migration." The step managers most often skip — the one that turns a complaint into a reason to change.

CCL later added Intent — making SBII: after the impact, ask what they were trying to accomplish, because "your intent misfired" lands very differently from "you're bad at this." Every sentence keeps the spotlight on the task, never the self.

SBI works for praise too, where it is most underused. "Your summary at the start of the call laid out the three risks before they asked, and the rest of the meeting was about solutions" tells the person exactly what to repeat. One caveat, from Buckingham and Goodall's 2019 HBR "Feedback Fallacy": we are not the reliable raters of others we think we are, and excellence is idiosyncratic — "spiky," not well-rounded. Treat feedback as a tool for closing a gap, not for correcting people toward an abstract standard.

Why the feedback sandwich fails

Ben Horowitz called the praise-criticism-praise sandwich a "shit sandwich": the structure protects the deliverer, not the receiver. It exists so you feel brave enough to say the middle part — which the recipient barely hears anyway.

Cleveland State's Ben Baran found the mechanism: all-positive or all-corrective feedback in one conversation beats mixing the two. Put the critique in its own conversation, directly and kindly; save praise for moments that deserve their own spotlight. Both become more believable.

How to run the conversation

Scott's criticism mnemonic is HIP: Humble, Helpful, Immediate, In person, In private, Not about personality. Three do the heavy lifting.

Immediate: Gallup's 2024 research: 80% of employees who get meaningful feedback weekly are fully engaged; employees who get it daily are 3.6 times more likely to be motivated than those who get it annually. Annual feedback is archaeology.

In private: non-negotiable for corrective feedback, for the Kluger-and-DeNisi reason — a public correction pushes attention straight to the self, everyone watching, and away from the task. Praise can go public.

Not about personality: the whole game. "You need to be more detail-oriented" is a verdict on a person. "The last two releases shipped with the changelog missing; support got 14 tickets about features that were already live" is a camera recording plus its impact. Only one can be fixed by Friday.

Before you deliver anything, ask for their view. "How did you feel the client review went?" People commit to fixes they helped shape — and the behavior you were about to critique sometimes has a reason you don't know about.

The tricky one: feedback to your own manager

Stick to your own observations — never claim to speak for the team. "Three people have told me…" reads as a conspiracy; "I noticed…" reads as data. Frame it as Action → Result → Solution: what happened, what it caused, one concrete suggestion, delivered soon after the event — stale upward feedback reads like a grudge. Skip the "if I were in charge…" framing: HBR's Amy Gallo notes it reads as arrogance.

None of this works unless the manager invites it. Google's Project Aristotle studied 180 teams and 250-plus attributes (2012–2016): seniority and tenure didn't reliably separate strong teams from weak ones. What mattered most, in analyst Julia Rozovsky's words, was "far and away" psychological safety — a shared belief that the team is safe for interpersonal risk-taking (Amy Edmondson's 1999 definition). Her hospital studies showed its signature: the units where people felt safest reported more errors — not because they made more, but because errors got surfaced and fixed instead of buried — same as a junior telling a manager the plan has a hole in it.

What to do this week

Pick one conversation you have been avoiding. Write three sentences — situation, behavior, impact. Schedule it, privately, this week. Ask for their view first; end with one concrete next step and a check-in date.

And when they do the thing, notice it out loud, in SBI form. The one-third isn't an argument against feedback — it is an argument against feedback aimed at the person. Aim at the task.

References

Avraham N. Kluger Angelo DeNisi, "The effects of feedback interventions on performance: A historical review, a meta-analysis, and a preliminary feedback intervention theory," Psychological Bulletin, 1996, Vol. 119, No. 2 — doi.org/10.1037/0033-2909.119.2.254
Jack Zenger Joe Folkman, "Feedback: The Powerful Paradox" white paper, 2019 (based on the 2014 HBR blog post and 2,700-respondent survey) — zengerfolkman.com
Kim Scott, "What is Radical Candor," Radical Candor (radicalcandor.com) — radicalcandor.com
Gallup, "Creating a Culture of Recognition Feedback," 2024 — gallup.com
Sloan R. Weitzel, Feedback That Works: How to Build and Deliver Your Message, Center for Creative Leadership, 2000 — overview at wikipedia.org/wiki/Situation-Behavior-Impact
Marcus Buckingham Ashley Goodall, "The Feedback Fallacy," Harvard Business Review, March–April 2019 — hbr.org
Lattice, "How Employees Can Give Feedback to Their Boss" — lattice.com
Ben Baran on uniformity in feedback, via business.com — business.com

A Russian Satellite Just Shadowed a US Satellite at 500 Meters. The Mechanics Are the Scary Part.

Mahmud Hasan — Thu, 22 Oct 2026 16:41:57 +0000

A Russian Satellite Just Shadowed a US Satellite at 500 Meters. The Mechanics Are the Scary Part.

A rendezvous and proximity operation — RPO — is when one satellite deliberately flies to another and works near it. Last week, Russia's Cosmos 2612 ran an unconsented one in low Earth orbit against a US-registered commercial satellite, closing from 320 kilometers to roughly 500 meters and holding station all weekend. It took three weeks of burns to get there. It is the closest uncoordinated rendezvous ever observed — and no law says how close is too close.

What actually happened between October 15 and 19

Cosmos 2612 is one of six Russian satellites launched together in April 2026 from Plesetsk. Moscow has said nothing about its payload; analysts treat it as an inspector. Its target was ICEYE-X36, a roughly 90-kilogram radar satellite operated through the US arm of Finnish-founded ICEYE. The groundwork started in May, when five of the six Kosmos satellites made fuel-hungry plane changes — about 0.8 degrees, costing roughly 105 m/s of delta-v each — a spend CSIS flagged as unusual. ICEYE's CEO told Reuters the company had moved its satellite in response.

The real campaign began September 30: Cosmos 2612 raised its orbit by about 47 kilometers and let natural drift realign its plane. On October 12 it fired a 27.9 m/s burn, dropping to roughly 555 km — about one kilometer below its target — and began the sprint. From over 320 kilometers out on October 15 to inside 5 kilometers the next morning, then roughly 35 to 40 hours holding station, deliberately sliding ahead of and behind its target. A Swiss firm caught the pair on a time-lapse over South America on October 18 — two dots in formation at 7.6 kilometers per second. Then a departure burn, and Cosmos 2612 drifted away at roughly 350 kilometers a day. No collision, no damage, no confirmed hostile act.

Public tracking models spit out figures as small as 26 meters, but the public element data behind them carries roughly 1.9 kilometers of in-track uncertainty — the 26-meter figure is a model's extrapolation, not a measurement. LeoLabs, which tracked the event with its own radar, states high confidence the pair came within about 500 meters.

What a rendezvous and proximity operation actually takes

"Cooperative" RPO means the target helps — docking ports, beacons, shared telemetry, like cargo vehicles visiting a station. "Uncooperative" RPO means the target is passive or unaware, so the chaser carries its own sensors to measure a relative position nobody is handing it.

Two things make the Cosmos 2612 profile impressive. First, plane matching: at LEO velocities, closing on something in a different orbital plane is a fuel problem, not a steering problem — Cosmos 2612 spent an estimated 175 m/s total since launch, about 60 m/s more than its sister satellites. Second, the phasing. To catch a target in the same plane, you drop slightly lower so your shorter orbit gains on it — two kilometers lower buys roughly 300 km/day of closure at 550 km. That drift is slow, which is why the campaign needed three weeks. The final approach then needs active control: small burns to arrest the drift and hold position. Doing that for nearly two days inside three kilometers is the "most advanced" part of what LeoLabs observed, per its VP for technical solutions, Adam Marsh.

What a 500-meter parking spot lets you do

LeoLabs' framing runs inspect, characterize, shadow, or potentially interfere. The analyst version: inspect means sensor-mapping the target's exterior; at sub-kilometer range, intercepting its emissions gets interesting too. Shadowing means persistent following — know where the imaging satellite is, and you can schedule your secrets around its passes. Coercive signaling is the demonstration itself: visibly showing you can reach the target forces the operator to burn its own finite propellant dodging. Interference and disruption sit further along; kinetic sits at the far end.

The core problem is not technical: a benign inspection profile and a hostile one look identical in tracking data until the moment something happens. Both need the same approach, the same loitering, the same departure. LeoLabs explicitly stated its observations "do not establish hostile intent." The payload is undisclosed, so what end of the spectrum Cosmos 2612 could reach is unknown. Capability and intent are separable — and in orbit, only the first is observable.

The precedents, and why this one outruns them

Russia has done versions of this at arm's length. In July 2020, Kosmos 2543 released an object at up to 186 meters per second relative velocity, which the head of US Space Force disclosed as an on-orbit anti-satellite weapons test. In November 2021, Russia destroyed its own Kosmos-1408 satellite with a ground-fired Nudol missile, generating more than 1,500 trackable debris fragments. In January 2022, China's Shijian-21 docked with a dead navigation satellite and towed it 3,000 kilometers into a graveyard orbit — dual-use, US officials warned: anything that can grapple a dead satellite can grapple a live one.

The United States does close-approach inspection too: the Geosynchronous Space Situational Awareness Program has maneuvered through the geostationary belt since 2014. Nobody with a space program is innocent of RPO. But every previous uncooperative episode kept tens of kilometers of separation and targeted government satellites. Cosmos 2612 closed to half a kilometer, in crowded low Earth orbit, against a commercial spacecraft. The Secure World Foundation's Victoria Samson: "in these earlier cases, the satellite that was being approached was a USG satellite; obviously in this case, it was a commercial satellite."

Why a commercial satellite changes the legal math

ICEYE has supplied radar imagery — the kind that sees through cloud and darkness — to Ukraine's military since August 2022. (Whether ICEYE-X36 itself serves Ukraine is not publicly confirmed.) Russia has repeatedly said "quasi-civilian" commercial satellites used for military purposes may become legitimate targets for retaliation.

No law settles what happened last week. The Outer Space Treaty declares space free for use by all states and defines no minimum safe distance, no keep-out zone, no right of way. There is no binding space-traffic regime for low Earth orbit; warnings come from the US military and commercial trackers like LeoLabs, and no authority can order a satellite to back off. US Under Secretary of State Thomas DiNanno told the UN First Committee Cosmos 2612's behavior "threatening" and "consistent with on-orbit weapons operations" that violated "long-established safety thresholds" — thresholds that exist nowhere in writing.

That gap is the story. Two facts are undisputed: the closest approach ever observed for an uncoordinated rendezvous, and the first commercial target — a private, US-registered asset in an active war's supply chain, with no established playbook for a response.

The takeaway

The episode ended quietly: a departure burn, no collision, a satellite drifting away at 350 kilometers a day. But it showed, in the open, that a military operator can spend three weeks and a modest fuel budget to park beside a specific commercial satellite — and that the victim's options are to burn its own fuel dodging, or do nothing. Space has spent sixty years assuming close approaches are rare, accidental, and self-evidently unfriendly. Cosmos 2612 just showed they're none of those things — and the rules for what happens next don't exist yet.

References

How to Choose Between Postgres and MySQL: Five Questions, Not Benchmarks

Mahmud Hasan — Thu, 22 Oct 2026 08:51:51 +0000

Every new project starts with the same quiet question: Postgres or MySQL? The standard answer in 2026 is "just default to Postgres" — and it's right more often than it's wrong. But "more often" is doing a lot of work in that sentence. I spent this week in the 2026 release notes, benchmarks, and operational war stories so you don't have to. The honest version: the decision isn't settled by benchmarks. It's settled by five practical questions.

The benchmarks won't settle this for you

Every Postgres vs MySQL post opens with a benchmark table, and nearly every one of those tables is lying by omission. Both databases ship defaults sized for a laptop — shared_buffers and innodb_buffer_pool_size both default to 128MB — so most published benchmarks measure configuration, not engines. On tuned hardware, most workloads land within about 30% of each other, and the right index matters 10x to 1000x more than the engine choice.

That said, the edges are real and they're workload-shaped. MySQL is genuinely faster at simple single-table OLTP and read-heavy work — up to ~21% higher peak TPS in sysbench-style tests, and Oracle moved the Thread Pool into Community in MySQL 26.7. Postgres wins where queries get complicated: multi-table joins, window functions, JSONB queries, full-text search — and PostgreSQL 18's async I/O pushes storage-bound reads up to ~3x faster. At extreme write intensity, MySQL's InnoDB has one more edge — old row versions live in the undo log, so heavily updated tables never bloat — but unless you're at Uber's scale, treat all of this as tiebreakers, not deciders.

Question 1: What does your team already know?

This is the boring answer and the correct one. A team fluent in MySQL ships a safer system on MySQL than on a Postgres it will learn by incident. Postgres has a learning curve MySQL doesn't. If your team already runs one of them well, the decision is mostly made.

The Stack Overflow Developer Survey 2026 (published October 7) puts numbers on the drift: 57.9% of developers used PostgreSQL in the past year versus 35.1% for MySQL — its fourth straight year topping "most used" and "most admired." DB-Engines' October 2026 snapshot tells the other half: MySQL is still #2 overall (837.96) ahead of Postgres at #4 (688.75) — incumbency versus momentum. Hire for the fleet you have.

Question 2: What shape is your data?

This is where the engines genuinely differ. If your application queries inside semi-structured JSON, Postgres's JSONB is the better document store and it isn't close: one GIN index covers the entire document at once. In MySQL you can't index a JSON column directly — you add a generated column over one specific path and index that, by hand, per path. (MySQL 9.6's JSON Duality Views are a clever counter-move: read and write JSON documents while the server stores normalized relational rows. Postgres has no equivalent.)

For AI workloads the gap is wider. pgvector's HNSW and IVFFlat indexes are the standard for RAG and semantic search inside one ACID database — one CREATE EXTENSION and your existing Postgres does vectors. MySQL has had a native VECTOR type since 9.0, but through MySQL 26.7 the Community Edition still lacks native distance functions and ANN indexing; DISTANCE() lives in the proprietary HeatWave tiers. If your roadmap has "add vector search," that's nearly a one-question decision.

Geospatial is the same story: PostGIS is the industry standard, full stop. And the extension ecosystem is Postgres's deepest structural advantage — pg_cron for scheduled jobs, TimescaleDB for time series, foreign data wrappers that query other systems — 400+ catalogued extensions, all coexisting in one database. MySQL never grew an equivalent extension culture.

Question 3: How will you run it?

Databases are not just query engines; they're things you operate at 3 AM. MySQL's high-availability story is simpler to adopt: Group Replication gives you multi-primary-capable HA with automatic primary election inside the server, and 26.7's Change Stream Applier finally answers replica lag under write bursts. Postgres's replication is flexible — WAL streaming plus logical publish/subscribe — but failover orchestration is not in core. Production Postgres HA means Patroni or equivalent, run by you.

Then there's the tax each engine charges. Postgres charges it as operational literacy: MVCC keeps old row versions in the table, so heavy update/delete workloads bloat tables and need vacuuming — and the quiet catastrophic version, MultiXact member exhaustion, is invisible on standard dashboards. Postgres also uses a process-per-connection model — roughly 2ms per new connection versus MySQL's ~0.8ms — so careless connection handling melts a Postgres instance. A pooler like PgBouncer is not optional in production.

MySQL charges its tax as upgrade discipline. MySQL 8.0 went end-of-life in April 2026, and Oracle switched to calendar versioning: MySQL 9.7.0 LTS is the production baseline, 26.7.0 Innovation shipped July 2026, and there will never be a 9.8. Upgrades must follow compatibility lineages — 8.4 to 9.7 to 26.7 — so for the world's largest MySQL fleets, 2026 was a project, not a patch. If you're already on 8.0, your near-term decision is "upgrade to 9.7," not "Postgres or MySQL." Don't stack a cross-engine migration onto a forced upgrade deadline. Two risky projects, one deadline.

Question 4: Are you shipping the database itself?

For most web apps this question doesn't apply — but when it does, it overrides everything else. PostgreSQL's license is liberal, BSD/MIT-style: embed, fork, ship commercial products, no obligations. That's why every modern app platform standardized on it. MySQL Community is GPLv2: if you distribute MySQL bundled inside your commercial software, the GPL requires your software to be under a GPL-compatible license — or you buy a commercial license from Oracle. Running MySQL behind your SaaS is unaffected (no distribution of the server itself), which is why cloud MySQL thrives; but appliances, OEM embeds, and shipped on-prem software hit a real decision point, and it's Oracle on the other side of the table. It's also why MariaDB exists. Postgres has no enterprise/community split — what you download is what everyone runs.

Question 5: What happens when you outgrow the choice?

The last question is the one people ask least and regret most. Data movement is the easy part — pgloader moves MySQL to Postgres in one command, schema discovery plus parallel COPY. The real cost is the application: the dialect conversions (AUTO_INCREMENT to SERIAL, ON DUPLICATE KEY UPDATE to ON CONFLICT, backticks to double quotes), rewritten stored procedures, and the gotcha that bites first — a MySQL "database" is closer to a Postgres schema than a Postgres database. Budget weeks to months for a production app with heavy MySQL-isms. One skeptical look at the consensus: "Postgres for everything" is one operational surface, but each workload deserves a conscious check before being folded in — a default this strong stops feeling like a choice.

So what do you actually do?

Run the five questions in order. If your team knows one engine well and the workload is ordinary, stop there — ship on what you know. Starting fresh with no legacy: Postgres is the 2026 default — extensions, JSONB, the managed ecosystem, the license, and the hiring market all agree. But the consensus is wrong in three specific, common cases: you're sitting on a MySQL 8.0 fleet (upgrade to 9.7, don't migrate); extreme write-intensive OLTP at serious scale (InnoDB skips the bloat tax); or your workload is simple, read-heavy, and your team already speaks MySQL.

Do this today: write down which of the five questions is doing the most work, and what would flip it. If you can't name the question, you don't have a decision yet — you have a preference wearing a benchmark table as a disguise. Whichever you pick, a well-tuned instance beats a neglected one — of either engine.

References

How to Run a Brainstorming Session That Actually Works

Mahmud Hasan — Thu, 22 Oct 2026 05:25:13 +0000

In 1953, advertising executive Alex Osborn promised that a group brainstorming together could think up twice as many ideas as the same people working alone. Five years later, Yale ran the first controlled test of that claim and found the opposite: people working on their own produced roughly twice as many good ideas as people brainstorming together. Here is how to run a brainstorming session that respects that result — because the meeting is still worth having, just not the way most teams run it.

The experiment that ruined brainstorming

In 1958, Taylor, Berry and Block at Yale ran 12 real groups of four through three problems using Osborn's official rules: no criticism, freewheeling, quantity first, build on each other's ideas. They also had 48 other people work alone, then randomly recombined those individuals into "nominal" groups of four and scored them as if they had worked together. The nominal group is exactly what the real group would have produced if talking to each other were neutral.

It wasn't neutral. The real groups were, in the authors' words, "markedly inferior" on total ideas, unique ideas, and three quality-weighted measures. The people who never spoke to each other produced roughly twice as many ideas.

The part that stings is the precision of the reversal. Osborn had written that "the average person can think up twice as many ideas when working with a group than when working alone." The first proper test found the effect going the other direction by about the same factor. One honest caveat: both conditions used Osborn's rules, so the study tested group versus individual under brainstorming rules — not brainstorming versus no method at all. The enemy was the group, not the rules.

Why talking first loses: production blocking

Three candidates were tested: social loafing (people coasting), evaluation apprehension (fear of sounding stupid), and production blocking — only one person can talk at a time, so everyone else waits, and while they wait their ideas decay. You forget the idea, or you spend your mental energy tracking the speaker instead of thinking.

Diehl and Stroebe (1987, Journal of Personality and Social Psychology) manipulated all three mechanisms directly and found that blocking accounted for "most of the productivity loss" of real brainstorming groups. A 1991 follow-up with 400 students confirmed it, and pinned down something sharper: the damage comes from cognitive interference during the delay between generating an idea and getting to say it, not from limited speaking time itself. The waiting is the poison.

Then the meta-analysis made it undeniable. Mullen, Johnson and Salas (1991) pooled 20 studies from 1958 to 1990: nominal groups produce substantially more nonredundant ideas and substantially more high-quality ideas than interactive groups — a large effect (r around .56–.57 on both counts). And the deficit grows with group size. Your eight-person war room is worse than two four-person ones.

Why it feels like it works anyway

This is the objection every manager raises, and it deserves an honest answer: if brainstorming is so bad, why does every company still do it?

Part of the answer is a documented self-deception. Stroebe, Diehl and Abakoumkin (1992) showed that group members rate their own brainstorming as more effective than it was — the "illusion of group effectivity." Group brainstorms are enjoyable, social, and loud. They feel creative. So we conclude they were.

The deeper answer comes from Sutton and Hargadon (1996), who spent a field study inside IDEO, then the largest product-design firm in the US. Judged purely on ideas per person, IDEO's brainstorms were no better than the lab said. But they served at least six functions the labs never measured: organizational memory, designer skill-building, an "attitude of wisdom" (acting with knowledge while doubting it), status competition, impressing clients who watched and joined — and, as they put it, fun. "Nearly everyone at IDEO likes them, and they feel their jobs are more interesting because of them."

So the ritual does real social work. The correct response is not to cancel the meeting. It is to keep the meeting and fix the mechanics.

What the evidence says actually works

The fix has a name: the hybrid approach. Write alone first, talk second. Girotra, Terwiesch and Ulrich (2010, Management Science) ran 4-person groups in both orders: the hybrid process generated about three times as many ideas, with average quality roughly 30 percentile points higher — "the difference between the 1st and the 30th idea in a pool of 100." And then the knife twist: Osborn's beloved "build on each other's ideas" rule was measured as counterproductive. Teams that did more building produced neither more ideas nor better ones.

The oldest working version of this is brainwriting 6-3-5, published by Bernd Rohrbach in 1968. Six people, each writes 3 ideas every 5 minutes, worksheets rotate through 6 rounds: 108 ideas in 30 minutes. Silent simultaneous writing kills production blocking and verbal dominance in one move — and everyone sees everyone else's written ideas without paying the turn-taking tax.

One more data point: when groups contribute simultaneously by typing instead of speaking, the verdict flips. Electronic brainstorming groups have been measured beating nominal groups — simultaneous typing removes blocking entirely and the synergy researchers kept hoping for finally shows up. (A caveat from the video era: camera-on video groups underperform face-to-face ones on fluency, which is why "write before you talk" is the design principle.)

And it is the best idea that counts, not the pile. Kornish and Ulrich (2014, Journal of Marketing Research), using real sales data from crowd-designed products, found that raw ideas one standard deviation better translated to roughly 50% higher sales. Organizations don't need more ideas. They need the ceiling raised.

The 60-minute agenda that actually works

Here is the session, end to end, with the research baked in. No special tools required.

0:00 — State the question as one sentence. "How might we improve onboarding?" is too broad. "How might we cut the time from signup to first value from five days to one?" is a brainstormable question. Write it where everyone can see it, and don't start until it's sharp.

0:05 — Silent writing, 15 minutes. Everyone writes alone. One idea per sticky note or card, no talking, no laptops, no peeking. This is the entire game — the science says this phase is where the ideas come from. Push for quantity; ten per person is a good floor.

0:20 — Round-robin read-out, 15 minutes. Each person reads their ideas out, one at a time, with no commentary or defense. A scribe clusters them into themes as they emerge. The rule is simple: evaluate nothing, capture everything.

0:35 — Silent dot-vote, 15 minutes. Everyone gets three votes (anonymous if the room has hierarchy) across two criteria: impact and feasibility. Voting creates a shortlist, not a verdict — but five survivors is about right.

0:50 — Convergence, 10 minutes. For each surviving idea, name an owner, one deliverable, and one deadline. An idea with no owner is entertainment, not work. And once the meeting ends, the notes still matter — write them for the person who wasn't there, or the decisions you just made won't survive the week.

Three rules that hold the whole thing together: no devices during the session, the same single question for everyone, and the meeting ends with owners or it failed.

Next week, change one thing about your next brainstorm: fifteen silent minutes before anyone speaks. The research has been sitting there since 1958. The only teams that benefit from it are the ones that rearrange the chairs.

References

Taylor, D. W., Berry, P. C., & Block, C. H. (1958). Does group participation when using brainstorming facilitate or inhibit creative thinking? Administrative Science Quarterly, 3(1), 23–47.
Diehl, M., & Stroebe, W. (1987). Productivity loss in brainstorming groups: Toward the solution of a riddle. Journal of Personality and Social Psychology, 53(3), 497–509.
Diehl, M., & Stroebe, W. (1991). Productivity loss in idea-generating groups: Tracking down the blocking effect. Journal of Personality and Social Psychology, 61(3), 392–403.
Mullen, B., Johnson, C., & Salas, E. (1991). Productivity loss in brainstorming groups: A meta-analytic integration. Basic and Applied Social Psychology, 12(1), 3–24.
Girotra, K., Terwiesch, C., & Ulrich, K. T. (2010). Idea generation and the quality of the best idea. Management Science, 56(4), 591–605.
Sutton, R. I., & Hargadon, A. (1996). Brainstorming groups in context: Effectiveness in a product design firm. Administrative Science Quarterly, 41(4), 685–718.
Rohrbach, B. (1968). Kreativ nach Regeln — Methode 635, eine neue Technik zum Lösen von Problemen. Absatzwirtschaft, 12, 73–75.
Kornish, L. J., & Ulrich, K. T. (2014). The importance of the raw idea in innovation: Testing the sow's ear hypothesis. Journal of Marketing Research, 51(1).
What is Brainstorming? Techniques, Tools, and Frameworks — Storyflow (2026 guide, framing section)
The Simple Secret to Running a Productive Brainstorm — The Heretic (silent-ideation opener)

PHP2Shell Is Patched (8.5.12, 8.4.27, 8.3.36, 8.2.35). Now Patch — the Exploits Are Already Circulating.

Mahmud Hasan — Wed, 21 Oct 2026 20:38:22 +0000

Yesterday, PHP's two critical RCE flaws were still a schedule: a patch at 14:00 UTC and a playbook for the hours before it landed. The patch has landed — PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 — and the October 2026 PHP security release is no longer about preparing. The exploits are circulating while most of the web is still on the old binaries.

The four versions that end this: 8.5.12, 8.4.27, 8.3.36, 8.2.35

Each php.net announcement for the October 21 release calls it what it is: "a security release fixing two critical vulnerabilities (CVE-2026-109618, CVE-2026-109619)." Advisories went public at 13:34 UTC, CVE records hit cve.org by 13:54, the fixed versions shipped at 14:00 UTC, and NVD had both analyzed (CVSS v3.1 9.8) by 17:00.

That 9.8 deserves one honest sentence: PHP's own 9.2 (CVSS v4.0) is the number to use; NVD's 9.8 is the same flaws under an older scoring version. Neither is the leak's made-up 10.0. The severity is real; the inflation wasn't.

The version table, from the advisories:

PHP 8.5 — vulnerable 8.5.11 and earlier → fixed in 8.5.12 (security support ends Dec 31, 2027)
PHP 8.4 — vulnerable 8.4.26 and earlier → fixed in 8.4.27 (ends Dec 31, 2026)
PHP 8.3 — vulnerable 8.3.35 and earlier → fixed in 8.3.36 (ends Dec 31, 2027)
PHP 8.2 — vulnerable 8.2.34 and earlier → fixed in 8.2.35 (ends Dec 31, 2026)

PHP 8.1, 8.0, and 7.4 get no official release — only source backports, no binaries. Per mySites.guru, 22.7% of the sites they monitor run PHP 8.1 or older. Yesterday's blunt version holds: if you can't upgrade today, isolate.

What the flaws actually do, now that the advisories are public

The embargo's lift brought real mechanics, and they're weirder than the leaked upload speculation suggested. Both flaws are memory bugs in PHP's engine — not in WordPress, not in your framework. The vulnerable code is in PHP itself: even a "Hello World" page on a vulnerable build is exposed.

CVE-2026-109618 — RCE via out-of-memory corruption. When PHP runs out of memory mid-request, it can get interrupted while its internal request data is only half-initialized; the cleanup path then treats that broken data as valid. Complete RCE was validated over HTTP against mod_php — one unauthenticated request, before any application code runs — and demonstrated against stock WordPress, Drupal, and Joomla container images. Reachable paths include multipart-upload tricks: parts with no declared content length, header-stuffed fields, piles of empty file fields. PHP-FPM is susceptible in theory; no complete FPM exploit has been shown.

CVE-2026-109619 — RCE via stale global state. Internal state tied to a request can survive after its memory is freed, and a later request handled by the same worker can use it before it's reset. Session-lifecycle RCE was validated against mod_php and PHP-FPM (the FPM path needs a suitable application operation). Confirmed trigger paths include session upload progress — on by default — and PHP 8.5's fatal_error_backtraces.

One detail in the 109619 advisory deserves its own line: the researchers confirmed it can disclose worker memory — passwords, tokens, API keys, certificates — without ever achieving code execution. Your secret scanner will not find this in your code. The leak is below your code.

The advisories' bottom line: "there are no complete mitigations — updating is the only safe choice." Config tweaks reduce exposure; they are not a fix.

The last 24 hours: leaked PoC, live attack traffic, sites going dark

PoCs are circulating CERT-EU's advisory 2026-018 says "initial proofs of concept have begun to circulate," which "raises the likelihood that attackers are already exploiting the vulnerabilities." One already escaped early: Calif — one of the credited research outfits — accidentally posted a working PoC video around 20:00 UTC on October 20, hours before the release. PHP's "no functional exploits at release" statement expired the moment the PoCs went public.

Attack traffic started before the patch existed. Cloudflare turned its WAF rules on at 03:02 UTC on October 21 — eleven hours before release — and says it has "observed attack traffic targeting our customers," with attackers already mutating payloads. Its advice is the right one: WAF rules are a seatbelt, not a fix. watchTowr's honeypots caught "active exploitation attempts" at 14:19 UTC, nineteen minutes after release; none had succeeded at last report. Patchstack, through its hosting partners, reports multiple active exploitation incidents.

People are pulling sites offline. When BreachForums and Dread go dark as a precaution, it's a signal. More consequentially: Dutch government portals (MijnOverheid, DigiD, parliament, the national cyber center), French Interior Ministry sites, Finnish services, a Danish school platform, and privacy org noyb all went offline. The US NSA told agencies to take systems offline if they can't patch; the UK's NCSC said the same.

The patching playbook: who gets the fix, in what order, and the traps

Ubuntu 24.04: USN-8948-1 backports the fix into 8.3.6-0ubuntu0.24.04.13 — the version string looks old because it's a backport. Check the changelog, not the version number. Debian 12/13 shipped fixed builds via DLA-4848-1 and DSA-6574-1.
Ondřej Surý's PPA: all four fixed versions by 13:36 UTC, plus a backport for 8.1.
Remi's RHEL repo: missed release day entirely — RHEL-family admins were told to switch to distribution packages or build from source.
Docker / Alpine: trailed by hours. An official php image rebuild at 15:59 UTC still shipped 8.5.11. Verify the digest you pulled actually contains the fix — don't trust the tag.

Now the order of operations is executable:

Find every PHP. php -v on every web root — app servers, panels, containers, CI runners, appliances. One line per binary, with its SAPI. Most teams find a PHP they forgot.
Patch internet-facing systems first, in order of exposure — and mod_php hosts before FPM ones, since that's where the demonstrated exploit path lives.
Restart every PHP worker after updating. The patch doesn't apply to running processes; old workers still serving are still vulnerable.
On EOL PHP (8.1 and older): no official fix exists. Isolate internet-facing apps from public networks, WAF them, and treat this as the forcing function for the upgrade you kept postponing.
WordPress on shared hosting: updating core, themes, and plugins does not fix this — the flaw is in the runtime underneath WordPress, and your firewall plugin fires after the attack does. Ask your host, verbatim: "Has the PHP fix for CVE-2026-109618 and CVE-2026-109619 been installed on my server?" Then check Tools → Site Health → Info → Server yourself.
After patching, hunt. Look for web workers spawning shells or interpreters. Exploit attempts now arrive within hours of disclosure — this time they started before it.

One fair objection: is this fear-mongering? The score was 9.2, not 10, and no successful attacks have been confirmed. The numbers cut the other way. Attackers got a full day of awareness before the patch existed; PoCs circulated within hours of release; Cloudflare was absorbing attack traffic eleven hours before disclosure. And the reach is total: ~70% of websites run PHP, the vulnerable code is in the engine, and the attack fires before a single line of your application runs. Patching today costs almost nothing. A web shell next week costs everything.

If you read yesterday's pre-release playbook, here's the one-line update: the fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, the exploits are real, and the package upgrade is the whole defense. Everything else is commentary.

References

Follow-up to Two 9.2-Rated Flaws in PHP. The Patch Lands Today at 14:00 UTC — Attackers Got a Day's Head Start.

How to Prioritize Tasks When Everything Is Urgent

Mahmud Hasan — Wed, 21 Oct 2026 14:40:06 +0000

You worked nine hours today. You answered the messages, sat through the meetings, bounced between tabs like a pinball. And if someone asks what you actually finished, you have to think about it.

This is not a laziness problem. It is a decision problem. When every item on a twenty-three-item list feels like it should be done today, your brain stops deciding and starts reacting — and reacting is what urgency is. The way out is not a better to-do list. It is a better rule for what you ignore.

Why everything feels urgent

Start with an uncomfortable fact: urgency is a feeling, not a property of the task. When a new request lands — a red notification, a message from your boss — your whole body tells you to drop what you were doing. Your focus narrows, your heart rate picks up a little, and acting right now feels like the only safe response. It isn't careful thinking. It is your survival wiring, and it was built for predators, not for deciding whether to answer a Slack thread or finish the proposal.

That wiring makes "busy" feel safer than "focused." Focused work means committing to one task and ignoring everything else, which is uncomfortable. Busy work gives you constant little hits of feedback — check, check, check — so your brain drifts toward what feels productive instead of what is. You can finish twenty tiny tasks and still avoid the one thing that mattered all day.

There is also a quieter problem: your list is lying to you. "Reply to email" and "write the annual plan" sit on the same list looking equal. They are not. One takes four minutes and the other takes four weeks, but your brain compares them by how loud they are, not how big they are. Add the four standard lies — Slack must mean urgent, quick wins first, I'm waiting on someone else, everything is high priority — and you get a day that was full of motion and empty of decisions.

The five-minute triage

Before you pick a framework, do the one exercise no framework replaces. Set a timer for five minutes and ask one question about every item: what actually happens if this does not get done today?

This question works because everything on your list has a cost of not doing it, which means every task can be argued as a priority — and that argument never ends on its own. The question forces an end to it. What you find is usually this: a few tasks have real, external consequences (a deadline someone else is waiting on, a blocker holding up three people), a few are internally-set deadlines that can shift if you say so, and a surprising number are just loud.

An honest observation from a 2026 prioritization guide makes this even sharper: treat "everything is urgent" as a signal that you have committed to too much, not that you need a better framework. Cut scope first — cross things off, move them to a "not this week" list, negotiate the deadline out loud — and only then sort what is left. Sorting a list that is twice too long just produces a well-organized list you will fail.

Pick one method that fits your actual problem

Here is where most advice goes wrong: it gives you seven frameworks and implicitly suggests using all of them. Don't. Match one method to the problem you actually have:

"I can't tell what matters." Use the Eisenhower Matrix. Sort every task by two questions: urgent? important? Do the urgent-and-important, schedule the important-but-not-urgent, delegate the urgent-but-unimportant, delete the rest. It is the best tool for breaking the urgency trap.
"I keep avoiding one hard thing." Eat the frog. Identify the single most important, usually most avoided task and do it first thing in the morning. Your frog is almost always important-but-not-urgent — which is exactly why it keeps getting bumped.
"My list is always too long." Use the 1-3-5 rule: one big task, three medium tasks, five small tasks. Nine items, and when something new arrives, it bumps something out instead of joining the pile.
"I just want a simple daily habit." Pick two or three Most Important Tasks each morning. If you finish only those, the day was a success. Everything else is a bonus.

The honest version of the advice: for most people, Eisenhower plus time blocking is enough. The specialized frameworks — MoSCoW for release scope, RICE scoring for product features — are tools for specialized problems. Chasing more frameworks usually backfires: you pay the setup cost of three systems and get the benefit of none. Pick one, use it for two weeks, and only then judge whether it fits.

When the system breaks anyway

Every framework has a failure mode, and you should know it before you commit. The Eisenhower Matrix breaks the day 80 percent of your list lands in "urgent and important." At that point it stops separating anything — it becomes a ritual that confirms the chaos. If that happens, the problem is upstream of the method: too much work was committed. No matrix fixes that.

Three behaviors matter more than which method you pick, and no framework can do them for you:

Work from one place, not five. If tasks live in Slack, email, a notebook, and three browser tabs, no amount of prioritization math will save you. Consolidate first.
Cap the day and defend it. Plan four things and finish four beats plan twelve and finish four. The number matters less than the commitment.
Learn to say no. Every yes to a new commitment is a no to something already on your list — and most people only ever see the yes.

One more, because it is where plans actually die: when something new arrives mid-day, don't just absorb it. Run it through your method and ask whether it is genuinely more important than what you would drop for it. Usually it isn't. It just arrived loudly.

What to do this week

Consolidate everything into one list. Run the five-minute triage — consequence question, cut the loud-but-harmless items. Pick one method from the matcher above and use it every morning for two weeks. Block time on your calendar for the important-but-not-urgent work, because priorities without a spot on the calendar lose to everything else.

You worked nine hours today and couldn't name one thing you finished. Tomorrow, try finishing two — the two you chose at 9 AM, before the day's noise started.