Nvidia has been in talks to ac­quire Hugging Face, the pop­u­lar AI plat­form for shar­ing and build­ing with open-source mod­els, in what could be one of the chip gi­ant’s biggest deals yet.

The two par­ties have had ac­qui­si­tion con­ver­sa­tions in re­cent weeks about a deal that would value Hugging Face at more than $13 bil­lion, ac­cord­ing to a per­son fa­mil­iar with the mat­ter. The com­pa­nies have not yet reached a deal, and the talks could still fall apart, the per­son said. Business Insider on Sunday was the first to re­port that Hugging Face was field­ing takeover in­ter­est.

Nvidia and Hugging Face did not re­spond to re­quests for com­ment.

Nvidia has in­creas­ingly ramped up deal­mak­ing with its enor­mous cash pile. The com­pany said Wednesday that it has $18 bil­lion com­mit­ted to eq­uity in­vest­ments for the rest of its fis­cal year, on top of $47.9 bil­lion it al­ready holds in pri­vate com­pa­nies.

Microsoft also met with Hugging Face, but the per­son fa­mil­iar and a sec­ond per­son said talks are not on­go­ing.

Nvidia al­ready has a re­la­tion­ship with Hugging Face. The chip­maker par­tic­i­pated in its $235 mil­lion fund­ing round in 2023 that val­ued it at $4.5 bil­lion.

Hugging Face turned down a $500 mil­lion in­vest­ment of­fer from Nvidia late last year that would have val­ued it at $7 bil­lion, the Financial Times pre­vi­ously re­ported. Hugging Face said at the time it did not want a dom­i­nant in­vestor that could sway de­ci­sions.

Hugging Face sits at the cen­ter of the open-source AI ecosys­tem, host­ing mil­lions of AI mod­els and datasets that de­vel­op­ers can build on. Owning the plat­form could give Nvidia a big­ger foothold with those de­vel­op­ers — and po­ten­tially drive more work­loads onto its chips.

Hugging Face was founded in 2016 by French en­tre­pre­neurs Clément Delangue, Julien Chaumond, and Thomas Wolf.

But Nvidia own­er­ship could also com­pli­cate one of Hugging Face’s strengths: its neu­tral­ity. The plat­form sup­ports mod­els and hard­ware from across the in­dus­try, in­clud­ing Nvidia com­peti­tors such as AMD and Intel.

Have a tip?

Contact Katie Roof via email at kroof@busi­nessin­sider.com or Signal at @kroof.26

Contact Geoff Weiss via email at gweiss@busi­nessin­sider.com or Signal at @geoffweiss.25.

Contact Ashley Stewart via email at astew­art@busi­nessin­sider.com or Signal at +1 – 425-344 – 8242.

Use a per­sonal email ad­dress and a non­work de­vice; here’s our guide to shar­ing in­for­ma­tion se­curely.

Read next

Geoff Weiss

You’re cur­rently fol­low­ing this au­thor! Want to un­fol­low? Unsubscribe via the link in your email.

Geoff Weiss is a se­nior re­porter on Business Insider’s tech team, where he writes about AI star­tups and Y Combinator, the in­ter­sec­tion of AI and the me­dia in­dus­try, and work­place dy­nam­ics within top AI labs and chip com­pa­nies.Pre­vi­ously, Geoff was on the me­dia desk, cov­er­ing YouTube and Netflix, and themes like the in­ter­sec­tion of Hollywood and the cre­ator econ­omy. His work on Netflix’s video pod­cast­ing am­bi­tions and Mr Beast’s lessons for Hollywood won sec­ond and first prize, re­spec­tively, at the 2025 LA Press Club Awards.Prior to join­ing Business Insider, Geoff was the se­nior ed­i­tor of Tubefilter and a staff writer at Entrepreneur. He grad­u­ated from New York University with a de­gree in English Literature.He can be reached at gweiss@busi­nessin­sider.com, on Signal @geoffweiss.25, and on LinkedIn. Have a tip? Use a per­sonal email ad­dress and a non­work de­vice; here’s our guide to shar­ing in­for­ma­tion se­curely.Se­lected sto­ries:Nvidia crushed its quar­ter — and CEO Jensen Huang said in a leaked all-hands that ’the mar­ket did not ap­pre­ci­ate it’N­vidia will foot the bill for Trump’s new visa fees. Here’s what CEO Jensen Huang told staff.Mas­sive AI salaries and RTO are fu­el­ing a real es­tate boom in San Francisco: ’It’s go­ing to rain mon­ey’The AI tal­ent wars are ric­o­chet­ing across star­tups. Here’s how they’re com­pet­ing with Big Tech.

Ashley Stewart

You’re cur­rently fol­low­ing this au­thor! Want to un­fol­low? Unsubscribe via the link in your email.

AI

Big Tech

Venture Capital

More

Exclusive

Open Executive

An AI sys­tem that acts as your com­pa­ny’s vir­tual ex­ec­u­tive team — a se­nior ad­vi­sor with Harvard MBA-level knowl­edge, cus­tomized for your spe­cific busi­ness.

Demo

A walk­through of Open Executive in ac­tion — watch on YouTube.

What It Does

Developed by sen­te­labs.ai Open Executive pro­vides a sin­gle co­her­ent ex­ec­u­tive voice backed by eight spe­cial­ist AI agents:

Chief Strategy Officer — com­pet­i­tive analy­sis, M&A, mar­ket po­si­tion­ing, OKRs

Chief Financial Officer — fi­nan­cial mod­el­ing, fundrais­ing, unit eco­nom­ics, cash flow

Chief HR/People Officer — hir­ing, com­pen­sa­tion, per­for­mance, cul­ture

General Counsel — con­tracts, IP, em­ploy­ment law ba­sics, com­pli­ance

Chief Operating Officer — process de­sign, ven­dor man­age­ment, op­er­a­tional scal­ing

Chief Marketing Officer — GTM strat­egy, brand, com­mu­ni­ca­tions, PR

Chief Product Officer — roadmap, pri­or­i­ti­za­tion, prod­uct strat­egy

Board Communications Director — board decks, in­vestor re­la­tions, gov­er­nance

All re­sponses come from one con­sis­tent ex­ec­u­tive voice. The in­ter­nal agent ar­chi­tec­ture is never ex­posed to the user. Beyond Q&A, the sys­tem main­tains episodic mem­ory of past de­ci­sions and ini­tia­tives across ses­sions, and a built-in sched­uler can proac­tively sur­face fol­low-ups and time-sen­si­tive ac­tions.

Architecture

User mes­sage ↓ Executive Orchestrator (claude-sonnet-4 – 6) ↓ tool use → par­al­lel spe­cial­ist calls CSO / CFO / CHRO / GC / COO / CMO / CPO / Board ↓ each spe­cial­ist re­trieves rel­e­vant con­text from ChromaDB Built-in MBA knowl­edge + Your com­pany doc­u­ments ↓ Synthesized ex­ec­u­tive re­sponse

Knowledge — Two re­trieval lay­ers per spe­cial­ist call: (1) built-in MBA-level Markdown (knowledge/builtin/, git-tracked) seeded into ChromaDB at startup, and (2) your up­loaded com­pany doc­u­ments chun­ked and stored in a sep­a­rate com­pa­ny_­docs col­lec­tion. RAG con­text is in­jected into the user turn, never the cached sys­tem prompt.

Episodic mem­ory — After every re­sponse, a back­ground claude-haiku-4 – 5 pass ex­tracts key de­ci­sions, ini­tia­tives, and ad­vice into SQLite. The next ses­sion opens with a <past_decisions> block so the Executive re­mem­bers what it rec­om­mended last month.

Scheduler — A built-in job run­ner claims due ac­tions via UPDATE … RETURNING to pre­vent dou­ble-fir­ing. The API must run as a sin­gle in­stance; do not hor­i­zon­tally scale it with­out gat­ing the sched­uler first.

Prompt caching — The sys­tem prompt is struc­tured so the Executive per­sona, com­pany pro­file, and knowl­edge in­dex are cached sep­a­rately (up to 85% cache hit rate af­ter the first few turns). No dy­namic con­tent ever goes in a cached block.

See docs/​ar­chi­tec­ture.md for the full de­sign.

Tech Stack

Repo Layout

openex­ec­u­tive/ ├── pack­ages/ │ ├── core/ │ │ └── openex­ec­u­tive/ │ │ ├── or­ches­tra­tor/ # Executive per­sona + rout­ing loop │ │ ├── agents/ # 8 spe­cial­ist agents │ │ ├── knowl­edge/ # ChromaDB store + RAG pipeline │ │ ├── mem­ory/ # Company pro­file + episodic mem­ory │ │ ├── on­board­ing/ # Wizard state ma­chine + pro­file builder │ │ ├── prompts/ # Persona + do­main prompts + cache man­ager │ │ ├── api/ # FastAPI app + routes │ │ ├── in­te­gra­tions/ # Slack, Email, Telegram, Google Chat, Discord │ │ ├── sched­uler/ # Background job run­ner (single-instance) │ │ ├── alerts/ # Proactive alert sys­tem │ │ ├── au­dit/ # Audit log­ging │ │ ├── ar­chi­tec­ture/ # Internal ar­chi­tec­ture util­i­ties │ │ ├── work­flows/ # Multi-step work­flow de­f­i­n­i­tions │ │ └── cli.py # Click CLI │ └── ui/ # Next.js 15 web UI ├── evals/ # Eval sce­nar­ios + LLM-as-judge run­ner ├── fix­tures/ # Demo com­pany fix­tures (profiles, docs, ros­ters) ├── scripts/ # Operator scripts (Fly se­crets, Google auth) ├── docker/ # Dockerfile(s) + docker-com­pose.yml ├── fly.api.toml / fly.ui.toml # Fly.io con­figs — dev API + UI apps ├── fly.api.qa.toml / fly.ui.qa.toml # Fly.io con­figs — QA API + UI apps ├── fly.hon­cho.toml # Fly.io con­fig — Honcho mem­ory app (optional) └── docs/ # Architecture + de­ploy­ment docs

Quick Start

# Clone the repo git clone https://​github.com/​Sen­te­Lab­sAI/​OpenEx­ec­u­tive.git cd OpenExecutive

# Set your Anthropic API key cp .env.example .env # Edit .env and add ANTHROPIC_API_KEY=sk-ant-…

# Start every­thing make dev

Open http://​lo­cal­host:3000 to start chat­ting with your ex­ec­u­tive. The API runs on port 8000 and the UI on 3000.

First run: re­quires Python 3.11+ and Node 22+. The ini­tial uv sync pulls heavy ML de­pen­den­cies (ChromaDB + sen­tence-trans­form­ers/​Py­Torch), and the first boot down­loads a small em­bed­ding model (~90 MB) to build the lo­cal vec­tor in­dex — so the first make dev takes a few min­utes be­fore the app is ready. Subsequent starts are fast.

First run: re­quires Python 3.11+ and Node 22+. The ini­tial uv sync pulls heavy ML de­pen­den­cies (ChromaDB + sen­tence-trans­form­ers/​Py­Torch), and the first boot down­loads a small em­bed­ding model (~90 MB) to build the lo­cal vec­tor in­dex — so the first make dev takes a few min­utes be­fore the app is ready. Subsequent starts are fast.

For con­trib­u­tors not us­ing make:

cd pack­ages/​core uv sync source .venv/bin/activate uvi­corn openex­ec­u­tive.api.main:app –reload –port 8000

# In a sec­ond ter­mi­nal cd pack­ages/​ui && npm in­stall && npm run dev

Run the Discord Bot

Create a Discord ap­pli­ca­tion at https://​dis­cord.com/​de­vel­op­ers/​ap­pli­ca­tions

Enable the Message Content priv­i­leged in­tent (Bot → Privileged Gateway Intents)

Invite the bot with bot + ap­pli­ca­tions.com­mands scopes

Set env vars in .env: DISCORD_BOT_TOKEN, DISCORD_APP_ID, DISCORD_GUILD_IDS

Run the API nor­mally — the bot starts as part of the FastAPI lifes­pan when DISCORD_BOT_TOKEN is set:

make dev

The bot is em­bed­ded in the API process (alongside the email poller, sched­uler, and re­sumer) so it shares the same SQLite data­base and ChromaDB vec­tor store un­der /data in pro­duc­tion. Skip the to­ken to dis­able.

For it­er­at­ing on bot-only code with­out restart­ing the API, make dis­cord runs the bot as a stand­alone process against the same lo­cal DB.

Users can DM the bot, @mention it in a chan­nel (replies in a thread), or use /ask and /today slash com­mands. Slash com­mands sync to DISCORD_GUILD_IDS in­stantly on startup; leave blank for global reg­is­tra­tion (up to 1-hour prop­a­ga­tion de­lay).

Deploying to pro­duc­tion

Just set the se­crets on the ex­ist­ing API app — no new Fly app re­quired:

fly­ctl se­crets set -a openexec-api-dev \ DISCORD_BOT_TOKEN=… \ DISCORD_APP_ID=… \ DISCORD_GUILD_IDS=…

Discord user ac­cess is man­aged via the /people UI — add a Person row with dis­cord_user_id set.

The ma­chine restarts and the bot starts on the next lifes­pan boot. To dis­able in prod: fly­ctl se­crets un­set -a openexec-api-dev DISCORD_BOT_TOKEN.

Onboarding Your Company

The first time you visit the app, you’ll be guided through a wiz­ard to set up your com­pany pro­file:

Company ba­sics (name, in­dus­try, stage, team size)

Business model and rev­enue

Competitive land­scape

Strategic pri­or­i­ties

Culture and val­ues

Optional: fi­nan­cial po­si­tion, doc­u­ment up­load

After on­board­ing, the Executive will ref­er­ence your spe­cific com­pany con­text in every re­sponse.

Interfaces

Document Upload

Upload your pitch deck, fi­nan­cial model, strat­egy docs, or any com­pany doc­u­ments via the web UI or API. The Executive will ref­er­ence them when rel­e­vant.

# Via CLI openex­ec­u­tive up­load deck.pdf model.xlsx strat­egy.md

# Via API curl -X POST http://​lo­cal­host:8000/​doc­u­ments \ -F “file=@deck.pdf” \ -F “domain=strategy”

Deployment (Fly.io)

Two en­vi­ron­ments, each a sep­a­rate set of Fly apps, dri­ven by branch:

Both work­flows use dorny/​paths-fil­ter to de­ploy only the changed app (API, UI, or both). QA is a sta­ble twin of dev — same im­age and run­time, only the app name dif­fers (fly.api.qa.toml / fly.ui.qa.toml) — so it lags main and stays vet­ted. An op­tional Honcho mem­ory app (fly.honcho.toml) de­ploys in­de­pen­dently.

Topology

⚠️ Single-instance only: The sched­uler claims rows via UPDATE … RETURNING. Running two API ma­chines would dou­ble-fire sched­uled ac­tions. max_­ma­chines_run­ning = 1 is set in fly.api.toml / fly.api.qa.toml — do not over­ride it.

⚠️ Single-instance only: The sched­uler claims rows via UPDATE … RETURNING. Running two API ma­chines would dou­ble-fire sched­uled ac­tions. max_­ma­chines_run­ning = 1 is set in fly.api.toml / fly.api.qa.toml — do not over­ride it.

Required GitHub Actions se­crets

Deploys au­then­ti­cate with per-app Fly de­ploy to­kens stored as repo (or org) Actions se­crets. Generate each with fly­ctl to­kens cre­ate de­ploy -a <app> -x 999999h:

Per-app run­time se­crets (ANTHROPIC_API_KEY, BACKEND_SHARED_SECRET, the AUTH_* set, in­te­gra­tion to­kens) are set di­rectly on each Fly app — see scripts/​fly-se­crets.sh.ex­am­ple.

One-time boot­strap (dev)

# 1. Create apps and vol­ume fly­ctl apps cre­ate openexec-api-dev fly­ctl apps cre­ate openexec-ui-dev fly­ctl vol­umes cre­ate ex­ec­u­tive_­data –region iad –size 1 -a openexec-api-dev

# 2. Set the re­quired se­cret fly­ctl se­crets set -a openexec-api-dev ANTHROPIC_API_KEY=sk-ant-…

# 3. Create de­ploy to­kens and add as GitHub se­crets FLY_API_TOKEN_API and FLY_API_TOKEN_UI fly­ctl to­kens cre­ate de­ploy -a openexec-api-dev -x 999999h fly­ctl to­kens cre­ate de­ploy -a openexec-ui-dev -x 999999h

# 4. First de­ploy gh work­flow run “Deploy (dev)” -f tar­get=both

QA boot­straps the same way against the -qa app names (push to the qa branch, or gh work­flow run “Deploy (qa)“). See docs/​de­ploy­ment.md for the full run­book (operations, roll­back, com­mon fail­ure modes, why .flycast is­n’t used).

Access con­trol

The de­ployed UI is gated be­hind Google sign-in with an email al­low-list, and the pub­lic API is pro­tected by a shared-se­cret header be­tween the UI proxy and the FastAPI back­end. See docs/​auth.md for the full setup (Google Cloud Console steps, re­quired Fly se­crets, adding/​re­mov­ing users, ro­tat­ing se­crets, and a de­bug­ging table).

Configuration

All set­tings via en­vi­ron­ment vari­ables. Minimum re­quired: ANTHROPIC_API_KEY — un­less you con­fig­ure a lo­cal or OpenRouter back­end in­stead (see Running on Local Models). At least one provider must be set or the app re­fuses to start.

See .env.example for the full list.

¹ ANTHROPIC_API_KEY is re­quired only when you serve Claude mod­els di­rectly. It can be omit­ted en­tirely if you run on lo­cal mod­els (LOCAL_MODELS_ENABLED) or route through OpenRouter (OPENROUTER_ENABLED).

¹ ANTHROPIC_API_KEY is re­quired only when you serve Claude mod­els di­rectly. It can be omit­ted en­tirely if you run on lo­cal mod­els (LOCAL_MODELS_ENABLED) or route through OpenRouter (OPENROUTER_ENABLED).

Running on Local Models

Open Executive can run against any OpenAI-compatible lo­cal server — Ollama, LM Studio, vLLM, or llama.cpp — in­stead of (or along­side) the Anthropic API. Local model slugs route to your server through the same provider ab­strac­tion the hosted mod­els use; no agent or or­ches­tra­tor code changes.

# 1. Pull a ca­pa­ble, tool-use-friendly model (example: Ollama) ol­lama pull lla­ma3.3

# 2. In .env — point at the lo­cal server and list the slugs to ex­pose LOCAL_MODELS_ENABLED=true LOCAL_BASE_URL=http://​lo­cal­host:11434/​v1 # Ollama de­fault LOCAL_MODELS=llama3.3

# 3. (Optional) run with NO Anthropic key — make lo­cal the de­fault every­where DEFAULT_MODEL=llama3.3 DEEP_REASONING_MODEL=llama3.3 ROUTING_MODEL=llama3.3 # …and leave ANTHROPIC_API_KEY un­set

The listed slugs ap­pear in the Council UI model drop­down, so you can also run a hy­brid setup — keep the Executive on Claude while flip­ping in­di­vid­ual spe­cial­ists to a lo­cal model per-agent.

Caveats. Server-side web search (ENABLE_WEB_SEARCH) and Anthropic prompt caching / ex­tended think­ing have no lo­cal equiv­a­lent and are au­to­mat­i­cally dis­abled for lo­cal mod­els. Multi-agent rout­ing leans heav­ily on tool use, so pick a model that’s strong at it (e.g. Llama 3.3 70B, Qwen2.5) — small mod­els may route poorly. LOCAL_API_KEY is only needed if your server (vLLM, or a gate­way) re­quires a bearer to­ken; Ollama and LM Studio need none.

Adding a New Specialist Agent

Create pack­ages/​core/​openex­ec­u­tive/​agents/​your_a­gent.py ex­tend­ing BaseAgent

Add a sys­tem prompt con­stant in pack­ages/​core/​openex­ec­u­tive/​prompts/​do­main_prompts.py

Register in pack­ages/​core/​openex­ec­u­tive/​or­ches­tra­tor/​router.py — add to SPECIALIST_REGISTRY and the spe­cial­ist enum in SPECIALIST_TOOLS

Add do­main alias to DOMAIN_ALIASES in pack­ages/​core/​openex­ec­u­tive/​knowl­edge/​re­triever.py

Add knowl­edge docs to knowl­edge/​builtin/​your_­do­main/

Add at least 2 eval sce­nar­ios to evals/​sce­nar­ios/

Amazon Mechanical Turk (MTurk) is a crowd­sourc­ing mar­ket­place that makes it eas­ier for in­di­vid­u­als and busi­nesses to out­source their processes and jobs to a dis­trib­uted work­force who can per­form these tasks vir­tu­ally. This could in­clude any­thing from con­duct­ing sim­ple data val­i­da­tion and re­search to more sub­jec­tive tasks like sur­vey par­tic­i­pa­tion, con­tent mod­er­a­tion, and more. MTurk en­ables com­pa­nies to har­ness the col­lec­tive in­tel­li­gence, skills, and in­sights from a global work­force to stream­line busi­ness processes, aug­ment data col­lec­tion and analy­sis, and ac­cel­er­ate ma­chine learn­ing de­vel­op­ment.

While tech­nol­ogy con­tin­ues to im­prove, there are still many things that hu­man be­ings can do much more ef­fec­tively than com­put­ers, such as mod­er­at­ing con­tent, per­form­ing data dedu­pli­ca­tion, or re­search. Traditionally, tasks like this have been ac­com­plished by hir­ing a large tem­po­rary work­force, which is time con­sum­ing, ex­pen­sive and dif­fi­cult to scale, or have gone un­done. Crowdsourcing is a good way to break down a man­ual, time-con­sum­ing pro­ject into smaller, more man­age­able tasks to be com­pleted by dis­trib­uted work­ers over the Internet (also known as ‘microtasks’).

MicroduckMade to move · Ready to learn

A 25 cm open-source biped you train your­self with re­in­force­ment learn­ing. Playable out of the box.

Pre-order for $399

The launch film · sound on

Roll thetape

Waking up the duck…

Meet the twin

sim2re­althat works

Trained in sim, de­ployed on the real ro­bot. This is the sim­u­lated twin the ducks were trained on.

Fun out of the box. Yours to re­train.

Teach it newtricks

Every be­hav­iour is a pol­icy you can re­train on your own ma­chine.

01

Train in sim­u­la­tion

Behaviours are learned in physics sim, on your ma­chine or on Hugging Face Jobs.

02

Deploy on the ro­bot

One step from sim­u­la­tion to the real thing.

03

Refine the sim­u­la­tion

Tune, re-train, re-de­ploy.

04

Publish the pol­icy

Share your new be­hav­ior with the com­mu­nity!

Walk

Velocity-tracking gait.

Sit & stand

Sits down, holds the pose, stands back up on its own.

Kick

A one-shot boot, then straight back to walk­ing.

Grab

Dips the beak to the ground, scoops, and pops back up­right.

Roller skat­ing

Roller skat­ing lo­co­mo­tion when the skates are equipped.

Get back up

Flat on its back to stand­ing, all by it­self, ready for the next com­mand.

One ro­bot, four colour­ways

Choose your­colour

Every Microduck ships in one of four colour­ways. Same ro­bot, same brains un­der­neath - pick the shell that best fits you.

Waking up the duck…

Out in the world

In the wild

The real ro­bot in real places - on desks, on the pitch, out at golden hour.

The ro­bot, and what to add to it

Pick your­pack

The ro­bot is every­thing you need on day one. The packs add play gear and spare parts.

$399

The ro­bot

Microduck

In the box

Robot, bat­tery, USB-C ca­ble, game con­troller.

$39

Dual charger, 2x bat­ter­ies.

$119

3x spare mo­tors, 5x mo­tor ca­bles, 2x bat­ter­ies, dual charger, 10x NFC tags, Hugging Face credit, screw­driver, screw pack.

$39

Laser pointer, NFC po­laroid, 2x rollers, ball, 10x NFC tags.

Built in the open

Open source

The SDK, the sim­u­la­tion and the full RL train­ing stack are on GitHub. What the ro­bot runs is what you can read, fork and re­train.

pollen-ro­bot­ics/​mi­cro­duck

ssh mi­cro­duck

$ ro­botctl mon­i­tor # sta­tus of the ro­bot$ ro­botctl con­fig­ure # con­fig­ure the ro­bot$ ro­botctl up­date # up­date the ro­bot

Apache-2.0

The whole soft­ware stack, per­mis­sively li­censed

MuJoCo

The physics sim every pol­icy is trained in

7 poli­cies

Every shipped move, pub­lished and re­train­able

Join the flock

Builds on show, poli­cies to swap, help when a leg does some­thing strange. The com­mu­nity lives on Discord.

End of tape · be kind, rewind

Pre-orders are­open now

Pre-order for $399

In four colour­ways. Ships be­fore Christmas 2026.Introductory price, be­fore taxes and ship­ping.

Linux 7.2 has been re­leased! That was fast. Let’s dive in to yet an­other Asahi Linux progress re­port. We’ve got a lot of in­ter­est­ing de­vel­op­ments for you to­day, so make your­self a cuppa and en­joy.

Think Different… again

The Apple Silicon plat­for­m’s power man­age­ment in­fra­struc­ture is com­pli­cated. Responsibilities are di­vided be­tween mul­ti­ple hard­ware blocks, in­clud­ing the SMC, PMGR, and PMP, all of which have fea­tured be­fore on this blog. While sup­port­ing these blocks is im­por­tant for power use, one of the biggest ob­sta­cles to im­prov­ing bat­tery life has been the ap­pli­ca­tion cores them­selves.

There are mul­ti­ple ways to “sleep” a CPU core, and each one should be used in a spe­cific con­text. The most ba­sic way to sleep an ARM CPU core is to use a Wait For Interrupt (WFI) in­struc­tion. This tells the core to stop do­ing things un­til it is woken up by an in­ter­rupt from an in­ter­rupt source. While this does save power by virtue of stop­ping the core from ex­e­cut­ing any code, the core stays pow­ered up and re­tains enough state for it to re­sume work ex­tremely quickly. As such, WFI is typ­i­cally only used for park­ing a core on a run­ning sys­tem. Apple cores in­clude a “deep” WFI mode, which shuts down more of the core at the ex­pense of los­ing its state. Our down­stream cpui­dle dri­ver op­er­ates by set­ting WFI up in this mode, sav­ing the core’s state, then is­su­ing a WFI loop.

Vendor-specific power man­age­ment odd­i­ties like this are quite com­mon. Thankfully for ker­nel main­tain­ers, there is a stan­dard way to deal with them: the Power State Coordination Interface. PSCI de­fines a stan­dard in­ter­face that al­lows an op­er­at­ing sys­tem to call into a de­fined set of CPU core power man­age­ment func­tions im­ple­mented by sys­tem firmware, in­clud­ing to pre­pare them for sleep.

To avoid a pro­lif­er­a­tion of ven­dor-spe­cific power man­age­ment hacks in­side the Linux ker­nel, the main­tain­ers of the ar­m64 arch-spe­cific code have man­dated that all up­stream hard­ware must use PSCI for power man­age­ment. As such, we are not able to up­stream our Apple-specific cpui­dle dri­ver. Why are we still us­ing it then?

PSCI de­fines “conduits” through which calls to firmware are to be dis­patched from the ker­nel. The two cur­rently sup­ported con­duits in the ker­nel are the SMC (Secure Monitor Call) and HVC (Hypervisor Call) in­struc­tions, which are used to yield ex­e­cu­tion to a higher Exception Level. The Linux ker­nel ex­pects to be run­ning at EL2, which means that its PSCI calls must yield to firmware run­ning in EL3. Except Apple’s cores do not im­ple­ment EL3…

With the ker­nel al­ready run­ning in EL2 and no firmware run­ning in EL3 to talk to, we are a bit stuck. Linux can­not is­sue an SMC or HVC in­struc­tion since there is no EL3 to yield ex­e­cu­tion to, which means we can­not make use of PSCI. Being able to prop­erly power-man­age the CPU cores is vi­tal for bat­tery life and ef­fi­ciency, so the sta­tus quo sim­ply will not do. One quick and dirty so­lu­tion would be to have m1n1 load the ker­nel into EL1, and host a PSCI im­ple­men­ta­tion in EL2. While this would the­o­ret­i­cally work, it would also break a lot of ar­chi­tec­tural fea­tures, such as vir­tu­al­i­sa­tion. There must be some­thing else we can do…

If you think about it, m1n1 is al­most like our own firmware for Apple Silicon. mBoot (formerly iBoot) starts it in EL2, it does its job, then jumps to what­ever pay­load is at­tached to it. m1n1 does not re­serve any mem­ory for it­self and does not have any code that must stay res­i­dent, so its pay­load is free to re­claim and over­write that mem­ory.

On pro­duc­tion Asahi Linux sys­tems, m1n1 loads U-Boot rather than the ker­nel di­rectly. We do this to make use of U-Boot’s UEFI im­ple­men­ta­tion, al­low­ing dis­tros and users to utilise whichever stan­dard UEFI boot­loader (GRUB, sys­temd-boot, etc.) they want. UEFI also pro­vides an­other fea­ture, Runtime Services. Much as the BIOS in­ter­rupts of old did, UEFI Runtime Services pro­vide a way for the op­er­at­ing sys­tem to ac­cess code orig­i­nat­ing in sys­tem firmware.

Reading the PSCI stan­dard as pub­lished by Arm, one will no­tice that it de­lib­er­ately de­fines the API with­out ref­er­ence to any spe­cific con­duit, and only lists SMC and HVC as ex­am­ples. If we take a broad in­ter­pre­ta­tion of this, we could con­clude that this means other con­duits are al­lowed by the spec…

To this end, Sven has been work­ing on im­ple­ment­ing a UEFI Runtime Service based PSCI con­duit. With m1n1’s mem­ory re­gion carved out like other firmware re­gions, this will al­low the ker­nel to call back into it for PSCI ser­vices, even though it is run­ning at the same Exception Level. Sven has al­ready mod­i­fied m1n1 to re­serve its mem­ory and leave be­hind a PSCI im­ple­men­ta­tion, and the patches to the ker­nel en­abling its use are al­ready on the mail­ing list as an RFC!

Please stop Thinking Different

Given that the cpui­dle sit­u­a­tion saw no progress un­til very re­cently, one might as­sume that some event has catal­ysed work in this space. One would be cor­rect.

The ARM spec­i­fi­ca­tion man­dates that cores in WFI loops should pre­serve all state. This is not the de­fault mode on Apple Silicon. On M1 through M3 se­ries SoCs, state re­ten­tion can be con­fig­ured on a per-core ba­sis us­ing chicken bits.

Due to a num­ber of rea­sons that are not worth men­tion­ing, Apple now sets each core’s chicken bits in mBoot and then locks down the reg­is­ters con­trol­ling them start­ing with the M4 se­ries. This makes our life a lit­tle eas­ier as m1n1 now has mar­gin­ally less work to do, how­ever it also means that we can­not fine tune low level CPU be­hav­iour. This is an is­sue on M4 par­tic­u­larly, as call­ing WFI causes the core to lose its state and crash what­ever was run­ning on it.

Yureka no­ticed this while do­ing M4 bringup work, and added a ker­nel com­mand line pa­ra­me­ter to make idle loop be­hav­iour con­fig­urable. The pa­ra­me­ter al­lows us to tell the ker­nel how it should park cores in idle loops, in­clud­ing by do­ing a ba­sic no-op loop. This pre­vents M4 ma­chines from crash­ing dur­ing early ker­nel ini­tial­i­sa­tion, be­fore our cpui­dle dri­ver has been loaded. Once the dri­ver takes over, it saves the the lost state be­fore is­su­ing WFI. The patches to en­able this are al­ready in linux-next.

They won’t stop Thinking Different

Apple takes its rep­u­ta­tion for plat­form se­cu­rity very se­ri­ously. As such, a lot of en­gi­neer­ing ef­fort goes in to fea­tures that make ex­ploit­ing vul­ner­a­bil­i­ties in their ecosys­tem in­fea­si­ble for all but the most so­phis­ti­cated of at­tack­ers. One such fea­ture is the Secure Page Table Monitor, or SPTM.

Traditionally, the op­er­at­ing sys­tem ker­nel has been di­rectly re­spon­si­ble for man­ag­ing mem­ory. This in­cludes han­dling mem­ory al­lo­ca­tions, vir­tual map­pings to phys­i­cal ad­dresses, and MMU/IOMMU man­age­ment. A vul­ner­a­bil­ity in the code re­spon­si­ble for these op­er­a­tions could give an at­tacker ac­cess to the plat­for­m’s en­tire ad­dress space. In other words, you’re cooked.

Naturally this makes mem­ory man­age­ment code a very com­mon tar­get for at­tack­ers, and given that its job is fun­da­men­tally in­se­cure (applications may want ar­bi­trary al­lo­ca­tions for just about any­thing) it is in­cred­i­bly dif­fi­cult to lock down cor­rectly.

Many years ago, Apple in­tro­duced the Page Protection Layer to XNU. PPL uses Apple’s hard­ware se­cu­rity fea­tures to iso­late pagetable man­age­ment from the rest of the ker­nel at the hard­ware level. This works very well, how­ever at­tack­ers even­tu­ally caught up and found ways in­side PPL that al­lowed them full ac­cess to the sys­tem.

Apple has had sim­i­lar is­sues with IOMobileFramebuffer in the past. As men­tioned on pre­vi­ous blog posts, Apple (mostly) solved the IOMFB prob­lem by putting it in­side DCP’s firmware, be­hind an IOMMU. Nothing in ma­cOS user­space nor in XNU can reach it, ex­cept via a de­fined set of IPC func­tions. Taking in­spi­ra­tion from this ap­proach, PPL even­tu­ally mor­phed into SPTM. SPTM takes PPL and places it in­side Apple’s Guarded Execution Framework (GXF), a set of Exception Levels that run par­al­lel to the stan­dard ARM64 Exception Levels. GXF also comes with SPRR, a cus­tom pagetable per­mis­sions sys­tem used when the CPU is run­ning code in GL1 or GL2.

When a mod­ern Apple Silicon de­vice starts up, iBoot or mBoot will de­tect if the con­fig­ured boot pay­load is an XNU im­age. If it is, it will first load SPTM into GL2. There, SPTM sets up pageta­bles and mem­ory man­age­ment and locks down con­trol of said fea­tures to GL2. XNU then runs, us­ing yet an­other IPC pro­to­col to talk to SPTM. If XNU can­not suc­cess­fully con­tact SPTM, it will panic very early in init and halt the sys­tem.

This is prob­lem­atic for us. If we try to run XNU un­der the m1n1 hy­per­vi­sor, it will crash as SPTM has not been loaded. If we con­fig­ure mBoot to treat m1n1 as an XNU bi­nary, m1n1 will crash as it will be un­able to man­age mem­ory in the way it needs to.

Given that SPTM is manda­tory for XNU on M4 and above, the hy­per­vi­sor was ren­dered en­tirely non­func­tional on these ma­chines. We don’t know when to quit how­ever, which is why that’s was and not is!

SPTM it­self is not par­tic­u­larly spe­cial. It is an ARM64 Mach-O bi­nary that lives in­side the same pre­boot di­rec­tory as the OS-specific firmware blobs for the var­i­ous co­proces­sors. That means we could the­o­ret­i­cally have m1n1 load it al­ready un­der the hy­per­vi­sor, load XNU next to it, then watch both of them! But SPTM must be run in­side GL2 with SPRR en­abled. If only we knew how both of them worked…

Thanks to Sven’s work re­verse en­gi­neer­ing SPRR and GXF way back when Asahi Linux was first get­ting started, he was re­cently able to teach the m1n1 hy­per­vi­sor how to em­u­late them! This al­lows us to load Apple’s SPTM blob in ex­actly the man­ner XNU ex­pects, do some quick surgery on the XNU bi­nary, load it, and then mon­i­tor MMIO ac­cesses just as we could from M1 to M3! The gory de­tails of how Sven achieved this means that trac­ing is slower on these ma­chines, how­ever not un­us­ably so. This will al­low us to con­tinue bring­ing up new hard­ware for the forsee­able fu­ture!

More M3 progress!

Work has also been pro­gress­ing on bring­ing Asahi Linux to M3 se­ries ma­chines.

The we­b­cam im­age sig­nal proces­sor re­mained largely un­changed, ex­cept for a sin­gle skipped ini­tial­i­sa­tion mes­sage on the M3 Max specif­i­cally. chaos_princess added sup­port for that to the Linux dri­ver, and with that en­abled full we­b­cam sup­port on all M3 se­ries de­vices with a builtin we­b­cam.

The builtin mi­cro­phones also changed slightly. New to M3 se­ries de­vices is a “High Frequency” dec­i­ma­tor re­quir­ing a new set of co­ef­fi­cients and a much larger ini­tial­i­sa­tion mes­sage. Once again, chaos_princess man­aged to get this fig­ured out in no time, bring­ing mi­cro­phone sup­port to all equipped M3 se­ries de­vices.

ATCPHY — the hard­ware block re­spon­si­ble for ne­go­ti­at­ing USB3, DisplayPort and Thunderbolt con­nec­tions over USB Type-C ports — also changed slightly, re­quir­ing a new se­quence of tun­ables at ini­tial­i­sa­tion due to the shift to TSMC’s N3 process node.

While our the­sis that Apple would avoid mak­ing sweep­ing ar­chi­tec­tural changes just for the sake of it has mostly held true, we have of course run into a few such changes…

All M1 through base M3 se­ries de­vices used an Apple-specific Texas Instruments USB port con­troller called CD3217 (or ACE2). This sits on the I2C bus and ne­go­ti­ates with USB de­vices when they are plugged in. Starting with M3 Pro/Max, Apple has switched to ACE3. ACE3 in­stead uses the SPMI bus, which re­quired some more re­verse en­gi­neer­ing. Thanks to the com­bined ef­forts of mild­sun­rise and chaos_princess, we dis­cov­ered that ACE3 has pretty much the same reg­is­ter set as CD3217, only wrapped in a SPMI in­ter­face in­stead of ad­dressed over I2C. Both the SPMI in­ter­face and ACE3 it­self are now work­ing in Asahi Linux, bring­ing USB 3.0 and Thunderbolt sup­port to all M3 se­ries de­vices.

A mas­sive change we were ex­pect­ing was the firmware ABI for both the GPU and dis­play con­troller. Since the firmware for both AGX and DCP are paired with a spe­cific ma­cOS ver­sion, Apple does not need to worry about keep­ing the in­ter­face sta­ble across re­leases. This is a large rea­son why we “target” spe­cific ma­cOS ver­sions for each gen­er­a­tion of hard­ware. M3 se­ries ma­chines will tar­get the ABI found in ma­cOS 14.8.3, and sup­port for DCP is now al­most at fea­ture par­ity with the ex­ist­ing ma­cOS 13.5 ABI we use for M1 and M2!

With all of this progress com­ing on top of mile­stones al­ready reached on M3, we are pleased to an­nounce that we are al­most ready to cut an of­fi­cial re­lease! We will have more to say about this in the com­ing weeks, so stay tuned!

Don’t for­get about M4 and M5 too!

Not con­tent with help­ing out only with M3, Yureka has also been work­ing on M4 and even early M5 bringup. Beyond the WFI is­sue on M4, these SoCs suf­fered from a break­ing change in Apple’s NVMe con­troller firmware in the ma­cOS 15.x firmware bun­dle. Yureka and Sven worked to­gether on in­ves­ti­gat­ing the changes and im­ple­ment­ing them in both m1n1 and Linux, so we now have work­ing NVMe on M4 and M5! Yureka also man­aged to get PCIe work­ing to a state where de­vices on the bus can be enu­mer­ated by Linux, and fixed an is­sue that caused Linux to crash shortly af­ter boot when more than one CPU core is en­abled. Not much else is work­ing on M4 and M5 so we aren’t quite ready to en­able them in the Asahi Installer just yet, but as al­ways we will have more to say in due course.

Desktop video is hard

Last time, we an­nounced pre­lim­i­nary sup­port for the Apple Video Decoder, or AVD. This hard­ware block ac­cel­er­ates H.264 (AVC), H.265 (HEVC) and VP9 video de­cod­ing on M1 and M2, in ad­di­tion to AV1 de­cod­ing on M3 ma­chines and above. Since then, AVD sup­port has been fur­ther re­fined by so­fus, with AVC, HEVC and VP9 all work­ing mostly re­li­ably on all ma­chines sup­ported by Asahi Linux! We are now at the stage where we are con­sid­er­ing desk­top in­te­gra­tion, which is where things start to get tricky…

The AVD hard­ware is fun­da­men­tally state­less, mean­ing that all it does is take an en­coded frame and turn it into a video buffer. The hard­ware does no bit­stream pars­ing, no de­cod­ing ses­sion track­ing, or any other man­age­ment of the de­cod­ing pipeline. This lends it­self well to the V4L2 Stateless API, which is de­signed with such de­coders in mind. While this API first landed in the up­stream ker­nel over 10 years ago, user­space has been slow to adopt it out­side of spe­cialised soft­ware tar­geted at em­bed­ded de­vices. GStreamer has ba­sic sup­port for V4L2 Stateless, how­ever FFmpeg (and every­thing that con­sumes it) does not with­out out-of-tree patches. Desktop-class soft­ware, such as web browsers, have his­tor­i­cally fo­cused on VA-API, NVDEC and VDPAU. More re­cently, ef­fort on the desk­top has be­gun shift­ing to Vulkan Video. This has left V4L2 Stateless ef­fec­tively aban­doned be­fore it even got started for desk­top soft­ware.

All hope is not lost, how­ever. VA-API is now near uni­ver­sal in desk­top-class soft­ware ow­ing to its adop­tion by both AMD and Intel for their video ac­cel­er­a­tion hard­ware. To pre­vent V4L2 Stateless hard­ware from be­ing un­us­able with such soft­ware, Bootlin au­thored a VA-API to V4L2 Stateless trans­la­tion layer. Sadly this has been aban­doned for quite some time and no longer builds with­out patches. A more re­cent ef­fort by megi how­ever does, which so­fus has forked it and got­ten it into a work­ing state for AVD. With this trans­la­tion layer in­stalled and an en­vi­ron­ment vari­able set for the lo­gin ses­sion, soft­ware im­ple­ment­ing VA-API sup­port is now able to use AVD to ac­cel­er­ate video de­cod­ing! This does not yet ship by de­fault in Fedora Asahi Remix, and will not work with Firefox’s video de­cod­ing sand­box, how­ever we hope to have some­thing ship­pable soon.

The road to di­rect scanout

The tra­di­tional ben­e­fit of hard­ware-ac­cel­er­ated video de­cod­ing has been the re­duc­tion in CPU load. While this alone is of course hugely im­por­tant, there are other places where power and time is be­ing wasted dur­ing video de­code. Firstly, the CPU must copy the de­coded frame data to GPU mem­ory. The GPU must then com­pos­ite that frame into the scene as di­rected by the com­pos­i­tor. The fi­nal ren­dered scene must then be copied to the dis­play con­troller’s mem­ory, and the dis­play con­troller pro­grammed to scan out the scene. This must all hap­pen at the play­ing video’s fram­er­ate.

We can do bet­ter than this. Linux’s DMA sub­sys­tem sup­ports shar­ing mem­ory re­gions be­tween mul­ti­ple de­vices. In this con­text, it al­lows us to elim­i­nate the mul­ti­ple copies of the same frame­buffer data from one re­gion to an­other. This only works if all hard­ware blocks in the chain sup­port the same frame­buffer for­mat, how­ever. This is where things start to get tricky.

Framebuffers come in all sorts of for­mats and sizes. Video data for ex­am­ple is al­most al­ways stored and trans­mit­ted in a semi­pla­nar Y’CbCr for­mat, in­spired by the ana­logue video stor­age and broad­cast stan­dards of the 20th cen­tury. On top of this, graph­ics hard­ware al­most al­ways uses some form of spe­cialised ad­dress­ing. Pixels are not “next” to each other in mem­ory and are in­stead tiled to re­duce cache misses and other per­for­mance is­sues. Moreover, frame­buffers are of­ten com­pressed too, fur­ther re­duc­ing mem­ory foot­print and pres­sure on the bus.

All of that to say, elim­i­nat­ing frame­buffer copies be­tween hard­ware blocks is not sim­ple. Each hard­ware block must agree on the frame­buffer’s pixel for­mat, its ad­dress­ing mode, and any com­pres­sion ap­plied to it. If they can­not agree on this, copies and con­ver­sions must be done in soft­ware.

One might be in­clined to ask why such “shared” frame­buffers can’t just be cre­ated with “raw” pixel data. Consider a 1920x1080 frame­buffer con­tain­ing raw 8-bit ARGB pixel data. That is around 8 MiB of data. At 4K, this bal­loons to just un­der 32 MiB. Even with­out the added penalty of copies, read­ing and writ­ing this much data at 30, 60, 165, or even 240 frames per sec­ond is an enor­mous strain on the mem­ory bus and there­fore an enor­mous power drain. Even if we some­how had an in­fi­nitely per­for­mant and ef­fi­cient mem­ory bus, each hard­ware block in the chain would still have to have enough lo­cal cache or RAM off the bus, as well as the horse­power to process such a vol­ume of data. This is in­fea­si­ble.

Luckily hard­ware ven­dors agree, and most “families” of dis­play hard­ware solve this prob­lem by im­ple­ment­ing sup­port for the same ad­dress­ing and com­pres­sion schemes. This al­lows their 3D en­gines, dis­play con­trollers and video ac­cel­er­a­tors to share mem­ory-ef­fi­cient frame­buffers with­out hav­ing their own mas­sive lo­cal caches or con­stantly ham­mer­ing the mem­ory bus. On Linux, each dri­ver de­clares which for­mats it sup­ports and var­i­ous parts of the soft­ware stack then ne­go­ti­ate and agree on a com­mon for­mat to use for shared buffers. Thankfully for us, Apple chose not to Think too Differently here. Well, mostly.

Apple hard­ware uses two main ad­dress­ing and com­pres­sion for­mats. AGX, named af­ter the GPU, and Interchange. While the AGX for­mat is used ex­clu­sively in­side AGX it­self, the Interchange for­mat is also sup­ported by DCP and AVD. On ma­cOS, this en­ables the di­rect scanout of frame­buffers from both AVD and AGX, al­low­ing Quartz (the ma­cOS com­pos­i­tor) to op­por­tu­nit­i­cally choose to do al­most noth­ing in a lot of every­day sce­nar­ios. If video is play­ing and noth­ing else is hap­pen­ing, the GPU can shut off com­pletely and all the com­pos­i­tor has to do is make sure DCP is dis­play­ing new frames as AVD gen­er­ates them. If a game or ap­pli­ca­tion is in fullscreen, the com­pos­i­tor can sim­ply pass DCP the ad­dress of that ap­pli­ca­tion’s own frame­buffer and dis­able all of its own ren­der­ing ac­tiv­i­ties. The good news is that we are now well on the way to be­ing able to repli­cate this in Asahi Linux!

Thanks to ground­work laid by Alyssa and Lina, the AGX dri­ver al­ready had ba­sic sup­port for Apple’s Interchange frame­buffer for­mat, it was sim­ply not yet wired up. Oliver Bestmann and I vol­un­teered to wire up and en­able Interchange sup­port in the DCP ker­nel dri­ver, as well as both the Asahi and Honeykrisp Mesa dri­vers. Coupled with work al­ready done bring­ing Y’CbCr and over­lay plane sup­port to DCP, this has cleared the way for di­rect scanout of AGX-rendered frame­buffers to DCP! AVD sup­port is on the way, with so­fus cur­rently in­ves­ti­gat­ing its abil­ity to out­put Interchange for­mat buffers.

While this is all fan­tas­tic news, we are not quite ready to ship this to users just yet. Kwin, the com­pos­i­tor for KDE Plasma, con­sid­ers our setup “multi GPU” as AGX and DCP are dis­tinct hard­ware blocks. As such, di­rect scanout us­ing the DMA-BUF API is com­pletely dis­abled for now. Kwin devs are ac­tively work­ing on im­prov­ing this sit­u­a­tion, and di­rect scanout on se­tups like ours could be en­abled in Kwin from as soon as Plasma 6.8!

Sundry up­stream­ing

As al­ways, we con­tinue to get patches up­streamed. Progress has slowed in re­cent months, and it may even ap­pear as though we’ve gone back­wards. This is only be­cause we have al­ready up­streamed most things! Most of what is left is ei­ther enor­mous work that we can­not up­stream yet (e.g. GPU, DCP) or new fea­tures that we have only been able to work on due to clear­ing most of the up­stream­ing back­log. That said, we still have some odds, sods, bits and bobs sit­ting in the tree. Recently up­streamed patches in­clude a num­ber of I2S pe­riph­eral changes re­lated to en­abling speak­er­safe­tyd to func­tion, the Devicetree patches en­abling the SMC-based hw­mon dri­ver, and of course fixes for all of the SMC firmware in­ter­face changes in­tro­duced by ma­cOS 27.

Thanks again!

Frequent read­ers will have no­ticed a num­ber of new names pop­ping up in the blog posts re­cently. Thanks to the gen­er­ous sup­port of our GitHub Sponsors and Open Collective back­ers, we have been able to get these folks the hard­ware they need to work the magic that they have been. AVD sup­port, M4 bringup, and other good­ies we have in store are only pos­si­ble be­cause of you.

James Calligeros · 2026 – 08-26

Wait… you said they were an­i­mated!

Ah, yes… well, un­for­tu­nately we do not have all the an­i­ma­tions work­ing yet, but we do have quite a few.

Look for the color thumb­nails. They iden­tify the com­pleted an­i­ma­tions. Use the prev and next links (above right) to browse the thumb­nail pages.

As time goes on, we’ll be adding more un­til all 507 are com­plete. Click the Facebook “Subscribe” or Twitter “Follow” but­ton be­low to be no­ti­fied of our progress.

Meanwhile, we hope you en­joy the an­i­ma­tions we have com­pleted, along with Henry T. Brown’s orig­i­nal il­lus­tra­tions in this clas­sic tech­ni­cal ref­er­ence.

See the About page for more.

Close

Comics I en­joy: Three Word Phrase, SMBC, Dinosaur Comics, Oglaf (nsfw), A Softer World, Buttersafe, Perry Bible Fellowship, Questionable Content, Buttercup Festival, Homestuck, Junior Scientist Power Hour

xkcd.com is best viewed with Netscape Navigator 4.0 or be­low on a Pentium 3±1 em­u­lated in Javascript on an Apple IIGSat a screen res­o­lu­tion of 1024x1. Please en­able your ad block­ers, dis­able high-heat dry­ing, and re­move your de­vice­from Airplane Mode and set it to Boat Mode. For se­cu­rity rea­sons, please leave caps lock on while brows­ing.

If you live in NYC and are any­where on so­cial me­dia, you’ll likely have seen Zohran’s videos.

Oftentimes, his videos an­nounce a new pro­ject or ini­tia­tive or event.

If the an­nounce­ment is some­thing that you can ac­tively par­tic­i­pate in, the videos also al­ways end with a short, top-level link: nyc.gov/{​ini­tia­tive}.

nyc.gov/

I love that. I think it:

Makes gov­ern­ment easy to en­gage with. It’s a hu­man-read­able URL that I can eas­ily fol­low through on. It also fun­nels so­cial me­dia dis­tri­b­u­tion into one place, owned and op­er­ated by NYC.

Sets up a pat­tern of in­ter­ac­tion. nyc.gov is where I can ex­pect to in­ter­act with city gov­ern­ment on­line.

Follows up an­nounce­ments with ac­tual ex­pe­ri­ences.

Allen, S. K., Linsbauer, A., Randhawa, S. S., Huggel, C., Rana, P., and Kumari, A.: Glacial lake out­burst flood risk in Himachal Pradesh, India: an in­te­gra­tive and an­tic­i­pa­tory ap­proach con­sid­er­ing cur­rent and fu­ture threats, Natural Hazards, 84, 1741 – 1763, https://​doi.org/​10.1007/​s11069 – 016-2511-x, 2016.

Allen, S. K., Zhang, G., Wang, W., Yao, T., and Bolch, T.: Potentially dan­ger­ous glacial lakes across the Tibetan Plateau re­vealed us­ing a large-scale au­to­mated as­sess­ment ap­proach, Sci. Bull., 64, 435 – 445, https://​doi.org/​10.1016/​j.scib.2019.03.011, 2019.

Allen, S. K., Frey, H., Haeberli, W., Huggel, C., Chiarle, M., and Geertsema, M.: Assessment Principles for Glacier and Permafrost Hazards in Mountain Regions, Oxford Research Encyclopedias: Natural Hazard Science, Oxford University Press, Oxford, UK, https://​doi.org/​10.1093/​acre­fore/​9780199389407.013.356, 2022.

Benn, D. I., Bolch, T., Hands, K., Gulley, J., Luckman, A., Nicholson, L. I., Quincey, D., Thompson, S., Toumi, R., and Wiseman, S.: Response of de­bris-cov­ered glac­i­ers in the Mount Everest re­gion to re­cent warm­ing, and im­pli­ca­tions for out­burst flood haz­ards, Earth Sci. Rev., 114, 156 – 174, 2012.

Bhardwaj, A. and Sam, L.: Reconstruction and Characterisation of Past and the Most Recent Slope Failure Events at the 2021 Rock-Ice Avalanche Site in Chamoli, Indian Himalaya, Remote Sens.-Basel, 14, 949, https://​doi.org/​10.3390/​rs14040949, 2022.

Bhattacharya A., Bolch T., Mukherjee K., King O., Menounos B., Kapitsa V., Neckel N., Yang W., and Yao T.: High Mountain Asian glac­ier re­sponse to cli­mate re­vealed by multi-tem­po­ral satel­lite ob­ser­va­tions since the 1960s, Nat. Commun., 12, 4133, https://​doi.org/​10.1038/​s41467 – 021-24180-y, 2021.

Bolch, T., Shea, J. M., Liu, S., Azam, F. M., Gao, Y., Gruber, S., Immerzeel, W. W., Kulkarni, A., Li, H., Tahir, A. A., Zhang, G., and Zhang, Y.: Status and Change of the Cryosphere in the Extended Hindu Kush Himalaya Region, in: The Hindu Kush Himalaya Assessment, edited by: Wester, P., Mishra, A., Mukherji, A., and Shrestha, A Springer International Publishing, Cham, 209 – 255, https://​doi.org/​10.1007/​978 – 3-319 – 92288-1_7, 2019.

Bolch T., Yao T., Bhattacharya A., Hu Y., King O., Liu L., Pronk J. B., Rastner P., and Zhang G.: Earth Observation to Investigate Occurrence, Characteristics and Changes of Glaciers, Glacial Lakes and Rock Glaciers in the Poiqu River Basin (Central Himalaya). Remote Sensing, 14(8):1927, https://​doi.org/​10.3390/​rs14081927, 2022.

Carlà, T., Intrieri, E., Raspini, F., Bardi, F., Farina, P., Ferretti, A., Colombo, D., Novali, F., and Casagli, N.:Perspectives on the pre­dic­tion of cat­a­strophic slope fail­ures from satel­lite InSAR, Sci. Rep.-UK, 9, 14137, https://​doi.org/​10.1038/​s41598 – 019-50792-y, 2019.

Carrivick, J. L. and Tweed, F. S.: A global as­sess­ment of the so­ci­etal im­pacts of glac­ier out­burst floods, Global Planet. Change, 144, 1 – 16, https://​doi.org/​10.1016/​j.glo­placha.2016.07.001, 2016.

Chen, F., Zhang, M., Guo, H., Allen, S., Kargel, J. S., Haritashya, U. K., and Watson, C. S.: Annual 30 m dataset for glacial lakes in High Mountain Asia from 2008 to 2017, Earth Syst. Sci. Data, 13, 741 – 766, https://​doi.org/​10.5194/​essd-13 – 741-2021, 2021.

Chen, N. S., Hu, G. Sh., Deng, W., Khanal, N., Zhu, Y. H., and Han, D.: On the wa­ter haz­ards in the trans-bound­ary Kosi River basin, Nat. Hazards Earth Syst. Sci., 13, 795 – 808, https://​doi.org/​10.5194/​nhess-13 – 795-2013, 2013.

Clague, J. J. and Evans, S. G.: A re­view of cat­a­strophic drainage of moraine-dammed lakes in British Columbia, Quaternary Sci. Rev., 19, 1763 – 1783, 2000.

Cook, K. L., Andermann, C., Gimbert, F., Adhikari, B. R., and Hovius, N.: Glacial lake out­burst floods as dri­vers of flu­vial ero­sion in the Himalaya, Science, 362, 53 – 57, https://​doi.org/​10.1126/​sci­ence.aat4981, 2018.

Cook, S. J. and Quincey, D. J.: Estimating the vol­ume of Alpine glacial lakes, Earth Surf. Dynam., 3, 559 – 575, https://​doi.org/​10.5194/​es­urf-3 – 559-2015, 2015.

Emmer, A. and Cochachin, A.: The causes and mech­a­nisms of moraine-dammed lake fail­ures in the Cordillera Blanca, North American Cordillera, and Himalayas, AUC Geographica, 48, 5 – 15, 2013.

Emmer, A., Harrison, S., Mergili, M., Allen, S., Frey, H., and Huggel, C.: 70 years of lake evo­lu­tion and glacial lake out­burst floods in the Cordillera Blanca (Peru) and im­pli­ca­tions for the fu­ture, Geomorphology, 365, 107178, https://​doi.org/​10.1016/​j.ge­o­morph.2020.107178, 2020.

Farinotti, D., Huss, M., Fürst, J. J., Landmann, J., Machguth, H., Maussion, F., and Pandit, A.: A con­sen­sus es­ti­mate for the ice thick­ness dis­tri­b­u­tion of all glac­i­ers on Earth, Nat. Geosci., 12, 168 – 173, https://​doi.org/​10.1038/​s41561 – 019-0300 – 3, 2019a.

Farinotti, D., Round, V., Huss, M., Compagno, L., and Zekollari, H.: Large hy­dropower and wa­ter-stor­age po­ten­tial in fu­ture glac­ier-free basins, Nature, 575, 341 – 344, https://​doi.org/​10.1038/​s41586 – 019-1740-z, 2019b.

Frey, H., Haeberli, W., Linsbauer, A., Huggel, C., and Paul, F.: A multi-level strat­egy for an­tic­i­pat­ing fu­ture glac­ier lake for­ma­tion and as­so­ci­ated haz­ard po­ten­tials, Nat. Hazards Earth Syst. Sci., 10, 339 – 352, https://​doi.org/​10.5194/​nhess-10 – 339-2010, 2010.

Frey, H., Huggel, C., Chisolm, R. E., Baer, P., McArdell, B. W., Cochachin, A., and Portocarrero, C.: Multi-source glacial lake out­burst flood haz­ard as­sess­ment and map­ping for Huaraz, Cordillera Blanca, Peru, Front. Earth Sci., 6, 210, https://​doi.org/​10.3389/​feart.2018.00210, 2018.

Fujita, K., Sakai, A., Takenaka, S., Nuimura, T., Surazakov, A. B., Sawagaki, T., and Yamanokuchi, T.: Potential flood vol­ume of Himalayan glacial lakes, Nat. Hazards Earth Syst. Sci., 13, 1827 – 1839, https://​doi.org/​10.5194/​nhess-13 – 1827-2013, 2013.

Furian, W., Loibl, D., and Schneider, C.: Future glacial lakes in High Mountain Asia: an in­ven­tory and as­sess­ment of haz­ard po­ten­tial from sur­round­ing slopes, J. Glaciol., 67 (264), 653 – 670, https://​doi.org/​10.1017/​jog.2021.18, 2021.

GAPHAZ: Assessment of Glacier and Permafrost Hazards in Mountain Regions: Technical Guidance Document, pre­pared by: Allen, S., Frey, H., and Huggel, C., Standing Group on Glacier and Permafrost Hazards in Mountains (GAPHAZ) of the International Association of Cryospheric Sciences (IACS) and the International Permafrost Association (IPA), Zurich, Switzerland/Lima, Peru, 72 pp., 2017.

Gardelle, J., Arnaud, Y., and Berthier, E.: Contrasted evo­lu­tion of glacial lakes along the Hindu Kush Himalaya moun­tain range be­tween 1990 and 2009, Global Planet. Change, 75, 47 – 55, 2011.

Haeberli, W., Buetler, M., Huggel, C., Lehmann Friedli, T., Schaub, Y., and Schleiss, A. J.: New lakes in deglaciat­ing high-moun­tain re­gions – op­por­tu­ni­ties and risks, Climatic Change, 139, 201 – 214, 2016.

Haeberli, W., Schaub, Y., and Huggel, C.: Increasing risks re­lated to land­slides from de­grad­ing per­mafrost into new lakes in de-glaciat­ing moun­tain ranges, Geomorphology, 293, 405 – 417, 2017.

Haritashya, U. K., Kargel, J. S., Shugar, D. H., Leonard, G. J., Strattman, K., Watson, C. S., Shean, D., Harrison, S., Mandli, K. T., and Regmi, D.: Evolution and con­trols of large glacial lakes in the Nepal Himalaya, Remote Sens.-Basel, 10, 1 – 31, https://​doi.org/​10.3390/​rs10050798, 2018.

Hock, R., Rasul, G., Adler, C., Cáceres, B., Gruber, S., Hirabayashi, Y., Jackson, M., Kääb, A., Kang, S., Kutuzov, S., Milner, A., Molau, U., Morin, S., Orlove, B., and Steltzer, H.: High Mountain Areas, in: IPCC Special Report on the Ocean and Cryosphere in a Changing Climate, edited by: Pörtner, H.-O., Roberts, D. C., Masson-Delmotte, V., Zhai, P., Tignor, M., Poloczanska, E., Mintenbeck, K., Alegría, A., Nicolai, M., Okem, A., Petzold, J., Rama, B., and Weyer, N. M., Cambridge University Press, Cambridge, UK and New York, NY, USA, 131 – 202, https://​doi.org/​10.1017/​9781009157964.004, 2019.

Huggel, C., Haeberli, W., Kääb, A., Bieri, D., and Richardson, S.: An as­sess­ment pro­ce­dure for glacial haz­ards in the Swiss Alps, Can. Geotech. J., 41, 1068 – 1083, 2004.

Huggel, C., Cochachin, A., Drenkhan, F., Fluixá-Sanmartín, J., Frey, H., García Hernández, J., Jurt, C., Muñoz, R., Price, K., and Vicuña, L.: Glacier Lake 513, Peru: lessons for early warn­ing ser­vice de­vel­op­ment, WMO Bulletin, 69, 45 – 52, 2020.

Kääb, A., Jacquemart, M., Gilbert, A., Leinss, S., Girod, L., Huggel, C., Falaschi, D., Ugalde, F., Petrakov, D., Chernomorets, S., Dokukin, M., Paul, F., Gascoin, S., Berthier, E., and Kargel, J. S.: Sudden large-vol­ume de­tach­ments of low-an­gle moun­tain glac­i­ers – more fre­quent than thought?, The Cryosphere, 15, 1751 – 1785, https://​doi.org/​10.5194/​tc-15 – 1751-2021, 2021.

Kargel, J. S., Leonard, G. J., Shugar, D. H., Haritashya, U. K., Bevington, A., Fielding, E. J., Fujita, K., Geertsema, M., Miles, E. S., Steiner, J., Anderson, E., Bajracharya, S., Bawden, G. W., Breashears, D. F., Byers, A., Collins, B., Dhital, M. R., Donnellan, A., Evans, T. L., Geai, M. L., Glasscoe, M. T., Green, D., Gurung, D. R., Heijenk, R., Hilborn, A., Hudnut, K., Huyck, C., Immerzeel, W. W., Liming, J., Jibson, R., Kääb, A., Khanal, N. R., Kirschbaum, D., Kraaijenbrink, P. D., Lamsal, D., Shiyin, L., Mingyang, L., McKinney, D., Nahirnick, N. K., Zhuotong, N., Ojha, S., Olsenholler, J., Painter, T. H., Pleasants, M., Pratima, K. C., Yuan, Q. I., Raup, B. H., Regmi, D., Rounce, D. R., Sakai, A., Donghui, S., Shea, J. M., Shrestha, A. B., Shukla, A., Stumm, D., van der Kooij, M., Voss, K., Xin, W., Weihs, B., Wolfe, D., Lizong, W., Xiaojun, Y., Yoder, M. R., and Young, N.: Geomorphic and ge­o­logic con­trols of geo­haz­ards in­duced by Nepal’s 2015 Gorkha earth­quake, Science, 351, 6269, https://​doi.org/​10.1126/​sci­ence.aac8353, 2016.

Khanal, N. R., Mool, P. K., Shrestha, A. B., Rasul, G., Ghimire, P. K., Shrestha, R. B., and Joshi, S. P.: A com­pre­hen­sive ap­proach and meth­ods for glacial lake out­burst flood risk as­sess­ment, with ex­am­ples from Nepal and the trans­bound­ary area, Int. J. Water. Resour. D., 31, 219 – 237, 2015a.

Khanal, N. R., Hu, J.-M., and Mool, P.: Glacial Lake Outburst Flood Risk in the Poiqu/Bhote Koshi/Sun Koshi River Basin in the Central Himalayas, Mt. Res. Dev., 35, 351 – 364, 2015b.

King, O.: Glacier sur­face el­e­va­tion es­ti­mates for a glac­ier in the Poiqu river basin, Central Himalaya, Zenodo [data set], https://​doi.org/​10.5281/​zen­odo.7333894, 2022.

King, O., Dehecq, A., Quincey, D., and Carrivick, J.: Contrasting geo­met­ric and dy­namic evo­lu­tion of lake and land-ter­mi­nat­ing glac­i­ers in the cen­tral Himalaya, Global Planet. Change, 167, 46 – 60, https://​doi.org/​10.1016/​j.glo­placha.2018.05.006, 2018.

King, O., Bhattacharya, A., Bhambri, R., and Bolch, T.: Glacial lakes ex­ac­er­bate Himalayan glac­ier mass loss, Sci. Rep.-UK, 9, 18145, https://​doi.org/​10.1038/​s41598 – 019-53733-x, 2019.

King, O., Bhattacharya, A., Ghuffar, S., Tait, A., Guilford, S., Elmore, A. C., and Bolch, T.: Six Decades of Glacier Mass Changes around Mt. Everest Are Revealed by Historical and Contemporary Images, One Earth, 3, 608 – 620, https://​doi.org/​10.1016/​j.oneear.2020.10.019, 2020.

Korup, O. and Tweed, F.: Ice, moraine, and land­slide dams in moun­tain­ous ter­rain, Quarternary Sci. Rev., 26, 3406 – 3422, 2007.

Kraaijenbrink, P. D. A., Bierkens, M. F. P., Lutz, A. F., and Immerzeel, W. W.: Impact of a global tem­per­a­ture rise of 1.5 degrees Celsius on Asia’s glac­i­ers, Nature, 549, 5 – 7, https://​doi.org/​10.1038/​na­ture23878, 2017.

Linsbauer, A., Paul, F., and Haeberli, W.: Modeling glac­ier thick­ness dis­tri­b­u­tion and bed topog­ra­phy over en­tire moun­tain ranges with GlabTop: ap­pli­ca­tion of a fast and ro­bust ap­proach., J. Geophys. Res., 117, F03007, https://​doi.org/​10.1029/​2011JF002313, 2012.

Linsbauer, A., Paul, F., Machguth, H., and Haeberli, W.: Comparing three dif­fer­ent meth­ods to model sce­nar­ios of fu­ture glac­ier change in the Swiss Alps, Ann. Glaciol., 54, 241 – 253, 2013.

Linsbauer, A., Frey, H., Haeberli, W., Machguth, H., Azam, M. F., and Allen, S.: Modelling glac­ier-bed overdeep­en­ings and pos­si­ble fu­ture lakes for the glac­i­ers in the Himalaya–Karakoram re­gion, Ann. Glaciol., 57, 119 – 130, 2016.

Liu, J.-J., Tang, C., and Cheng, Z.-L.: The Two Main Mechanisms of Glacier Lake Outburst Flood in Tibet, China, J. Mt. Sci., 10, 239 – 248, https://​doi.org/​10.1007/​s11629 – 013-2517 – 8, 2013.

Lliboutry, L., Morales, A. B., Pautre, A., and Schneider, B.: Glaciological prob­lems set by the con­trol of dan­ger­ous lakes in Cordillera Blanca, Peru. I. Historic fail­ure of morainic dams, their causes and pre­ven­tion, J. Glaciol., 18, 239 – 254, 1977.

Magnin, F., Krautblatter, M., Deline, P., Ravanel, L., Malet, E., and Bevington, A.: Determination of warm, sen­si­tive per­mafrost ar­eas in near-ver­ti­cal rock­walls and eval­u­a­tion of dis­trib­uted mod­els by elec­tri­cal re­sis­tiv­ity to­mog­ra­phy, J. Geophys. Res.-Earth, 120, 745 – 762, 2015.

Magnin, F., Haeberli, W., Linsbauer, A., Deline, P., and Ravanel, L.: Estimating glac­ier-bed overdeep­en­ings as pos­si­ble sites of fu­ture lakes in the de-glaciat­ing Mont Blanc mas­sif (Western European Alps), Geomorphology, 350, https://​doi.org/​10.1016/​j.ge­o­morph.2019.106913, 2020.

Maurer, J. M., Schaefer, J. M., Rupper, S., and Corley, A.: Acceleration of ice loss across the Himalayas over the past 40 years, Sci. Adv., 5, eaav7266, https://​doi.org/​10.1126/​sci­adv.aav7266, 2019.

Mergili, M. and Pudasaini, S. P.: r.avaflow — The mass flow sim­u­la­tion tool, https://​www.land­slide­mod­els.org/​r.avaflow/ (last ac­cess: 22 November 2022), 2021.

Mergili, M., Fischer, J.-T., Krenn, J., and Pudasaini, S. P.: r.avaflow v1, an ad­vanced open-source com­pu­ta­tional frame­work for the prop­a­ga­tion and in­ter­ac­tion of two-phase mass flows, Geosci. Model Dev., 10, 553 – 569, https://​doi.org/​10.5194/​gmd-10 – 553-2017, 2017.

Mölg, N., Ferguson, J., Bolch, T., and Vieli, A.: On the in­flu­ence of de­bris cover on glac­ier mor­phol­ogy: How high-re­lief struc­tures evolve from smooth sur­faces, Geomorphology, 357, 107092, https://​doi.org/​10.1016/​j.ge­o­morph.2020.107092, 2020.

Nie, Y., Sheng, Y., Liu, Q., Liu, L., Liu, S., Zhang, Y., and Song, C.: A re­gional-scale as­sess­ment of Himalayan glacial lake changes us­ing satel­lite ob­ser­va­tions from 1990 to 2015, Remote Sens. Environ., 189, 1 – 13, https://​doi.org/​10.1016/​j.rse.2016.11.008, 2017.

Nie, Y., Liu, Q., Wang, J., Zhang, Y., Sheng, Y., and Liu, S.: An in­ven­tory of his­tor­i­cal glacial lake out­burst floods in the Himalayas based on re­mote sens­ing ob­ser­va­tions and ge­o­mor­pho­log­i­cal analy­sis, Geomorphology, 308, 91 – 106, https://​doi.org/​10.1016/​j.ge­o­morph.2018.02.002, 2018.

Obu, J., Westermann, S., Bartsch, A., Berdnikov, N., Christiansen, H. H., Dashtseren, A., Delaloye, R., Elberling, B., Etzelmüller, B., Kholodov, A., Khomutov, A., Kääb, A., Leibman, M. O., Lewkowicz, A. G., Panda, S. K., Romanovsky, V., Way, R. G., Westergaard-Nielsen, A., Wu, T., Yamkhin, J., and Zou, D.: Northern Hemisphere per­mafrost map based on TTOP mod­el­ling for 2000 – 2016 at 1 km2 scale, Earth-Sci. Rev., 193, 299 – 316, https://​doi.org/​10.1016/​J.EARSCIREV.2019.04.023, 2019.

Pronk, J. B., Bolch, T., King, O., Wouters, B., and Benn, D. I.: Contrasting sur­face ve­loc­i­ties be­tween lake- and land-ter­mi­nat­ing glac­i­ers in the Himalayan re­gion, The Cryosphere, 15, 5577 – 5599, https://​doi.org/​10.5194/​tc-15 – 5577-2021, 2021.

Pudasaini, S. P. and Mergili, M.: A Multi-Phase Mass Flow Model, J. Geophys. Res.-Earth, 124, 2920 – 2942, https://​doi.org/​10.1029/​2019JF005204, 2019.

Quincey, D. J., Richardson, S. D., Luckman, A., Lucas, R. M., Reynolds, J. M., Hambrey, M. J., and Glasser, N. F.: Early recog­ni­tion of glacial lake haz­ards in the Himalaya us­ing re­mote sens­ing datasets, Global Planet. Change, 56, 137 – 152, 2007.

Ren, Y.-Y., Ren, G.-Y., Sun, X.-B., Shrestha, A. B., You, Q.-L., Zhan, Y.-J., Rajbhandari, R., Zhang, P.-F., and Wen, K.-M.: Observed changes in sur­face air tem­per­a­ture and pre­cip­i­ta­tion in the Hindu Kush Himalayan re­gion over the last 100-plus years, Advances in Climate Change Research, 8, 148 – 156, https://​doi.org/​10.1016/​j.ac­cre.2017.08.001, 2017.

Richardson, S. D. and Reynolds, J. M.: An overview of glacial haz­ards in the Himalayas, Quatern. Int., 65/66, 31 – 47, 2000.

Sanjay, J., Krishnan, R., Shrestha, A. B., Rajbhandari, R., and Ren, G. Y.: Downscaled cli­mate change pro­jec­tions for the Hindu Kush Himalayan re­gion us­ing CORDEX South Asia re­gional cli­mate mod­els, Advances in Climate Change Research, 8, 185 – 198, https://​doi.org/​10.1016/​j.ac­cre.2017.08.003, 2017.

Sattar, A. and Allen, S.: Glacial lake out­burst flood sim­u­la­tions for Poiqu Basin, Zenodo [data set], https://​doi.org/​10.5281/​zen­odo.7326610, 2022.

Sattar, A., Haritashya, U. K., Kargel, J. S., Leonard, G. J., Shugar, D. H., and Chase, D. V.: Modeling Lake Outburst and Downstream Hazard Assessment of the Lower Barun Glacial Lake, Nepal Himalaya, J. Hydrol., 598, 126208, https://​doi.org/​10.1016/​j.jhy­drol.2021.126208, 2021.

Sattar, A., Haritashya, U. K., Kargel, J. S., and Karki, A.: Transition of a small Himalayan glac­ier lake out­burst flood to a gi­ant trans­bor­der flood and de­bris flow, Sci. Rep.-UK, 12, 1 – 15, https://​doi.org/​10.1038/​s41598 – 022-16337 – 6, 2022.

Schmid, M.-O., Baral, P., Gruber, S., Shahi, S., Shrestha, T., Stumm, D., and Wester, P.: Assessment of per­mafrost dis­tri­b­u­tion maps in the Hindu Kush Himalayan re­gion us­ing rock glac­i­ers mapped in Google Earth, The Cryosphere, 9, 2089 – 2099, https://​doi.org/​10.5194/​tc-9 – 2089-2015, 2015.

Schneider, D., Huggel, C., Haeberli, W., and Kaitna, R.: Unraveling dri­ving fac­tors for large rock-ice avalanche mo­bil­ity, Earth Surf. Proc. Land., 36, 1948 – 1966, 2011.

Searle, M. P., Parrish, R. R., Hodges, K. V., Hurford, A., Ayres, M. W., and Whitehouse, M. J.: Shisha Pangma Leucogranite, South Tibetan Himalaya: Field Relations, Geochemistry, Age, Origin, and Emplacement, J. Geol., 105, 295 – 317, 1997.

Shedlock, K. M., Giardini, D., Grünthal, G., and Zhang, P.: The GSHAP Global Seismic Hazard Map, Seismol. Res. Lett., 71, 679 – 686, https://​doi.org/​10.1785/​gssrl.71.6.679, 2000.

Shrestha, A. B., Eriksson, M., Mool, P., Ghimire, P., Mishra, B., and Khanal, N. R.: Glacial lake out­burst flood risk as­sess­ment of Sun Koshi basin, Nepal, Geomatics, Natural Hazards and Risk, 1, 157 – 169, https://​doi.org/​10.1080/​19475701003668968, 2010.

Shugar, D. H., Burr, A., Haritashya, U. K., Kargel, J. S., Watson, C. S., Kennedy, M. C., Bevington, A. R., Betts, R. A., Harrison, S., and Strattman, K.: Rapid world­wide growth of glacial lakes since 1990, Nat. Clim. Chang., 10, 939 – 945, https://​doi.org/​10.1038/​s41558 – 020-0855 – 4, 2020.

Shugar, D. H., Jacquemart, M., Shean, D., Bhushan, S., Upadhyay, K., Sattar, A., Schwanghart, W., McBride, S., van Wyk de Vries, M., Mergili, M., Emmer, A., Deschamps-Berger, C., McDonnell, M., Bhambri, R., Allen, S., Berthier, E., Carrivick, J. L., Clague, J. J., Dokukin, M., Dunning, S. A., Frey, H., Gascoin, S., Haritashya, U. K., Huggel, C., Kääb, A., Kargel, J. S., Kavanaugh, J. L., Lacroix, P., Petley, D., Rupper, S., Azam, M. F., Cook, S. J., Dimri, A. P., Eriksson, M., Farinotti, D., Fiddes, J., Gnyawali, K. R., Harrison, S., Jha, M., Koppes, M., Kumar, A., Leinss, S., Majeed, U., Mal, S., Muhuri, A., Noetzli, J., Paul, F., Rashid, I., Sain, K., Steiner, J., Ugalde, F., Watson, C. S., and Westoby, M. J.: A mas­sive rock and ice avalanche caused the dis­as­ter at Chamoli, Indian Himalaya, Science, 373, 300 – 306, https://​doi.org/​10.1126/​sci­ence.ab­h4455, 2021.

Steffen, T., Huss, M., Estermann, R., Hodel, E., and Farinotti, D.: Volume, evo­lu­tion, and sed­i­men­ta­tion of fu­ture glac­ier lakes in Switzerland over the 21st century, Earth Surf. Dynam., 10, 723 – 741, https://​doi.org/​10.5194/​es­urf-10 – 723-2022, 2022.

Stolle, A., Bernhardt, A., Schwanghart, W., Hoelzmann, P., Adhikari, B. R., Fort, M., and Korup, O.: Catastrophic val­ley fills record large Himalayan earth­quakes, Pokhara, Nepal, Quaternary Sci. Rev., 177, 88 – 103, https://​doi.org/​10.1016/​j.quas­cirev.2017.10.015, 2017.

Thompson, S., Benn, D. I., Mertes, J., and Luckman, A.: Stagnation and mass loss on a Himalayan de­bris-cov­ered glac­ier: Processes, pat­terns and rates, J. Glaciology, 62, 467 – 485, https://​doi.org/​10.1017/​jog.2016.37, 2016.

Tiwari, A., Sain, K., Kumar, A., Tiwari, J., Paul, A., Kumar, N., Haldar, C., Kumar, S., Pandey, C. P.: Potential seis­mic pre­cur­sors and sur­fi­cial dy­nam­ics of a deadly Himalayan dis­as­ter: an early warn­ing ap­proach, Sci. Rep.-UK, 12, 3733. https://​doi.org/​10.1038/​s41598 – 022-07491-y, 2022.

Veh, G., Korup, O., von Specht, S., Roessner, S., and Walz, A.: Unchanged fre­quency of moraine-dammed glacial lake out­burst floods in the Himalaya, Nat. Clim. Change, 9 (5), 379 – 383, https://​doi.org/​10.1038/​s41558 – 019-0437 – 5, 2019.

Veh, G., Korup, O., and Walz, A.: Hazard from Himalayan glac­ier lake out­burst floods, P. Natl. Acad. Sci. USA, 117, 907 – 912, https://​doi.org/​10.1073/​pnas.1914898117, 2020.

Wang, S. and Jiao, S.: Evolution and out­burst risk analy­sis of moraine-dammed lakes in the cen­tral Chinese Himalaya, J. Earth Syst. Sci., 124, 567 – 576, https://​doi.org/​10.1007/​s12040 – 015-0559 – 8, 2015.

Wang, S. and Zhou, L.: Glacial Lake Outburst Flood Disasters and Integrated Risk Management in China, Int. J Disast. Risk Sc., 8, 493 – 497, https://​doi.org/​10.1007/​s13753 – 017-0152 – 7, 2017.

Wang, S., Dahe, Q., and Xiao, C.: Moraine-dammed lake dis­tri­b­u­tion and out­burst flood risk in the Chinese Himalaya, J. Glaciol., 61, 115 – 126, 2015.

Wang, W., Xiang, Y., Gao, Y., Lu, A., and Yao, T.: Rapid ex­pan­sion of glacial lakes caused by cli­mate and glac­ier re­treat in the Central Himalayas, Hydrol. Process., 29, 859 – 874, https://​doi.org/​10.1002/​hyp.10199, 2015.

Wang, W., Gao, Y., Iribarren Anacona, P., Lei, Y., Xiang, Y., Zhang, G., Li, S., and Lu, A.: Integrated haz­ard as­sess­ment of Cirenmaco glacial lake in Zhangzangbo val­ley, Central Himalayas, Geomorphology, 306, 292 – 305, https://​doi.org/​10.1016/​j.ge­o­morph.2015.08.013, 2018.

Wang, X., Guo, X., Yang, C., Liu, Q., Wei, J., Zhang, Y., Liu, S., Zhang, Y., Jiang, Z., and Tang, Z.: Glacial lake in­ven­tory of high-moun­tain Asia in 1990 and 2018 de­rived from Landsat im­ages, Earth Syst. Sci. Data, 12, 2169 – 2182, https://​doi.org/​10.5194/​essd-12 – 2169-2020, 2020.

Zemp, M., Huss, M., Thibert, E., Eckert, N., McNabb, R., Huber, J., Barandun, M., Machguth, H., Nussbaumer, S. U., Gärtner-Roer, I., Thomson, L., Paul, F., Maussion, F., Kutuzov, S., and Cogley, J. G.: Global glac­ier mass changes and their con­tri­bu­tions to sea-level rise from 1961 to 2016, Nature, 568, 382 – 386, https://​doi.org/​10.1038/​s41586 – 019-1071 – 0, 2019.

Zhang, G.: Bathymetry data of glacial lakes in the greater Himalaya, figshare [data set], https://​doi.org/​10.6084/​m9.figshare.21569175.v1, 2022.

Zhang, G., Yao, T., Xie, H., Wang, W., and Yang, W.: An in­ven­tory of glacial lakes in the Third Pole re­gion and their changes in re­sponse to global warm­ing, Global Planet. Change, 131, 148 – 157, 2015.

Zhang, G., Bolch, T., Allen, S., Linsbauer, A., Chen, W., and Wang, W.: Glacial lake evo­lu­tion and glac­ier–lake in­ter­ac­tions in the Poiqu River basin, cen­tral Himalaya, 1964 – 2017, J. Glaciol., 1 – 19, https://​doi.org/​10.1017/​jog.2019.13, 2019.

Zhang, T., Wang, W., Gao, T., and An, B.: Simulation and Assessment of Future Glacial Lake Outburst Floods in the Poiqu River Basin, Central Himalayas, Water, 13, 1376, https://​doi.org/​10.3390/​w13101376, 2021.

Zheng, G., Allen, S. K., Bao, A., Ballesteros-Cánovas, J. A., Huss, M., Zhang, G., Li, L., Yuan, Y., Jiang, L., Yu, T., Chen, W., and Stoffel, M.: Increasing risk of glacial lake out­burst floods from fu­ture Third Pole deglacia­tion, Nat. Clim. Change, 11, 411 – 417, https://​doi.org/​10.1038/​s41558 – 021-01028 – 3, 2021a.

Zheng, G., Mergili, M., Emmer, A., Allen, S., Bao, A., Guo, H., and Stoffel, M.: The 2020 glacial lake out­burst flood at Jinwuco, Tibet: causes, im­pacts, and im­pli­ca­tions for haz­ard and risk as­sess­ment, The Cryosphere, 15, 3159 – 3180, https://​doi.org/​10.5194/​tc-15 – 3159-2021, 2021b.

カラフルな水玉や網目模様を描いた作品で世界的に評価され、カボチャのオブジェでも知られる前衛芸術家で文化勲章受章者の草間弥生（くさま・やよい）さんが14日、多臓器不全のため東京都の病院で死去した。97歳。長野県出身。葬儀は近親者で行った。後日お別れの会を開く予定。

1957年に渡米し、73年に帰国するまで主にニューヨークを拠点に活動。ベトナム反戦を訴え、裸の男女に水玉を描くなどの街頭パフォーマンスで注目され「ハプニングの女王」と呼ばれた。

トレードマークの無数の水玉や網目は、幼い頃から悩まされてきた幻覚に由来。恐怖や不安を逃れようとして、それらを描き始めたという。絵画や版画のほか、柔らかい布に詰め物をした「ソフトスカルプチャー」や、香川県・直島に設置された「南瓜」など多彩な作品を発表した。

93年のベネチア・ビエンナーレ国際美術展に日本代表として参加し、98年にニューヨーク近代美術館で個展が開かれるなど、90年代以降に国内外で評価が高まり、2011～12年には欧米の主要美術館が大規模な回顧展を行った。