Wellfed - Planet Jamie
⚛️ Atom RSS Feed
I take short consulting engagements — architecture review, technical due diligence, mail infrastructure — through aljuna.tech .
TL;DR: I had an AI write a plakar integration to back up Minecraft servers without stopping them, it pauses world saves over RCON while the backup runs and lets players keep digging.
For those who haven’t followed, plakar is an open-source backup solution that I started in 2015, free to use, ISC-licensed, written in Go and built on top of kloset, a content-addressed storage engine that deduplicates, compresses and encrypts everything it stores and keeps snapshots immutable. It backs up from a lot of sources, stores on a lot of storages, and restores to a lot of destinations: a filesystem, an S3 bucket, an SFTP server and many more… These sources and destinations are not baked into plakar: they’re connectors, packaged as integrations that anyone can write and install.
Don’t forget to star the project on Github and join the Plakar discord .
For the last few years, I’ve been claiming that Plakar was designed with a goal to backup anything… but a claim is only a claim if it’s not backed up (pun intended) by facts. We have written 45 connectors so far but pretty much none of them are targeting general consumer products and tools, so… every now and then I’ll pick a random project, have an AI generate a fully-working connector for it, and make it available to the plakar community.
I’ll use an AI because this is what most people will do and I really want to show that there’s no excuse not to protect your data, whatever it is, even if you’re not a programmer. I hope this will inspire people to write new connectors and share them with the community.
Oh and one more note, this is not company endorsed and not done on my work time, I’m doing this on my spare time and distributing them on my personal Github account, just like any open-source contributor.
First one up: Minecraft.
A Minecraft server looks like the easiest thing in the world to back up: it’s a directory, you copy it, done. Nope. A running server rewrites its region files all the time, and a copy taken while it does is a world made of chunks from different moments… which may or may not load the day you need it, and you’ll only find out then.
The usual answers are to stop the server for the backup, which nobody enjoys when there are people playing, or to wrap
rsync
in a shell script that pokes the console and hopes for the best.
While looking for existing solutions people implemented I found a fair share of those scripts and well…
it’s very often a leap of faith.
plakar already knows how to back up a directory, deduplicate it, encrypt it and push it wherever you want, so the missing piece was small: tell the server to hold still, back up, let it go.
Nothing hidden, this is the prompt that produced the integration with Claude Opus 5.5:
Implement a fully working minecraft server integration for Plakar,
inspiring yourself from other integrations in PlakarKorp/integrations.
It needs to provide fully working and consistent backup and restore.
It needs to be tested on a real implementation with a roundtrip:
back up worlds, restore them to a new instance, ensure they are identical.
Write full test coverage validating behavior not code.This is under-specified of course, but with our straight-forward SDK and other examples, it’s enough to get going.
Every Minecraft server ships with RCON, a remote console that accepts the same commands an operator would type, so there is no need to be clever. The importer connects to it and wraps the backup with four steps:
save-off
: autosave stops and the region files stop changing
save-all flush
: everything loaded in memory is written to disk
save-on
: autosave resumes once the last file has been read
Players keep playing throughout, whatever they do during the backup stays in memory until autosave resumes and lands on disk as usual. A stopped server doesn’t need any of this and is backed up as is.
The importer and exporter are really the
fs
connectors with the server-side care added on top, which means excludes, permissions, ownership and times behave exactly like a regular filesystem backup. It also means the whole server directory goes in, not just the world:
server.properties
, whitelist and bans, plugins or mods and their configuration, everything you’d need to bring the server back up elsewhere.
The package is built and available in the devel channel, so installing it is a one-liner:
$ plakar pkg add -devel minecraft
If you’d rather build it yourself, the code lives on the
integration/minecraft
branch of
poolpOrg/plakar-integrations
and
make install
packages it and installs it in your local plakar:
$ git clone -b integration/minecraft https://github.com/poolpOrg/plakar-integrations
$ cd plakar-integrations/minecraft
$ make install
If RCON isn’t enabled already, it’s three lines in
server.properties
and a restart of the server:
enable-rcon=true
rcon.port=25575
rcon.password=choose-oneThe integration reads these settings from the server directory so there’s nothing to configure on the plakar side. Keep in mind that the console speaks plaintext, so keep the port on localhost or on a private network and not on the internet (please !).
Without RCON, a stopped server still backs up fine, but a running one is refused rather than copied inconsistently. I’d rather have a backup fail loudly tonight than have a restore fail silently in three months.
Assuming a repository was created with
plakar at /var/backups/minecraft create
, backing up the server is just:
$ plakar at /var/backups/minecraft backup minecraft:///srv/minecraftLogs are rarely worth keeping, so they can be left out:
$ plakar at /var/backups/minecraft backup -exclude 'logs/**' \
minecraft:///srv/minecraftand since nobody gets kicked out, there’s no reason not to run it from cron every night, with a tag to find them easily later on:
0 4 * * * plakar at /var/backups/minecraft backup -tag nightly \
minecraft:///srv/minecraftThis is where plakar makes a real difference compared to a tarball a night. From one night to the next most of a world doesn’t change, players hang around their bases and the rest of the map just sits there, and since plakar splits files into content-defined chunks and stores each chunk once, a region file that barely changed only costs the bytes that did. Keeping months of nightly snapshots is cheap, and each one of them is a complete server you can browse, diff or restore.
Here’s a nice screenshot of a world at the time of a backup:
Here’s how it appears after three backups in plakar:
And picking into server directory, world folder and region files:
With a preview of the EULA and properties:
Restores refuse to write into a directory where a server is running, because writing region files under a live server is the fastest way to corrupt a world. Stop it first.
Restoring the whole server where it was:
$ plakar at /var/backups/minecraft restore -to minecraft:///srv/minecraft \
<snapid>:/srv/minecraft/Someone blew up spawn last night but the rest is fine ? Restore only the overworld:
$ plakar at /var/backups/minecraft restore -to minecraft:///srv/minecraft \
<snapid>:/srv/minecraft/worldAnd moving the server to another machine is the same command, pointed at wherever the repository lives:
$ plakar at s3://backups/minecraft restore -to minecraft:///srv/minecraft \
<snapid>:/srv/minecraft/
So you can technically use
plakar
as a minecraft server migration tool :-)
There’s an
allow_running
option on the exporter to restore files the server doesn’t hold open, a plugin configuration for example, without stopping it.
It’s there for that and nothing else, don’t come complaining if you use it on a world and hell breaks loose.
Here’s a screenshot of a world after restore, identical to the previous one:
Most setups won’t need any of these, but on the importer
quiesce
(on by default) can be turned off to copy the directory as is whatever the server is doing,
rcon
sets the console address if it’s not the one from
server.properties
,
timeout
(5 minutes by default) is the time allowed for each console exchange because
save-all flush
on a large world takes a while, and
dont_traverse_fs
keeps it from following mount points under the directory.
The exporter has
allow_running
,
rcon
and
timeout
(30 seconds there), plus the usual
skip_ownership
,
skip_permissions
and
skip_times
from
fs
.
As usual, don’t use an option if you don’t know that you need it, the defaults should be fine for most.
If plakar is killed between
save-off
and
save-on
, saving stays off until someone runs
save-on
on the console. A cancelled backup turns it back on by itself, a crash cannot… so if your backups run unattended, it’s worth keeping an eye on.
A server in a container on Docker Desktop holds its world locks inside the Docker VM where the host can’t see them, so there the connectors only know the server is up through the console. Keep RCON enabled and published.
Finally, worlds on a Bukkit, Spigot or Paper server are three directories,
world
,
world_nether
and
world_the_end
, and they should be restored together unless you enjoy Nether portals leading nowhere.
All of this was tested with vanilla 26.3 in the
itzg/minecraft-server
image: a backup of the live server with saves paused, a restore refused while it ran, then a restore of the snapshot into a new directory and a server booted from it with the same seed and the same world \o/
If you’ve followed me for a while, you know that I like stupid :-)
Technically, nothing prevents us from using a minecraft server as a store for backups and encode the data as blocks to be turned into a walkable landscape.
Is it useful ? nopes. Shall we do it ? yes, we MUST.
I present to you the stupidest idea of this week-end: backups as a world .
Backing up a Minecraft server is the sensible half of this integration. The other half is half a joke, half a technical demonstration: if plakar can back up a world, could a world be the thing plakar backs up to ? Not a folder on the server, the world itself. Blocks.
It turns out the storage contract makes that easier than it sounds. A kloset store has to do very little: hold packfiles and states, give them back by content address, serve a byte range out of a packfile, list what it has, delete what it is told to. It does not care what the bytes are stored as . The fs store writes files, the S3 store writes objects, and nothing in kloset would notice if a store wrote terrain. So the problem is not plumbing, it is a codec to translate our bytes back and forth to something sensible.
Every column of a Minecraft world, every x and z, carries two bytes. The low nibble of the first byte is a height: that many blocks of stone above a base at y=64. On top of the stone sit three blocks, a stained glass, a terracotta and a concrete, and each comes in sixteen colours, so the remaining three nibbles are colours. A chunk is 256 columns, so it holds 512 bytes. A region file is 32 by 32 chunks, and chunk (0,0) of every region is a header that says which packfile or state this is, how long it is and where this region sits in it, encoded as terrain like everything else. The remaining 1023 chunks hold 511 KiB of payload.
A packfile is placed by hashing its address into region coordinates, so there is no catalog to keep in sync: listing the store is a scan of the region files and a read of each header chunk. Locks and the kloset configuration are plain files next to the world, because they change, and terrain is not meant to.
That is eight region files of my plakar checkout, seen from above at one pixel per block. Since plakar compresses and encrypts data before storing, this makes a surface that looks like noise, which is correct. The white squares in the corners are the header chunks: the padding after a header is zeros, and a zero column is white glass, white terracotta and white concrete on no stone at all.
Up close it is a field of pillars, each one a column of stone with three coloured blocks on top. This is what a player walks across (or at least tries to walk across :p). The heights are a nibble so the hills stay walkable, and nothing in the palette falls, burns, flows, spreads or gets picked up by an enderman, because the server will keep running on this world and the bytes have to survive it.
The dense version of this is obvious: 256 block types, one byte per block, 96 MiB per region, and we’re done. It would also be a solid cube of static nobody can walk on, and walking on your backups is the whole point otherwise… it’s boring and no fun. Terrain costs density, two bytes per column instead of one per block, and the region files on disk come out at roughly ten times the kloset. We’re not building something serious here so it’s fine, I’ll trade space for lulz.
The more interesting constraint is that a running server does not leave region files alone. It relights chunks it loads, it rewrites them on save, and when you upgrade the server it runs every chunk through its data fixers. So the codec cannot depend on how a chunk is laid out on disk, only on which block is where.
Players cannot be allowed to change a byte, otherwise they break the store. That is three layers:
level.dat
stop random ticks, fire, weather, mob spawning and mob griefing, so nothing grows, melts, burns or wanders off with a block.
If something gets through anyway, kloset verifies every read against its address, so a creeper that edits a packfile produces an error, not a quietly wrong restore.
$ plakar at minecraft:///srv/minecraft create
$ plakar at minecraft:///srv/minecraft backup ./plakar
$ plakar at minecraft:///srv/minecraft backup ./plakar
$ plakar at minecraft:///srv/minecraft backup ./plakar
$ plakar at minecraft:///srv/minecraft ls
2026-11-14T21:57:05Z b81e9a60 106 MiB 0s /Users/gilles/Wip/github.com/PlakarKorp/plakar
2026-11-14T21:57:03Z 703d4848 106 MiB 1s /Users/gilles/Wip/github.com/PlakarKorp/plakar
2026-11-14T21:56:15Z 881849ce 106 MiB 1s /Users/gilles/Wip/github.com/PlakarKorp/plakar
$ plakar at minecraft:///srv/minecraft cat b81e9a60:/Users/gilles/Wip/github.com/PlakarKorp/plakar/README.md
<div align="center">
<img src="./docs/banner.png" alt="Plakar: open source backup engine" />
# Plakar: open source backup engine
**Encrypted, deduplicated, verifiable, and scalable.**
Back up anything, store anywhere, restore everywhere, with zero-trust encryption and no vendor lock-in.
...
## What is Plakar?
Plakar is an open-source backup solution powered by Kloset and ptar. It creates snapshots of your data, stores them in an encrypted and deduplicated store, and lets you inspect, verify, and restore them later.
It does. Three backups of the checkout went in, deduplicated as usual, and
ls
and
cat
came back out working just like they would on a filesystem or an S3 store.
More interestingly, I launched the UI on the minecraft server store:
$ plakar at minecraft:///srv/minecraft uiand you can browse the snapshots and preview files:
Nothing, mostly. It is a toy, and I am fond of it. But it is an honest toy: it exists because the store contract is narrow enough that anything which can hold bytes and hand them back by offset can be a kloset, and the integrity checks are strong enough that a store you do not trust, like a world full of players, is still safe to restore from. Those are the properties that make plakar work on the stores that matter. This one just happens to have hills.
Do backup your minecraft servers, and do restore them.
DON’T store your backups on a minecraft server as world, really, DON’T :-)
It’s in the devel channel for now, so give it a try and tell me what breaks, issues and pull requests go to the
integration/minecraft
branch of
poolpOrg/plakar-integrations
.
As for the series, I’ll keep picking random projects and generating connectors for them every now and then. If there’s something you value and would like to see backed up, tell me… or better, grab the SDK and the docs and beat me to it: I’ll make sure the authors of the funniest integrations get their goodies :-)
Stay tuned !
I take short consulting engagements — architecture review, technical due diligence, mail infrastructure — through aljuna.tech .
L3Harris has been modernizing the communications infrastructure supporting the National Airspace System in close coordination with the FAA. With safety and reliability as our highest priorities, L3Harris, together with its telco partners and the FAA, has completed more than 70% of the planned airspace communications conversion from legacy copper wires to a fiber optic system. We are supporting the FAA in its investigation to understand the conditions that led to the Nov. 13 ground stop of our nation’s air travel. L3Harris takes the nationwide ground stop and its impact on travelers, airlines and air traffic operations seriously.
Something strange is going on in the job market for software developers.
Everyone is worried that their job is going to go away and businesses are going to turn software development over to the machines. Few dispute that agents write good code . I’ve even argued that our days of writing code are pretty much over .
Sure, agents are writing the code, but we aren’t quite ready to turn the whole thing over to agents. We are still feeling the need to supervise what they do, look closely at the code they write, and serve as gatekeeper for what gets checked into Git.
We can do this because we are seasoned, experienced developers, with hundreds of thousands of lines of code under our belt, and we’ve seen it all. We can spot bad designs, inefficient algorithms, and code smells. If the agent isn’t doing things the right way, we can spot the problem and correct it.
And how did we become seasoned, experienced developers? We started out writing bad code that was reviewed — probably first by a high school teacher or college professor, and later by senior devs. Or maybe we just wrote a lot of sloppy code and learned it was sloppy by reading, studying, and gaining experience on our own. But however it happened, it was more or less “learn by doing.”
But we aren’t “doing” anymore. So the question becomes, how is anyone going to learn to code if we don’t code? It doesn’t take advanced calculus to realize that if we don’t teach early-career developers how to develop software, then we will lose all the expertise in the profession as time relentlessly marches forward.
The classic example of a job that AI promised to take was radiology. The thinking was that AI can look at an x-ray and see the problems as well as or better than any human — often spotting problems that humans would overlook. The demise of the profession was predicted, but the opposite has occurred as demand and salaries for radiologists have risen.
And this raises an interesting question. To become a radiologist, you need to go to medical school for four years, and do an internship and a residency. And let’s not forget the four-year undergraduate degree.
But how do you become a seasoned software developer? If the job is going to become “Review this code an agent wrote for accuracy, good design, and correctness,” then how does one acquire the knowledge and experience to be able to do that job?
The training to become a radiologist involves looking at thousands of existing x-rays and learning what those x-rays reveal. The students have a specific curriculum designed to teach them everything they need to know. Their first real-world experience is under close supervision. It’s a time-tested system that trains radiologists in a proven and effective way long before they have to diagnose the maladies of actual patients on their own.
Interestingly, we don’t have any such training program for software developers. We don’t show them fully designed systems with flaws in them, pointing out what the problems are, and teaching them to understand bad code and why it’s not right. Instead, we just throw them into the deep end and say “Well, here’s a Jira ticket, get to work, and we’ll tell you how you screwed up.”
Sure, you can go to a boot camp or get a computer science degree, but those places mainly just teach you the basics, or take you somewhat beyond the basics. There really isn’t a place where developers learn what is and isn’t good code except on the job, struggling in the deep end until they can swim laps. There is no equivalent to “Here are a thousand x-rays and what is wrong with them.”
The job market for software developers is bearing this out. Sure, the numbers are going up, but 71% of that growth is companies looking for senior developers . Good for us grizzled veterans, but you can only hire so many senior developers before the lack of hiring junior developers comes up and bites you in the rear end.
So if junior developers stop writing code, how will they become senior developers?
That, my friends, is the question of the day.
Safia Southey is an international lawyer and writer who focuses on how societies reckon with wartime abuses.
Abdullah Abu Zubaida’s family spent the first anniversary of the Gaza ceasefire last month in a shelter they built from the debris of their own home. Ne’man Abu Jarad and his five daughters spent it in tents, still displaced and with no clear way back. These families and millions of other Palestinians find themselves in a twilight state between war and peace: a zombie conflict in which a ceasefire has been announced while Israeli military control and attacks continue. The agreement risks making that condition permanent by leaving Palestinian governance and Israeli withdrawal dependent on decisions made largely by outside powers.
For these families, whose circumstances were reported by the Associated Press , and others in their position, the ceasefire that was supposed to end the war has brought little control over what happens next. Whether they can return home, rebuild, or resume anything resembling ordinary life remains subject to decisions made by outside authorities, whose hold on Gaza’s future may be further entrenched by the agreement itself.
While violations of the ceasefire warrant the attention they receive (and more), the agreement’s own terms demand scrutiny too, since arrangements negotiated to end wars also decide who holds power once the fighting stops. Christine Bell , a legal scholar specializing in peace accords, has shown how such agreements can perform constitutional functions. They determine who governs, over what territory, and subject to whose approval.
In Gaza, the conditions for Israeli withdrawal and Palestinian self-government give outside actors considerable power to determine when, and whether, the transition ends. The framework therefore threatens to turn the temporary administration of a devastated territory into a durable system of external control with no enforceable end, legitimized by the very agreement meant to bring peace.
Gaza’s current predicament has a long history of displacement and outside control. In 1947, the United Nations General Assembly adopted a plan to partition Palestine (then under British rule) into Arab and Jewish states. While Jewish leadership accepted the plan, Arab leadership rejected it. During the war surrounding Israel’s establishment in 1948, approximately 750,000 Palestinians fled or were expelled from their homes. Many sought refuge in Gaza. The mass displacement and dispossession of the Nakba — Arabic for “catastrophe” – never ended.
Israel occupied Gaza and the West Bank, including East Jerusalem, in 1967 . In 2005, it removed its settlements and withdrew its army from inside Gaza while retaining control over its airspace and maritime access and substantial authority over its borders and the movement of people and goods. In 2024, the International Court of Justice concluded that because Israel continued to exercise authority over Gaza’s borders and the movement of people and goods, the withdrawal had not entirely released it from its obligations under the law of occupation.
The current institution of Palestinian self-governance also began as a temporary arrangement intended to last no more than five years. The Oslo process of the 1990s provided for an interim Palestinian government in Gaza and the West Bank until a permanent settlement could be reached. That institution, the Palestinian Authority, remains central to proposals for Gaza’s future.
Hamas won the 2006 Palestinian legislative elections and took control of Gaza in 2007 after armed conflict with Fatah, the rival Palestinian faction. Israel, citing security concerns, tightened its border restrictions into a blockade by land, sea, and air, restricting the movement of people into and out of Gaza and the entry of food, construction materials, and other necessities. Egypt restricted passage through its own border crossing. Years before the current war, the U.N.’s humanitarian office documented the effects: restrictions on movement and trade had undermined Gaza’s economy, increased its dependence on aid, and obstructed access to healthcare and education.
On Oct. 7, 2023, Hamas-led groups attacked Israel, deliberately killing civilians and taking hostages; Human Rights Watch has documented these acts as crimes against humanity and war crimes. Israel’s subsequent military response devastated Gaza. By Oct. 21 of this year, Gaza’s Health Ministry reported 74,494 Palestinians killed and 175,604 injured. In an October 2026 report , the U.N. Independent International Commission of Inquiry concluded that Israeli authorities and forces continued committing genocidal acts against Palestinians in Gaza after the ceasefire, with the intent to destroy the group in whole or in part. By September of this year, Israeli military control had expanded beyond the approximately 53 percent of Gaza envisioned under the ceasefire agreement to at least 60 percent .
By the ceasefire’s first anniversary, nearly two-thirds of housing units had been destroyed, many of the remaining buildings were unsafe, and large-scale reconstruction had yet to begin. With winter approaching, displaced families need immediate decisions about shelter. The Israeli authorities who control access to their homes and to building materials can postpone those decisions. Such delays favor whoever controls access, and waiting itself becomes a source of political leverage.
In June 2024, the U.N. Security Council endorsed a three-phase framework in Resolution 2735 . An initial ceasefire and exchanges of hostages and prisoners were to lead, upon agreement, to a permanent end to hostilities and full Israeli withdrawal, followed by major reconstruction. The initial ceasefire was to continue for as long as negotiations over the second phase went on.
In November 2025, the Security Council adopted Resolution 2803, endorsing U.S. President Donald Trump’s plan to end the Gaza conflict and authorizing international arrangements for its implementation. The framework retains the language of transition while placing Gaza’s administration and redevelopment under the oversight of a Board of Peace chaired by Trump. Palestinian Authority control would depend on completing a reform program and demonstrating the capacity to govern securely and effectively. The resolution refers to earlier proposals , including a Saudi and French initiative calling for reforms to governance, transparency, public finances, and service provision. Israeli withdrawal is tied to demilitarization milestones to be agreed among the Israeli military, an International Stabilization Force, the guarantor states, and the United States. The force’s mandate includes demilitarization and civilian protection. An Israeli military presence along Gaza’s perimeter could remain until the territory is judged secure against a renewed terrorist threat.
The plan endorsed by the resolution states that Israel will not occupy or annex Gaza, that no one will be forced to leave, and that full humanitarian aid will enter immediately. Continued attacks and restrictions on assistance must therefore be assessed against those obligations, but compliance with these provisions would still not resolve the deeper problem. The framework grants outside institutions concrete powers over Gaza while making the restoration of Palestinian political authority dependent on future conditions. It establishes who governs during the transition far more clearly than it establishes how the transition ends.
The resolution authorizes the international arrangements until Dec. 31, 2027, subject to further Security Council action, but it sets no deadline for full Israeli military withdrawal or the transfer of political authority to Palestinians.
Israeli withdrawal depends on milestones agreed with Israel and other actors, but the criteria for determining when those milestones have been satisfied, and the consequences of disagreement, remain ill defined. Whoever can set the benchmarks, withhold agreement, or dispute compliance has considerable power over how long Gaza remains under outside supervision. This effectively means that the decision will be made in large part by Israel and institutions overseeing the transition, including Trump’s Board of Peace, which counts Israeli Prime Minister Benjamin Netanyahu as a member.
No security arrangement can eliminate every future threat; clear benchmarks and a truly independent arbiter are essential if the ceasefire is to ever become a lasting peace.
The demand for protection against another attack is understandable. Hamas’s weapons, and its coercive power over Palestinians, are serious problems. But if the security conditions for withdrawal can be revised indefinitely, Palestinians cannot know when the promised transfer of authority will occur. The obligations of one armed faction should not determine whether an entire population has a political future.
Israel Policy Forum , a U.S. policy organization supporting a two-state solution, analyzed and supported the basic approach of the July 2026 road map . The proposal linked phased Hamas disarmament to incremental Israeli withdrawal and the creation of a new Palestinian civilian administration. The organization’s analysis described Israel’s refusal to accept that bargain, conflicting explanations of when withdrawal could proceed, and unresolved definitions and verification arrangements.
No security arrangement can eliminate every future threat; clear benchmarks and a truly independent arbiter are essential if the ceasefire is to ever become a lasting peace. Otherwise, the conditions for withdrawal could be extended indefinitely. If Hamas disarms and the promised withdrawal never comes, the disarmament stands while Israel’s commitment remains open to renegotiation. A single attack by a faction opposed to the agreement could then be invoked to suspend the political future of an entire population, allowing armed spoilers to trigger further delays in Palestinian self-government and giving Israel and the United States grounds to prolong those delays.
Palestinians have seen an interim arrangement outlast its deadline before. The 1993 Oslo agreement between Israel and the Palestine Liberation Organization established a framework for interim Palestinian self-government and negotiations toward a permanent settlement. It envisioned a transitional period of no more than five years, with negotiations on permanent status to address the sovereignty and governance of Jerusalem, the fate of Palestinian refugees since 1948, Israeli settlements, and state borders. More than three decades later, there is still no comprehensive settlement. The new plan follows the same design: concrete authority now, political rights later.
In an Oct. 2 report , the UN’s humanitarian office identified 217 displacement sites at medium to high risk of flooding, hosting approximately 235,000 people. Nearly 44,000 people were sheltering in unsafe buildings that required full or partial demolition, the report said. Restrictions on land access and on the entry of supplies continued to hamper preparations for winter.
No later breakthrough can give back a lost winter, a child’s interrupted schooling, or a patient’s postponed treatment. The longer a household has to survive elsewhere, the harder it may become to rebuild the life it was forced to leave, and an agreement can keep promising recovery while the conditions for recovery disappear.
Palestinians are also asked to prove they can govern before they are allowed to do so, and governing requires revenue . In the October report , the U.N. described how Israel’s withholding of approximately $6 billion in tax revenues it collected on the Palestinian Authority’s behalf was undermining that government body’s ability to provide services and pay salaries. The crisis extends beyond Gaza and exposes a circular test of readiness. An administration deprived of its own revenue struggles to deliver services, and those failures can then be invoked to justify continued outside supervision.
Blame works the same way: If a Palestinian administration is responsible for public services while other actors control access, security, and funding, residents may blame its officials for failures it could not prevent. The resulting loss of public trust would make representative government harder to build, and that weakness could in turn be cited as a reason for continued outside supervision.
Nathan J. Brown, a scholar of Palestinian politics, has argued that Gaza diplomacy is separating administrative functions from national political representation. A committee of technocrats can run clinics and restore water service, but deciding the political future of the people it serves requires authority grounded in their consent. An administration accountable primarily to a foreign board chaired by Trump lacks that democratic mandate.
The United States helped broker the Gaza ceasefire, holds a central position in the system meant to implement it, and underwrites Israeli military power. According to the Congressional Research Service , the 2016 memorandum covering fiscal years 2019 through 2028 pledged $38 billion in military assistance, subject to congressional appropriation. Without credible American consequences for obstructing withdrawal, the material advantages of continued control may outweigh any incentive to implement the agreement.
Donors providing humanitarian aid may end up paying to keep civilians alive while decisive political control remains elsewhere . Each emergency would then produce another funding appeal, while the authority to lift the restrictions causing the emergency would remain in place. Humanitarian funding could consequently help sustain that arrangement. The proposed International Stabilization Force , tasked with demilitarization and civilian protection, would need the authority and backing to restrain abuses by all parties, including Israel.
Lebanon offers a warning. After the April truce in the Iran war, Pakistan’s prime minister said the ceasefire included Lebanon. U.S. Vice President JD Vance said Washington had agreed to no such thing. Israeli attacks in Lebanon continued while the parties disputed what the agreement covered. Lebanese civilians were exposed to violence while governments argued over whether their country was protected at all. Whoever defines a ceasefire’s scope decides whose security it guarantees.
Gaza already displays the features of a zombie conflict, with an announced ceasefire, recurring military operations, and unresolved struggles over territory and power. The danger is that this condition becomes entrenched. Diplomats go on describing a transition, while people live under a system of control that survives one round of negotiations after another.
These conditions, though, are sustained by identifiable governments and institutions, through decisions they could make differently.
In a July 2024 advisory opinion , the International Court of Justice stated that the Palestinian people’s right to self-determination could not be made conditional by the occupying power, and it concluded that Israel must end its unlawful presence in the occupied Palestinian territory as rapidly as possible. The Security Council’s Resolution 2803 places Palestinian statehood after reform and redevelopment, saying that the conditions for a credible pathway “may finally be in place” at that time. The political framework thus makes progress toward exercising an existing right dependent on conditions assessed by outside actors, while establishing their immediate authority much more clearly.
Every grant of outside authority under the ceasefire needs an expiration date: thresholds that can actually be met, independent assessors to judge them, and consequences for any party that blocks the next step. Without them, Israeli withdrawal and Palestinian self-government in Gaza will remain promises that outside actors renew indefinitely and never keep. For the families still displaced, another anniversary will mean another year in a tent or a ruined home, waiting for decisions they cannot make. Their ability to return, rebuild, and determine their own future remains subject to a political framework in which authority rests largely elsewhere. The Gaza ceasefire risks giving the structures of control that preceded the war a new institutional form, backed by the U.N. Security Council and administered indefinitely in the name of peace.
Apple hardware chief Johny Srouji would be an incredible choice to lead @nvidia -- and I believe he'd accept it. He's hit the ceiling at Apple and won't ever be CEO ; obviously competent; ambitious as hell; has long wanted chip designs to dictate Apple product launches/timelines.
One person being considered for the top job (NVDA CEO) is Apple hardware chief Johny Srouji, who was among the executives considered for Intel CEO in 2019, according to another person familiar with the matter. - Semafor
Cursor confirmed it suffered a security breach that let hackers distribute a malicious Claude Code extension through its marketplace after stealing credentials from AI infrastructure provider Fireworks AI.
The breach also let attackers access internal systems and steal customer data, including historical AI coding-agent traces containing unredacted credentials that were later used to compromise additional services.
The breach was disclosed in a new incident report published Friday, which explains how attackers distributed malicious versions of Anthropic's Claude Code extension through Cursor's marketplace on October 29.
The attack exposed up to 5,000 developers to malware that installed persistent SSH backdoors.
Cursor is an AI-powered code editor built on Microsoft's open-source Visual Studio Code (VS Code), allowing developers to write, modify, and debug software using AI assistants.
According to Cursor, the attack began when hackers obtained an access key stored on Fireworks AI, a third-party provider used for AI model training and inference.
The attackers used the exposed key to copy data from a read-only storage bucket Cursor used to share information with Fireworks.
This bucket contained historical AI coding-agent traces, mostly from 2025, collected from users who had not enabled Privacy Mode and whose data could be used for model training. Some of these traces contained unredacted API credentials, allowing the attackers to access additional Cursor systems.
Cursor says fewer than 0.05% of users had coding-agent traces exposed, while fewer than 0.01% of customers had API credentials compromised.
Using the exposed credentials, the hackers stole data from several of Cursor's software-as-a-service (SaaS) tools, including:
Cursor says its monitoring systems detected the unauthorized activity, leading the company to revoke the Fireworks access key, rotate exposed credentials, and investigate additional unauthorized access.
As the investigation progressed, Cursor temporarily turned off some internal and product services as a precaution.
However, the attackers had already obtained a credential that allowed them to distribute extensions through Cursor's marketplace.
On October 29, the hackers used that credential to publish malicious copies of Anthropic's Claude Code extension on Cursor's VS Code extension marketplace.
"On October 29, using a stolen credential from the exposed data from our internal system, the attacker placed malicious, unauthorized copies of Anthropic's Claude Code extension directly on the cache used to serve the Cursor VS Code extension marketplace," Cursor explained.
The attack did not compromise Anthropic's legitimate extension or Open VSX, the extension marketplace Cursor uses.
The malicious extensions, versions 2.1.312 and 2.1.313, were available for approximately 11 hours before Cursor removed them.
As BleepingComputer previously reported , the attackers modified the legitimate Claude Code extension to execute malicious JavaScript that attempted to install persistent SSH backdoors on developers' computers.
The malware collected system information, installed an attacker-controlled SSH key, attempted to enable SSH access, and configured persistence mechanisms to maintain remote access.
However, security researchers found coding errors that likely prevented the backdoor from working on many Windows and macOS systems where SSH was not already enabled.
Cursor estimates that up to 5,000 users who requested affected extension versions during the exposure window may have received the malicious builds.
The company says its production infrastructure, official application releases, customer code repositories, and code and prompts belonging to users with Privacy Mode enabled were not affected.
Cursor says it has moved all inference traffic away from Fireworks, revoked and rotated exposed credentials, rebuilt its extension marketplace, and redeployed its production infrastructure as a precaution.
Customers who installed or updated to the affected Claude Code extension during the attack are advised to follow Cursor's remediation guidance .
The incident comes amid a wave of attacks targeting AI developer platforms that cybersecurity company Wiz has dubbed "Black October" .
These attacks targeted development infrastructure to steal authentication credentials, especially those providing access to AI models.
Stolen credentials have been used for unauthorized AI inference, generating substantial charges for affected customers, with some incidents also linked to attempts at AI model distillation.
The attacks have affected numerous companies, including Railway , Northflank, Lightning AI, OpenCode , and Warp .
At Railway, attackers stole customer authentication secrets, which were later used to generate approximately $740,000 in fraudulent AI charges. OpenCode also reported exposed API keys and unauthorized AI usage.
Fireworks AI was also affected, disclosing multiple security breaches in October, including one involving exposed API keys and tokens and another in which attackers accessed development machines through a compromised third-party cloud provider.
The Fireworks incidents also affected other customers, including Notion , which recently disclosed that AI chat transcripts from a small number of workspaces were exposed.
Adaptive Security's AI agents analyze email intent, context, and behavior to uncover phishing, business email compromise, and invoice fraud.
See what's getting through with a 14-day read-only scan of Microsoft 365 or Google Workspace, with no MX changes.
A new release of Datasette's longest untouched plugin, for rendering charts (using Vega-Lite against data in a table or custom query. The last release was in July 2018!
I finally bumped it for compatibility with the latest Datasette alphas, plus some cosmetic tweaks to make it work better with Datasette Lite .
(Datasette Lite just gained the ability to run JavaScript plugins like this! I'll write more about that soon.)
Since it works with Datasette Lite, the live demo in the README now links to this demo on Datasette Lite .
I am a public-interest technologist , working at the intersection of security, technology, and people. I've been writing about security issues on my blog since 2004, and in my monthly newsletter since 1998. I'm a fellow and lecturer at Harvard's Kennedy School and the Munk School at the University of Toronto, a board member of EFF , and the Chief of Security Architecture at Inrupt, Inc. This personal website expresses the opinions of none of those organizations.
I’ve wanted a product like the Apple HomeView for years now. After spending a lot of time with various personal assistant “smart speakers” in my kitchen—some with screens—I’ve never been more certain about the potential of the product category or more disappointed in the reality.
I’ve spent years with Google and Amazon displays in my kitchen, and was never really satisfied. They were slow, their screens weren’t very good, they didn’t integrate well with my home, and Amazon would not stop opting me into new forms of distracting marketing messages.
The HomeView, which has been standing like a tiny, cute sentinel atop the bar in my kitchen for the last week, improves on those other devices in innumerable ways. It’s got a great 5-inch square screen, it’s fast and responsive, and it fits into my home ecosystem.
While it is far from perfect, the HomeView is great at some jobs, and pretty good at others. Where it falls short, it does so while hinting at some great potential that could be addressed with software updates.
The Echo Show was sent back long ago. The Google Nest Home is unplugged and relocated to the tech recycling pile. The HomeView? It’s here to stay, at least in my kitchen.
The $299 HomeView is a slab-like device that’s 5.73 inches square and 0.39 inches thick, kind of like a tiny, square iPad. It comes mounted either on a perforated cylindrical aluminum base or (optionally) sans base, ready for wall mounting via a series of optional, extra-cost mounts. I tested one with the aluminum base, which makes it look like an extremely tiny iMac.
The hardware is solid and coherent, the screen a pleasure to touch and tilt. In terms of software, though, the HomeView feels like a peculiar amalgam of numerous other Apple products. Its main interface makes it look a bit like an overgrown Apple Watch, complete with customizable “faces” that sometimes resemble actual Apple Watch faces and other times resemble the iPhone’s StandBy mode. Its apps sometimes feel like they’ve escaped from the iPhone or iPad, but at other times they feel more like they’re right off of an Apple TV. And still other “apps” resemble what you might see in your car, since Apple is also using CarPlay to project interfaces from apps running on your iPhone.
Given the fact that this product’s tech stack feels like it was created in a blender, it’s remarkable that it holds together as well as it does—but there are still places where the seams show.
Let’s start with the HomeView’s default “faces”, which are what the device defaults to when it’s not actively being used. Faces are a series of individual pages arranged in a strip that you can swipe through from side to side, very much reminiscent of how Apple Watch faces used to work. Tap and hold on a face and you’ll enter editing mode, where you can customize a face using an interface that is right out of watchOS or the new editable StandBy mode on the iPhone Duo.
Some faces feel very much like they’re from the Apple Watch—simple clocks with the occasional widget that’s a single line of text very much in the style of a watch complication or a simple iPhone lock screen widget. There’s also a pretty animated clock and a lighthearted clock face featuring Snoopy animations. My favorite is undoubtedly the Photos face, which lets you choose a set of items, albums, or collections from your iCloud Photos library, all of which will be shuffled through, very much like an iPhone lock screen or the Apple Watch’s widget face. It is delightful to walk into my kitchen and see a picture of my family.
Other HomeView faces are much more complex, offering dashboards to control Apple Home items, a live view of a HomeKit-compatible security camera, or even a custom Modular face you can populate with widgets from the device or from your iPhone.
In many ways, these faces are the core of the product. They are the images you want to look at, yes, but they’re also the dashboards you can use to quickly interact with items in your home. And this is where HomeView’s software comes up a bit short.
The layouts aren’t flexible enough, for starters. Simple faces like photos work a charm, but more complex faces are kind of a mess. I’d like more options about what items to place on a face, and where to place them. The HomeView seems like the perfect device to use as a control panel for my smart-home devices, but the Home Modular face is strangely limited. For example, I can only use it to turn dimmable lights on to full brightness. To dim a light, I have to open the Home app, select the item in there, and then swipe up or down on the dimming interface.
It’s great that you can view iPhone widgets on the HomeView just as you can on the Mac, but it’s a bit frustrating that it will only display the small square widget style. Presumably because of the Apple Watch roots of some of these faces, there’s a surprising lack of digital clocks. In fact, in some face views you can create a face featuring a clock, but if you delete it, you can’t add it back. I admit to being frequently baffled about what I was able to add and customize, and what I wasn’t, when trying to build faces.
All of this is really unsurprising when you consider that this is an interface welded together from disparate parts of other Apple products, but it feels like it needs some more tweaking and attention for it to fully come together.
Swipe up from the bottom of any face and you’ll find yourself in the HomeView’s app view, its equivalent of an iOS home screen. You can customize this view to drag icons around and even add widgets. This screen is designed to be personalized to you—it shows your picture and welcomes you by name, all because you train the HomeView on your appearance (via its included webcam) as well as voice, and link it to your iPhone, which needs to be on the same Wi-Fi network and have been unlocked relatively recently. HomeView uses all of those hints to decide if it’s you who’s swiping up. If it doesn’t recognize you, it’ll put up a more generic interface without any linked iPhone apps.
There are some “real” Apple apps on the HomeView: Music, Safari, Home, FaceTime, Weather, Find My, Calendar, Messages, Timers/Alarms/World Clock (all escapees from the Clock app), Reminders, and Settings all offer functionality that’s not far from what you’d get on an iPhone.
Also appearing in the same app view are things that look like apps but are not the same as the onboard apps that every person can see. These are items pushed from your paired iPhone, and they’re actually the CarPlay extensions of iPhone apps (running on the paired iPhone of the person HomeView has determined is using the device, via face/voice/device recognition) in CarPlay’s audio and video categories. So, for example, Instapaper appears on my HomeView—but only its CarPlay interface, which offers to read stories out loud. The New York Times app is there, but just to play its podcasts. Libby will offer me audiobooks. Overcast and Apple Podcasts will play my podcasts, and the Apple TV app will play TV shows (in an extreme letterbox on this square screen).
Using CarPlay to let iPhone apps run (in a way) on HomeView was a stroke of genius. The feature works pretty well and it allows Apple not to clutter the device with an App Store or force developers to write new versions of their apps for yet another platform. That said, I do wonder if there might be a better path forward for HomeView that does allow developers to write more full-featured apps if they wish, either via CarPlay (outside of the audio and video categories) or by allowing iPhone apps to install a HomeView version of themselves, which is how most Apple Watch apps are installed. (There are already reports that Apple may be adding support for AI voice assistants via CarPlay in the future.)
Or consider recipe apps as a category. They don’t really make sense in CarPlay, but they sure do on this device. Apple has built a clever recipe view into Safari on the HomeView that displays recipes with clear ingredients lists, cooking steps, and even hyperlinks to quickly create timers. Unfortunately, I keep all my recipes in Mela, a very nice app that seemingly is unavailable on HomeView. Maybe recipe app developers will find a way to get their content on the HomeView, perhaps via the web, but it would be nice if they had the option to somehow bring their users’ data to this device directly. The clever CarPlay hack only goes so far.
If Mark Gurman’s reports are to be believed, Apple has had the HomeView hardware ready for quite a while, but felt it was unable to release it because of the 2024 failure to launch of numerous Apple Intelligence features. Now that Siri AI has arrived, HomeView is finally ready to blast into stores.
Powered by an A18 processor, the HomeView supports Apple Intelligence and Siri AI, and when paired with an Apple Intelligence-capable iPhone or iPad, it’s capable of using that device to search through your personal context to answer your questions. Just as is true everywhere else, when Siri AI works on the HomeView it can be spectacular. I have asked targeted questions about items in long-ago Messages threads or on my Calendar and it has managed to unearth the answer without me having to do a lick of work. It’s vastly better at general world-knowledge questions than the old Siri. That said, Siri AI isn’t as reliable as it should be, both in general and on the HomeView. Sometimes it just seems to go off in its own world and not respond, or respond accurately. Other times, it works just as advertised. Apple’s challenge (and this goes way beyond the HomePod) is to make Siri AI work more reliably.
I also had some bizarre, HomeView-specific issues with Siri AI. After I paired my iPhone with the HomeView, every command I gave it to play music was instead routed to Broadcasts, a third-party app on my iPhone (with a CarPlay connector, to be fair) that I use to stream live podcasts. I had to delete Broadcasts entirely in order to get Music playback to work properly. Once I did that, everything settled down, but I still have no idea why Siri got so hung up on an app that couldn’t offer albums or playlists or anything else I was looking for.
But again, when it works, it’s great. I was able to ask the HomeView what that painting is “where the guy from the French Revolution is dead in a bathtub,” and not only did it answer correctly that it’s Jacques-Louis David’s “ Death of Marat ,” it pulled up the painting for me to look at on the HomeView screen. My HomePod could never.
Beyond Siri, the HomeView is pretty versatile as a media device. It will play audio itself, via its speakers and (on the model with the cylindrical base) an extra downward-pointing woofer. It sounds… fine? It sounds like a kitchen speaker. The HomeView’s speaker is not going to win any awards from audiophiles, but it’s absolutely good enough to do the job when you’re making pizza, drinking some wine, and rocking out to the hits of the ’80s. (Ask me how I know.)
HomeView also integrates well with AirPlay, so if you do have other speakers, HomeView can play to them, too. And it’s an AirPlay receiver, so if you want to play audio or video on the HomeView that originated on another Apple device, it’s up to the challenge. (This is useful if you want to, for example, watch a college football game on YouTube TV, which does not have a video CarPlay app. Of course, you’ll be watching it extremely letterboxed, but it does work!)
The star of HomeView’s playback versatility may be its support for Handoff, which is extremely present on this device, perhaps even to a fault. Get an iPhone close to a HomeView and both devices will show a ripple on screen, and your phone will ask you to either throw whatever you’re consuming over to the HomeView, or suck back whatever is playing on the HomeView onto your iPhone. I used this feature to toss music, podcasts, AirPlay from random apps, and even web pages (via Safari) from my iPhone to the HomeView, and pulled music I was listening to on the HomeView back to my iPhone. My only real complaint is that it kept triggering when I came even vaguely close to the HomeView with my phone, though it was easy to just opt not to transfer anything either way.
There were some other quirks. The HomeView does FaceTime, and does a pretty nice job thanks to its 12-megapixel Center Stage camera. But it struggled to connect to a multi-person FaceTime call when I handed it off from an iPhone, and after a brief two-person interlude, the call failed completely. Occasionally attempts to play audio via a CarPlay-based app (Overcast) would claim to succeed, but no audio would be audible until I switched to playing audio from a different app (Music) and then moved back to Overcast.
I’m willing to chalk all this up to this essentially being the 1.0 version of the HomeView software experience, as well as a side effect of Apple’s ambition in fusing together so many disparate aspects of its ecosystem in this product. It’s all a little bit messy.
So after years of waiting for Apple’s take on the smart speaker, was it worth it? To be clear, I would rather have not waited this long—and I’m pretty sure that’s true of Apple, as well. But here we are, and at $299 for the self-standing model, it strikes me as being a pretty great deal if you’re someone who is immersed in the Apple ecosystem and wants a little helper to answer questions, show pictures, play music, control devices, and otherwise just be a nice companion in the kitchen (or wherever else you might want one in your home).
The wall-mounted model, while also priced at $299, is a worse deal—in that it lacks a woofer and requires an additional purchase of a mounting assembly, meaning it’s got fewer features and ultimately costs more. I’m a little baffled why Apple didn’t offer a basic wall mount for that price, but it didn’t, and it makes that product a worse deal. (That said, I’m still interested in buying one, as I’d really like to put a panel on my wall that allows anyone in my home to control my smart-home stuff even when I’m not around.)
My real issues with the HomeView aren’t with its hardware, which is solid and functional and kind of adorable when spotted from any angle other than screen-on. It’s with the software, which has an impressive array of features welded on from various other Apple products—but can really show the seams. Apple’s use of CarPlay to support media apps on the device is clever, but it’s a little buggy and the device still feels limited. The recipe browser is cute, but I have all my recipes in an app that’s entirely walled off from the HomeView, and that’s a bummer.
The product also really lives or dies by its “faces,” and the current ones are either pretty-but-not-useful or useful-but-not-pretty. (I can’t believe you can’t dim a light from a face screen.)
Still, solid hardware and a decent array of services are a start. HomeView (and its successors) has a real chance to fill the homes of avid iPhone users everywhere, so long as Apple works to improve the flexibility and polish of its software.
If you appreciate articles like this one, support us by becoming a Six Colors subscriber . Subscribers get access to an exclusive podcast, members-only stories, and a special community.
A UCL study found that people searching a mock living room with commercial detectors still missed most hidden cameras and trackers.
The devices sold to help people find hidden cameras and trackers barely work, our research at UCL has found. Imagine you have left an abusive relationship and moved somewhere new, and yet your former partner seems to know things about you they should not. They repeat something you said in your living room or appear somewhere you told nobody you would be. You change your passwords and it carries on, until you begin to wonder whether something in your home is watching you, or whether, as you have been told so many times, you are imagining it.
This is what technology-facilitated abuse can look like from the inside: the ordinary tools of digital life turned into ways of monitoring, coercing and harassing someone. For many people it is now part of how stalking works. In England and Wales, around one in five stalking victims in the year to March 2024 were stalked by a partner or ex-partner and 42% said online methods were involved, while colleagues at UCL found cyberstalking growing faster than its offline counterpart. Most of this abuse runs through shared accounts and the phones and smart devices already in the house. Hidden devices sit at its far end: cameras built into clocks, picture frames and USB chargers, and Bluetooth trackers slipped into a toy or a car, sold through mainstream online retailers and sometimes openly marketed for catching a ‘cheating partner’.
A growing parallel market sells handheld detectors and phone apps that promise to find these devices. Coercive control can leave people living on constant alert, and gaslighting works by making them doubt their own perceptions, so being able to rule out a hidden device can bring peace of mind, and matter as much as finding and removing one. As one domestic abuse advocate told us, “We need to be ruling things out.” The question that drove our study at UCL was whether these tools can really do that.
We gathered 19 detectors, from handheld bug detectors to phone apps that scan for trackers, wireless networks and camera lenses. We then hid nine devices, including cameras and trackers, in a mock living room setup. Thirty-four people, including police officers, network specialists, domestic abuse advocates, tech abuse researchers, and members of the public, searched it first with their eyes and then with three different tools.
In the first round, people missed two-thirds of the devices when looking for them manually. A detector only helped them marginally, leaving them missing close to three in five. Most participants followed their instincts towards suspicious objects like clocks, toys and crowded shelves while walking straight past everyday objects like USB chargers and sockets. Instead of widening the search, the detectors mostly encouraged people to recheck the places they already suspected. Those who worked through the room methodically tended to find more, and experienced participants who had familiarity with surveillance devices, detectors or networking held a slight advantage due to prior knowledge about technical cues and likely objects.
What stayed with us most however was how the search made people feel, even though they knew nothing was at stake. One participant kept returning to an innocuous spot as the detectors beeped inconsistently, until they felt “crazy” and could no longer tell whether the fault lay with them or the device. When a tool stayed quiet, people tended to assume the area was safe and move on. Women participants more often blamed themselves for confusing results while men more often blamed the tool, a pattern our sample of 21 women and 13 men cannot confirm statistically, but one that is hard to ignore when the person holding the detector may have spent years being told she is the problem.
The difference between outcomes of various tools had little to do with how much they could sense. Most detectors report signal strength through beeps, lights or numbers, and leave the user to work out what has been found, where it is and whether it matters. Handheld detectors that did well in a lab setting shielded from radio signals held no measurable advantage in the room, and neither did the more expensive devices we tested.
The tools that stood out were Bluetooth tracker apps such as ‘AirGuard’. They could only find Bluetooth trackers, not devices like cameras, but they showed people a list of what Bluetooth tracking devices were nearby, and if an unknown tracker was compatible, they could make it play a sound. Consequently, people missed only about a fifth of Bluetooth trackers, and had fewer false alarms. However, a list alone was not enough, because network scanning apps like ‘nRF-Connect’ also list every wireless device they can detect nearby, but they show each one as a string of codes and numbers rather than a name, and give no way to find where it is. People did far worse with them.
A detector, then, should be designed as an aid to decision-making. We recommend breaking a search down into five stages: detecting a signal, making sense of it, finding its source, confirming what it is, and deciding what is safe to do next. Most of the tools we tested only performed the first step. Designing for all five also means treating emotional wellbeing as a requirement, with discreet alerts and honest language that says, “no devices detected” rather than “no devices present”.
Improved design and usability of detectors will only take us part of the way. The trackers in our study could be found largely because they are built to be found. They broadcast a signal phones can pick up and can be made to play a sound, features the IETF’s DULT working group is now turning into a standard for all trackers. Hidden cameras are built to do the opposite, so however good the detectors become, the burden to find them remains with the person being watched.
That should lead us to ask why disguised cameras are sold so freely in the first place. They are usually marketed as home security, yet much of the protection comes from people knowing a camera is there. Cameras are thought to deter crime partly by raising the perceived risk of being caught , and a camera nobody can see raises no such risk. Even the reassurance of visible cameras is less certain than we tend to assume , and a hidden one can reassure only its owner. For everyone else in the room it does the reverse, turning a home into a place where nobody can be sure who is watching.
Some people have legitimate reasons to record in secret, including domestic abuse survivors and journalists gathering evidence. Those use cases deserve to be weighed properly, but regulators should ask of these products what the law already asks of covert filming at work : is it necessary, could a less intrusive option such as a visible camera do the job, and is it proportionate to the harm done to those recorded? Until someone asks, survivors will be left searching their own homes for something designed not to be found.
Akhil Polamarasetty is a PhD candidate in the CDT in Cybersecurity and the Gender & Tech Research Lab at University College London. His research examines technology-facilitated abuse within internet-connected environments, focusing on the usability and safer design of technical surveillance countermeasures to better support survivors of interpersonal abuse.
Worried about a hidden device? It may be safer to speak to a specialist service before searching or removing anything. In the UK, Refuge’s 24-hour National Domestic Abuse Helpline is 0808 2000 247. You can find international services at
https://www.chayn.co/global-directoryAccess or call using a device you trust.
Akhil Polamarasetty, author of this week’s lead story, will present the research at IETF 127 in San Francisco on Monday, November 16th , in the Human Rights Protocol Considerations (HRPC) research group session co-chaired by IX’s Mallory Knodel. HRPC researches whether standards and protocols can enable, strengthen or threaten human rights, and works to increase awareness in both the human rights community and the technical community. Akhil will discuss the implications of hidden cameras for safety and privacy, and explore how existing RFCs might relate to these issues or where additional work may be needed.
Full agenda . Stream details for Monday, 14:00 PST (22:00 UTC).
Want to appear here? Sponsor a newsletter.
Support the Internet Exchange
If you find our emails useful, consider becoming a paid subscriber! You'll get access to our members-only Signal community where we share ideas, discuss upcoming topics, and exchange links. Paid subscribers can also leave comments on posts and enjoy a warm, fuzzy feeling.
Not ready for a long-term commitment? You can always leave us a tip .
🚨
Stop press! Do you enjoy our links? Links are now available to paid subscribers only. Become a paid subscriber today.
The Guarini School of Graduate and Advanced Studies has suspended admissions to the next cohort in its math Ph.D. program, which would matriculate in the 2027-2028 academic year. Guarini dean Carrie Colla ’01 and College spokesperson Jana Barnello did not specify when or whether the program would resume admissions.
Colla wrote in a Nov. 10 email statement to The Dartmouth that Guarini “regularly considers how to best invest in graduate education.”
“As part of those regular reviews, we are pausing admissions to the math Ph.D. program for the 2027-2028 cycle while the School of Arts and Sciences conducts a department review,” she wrote.
The decision to suspend the program “was made in close partnership with leaders in the School of Arts and Sciences and we look forward to working collaboratively with the department on this review,” Colla added.
She wrote in a Nov. 10 email to current graduate students that there “will be opportunities for students to participate in the review” and that she would meet with math graduate students and department faculty on Nov. 17. Graduate students can also reach out to math department chair Dimitrios Giannakis and math professor Vladimir Chernov to share questions and concerns, she wrote.
“While I know it is disappointing news that your cohort will not be growing next year, I am confident that this approach will allow us to strengthen the experience of both our Ph.D. students and the undergraduate students in the department,” Colla wrote.
During a Q&A at the Nov. 9 general faculty meeting, which The Dartmouth attended but was not permitted to record, faculty raised concerns about the suspension. Math professor Peter Winkler, who opposed the suspension, said at the meeting the decision was communicated to math department faculty on Nov. 6. Winkler declined to provide additional comment after the meeting.
The Ph.D. program’s pause follows a national trend of decreasing Ph.D. program seats. Data collected from 55 undisclosed research institutions demonstrated that Ph.D. acceptances dropped 15% in 2026 from the previous year, even though domestic applications increased.
In a Nov. 10 email to current graduate students, which was obtained and reviewed by The Dartmouth, Giannakis wrote that faculty members were “continuing to engage” with College administrators to “find a path forward” that would “eventually resume” the Ph.D. program.
Giannakis added in the email that Colla and School of Arts and Sciences dean Nina Pavcnik would attend a math department faculty meeting on Nov. 11 to discuss the suspension.
“While I do not expect a reversal of the decision to pause admissions, I hope there will at least be a constructive dialogue with actionable outcomes,” he wrote.
Giannakis was unable to comment by time of publication.
The Guarini admissions office communicated the decision to applicants on Nov. 10, according to an email obtained by The Dartmouth. Any materials or recommendation letters that have already been submitted “will not be reviewed,” the Guarini admissions office wrote. Applications for the program, which typically accepts seven to nine students per year, would have been due on Dec. 15, 2026, according to the math department website .
“We recognize this is disappointing news and we are sorry for the disruption to your plans,” the email to people who already submitted application materials reads.
On Nov. 10, Colla wrote to current math graduate students that “status and support” for current students “are not changing” and that the program will see “every currently enrolled student through graduation,” according to an email obtained and reviewed by The Dartmouth.
“Stipends, insurance and the five-year funding guarantee all remain in place for students making satisfactory academic progress,” Colla wrote. “Advising relationships, qualifying exams, degree requirements and teaching and research appointments will continue as planned.”
Guarini Ph.D. students received an annual stipend of $49,862.40 for the 2026-2027 academic year, along with tuition remission, health insurance and other benefits, according to the Guarini website. The College guarantees five years of financial support to students making satisfactory academic progress.
Graduate students typically teach “one course in each of their final three years of study,” according to the math department graduate student handbook. Starting this term, math Ph.D. candidates must also serve as a teaching assistant for one term each year after their third year, while first and second-year Ph.D. candidates must serve as teaching assistants for three terms a year instead of the previously required two, according to the handbook.
Third-year math Ph.D. candidate Jacob Lehmann Duke GR said he and his fellow graduate students learned of the suspension from Colla’s Nov. 10 email. He said he was “frustrated” by the “lack of transparency” surrounding the decision.
“We were all shocked,” he said. “There was no indication that this was coming.”
Second-year math Ph.D. candidate Alex Moon GR said they believe suspending applications for the upcoming cycle sends “a message of instability” to future applicants.
“Part of the deal of graduate school is that you want there to be minimal factors outside of your control that will prevent you from getting this Ph.D.,” Moon said. “If this is something they do once, it’s something they can do later.”
In an interview with The Dartmouth, second-year math Ph.D. candidate Aidan Hennessey GR said “losing out on a cohort of students” would negatively affect the discussions among the “already quite small” Ph.D. program.
“Having people in adjacent areas of math to you — that you can talk about math and learn from, teach and talk through ideas with — all of this is very helpful,” Hennessey said. “Having more students around is nice for community.”
Lehmann Duke added that the suspension could put undergraduates intending to enroll in graduate-level mathematics courses “at a real deficit.”
Ben Singer ’27 — who said they have taken graduate-level math courses since their freshman year — added that there are “a few core graduate courses” that are “really important for undergraduates here who want to get into graduate school.” A decrease in Ph.D. students raises questions about whether those classes will be offered, whether undergraduates will be able to take them and how fewer course offerings will affect people who want to go to graduate school, Singer said.
The College “reserves the right to make changes in the offering” or cancel a course with fewer than five enrolled students, according to the Arts and Sciences Registrar’s Office website.
First-year computational science and modeling Ph.D. candidate Ethan Baird GR said “almost half” of his program’s coursework requirements are typically fulfilled through mathematics department courses. Baird added that these classes are the “basis of everything that we end up doing later,” which leads him to worry that the suspension of the admissions will have trickle-down effects on the computational science and modeling Ph.D. programs.
Math major Ribhu Hooja ’27 said the department “did not officially” inform undergraduate students about the pause and that he instead found out from graduate students. If the pause lasts “even for a year, there could still be harm” because of “the relationships formed” between undergraduate and graduate students in advanced math classes, Hooja said.
“We learn how to apply to grad school, and what it means,” Hooja said. “It’s an important relationship I’ve really benefitted a lot from.”
Third-year Ph.D. candidate Michaela Polley GR said she was concerned about the pause’s effects on “research culture” among Dartmouth graduates and undergraduates alike.
“The idea of being a research university and a liberal arts college doesn’t work if you don’t have graduate students,” she said.
During the Nov. 9 meeting, College President Sian Leah Beilock and Pavcnik also addressed faculty
concernsabout the College’s discontinuation of the Society of Fellows, a three-year interdisciplinary research program established in 2014 to support postdoctoral research and scholarship. The Society has stopped recruiting new fellows and will
concludein summer 2028, when its current cohort completes their appointments, according to the program’s website.
Beilock said at the meeting that the decision follows the need to reinvest funding in other institutional priorities.
Beilock announced at the meeting that the College is “working to reduce Dartmouth’s spending by $50 million,” in order to increase faculty and staff salaries “especially if and when inflation continues to rise,” according to a transcript of her speech published on the Office of the President’s website .
In a Nov. 11 email statement to The Dartmouth, Barnello wrote that the $50 million “reflects adjustments already made” to the budget, and that “roughly half” is “already in place” for fiscal year 2027.
Beilock also announced at the meeting that the College is “preparing” to convert North Park apartments, which are currently listed on the Office of Residential Life website as undergraduate housing, to graduate student housing. The North Park apartments have exclusively housed undergraduates since the 2022-2023 academic year, according to the Dartmouth Graduate Student Council website .
Correction appended (Nov. 12, 9:30 a.m.): A previous version of this article referred to Alex Moon as he. They use they/them pronouns.
Sahil Gandhi
Sahil Gandhi ’29 is a reporter from Staten Island, N.Y., and is majoring in environmental studies and government modified with philosophy and economics. He loves word searches and falling down internet and Wikipedia rabbit holes. He can be reached at sgandhi@thedartmouth.com.
More than 1,500 misleading job postings — offering remote work, no experience needed — have been taken down from LinkedIn and Monster after a CBC visual investigation revealed the listings funnelled unsuspecting applicants to a multi-level marketing (MLM) company that asked for money.
CBC connected a network of travel-related pages posting suspicious jobs — positions like "Work From Home Travel Planner and Virtual Customer Support Representative" — to a U.S.-based MLM called Evolution Travel. Some of the roles promised to pay up to $75,000 US per year.
In reality, there was no job and no salary.
Applicants were quickly directed to join virtual information sessions, where they were asked to pay hundreds of dollars up front, followed by a monthly subscription fee. The program promised to teach members how to make money from booking travel as an independent agent and recruiting others into the program, taking a cut of their commissions.
WATCH | Investigating who's behind hundreds of fake job postings:
Exposing who’s behind fake job ads online
Major job-seeking platforms host hundreds of listings for remote travel jobs that promise salaries up to $75,000 with no experience required. CBC Visual Investigations applied online and found that there is no job: The ads lead to a U.S.-based multi-level marketing scheme that asks unsuspecting applicants to pay up front. After flagging the listings to LinkedIn and Monster, nearly 1,500 were taken offline.
The companies went by names like Wanderwell Collective, Professional Travel Hub, Remote-Careers, Sky Land & Ocean Travel and Sunkissed Getaways.
The job postings made no mention of Evolution Travel or sign-up fees.
Many of the jobs did not require experience and promised to pay up to $75,000 US. (Illustration: Matthew Hoddy/CBC; LinkedIn)
"This is disgusting," said Jay Jones, a Chicago-based job listing investigator who CBC shared its findings with. "They catch you with the lure of the fake job. The money is great, [successful applicants] get to stay at home. You have to pay to get work — that's not how work works."
Misleading job postings — including ones that require payment or lead to MLMs — are strictly prohibited on platforms like LinkedIn and other job sites.
Jay Jones investigates misleading and fake jobs online. (CBC)
"It feels in so many ways that we're living in a funhouse mirror," said Vass Bednar, managing director of the Canadian Shield Institute, a public policy think-tank that focuses on economic resilience and digital sovereignty.
These postings risk "eroding confidence — confidence in the self and confidence that there is, frankly, meaningful work out there for people that is worth pursuing."
MLMs are not illegal in Canada or the U.S. However, in the U.S., companies and individuals could face fines if they are found to violate the U.S. Federal Trade Commission Act, which prohibits "unfair or deceptive acts or practices in or affecting commerce."
"I would consider [these job posts] misleading… and would invite enforcement by either the FTC, the state governments or other federal enforcement agencies," said William Kovacic, former FTC chairman and commissioner, with whom CBC also shared its findings.
One independent agent behind multiple travel businesses linked to misleading jobs ads CBC identified — Wanderwell Collective, Destination Knot, Aisle and Abroad, and Professional Travel Hub — was Diedre Norton. In one video posted to YouTube, Norton said she had a network of 300 recruits for Evolution Travel.
Even though Evolution Travel’s founder, David McCovy, praised her in online videos as being a top performer, Norton denied being affiliated with the program before hanging up on CBC News.
Screenshot of an online video showing Evolution founder David McCovy during a conference. (EvolutionTravelCafe/YouTube)
McCovy did not respond to CBC’s requests for comment.
A representative from Evolution Travel who only identified themselves by their title, chief operating officer, told CBC they have consistently told their independent agents not to post job ads on any platforms.
Late last month, LinkedIn took down close to 900 ads connected to Evolution Travel, saying it had removed them because they were "misleading and violated" company policy, adding "the companies behind them will no longer be able to post jobs" on the platform.
Monster took down 600 listings, saying it has "clear policies prohibiting misleading job postings and multi-level marketing opportunities, and we take action to remove listings that do not meet our standards."
Hundreds of job postings posted to LinkedIn and Monster actually brought applicants into the recruiting process for a multi-level marketing company, a CBC News visual investigation has found. (Illustration: Matthew Hoddy/CBC, LinkedIn, Monster)
Evolution Travel does not operate in Canada, but CBC journalists still came across the job posting in their feeds. They were also recommended in emails from LinkedIn.
The ads contained immediate red flags. The travel companies named in the ads had minimal to no presence online, and there were close to 1,500 postings, often with almost identical job descriptions.
Many of the jobs did not require experience and were remote. CBC found more than 1,500 misleading or fake jobs. (LinkedIn)
The jobs, in many cases, required no education, no prior experience and often did not require a resumé.
CBC applied for eight jobs on LinkedIn and Monster, attaching a blank document as a resumé in cases that required it. Upon applying, the team was sent automated emails to join a virtual information session by individuals connected to Evolution Travel.
CBC journalists were sent automated emails and asked to join a virtual information session by individuals connected to Evolution Travel upon applying for the jobs. (CBC)
Evolution Travel and its partner Archer Travel Services describe themselves as an international "home-based travel business" that trains its members to book travel and earn a commission.
But it's not just about booking travel. Archer Travel’s website describes Evolution Travel as its "recruiting partner" and describes it as a "network marketing" company — another term for multi-level marketing, according to the U.S. Commodity Futures Trading Commission.
A compensation plan for members on Evolution Travel’s website shows a percentage of commissions and monthly bonuses are paid to the most effective recruiters, with membership tiers up to "8 Star Platinum" for recruiting 100,000 people.
Documents show compensation plans for Evolution Travel. (Evolution Travel)
None of this was mentioned in the information sessions CBC attended, which covered travel booking exclusively. When a CBC journalist posing as a job applicant asked about getting commissions from their own recruits, the session host said it was not covered in the information sessions and that the person who invited them into the program would address it.
Session hosts also didn’t disclose there is a hidden $50 annual fee in the independent contractor agreement, seen by CBC, when signing up.
A screenshot from an Evolution virtual session shows the packages attendees can pay to enrol in the program. (Evolution Travel)
Former FTC chairman and commissioner Kovacic said if he were still at the agency, he would be looking into the company.
"[Fees are] not presented in the initial interaction," he said. "It's shrouded in a way that's very important and would mislead users."
Job seekers have been complaining about Evolution Travel, its members and agents like Deidre Norton online and to the Better Business Bureau for years.
In 2021, Evolution Travel was among 1,000 companies put on notice by the U.S. Federal Trade Commission that they could face fines if they or their representatives made "misleading, or deceptive representations" about a "money-making opportunity."
Kovacic said a firm that "defied" FTC notices and continued to persist in these practices would be a "worthy target for an investigation."
CBC News found numerous complaints online about companies linked to the job postings. (Illustration: Matthew Hoddy/CBC, Reddit, Better Business Bureau)
Ron Archer, the CEO of Archer Travel Services, said that the company does "not condone illegal job postings and addresses them when we are made aware."
Yet in videos online, travel agents connected to Evolution Travel talked openly about using LinkedIn job postings to recruit people into the business.
Archer said they cannot "tell people how they train for their business" because they have "27,000 independent contractors around the world."
"LinkedIn is a big one," said one member in a June 2026 training video posted to YouTube. "We have quite a few different trainings on how to post on LinkedIn."
Jay Jones, who has gotten tens of thousands of jobs taken down from platforms himself, said companies like LinkedIn and Monster generate revenue through this traffic.
"There's no actual vetting of what companies get to be created, what jobs get to be listed," said Jones. "People coming [to LinkedIn] believing that there are real opportunities are greeted with this MLM nonsense."
For any tips related to this investigation, contact eric.szeto@cbc.ca or the visual investigation team’s inbox: vi@cbc.ca
We found sqrt(2.0) in the standard's float_pkg returns one unit in the last place too low in double precision by default. This is the IEEE 1076-2008 and 1076-2019 VHDL floating-point package; IEEE publishes the file, GHDL and NVC ship it unchanged.
The root uses a fixed count of Newton steps and no sticky bit. But taking it one bit at a time from the definition is exact, with a subtraction per bit, the same thing as square root by hand on paper.
Our check treats operands as exact fractions, does each operation exactly and rounds once before comparing. mac(-6, -1, -5), or (-6)(-1)+(-5), returns -15 instead of 1. Converting 2^-512 double to single returns 1.0; reciprocal of 2^127 in single returns infinity. For all operands and pairs in a 7-bit format (3 exponent bits, 3 fraction bits), plus all mac triples, we ran 8,692,326 calls, and 1,271,619 weren't correctly rounded.
The exact reference, testbench, causes with source line numbers and patch are in the folder. All 32,470,838 calls from four test sets pass with patch; GHDL and NVC produce identical result files on common sets. fixed_pkg division gets 41,026 of 751,418 wrong and has its patch there. Reported to IEEE P1076 working group (VHDL-Issues 388), ghdl 3486, nvc 1758.
To see it yourself, with GHDL and nothing else:
ghdl -a --std=08 plain.vhd
ghdl --elab-run --std=08 plain
The rest of this page is the record: every wrong call, the counts, the causes by line, the patch.
ieee.float_pkg
is the floating-point package of the VHDL standard, IEEE Std 1076-2008 and 1076-2019. The source is the IEEE's own:
ieee/float_generic_pkg-body.vhdl
on the
release
branch of
opensource.ieee.org/vasg/Packages
, 5,712 lines,
$Revision: 1220 $
. The working group's
develop
branch at
gitlab.com/IEEE-P1076/Packages
has the same bytes, and GHDL and NVC ship them unchanged. The runs here are in GHDL 7.0.0-dev and NVC 1.23.1, and where both ran the same vectors they wrote the same result file.
The package is set beside exact arithmetic. An operand is a sign and a fraction of two integers, the operation is done on the fractions, and the result is rounded once into the format in the rounding style the call names.
exact.py
is that reference.
With the package's own settings:
round_nearest
, 3 guard bits, denormal numbers on.
call returns exactly rounded
sqrt (2.0) in float64 3FF6A09E667F3BCC 3FF6A09E667F3BCD
sqrt (14.0) 406F7750 406F7751
sqrt (2.0**-149) 4.2e-22 3.7e-23
mac (-6.0, -1.0, -5.0) -15.0 1.0
mac (-5.0, 1.0, 4.0) 15.0 -1.0
mac (1.0, 1.0, -infinity) +infinity -infinity
mac (1 + 2.0**-23, 1 - 2.0**-23, -1.0) -2.0**-26 -2.0**-46
resize (2.0**-512 in float64, 8, 23) 1.0 0.0
resize (2.0**600 in float64, 8, 23) 2.0**88 +infinity
resize (2.0**-1074 in float64, 8, 23) +infinity 0.0
resize (2.0**-650 in float64, 8, 23) stops the simulator 0.0
reciprocal (2.0**127) +infinity 2.0**-127
divide (2.0**-149, 2.0) 2.0**-149 0.0
dividebyp2 (3 * 2.0**-149, 2.0) 2.0**-149 2.0**-148
scalb (1.0, 300) 0.0 +infinity
scalb (+infinity, -10) 2.0**118 +infinity
to_signed (0.50000006, 32) 0 1
to_unsigned (199.78125, 8) 199 200
And where the call names a rounding style:
divide (6.0, 3.0, round_inf) 2.0000002 2.0
reciprocal (2.0, round_inf) 0.50000006 0.5
add (largest, largest, round_zero) +infinity largest
multiply (2.0**-100, 2.0**-100, round_inf) 0.0 2.0**-149
add (1.0, -1.0, round_neginf) +0.0 -0.0
to_signed (2.25, 8, round_inf) 2 3
to_float (100000, 5, 10, round_zero) +infinity 65504.0, the largest
plain.vhd
makes these calls and prints
WRONG
beside each result that is not the exactly rounded one: 24 lines, and the 25th call stops the simulator with an index out of bounds at line 358 of the package body. It needs GHDL and nothing else:
ghdl -a --std=08 plain.vhd
ghdl --elab-run --std=08 plain
The plain operands are not rare ones. Of the integers 1 to 4,096,
sqrt
returns a float32 one unit off for 256 and a float64 one unit off for 264. Of the 4,913 triples made from -6 to 6, 0.25, 0.5, 1.5 and 10,
mac
returns the wrong float32 for 290.
resize
from float64 to float32 returns +infinity for every power of two from 2^-1074 to 2^-1024, stops the simulator from 2^-662 to 2^-639, returns 2^(e+512) from 2^-638 to 2^-512 and 2^(e-512) from 2^513 to 2^639.
10,000 calls per operation, format and rounding style, on operands aimed at the places arithmetic breaks: denormal operands and results, both ends of the exponent range, fractions that round up into the next binade, exact ties, signed zeros, infinities. A cell is the number of results that are not the exactly rounded one, of the calls compared. A conversion whose result does not fit the integer is not compared.
float32 round_nearest round_zero round_neginf round_inf
add 0 of 10,000 304 of 10,000 312 of 10,000 159 of 10,000
subtract 0 of 10,000 314 of 10,000 312 of 10,000 143 of 10,000
multiply 0 of 10,000 1,102 of 10,000 781 of 10,000 775 of 10,000
divide 27 of 10,000 670 of 10,000 2,324 of 10,000 2,395 of 10,000
sqrt 735 of 10,000 581 of 10,000 542 of 10,000 774 of 10,000
mac 2,671 of 10,000 3,697 of 10,000 3,213 of 10,000 3,302 of 10,000
reciprocal 384 of 10,000 586 of 10,000 1,093 of 10,000 2,613 of 10,000
resize to a narrower format 422 of 20,000 2,728 of 20,000 2,516 of 20,000 2,466 of 20,000 272 more stop the simulator
resize to a wider format 0 of 20,000 0 of 20,000 0 of 20,000 0 of 20,000
to_float (signed, 32 and 64 bits) 0 of 20,000 0 of 20,000 0 of 20,000 0 of 20,000
to_signed (8, 32, 64 bits) 613 of 28,637 0 of 28,626 5,934 of 28,608 5,898 of 28,623
to_unsigned (8, 32, 64 bits) 280 of 16,506 0 of 17,133 0 of 14,493 5,964 of 17,145
to_integer 0 of 10,000 0 of 10,000 1,921 of 10,000 1,973 of 10,000
to_float (integer) 0 of 10,000 0 of 10,000 0 of 10,000 0 of 10,000
dividebyp2 1,542 of 10,000 1,904 of 10,000 2,313 of 10,000 2,262 of 10,000
scalb 2,653 of 10,000 3,088 of 10,000 3,381 of 10,000 3,401 of 10,000
float64 round_nearest round_zero round_neginf round_inf
add 0 of 10,000 260 of 10,000 311 of 10,000 138 of 10,000
subtract 0 of 10,000 283 of 10,000 317 of 10,000 147 of 10,000
multiply 0 of 10,000 1,163 of 10,000 852 of 10,000 866 of 10,000
divide 18 of 10,000 698 of 10,000 2,495 of 10,000 2,406 of 10,000
sqrt 1,278 of 10,000 619 of 10,000 659 of 10,000 799 of 10,000
mac 2,673 of 10,000 3,697 of 10,000 3,285 of 10,000 3,290 of 10,000
reciprocal 350 of 10,000 477 of 10,000 1,087 of 10,000 2,623 of 10,000
resize to a narrower format 801 of 30,000 4,116 of 30,000 3,980 of 30,000 4,014 of 30,000 445 more stop the simulator
resize to a wider format 0 of 10,000 0 of 10,000 0 of 10,000 0 of 10,000
to_float (signed, 32 and 64 bits) 0 of 20,000 0 of 20,000 0 of 20,000 0 of 20,000
to_signed (8, 32, 64 bits) 618 of 28,219 0 of 28,231 6,161 of 28,340 5,952 of 28,262
to_unsigned (8, 32, 64 bits) 321 of 16,330 0 of 16,839 0 of 14,237 6,155 of 16,776
to_integer 0 of 10,000 0 of 10,000 2,125 of 10,000 2,183 of 10,000
to_float (integer) 0 of 10,000 0 of 10,000 0 of 10,000 0 of 10,000
dividebyp2 1,543 of 10,000 1,902 of 10,000 2,321 of 10,000 2,391 of 10,000
scalb 2,218 of 10,000 2,540 of 10,000 2,982 of 10,000 2,967 of 10,000
In float32 that is 81,068 wrong and 272 stops in 859,771 calls, and in float64 86,081 wrong and 445 stops in 857,234. The same calls in float16 give 113,980 wrong in 866,782, and in float128 90,744 wrong and 585 stops in 855,777.
Where a format is small enough, every operand there is:
format calls compared wrong
7 bits, 3 of exponent and 3 of fraction every operand, every pair, every triple of mac 8,692,326 1,271,619
10 bits, 4 of exponent and 5 of fraction every operand and every pair 17,340,682 883,716
float16 every operand of the one-operand functions 2,998,266 266,342
mac
in
round_nearest
is wrong for 243,520 of the 2,097,152 triples of the 7-bit format.
Line numbers are those of the IEEE file.
normalize
, line 422.
Every result goes through
exp := resize (expon, exp'length) + shiftr
. The exponent comes in at the width of the caller's format and is cut to two bits more than the target's. From float64 to float32 that is ten bits, so the exponent is taken modulo 1,024: 2^-512 comes out as 1.0 and 2^600 as 2^88. Where the cut exponent lands among the denormal numbers, the shift count that follows indexes outside the fraction and the simulator stops. In the same function a result too large for the format is infinity in every rounding style and a result too small is zero in every rounding style. Rounding toward zero gives the largest number, and rounding away from zero gives the smallest.
divide
, line 1243, and
reciprocal
, line 1099.
The sticky bit handed to the rounding is the constant
'1'
. An exact quotient is rounded as if something were left over: one unit up in
round_inf
, and to the wrong side of an exact tie in
round_nearest
, which happens among denormal quotients.
reciprocal
, lines 1053 to 1093.
The exponent of the result, -e - 3, is kept in as many bits as e, and for the top binade it does not fit. In float32 every argument from 2^127 up returns infinity, and in float64 every argument from 2^1023 up. 1/-0 returns +infinity and 1/-infinity returns +0.
sqrt
, line 1787.
Newton's iteration from (1 + x)/2,
fraction_width/4 + 1
steps in truncated fixed point, and the result goes to the rounding without a sticky bit. For a normal argument it ends on the root or one unit beside it: in the vectors above it is one unit off for 607 of 9,156 normal float32 arguments and 1,146 of 9,236 normal float64 ones, and never further. For a denormal argument the start is too far away for that many steps: 128 of 359 float32 denormals are wrong, 104 of them by more than two units, and
sqrt (2.0**-149)
returns 11 times the root.
mac
, lines 1438 to 1536.
The product is cut to the width of one operand before
c
is added (lines 1529 and 1536), so a sum that cancels returns what the cut left. Where the product and
c
have the same exponent and unlike signs and the product is the larger, line 1514 subtracts the larger from the smaller: (-6)(-1) + (-5) returns -15. An infinite
c
takes the sign of the product, and infinity minus infinity returns infinity (line 1438).
add
, line 839.
An exact zero from operands of unlike signs is +0 in every style. The paragraph the comment cites, IEEE 854 6.3, makes it -0 when rounding toward minus infinity.
to_signed
,
to_unsigned
, lines 301 to 345, and
to_integer
, line 3193.
Three bits below the integer are kept and the rest are dropped without a sticky bit, so 0.50000006 is taken for one half and goes to the even neighbour, 0. For a number that fills every bit of a
to_unsigned
result the three bits are zeros: 199.78125 into 8 bits returns 199.
round_inf
and
round_neginf
look at the half bit only, so 2.25 rounded up is 2.
resize
, line 2407.
-0 to a narrower format returns +0, and the comment says
hate -0
. To a wider format it stays -0.
to_float
of an integer, lines 2676 and 2803.
A number too large for the format returns infinity in every rounding style.
dividebyp2
, line 1378, and
Scalb
, lines 4601 to 4610.
Both hand the result to
normalize
with no guard bits, so a denormal result is cut off where it should be rounded.
Scalb
adds N in
exponent_width + 1
bits, where a large N wraps, and it scales infinity like a number.
dividebyp2
takes a denormal power of two for a divisor that is not a power of two.
With
denormalize
false.
A zero is broken up with a higher exponent than a number of the lowest binade, so
add
of a zero and such a number of the opposite sign subtracts the number from zero and returns the wrapped difference.
reciprocal
treats those numbers as the denormals they are not.
float_generic_pkg-body.patch
applies to the IEEE file. It changes the package body only, 33 hunks, and no declaration.
normalize
decides between zero, denormal, normal and infinity on the exponent at its full width, and returns the largest or the smallest number where the rounding style asks for it.
divide
and
reciprocal
take the sticky bit from the remainder of the division.
reciprocal
keeps its exponent two bits wider and gives zero and infinity the sign of the argument.
sqrt
takes the integer square root of the significand one bit per step, with the remainder as the sticky bit.
mac
places the whole product and
c
in one window of 3 *
fraction_width
+ 9 bits, adds or subtracts there and rounds once. It is a fused multiply-add.
add
returns the other operand when one is zero and gives an exact zero the sign the rounding style calls for.
resize
keeps the sign of zero.
to_float
of an integer returns the largest number where the style rounds toward zero.
dividebyp2
and
Scalb
round a denormal result with guard bits.
Scalb
returns infinity and zero as they are and takes any N.
On the same vectors:
the package as shipped patched
four formats, 10,000 per cell, 3,439,564 calls 371,873 wrong, 1,302 stop 0 wrong, 0 stop
the 7-bit format, 8,692,326 calls 1,271,619 wrong 0
the 10-bit format, 17,340,682 calls 883,716 wrong 0
float16, the one-operand functions, 2,998,266 calls 266,342 wrong 0
plain.vhd, 25 calls 24 wrong, 1 stop 0
GHDL and NVC wrote the same result files with either package: 8,693,248 lines for the 7-bit format and 3,680,000 for the four formats, the 1,302 stops on the same lines. The reference itself was set beside this machine's own arithmetic on the float32 and float64 vectors of add, subtract, multiply, divide and sqrt in
round_nearest
: 99,135 operations, none different.
The package takes its guard bits and its denormal numbers as parameters. On 1,000 calls per cell in float16, float32 and float64:
setting calls patched right, shipped wrong neither right shipped right, patched wrong
3 guard bits, the default 258,075 28,103 0 0
4 guard bits 258,075 27,758 0 0
2 guard bits 258,075 28,760 112 0
1 guard bit 258,075 30,212 2,194 0
denormalize false 255,606 27,745 0 0
With two guard bits 112 results of
add
and
subtract
are not the rounded ones, and with one guard bit 2,194 of
add
,
subtract
and
multiply
: too few bits to round every result, and both packages return the same bits on those lines. With no guard bits nothing is rounded: the patched
sqrt
,
mac
and
reciprocal
then return the exact result cut off toward zero on every line, where the shipped ones do on 10,207 of 11,141, 3,902 of 9,750 and 10,749 of 11,102. With
denormalize
false the comparison is with that setting's own numbers, where an exponent field of zero is one more binade of numbers with a leading one.
ieee.fixed_pkg
comes from the same source,
ieee/fixed_generic_pkg-body.vhdl
, and NVC ships that file byte for byte. Every operand of six pairs of small index ranges, unsigned and signed, went through every arithmetic operation: 751,418 calls. Addition, subtraction, multiplication,
rem
,
mod
, the comparisons,
add_carry
,
resize
in both rounding and both overflow styles,
to_integer
,
scalb
, unary minus and
abs
are right on every one. Division is not.
ufixed sfixed
/ 1,073 of 19,984 952 of 19,984
divide, fixed_round, 1 guard bit 4,632 4,376
divide, fixed_round, 2 guard bits 2,433 2,370
divide, fixed_round, 3 guard bits 1,073 952
divide, fixed_round, 4 guard bits 487 402
divide, fixed_truncate, 3 guard bits 0 651
divide, no guard bits 0 7,785
0.125 / 1.875
in
ufixed (3 downto -3)
returns 0.0625. The quotient is 0.0667, and the nearest number the result can hold is 0.0703.
The quotient is an integer division carried to the guard bits (lines 604 and 646), and the rounding sees those bits and not the remainder of the division. Guard bits of 100 with a remainder behind them are above the halfway point, and they are rounded as a tie, to even. That is about one quotient in twenty with the default three guard bits. A signed division cuts toward zero and
resize
then cuts toward minus infinity, so with
fixed_truncate
a negative quotient goes one way or the other depending on where its guard bits end.
fixed_generic_pkg-body.patch
gives both
divide
functions one more bit below the guard bits, set when the division leaves a remainder, and takes a negative signed quotient that is not exact down to the next lower number before
resize
rounds or cuts it.
reciprocal
calls
divide
. With it nothing is wrong in the 751,418 calls, and GHDL and NVC write the same result file with either package.
sh run_fixed.sh ghdl /path/to/ieee # 41026 wrong in 751418 operations, then 0 wrong in 751418 operations
sh run_fixed.sh nvc /path/to/ieee
tb_fixed.vhd
is the testbench and
fixed_exact.py
the reference.
GHDL or NVC, Python 3.9 or later, and the three files
float_generic_pkg.vhdl
,
float_generic_pkg-body.vhdl
and
float_pkg.vhdl
from the directory
ieee
of the IEEE repository or from
lib/ghdl/src/ieee2008
of a GHDL installation.
sh run.sh ghdl /path/to/ieee 100 # plain.vhd, then 100 vectors per operation, format and style: half a minute
sh run.sh nvc /path/to/ieee 10000 # the tables above
With 100 the last lines read
3696 wrong and 8 stops in 34440 operations
for the package as shipped and
0 wrong and 0 stops in 34440 operations
for the patched one, in both simulators. NVC is the faster of the two on the large runs: the shipped
sqrt
and
divide
work in fixed point and are slow in float128.
run.sh
compiles the patched body into a library of its own,
patched
, beside the declaration it belongs to, and runs each testbench twice: against the package the simulator ships and against that library.
tb_float_pkg.vhd
reads one operation per line and writes the result;
exact.py run
restarts it behind a line that stops the simulator.
python3 exact.py gen 2026 10000 5,10 8,23 11,52 15,112 > vectors.txt # the vectors of the tables above
python3 exact.py all 3,3 > vectors.txt # every operand of the 7-bit format
python3 exact.py check vectors.txt results.txt
To use the patched package in a design, compile
float_generic_pkg.vhdl
and the patched body into a library and instantiate
float_pkg
from it, as
run.sh
does.
remainder
,
modulo
,
Logb
,
Nextafter
, the comparisons, the conversions with
real
and with fixed point, the text input and output, operands of two different formats in one call, and
check_error
false.
The VHDL-93 version of the package,
float_pkg_c.vhdl
in
FPHDL/fphdl
, carries the same lines. It was not run here.
To the IEEE P1076 working group on 13 November 2026 as VHDL-Issues#388 and by mail, and as ghdl/ghdl#3486 , nickg/nvc#1758 and FPHDL/fphdl#4 .
A University of Chicago law professor has warned of the dangers of using AI for mundane tasks after Claude AI accidentally deleted an entire year of Constitutional Law lecture notes and his entire current syllabus. While the files were later recovered via Dropbox, William Baude shared the story as a public service announcement, the latest story shared in a line of unfortunate AI missteps as proliferation increases.
Latest Videos From Tom's Hardware
Stephen is Tom's Hardware's News Editor with almost a decade of industry experience covering technology, having worked at TechRadar, iMore, and even Apple over the years. He has covered the world of consumer tech from nearly every angle, including supply chain rumors, patents, and litigation, and more. When he's not at work, he loves reading about history and playing video games.
Anyone who reads this article and, still doesn't backup important files , you are an idiot...
Altman: introducing Ai Backup. Getting tired of ai agents deleting your stuff? We got you fam, our new cloud backup system automatically backs up everything before one of our agents "accidentally" deletes it...
Dementoss said:
Anyone who reads this article and, still doesn't backup important files , you are an idiot...
While true and the headline seemingly purposely avoids mentioning it, the article does say the files were recovered through Dropbox. Not my preferred backup method, but it's something. My guess is the headline omitted this to make the non-story more sensational.
Thunder64 said:
While true and the headline seemingly purposely avoids mentioning it, the article does say the files were recovered through Dropbox. Not my preferred backup method, but it's something. My guess is the headline omitted this to make the non-story more sensational.
Yes, I did read that first before typing. If it gets more people taking backing up seriously, then the article is worthwhile.
S58_is_the_goat said:
Altman: introducing Ai Backup. Getting tired of ai agents deleting your stuff? We got you fam, our new cloud backup system automatically backs up everything before one of our agents "accidentally" deletes it...
until the ai think you aren't current on subscription and delete the backup.
the AI seems to have deleted the files by accident , rather than of its own volition.
an "ai" can't do anything by accident.
They think and act. It chose to do the task.
hotaru251 said:
an "ai" can't do anything by accident.
They think and act. It chose to do the task.
I don't think they think. they take a % and act on it.
rgd1101 said:
I don't think they think. they take a % and act on it.
poor word choice i guess but i didnt mean actual think like humans but it just runs its algorithm to decide what its to do
Dementoss said:
Anyone who reads this article and, still doesn't backup important files , you are an idiot...
I absolutely agree with you, with the unfortunate caveat that buying storage in 2026 is getting ridiculusly expensive
In the good old days, as in right NOW, MS Word can renumber pages also....without the need for a rogue or sweet-tempered AI Claude, or whoever.
PS: Was that AI already rogue before or became one after the fact?? Asking for wannabe AI users.
Direct File is a service from the United States Government that provides taxpayers the option to electronically file their federal tax return for free, directly with the Internal Revenue Service (IRS). Direct File is an interview-based service that is intended to work as well on a mobile phone as it does on a laptop, tablet, or desktop computer. It is available in English and Spanish and is designed to be accessible to taxpayers who have a variety of attitudes, aptitudes, abilities, and access needs.
Direct File interprets the United States' Internal Revenue Code (26 USC) as plain language questions, the answers to which should be known to taxpayers without need of external instructions or publications. Taxpayers' answers are then translated into standard tax forms and transmitted to the IRS's Modernized e-File (MeF) API, which is available for authorized public use. These questions and logic, developed in close collaboration with the IRS Office of Chief Counsel , as well as the associated test cases and scenarios, may be useful for others working on products that need to accurately interpret United States tax law as of Tax Year 2024.
Direct File also incorporates the Fact Graph, a declarative, XML-based knowledge graph data structure that is designed to reason about incomplete information, such as a partially completed tax return. The Fact Graph is written in the Scala programming language; it runs on the JVM on the backend and is transpiled via Scala.js to run on the client as well. Direct File's Fact Graph is not domain-specific, and it may be useful to revenue agencies and as a reference for business rules engine implementations.
Although Direct File only files federal tax returns, United States taxpayers also have state and local filing obligations. Direct File facilitates the completion of these obligations by enabling taxpayers to optionally import their federal return data into a third-party tool that can file state and/or local taxes, without needing to reenter information. This transaction is enabled via a State API, which transfers both standard MeF XML as well as an enriched JSON format that includes additional data elements that were identified as being useful to state revenue agencies to streamline the state tax experience.
Direct File was developed by an in-house team of technologists at the IRS. The blended, cross-agency team included support from USDS and GSA , as well as vendor teams TrussWorks , Coforma , and ATI .
For a more details on the program and its history see https://www.irs.gov/pub/irs-pdf/p5969.pdf and https://www.irs.gov/filing/irs-direct-file-for-free
This repository has been archived and is no longer maintained. The code is provided for historical reference and may contain unpatched or unknown vulnerabilities. It should not be used in production systems.
See ONBOARDING.md if you want to jump into running Direct File locally
Not all source code, documentation and metadata used in the development of Direct File is included in this repository. Specifically, any code or data that is considered Personally Identifiable Information (PII), Federal Tax Information (FTI), Sensitive But Unclassified (SBU), or source code developed for National Security Systems (NSS), as defined in 40 U.S.C. § 11103, is exempt. Due to these restrictions, certain pieces of functionality have been removed or rewritten.
Legal foundations for work include:
There’s a particularly virulent strand of column-publishing and Twitter/X debate happening right now which, if it continues, will require me to seek medical attention for perpetual eye roll. It consists of American and British people gleefully writing about America’s explosive economic growth at the moment, and comparing it to Europe’s sluggish post-Covid recovery. Everyone seems to have their own opinion explaining the difference, the most convincing of which I find the idea that the EU has stuck with conservative neoliberal orthodoxies for the economy while America has been quietly more flexible.
On Twitter, these columns have then translated to a bunch of reply guys (it’s always men) gloating about the American economy and mocking the “ europoors ” who live in abject poverty while enviously looking across the Atlantic. Life is much better in America, they insist, because they have tumble dryers , bigger houses , bigger cars , higher salaries and, of course, freedom. These messages are not only coming from Americans but also from Brits - and it feels to me like the genesis for this is coming more from the latter than the former. There’s a particular strain of Tory Britain-bashing America-obsessed London elite, in the mould of Dan Hannan , who seem to think they are Americans born in the wrong body.
As someone who grew up in the US and moved to Europe at age 26, I could go on with a nuanced take about the positives and negatives of each. I’ll leave that to others. What I find much more interesting is why we’re getting this sudden rush of America-gloating and Europoor-bashing at this particular moment. This conversation isn’t being sparked in the EU. All of these Twitter flare-ups are started by people in Britain or America, and when people in the EU reply to point out that what they’re saying is nonsense, it’s “cope from pathetic europoors”. In other words, this isn’t a two-way dialogue. This is a man draped in red, white and blue standing on a soapbox on the street and screaming at European passers-by, who occasionally stop to challenge him.
Why have Americans suddenly become so insecure about their own supposed greatness? 20 years ago it would have just been taken as a given that life in America is better than life in Europe - also by most Europeans. For Americans, Europe was a holiday destination, not a real place with real economies who might compete with the mighty US. I can attest to this from personal experience. When I emigrated in 2006, Americans couldn’t really wrap their heads around what I was doing. My last job in the US was TV and radio reporting covering the US Congress in Washington. During that time I read Jeremy Rifkin’s The European Dream and it inspired me to move to Europe. My intention then, as it remains, was to do a permanent move for a better life. Since the US has no history of emigration like European countries do, people couldn’t quite understand this concept. They would get it if I was taking some time off to go live the wine and cheese life for awhile. They could understand it if my job was temporarily transferring me to Europe for a few years (as some of my friends and family have done). They could not understand the idea that I would choose to immigrate to Europe, without a job (or, at the time, a European passport), in search of a better life. This had always only happened in the other direction, as my Italian Great Grandfather did in 1916. 90 years later after his boat trip across the Atlantic, I used Italy’s strange ancestry citizenship policy to get myself an EU passport through him. If you had told him then that his great grandson would use his Italian roots to emigrate the other way to improve his life, he probably wouldn’t have believed you.
But now, 20 years later, my friends and family get it. Since 2016, as the United States seems to drift closer and closer to democratic collapse , I keep being told during my biannual visits to my country of birth that they are envious. My peers my age who I graduated high school and college with (a lot of whom, I can tell you candidly, are pretty damn miserable), say they wish they had made the move when they could have when they were younger. We all grew up being told that America is the best country on earth, that all other countries are living in squalor and we’re so lucky to have been born where we were. I’ve had experiences of American visitors coming to Europe for the first time feeling shocked and confused to find that so many things are more developed than in the US.
For years, Europeans also operated under the assumption that life in America was better than in Europe. Growing up on a continent dominated by American culture, they have been inundated with idealized Hollywood images of how great life in the US is. When I moved from New York City to London in 2006 I heard a constant response of “but why would you come here ?” Ditto for when I later moved to Paris and Brussels. The people saying this had no experience of living in America themselves (or, often, even visiting). They were basing their assumption that life must be better there based on the television, movies and music they have been surrounded by their whole lives. Over the years many Europeans have told me they dream of one day winning the “ green card lottery ” to win a chance to live in America, as if it’s a prize. It’s a system that is incredibly insulting to Europeans, but for decades in the European mind it made sense.
However over the past ten years I’ve noticed this perception has been slowly changing here in Europe, and it’s also starting to change in America. No longer is the starting assumption point that America is great and Europe is inferior. Americans have started to wake up to the economic power of the European Union, which is now a larger market than the US. The spread of English as Europe’s lingua franca, at the same time that social media has connected the world, has also enabled more communication across the Atlantic. For the first time, Europeans have started to see the truth about life in America. And even though the US remains in a cultural bubble (media goes out but rarely comes in) and Americans don’t see much of the outside world, they are still starting to see glimpses of what daily life (not vacations) in Europe is really like. They can see on social media that people actually live pretty happy lives. That they’re given at least 20 days vacation per year (the legal EU minimum) as opposed to the usual five in America. That they’re able to attend university for free or next-to-nothing and start their careers without student debt. That they don’t need to worry about healthcare costs. That they can live comfortably without owning a car. That they enjoy social protections which guarantee them a good quality of life.
The opening of that window into what life is like in Europe seems to be making certain people in America (and their admirers in Britain) very defensive. But there is another, larger reason why these people are lashing out at the “europoors” in this defensive way right now. They can see that both Britain and America, once the envy of the world, have now become internationally renowned basket cases. Americans are now living with the knowledge that half their fellow citizens either support a Trump dictatorship or are indifferent to it. They are living with the anxiety that comes from living in a country that could, at any moment, slip into civil war. Brits, on the other hand, are living with the humiliations of Brexit’s effects on their economy and society. They have been reduced to a country with an Italian-style revolving door of prime ministers, the most recent former one reduced to hawking upside-down books on US cable news to anchors who don’t seem to even know who they are. This humiliation is a national trauma, there is no other way to describe it. And many are lashing out as a result. They’re defending the American horse they bet on in 2016, and feel the constant need to demonize and denigrate the EU horse they sold. And because the American media still gets so much of its knowledge about Europe via the biased British prism , the discourse in the US has become infected by the UK’s post-Brexit trauma.
To put it bluntly, 20 years ago Europe was an afterthought for Americans - an irrelevant Disneyland. That they are suddenly paying so much attention to it, even to denigrate it, shouldn’t get under our skin. It comes from a place of fragility, of psychological trauma. It is their problem, not ours.
I know I said I wouldn’t get into a debate about the pros and cons of Europe and America, but I do want to say one thing about this “higher salaries” thing that I keep hearing Europeans talk about . Yes, net salaries in wealthy areas of the US are much higher than in wealthy areas of Europe, largely because of the drastically lower tax rate. But if you’re just comparing the headline figure, it’s giving you a misleading impression of people’s disposable income. Subtract from that monthly net the monthly healthcare co-pay even when you have insurance through your company (mine at my last US job was $400/month), your student loan repayments (mine are still $300/month), your car and fuel costs (New York City is the only place you can get by without a car), and various other costs that would be provided by the state in Europe such as childcare. And when it comes to those super-high salaries in New York City or Washington I keep seeing people talk about, go have a look at average rental prices in those cities and you might understand why my friends who live there have far far less disposable income than I do, even though on paper it might look like they’re making more.
For a few years I was ‘Head of DevOps’. Before I got that job title I’d done much the same work under other names, and since then I’ve watched the same work get called SRE, and then it seemed to morph towards platform engineering. If you’ve been in this industry for any length of time you’ll have seen titles come and go like this, and you might have wondered where they all came from.
So I (with the help of Mr Claude) built this family tree of software job titles, from the 1940s to now.
It’s here: ianmiell.github.io/sw-job-title-family-tree
There are 104 titles, from ‘Computer’ (a person, not a machine) at the top to ‘AI Agent / Context Engineer’ at the bottom.
Time runs from top to bottom, in five-year rows. The titles sit in seven coloured columns by family:
A solid arrow means the title grew out of its parent. A dashed arrow means influence, or a common career move. Landmark titles are in bold.
On the site you can click a family to see just that column (here’s Data & AI ), or click a title to get its history, background and connections (here’s SRE ).
The whole thing is one Graphviz file and one JSON file of descriptions. Each title is one line in the
.dot
file, and the picture is rendered with:
$ dot -Tsvg job_title_family_tree.dot -o job_title_family_tree.svgAdding a title is three small edits: a node in its family’s column, an entry in the row for its five-year period, and its parent arrows.
A word on the dates. They’re roughly when a title became common , not its first recorded use, and they’re my best estimates, not sourced citations. Some are well known (SRE at Google in 2003, ‘DevOps’ coined in 2009, ‘Data Scientist’ in 2008). Plenty are a ‘c.’ and a shrug.
Drawing it out made a few patterns hard to miss.
In 1947, Goldstine and von Neumann’s ‘Planning and Coding of Problems’ split the work of using a computer in two: mathematicians planned the problem, and coders translated the plan into machine instructions. Coding was treated as lower-status clerical work, and much of it was done by women.
It turned out that coding eventually became the hard, creative part, and the coder merged into the programmer.
Go back further and it’s stranger still. Several of the first ENIAC programmers were recruited from the Army’s human computers, people whose job was to compute by hand. So the job gave its name to the machine, and its people to programming.
The webmaster turned up around 1993, and was often a single person who wrote the HTML, ran the webserver (often a box under a desk), answered the email, and kept the site up (sometimes by kicking it, more often by plugging it back in after kicking it).
By the mid-2000s the title had all but gone, as it was unfashionably ancient. The code went to web developers, the servers to sysadmins, and the content to editors and designers.
Then the web developer split into front-end and back-end around 2005, and the two joined back up again as ‘full-stack’ around 2008.
This is the centralisation/distribution see-saw I’ve written about before , playing out in job titles.
The prompt engineer made headlines in 2023 with a few eye-wateringly well-paid job listings. As the models got better, the skill became part of other jobs, and on the tree it gets absorbed into the AI engineer almost as soon as it appears.
The scrum master is a slower version of the same story: demand peaked in the 2010s, and many organisations have since folded it back into engineering management or delivery roles.
The newest title on the tree is the ‘AI Agent / Context Engineer’ (c. 2025). The description for it currently says “time will tell whether it stays a separate title”. I’m not taking bets.
‘Systems Engineer’ is two different jobs on the tree. At IBM in the 1960s it was a pre-sales role, working with customers to design installations and get them running. In the 1990s, thanks largely to Microsoft’s MCSE certification, it meant a more senior, design-oriented sysadmin. Same title, different branch, no relation.
‘Configuration management’ started as a 1960s US defence discipline for tracking hardware changes, became software version control in the 1970s, and then came back decades later as the name for tools like Puppet and Chef.
The ‘forward deployed engineer’ (FDE) is one of the hottest titles of 2025, as OpenAI, Anthropic and plenty of AI startups hire FDEs to get AI working inside their customers’ organisations.
Palantir built its business around them from about 2010: software engineers embedded with a customer, often on site, building whatever is needed to make the product work for that customer’s problem.
Which sounds a lot like IBM’s systems engineers of the 1960s, who worked with customers before and after the sale, designing installations and getting systems running. (It also sounds a lot like old-style consulting, but I would say that.)
Ben Treynor Sloss defined SRE as “what happens when you ask a software engineer to design an operations team”. DevOps was meant as a culture of developers and operations working together, but by about 2011 ‘DevOps Engineer’ had become a job title, usually for whoever did the automation. On the tree, the arrow between SRE and DevOps points both ways. Platform engineering has both of them as parents, and was sold around 2022 as ‘the successor to DevOps’.
The Dev/Ops divide has never been resolved. It just keeps getting new names.
When I’m asked what the difference is between a DevOps engineer, an SRE and a platform engineer, the honest answer is always a little history lesson. This is the shortest version of that lesson I’ve managed so far.
The dates are best guesses, and I’ll have missed titles, mangled some lineages and drawn arrows people will argue with. If you know better, let me know, or raise a PR on the repo .
Which brings me back to the coders.
In 1947 coding was the clerical bit, and the real work was in the planning. Wind forward eighty years and you’ll hear much the same said about coding again, because AI. Last time, the coders turned out to be doing the hard part.
I’ll leave you to draw that arrow yourself.
AI makes it easier to build your own web applications, but handling sensitive data still requires special care. We examined 159,041 Lovable projects and found many cases where personal and confidential information was accessible without logging in.
Lovable is a Swedish AI startup founded in Stockholm in 2023 by Anton Osika and Fabian Hedin. The platform turns plain-language descriptions into web applications and is designed to be accessible even to people with little or no programming experience .
Lovable grew out of Osika’s open-source project “GPT Engineer”, released in 2023. The project evolved into the GPT Engineer App before being renamed Lovable in late 2024 and launching publicly that November.
Lovable can build impressively sophisticated web projects with AI, from static websites to full applications with user management and database connections. But as soon as an application handles confidential information, one question becomes crucial: Is that data protected against unauthorized access?
In its marketing , Lovable repeatedly emphasizes that no technical knowledge is needed to build projects . This can give the impression that the platform takes care of security too. Yet Lovable’s Terms & Conditions place responsibility for applications and data handling on the customers themselves.
That leaves a troubling gap between the promise of an easy-to-use, all-in-one service and the responsibilities customers are expected to take on.
Against this backdrop, we investigated how well sensitive data in Lovable applications is protected, in collaboration with Handelsblatt . Lina Knees reported on the findings on November 2, 2026 (in German) .
We wanted to find out whether sensitive data in Lovable applications was accessible without logging in. We looked separately at data sent when a website first loaded and additional content we checked by making further read-only requests with the same API key.
The result: We found many clear examples of sensitive data left unprotected.
We focused on the database service Supabase . Its integration is relatively easy to analyze, and we believe it is the most widely used database service among Lovable projects. Lovable’s own database features, introduced in late 2025, are still less widely used. Similar misconfigurations may occur there too, but we did not examine them in this analysis.
Using datasets from the open web archive Common Crawl , we identified and analyzed 159,041 Lovable projects from December 2025 to September 2026 . Of these, 34,545 used Supabase.
24,664 websites sent database records from Supabase as soon as they loaded, without requiring a login or any other interaction. That alone is not a security issue: the data may be intended for public display. But by making additional read-only requests, we were able to retrieve more database content. We found records containing email addresses in 10,560 tables across 7,403 of the 24,664 websites (30%).
Email addresses can help identify records containing personal data, but they may also be public contact addresses or test data. At the same time, this approach misses personal records that contain no email address. These effects partly offset one another, though we could not establish to what extent. The 30% figure should therefore not be read as a confirmed data leak rate. It applies only to the 24,664 websites we examined more closely. Our sample, drawn from Common Crawl, is also not representative of all Lovable applications.
We retrieved only parts of the datasets rather than downloading them in full. The figures below reflect the records we actually downloaded; the affected datasets may contain more. We are not publishing details of how to access them, as doing so could make further access easier.
We found many serious cases of exposed data, including:
A German lifestyle forum exposed more than 80,000 profiles containing full names, email addresses, dates of birth, and gender information. More than 200,000 chat messages were also accessible.
Several event organizers and restaurants exposed tens of thousands of records relating to ticket and food sales , with no login required. The records we inspected included email addresses, phone numbers, postal addresses, payment information, and ticket codes.
A property management company exposed AI-generated summaries of internal emails containing sensitive information about tenants, property owners, and business partners.
In a particularly serious case, a service provider exposed more than 1,000 records containing identity document details , including passport numbers , expiration dates , and nationalities . These highly sensitive identity details could be used for identity theft.
Other accessible content included tens of thousands of contracts , invoices , personal photo albums , and internal WhatsApp communications .
We also found numerous newsletter subscriptions, waiting lists, and contact and support inquiries. In one case, 280,000 emails sent to a provider’s customers were accessible.
Depending on what it contains, exposed data like this could be used for phishing, ticket fraud, or identity theft. We could not establish whether any of it had been misused.
Handelsblatt contacted Lovable with the findings of our investigation.
Our analysis shows that many Lovable applications leave even highly sensitive data unprotected, with potentially serious consequences for the people affected.
Access control mistakes can happen in any application, whether written by people or built with AI. With Lovable, database integrations follow recurring patterns, making it easier for attackers to look for similar misconfigurations across many applications. An approach that works against one app may then work against others with little extra effort. Users without a technical background also face a harder task spotting and preventing these flaws.
An easy-to-use development platform does not remove the need for an expert review of access permissions before an application handles confidential data.
Automated checks are no substitute for a professional security assessment .
Before an application handles real customer or business data, its access permissions, interfaces, and separation between user accounts should be reviewed. These checks should be repeated after significant changes. If the necessary expertise is not available in-house, bring in qualified support.
If you would like help securing your application, please get in touch.
Note: This research report presents a more recent analysis and updated figures compared with the Handelsblatt article published on November 2, 2026.
Get in touch for an informal conversation. We'll look at your current situation and work with you to find the right solutions.
Several major technology companies have announced plans to operate AI data centers in orbit. Elon Musk recently claimed : “the lowest-cost place to put AI will be space […] within two years, maybe three.” If a meaningful fraction of new AI compute really is placed in space within a few years, that would be a fairly big deal for AI governance and strategy. Here we try to disentangle the hype from reality and provide a sober assessment of the technical and economic feasibility of orbital data centers (ODCs).
The main case for ODCs is the cost of energy: space solar panels in the right orbits receive more constant and intense sunlight compared to Earth. Moreover, ODCs don’t currently face the same permitting and regulatory delays as on Earth, cause fewer ongoing environmental harms compared to grid or onsite natural gas-powered data centers, and may be more secure against data exfiltration. We find that the cost-competitiveness case for ODCs depends almost entirely on Starship achieving reusability comparable with what SpaceX achieved with Falcon: space-based solar reaches cost parity with present-day off-grid terrestrial power continuously at roughly $250/kg to orbit, and becomes cheaper than any current terrestrial energy source at around $50/kg, from the present-day launch cost of roughly $1,500/kg. Radiative cooling, often cited as a fatal obstacle, appears surprisingly manageable — potentially even cheaper than on Earth. However, ODCs may require substantial (perhaps ~38%) extra non-compute hardware (like solar, racks, and cooling) over 5 years to compensate for their inability to swap out failed chips, and inter-satellite bandwidth limitations likely confine ODCs to inference workloads, at least early on.
Assuming no transformative AI, 1 but continued demand for data center buildout, we estimate that ODCs are unlikely to represent a meaningful share of compute before 2030, but become cost-competitive with present-day terrestrial data centers within 3–5 years if Starship development stays on track.
Some of the world's largest technology companies continue racing for compute. If progress continues, demand for data centers may more than double by 2030. 2 Increasingly, though, new data center capacity is bottlenecked by multi-year queues to connect to the power grid. 3
The result has been a scramble for workarounds. Leading AI labs have increasingly adopted a “Bring Your Own Generation” model to source power, deploying onsite gas turbines and engines to bypass grid bottlenecks. xAI, for example, reportedly installed hundreds of megawatts of onsite gas generation in Memphis to accelerate deployment, and OpenAI and Oracle have placed large turbine orders for new Texas campuses.
Some argue that energy will become the binding constraint on AI progress, given grid interconnection delays as gas turbines are themselves facing multi-year manufacturing backlogs . But the constraint does not appear fundamentally binding (as Epoch notes ): turbine manufacture may expand to meet more demand and companies could go off-grid using combinations of gas, solar, and batteries, scaling power in parallel with compute, albeit at a cost premium. This raises a natural question: if you're going off-grid anyway, then what’s the best way to get power and where is the best place to put your data center?
Some think the answer will be in orbit. In November 2025, Google announced Project Suncatcher , a plan to put TPU-equipped satellites in dawn-dusk sun-synchronous orbit. In early 2026, SpaceX filed with the FCC for authorization to launch and operate a constellation of up to one million data center satellites . 4 Other entrants include Blue Origin , Ramon.Space and startups like Starcloud , and Aetherflux while China's Three-Body Computing Constellation has launched 12 operational satellites and run Alibaba's Qwen3 model in orbit. Recently, at GTC in March 2026, NVIDIA announced the Space-1 Vera Rubin Module, meant to be a dedicated space-rated GPU platform.
At first glance, it seems very unlikely that any meaningful fraction (say, >10%) of additional data center capacity will be placed in space in the next few years. But if the companies betting on space are right, that would be a fairly big deal, and it could change the landscape of AI governance. For example, terrestrial data centers are subject to national and regional regulations, whereas AI developers could potentially exploit jurisdictional ambiguities around compute in space. Also, the path to low-cost orbital compute likely routes through a single launch company, SpaceX, which also now operates a frontier AI lab since its acquisition of xAI . And that might raise concerns around concentration of power.
We've been looking into the technical and economic viability of orbital data centers (ODCs). Our core model gives estimates for the total cost of Earth and space-based data centers across several scenarios.
Cost breakdown for three Earth-based and three space-based scenarios building out 1 GW of compute. As best we can determine, orbital data centers could become cost competitive with a bullish terrestrial buildout if launch cost reaches around $100/kg given modest reductions to server and cooling system mass, while a bullish case for orbital data centers with substantial mass reductions and launch at $50/kg may offer cost savings.
The report focuses on three questions. First, what is the basic economic case for a meaningful fraction of AI compute being placed in space? Second, the most obvious physical blocker: can you cheaply cool a data center in orbit? Third: how fast could the shift to space data centers happen, how soon, and what would have to go right?
Here is our provisional assessment:
SpaceX's Starship is the only vehicle currently on track to deliver the launch costs and cadence that meaningfully scaling orbital data centers would require. Competitors are years behind, making SpaceX’s Starship the only near-term path to large-scale orbital compute. SpaceX aims to complete Starship development by late 2026, with several necessary milestones still ahead. If development stays roughly on track, Starship could plausibly hit the cost and cadence required to scale meaningful orbital compute within 3–5 years. However, chip production may become the limiting factor by this point, rather than launch capacity.
The cooling problem is more tractable than commonly assumed. Passive radiators using selective coatings and lightweight carbon fibre panels could achieve ~163–346 W/kg at system level, a 13-28× improvement over ISS-era radiators (~13 W/kg). 5 No radiator at these performance levels has been deployed at the scale an orbital data center would require, but prototype high-conductivity carbon composite panels have demonstrated the material properties required. At these performance levels, thermal hardware is 2-5% of total data center cost, and actually less than what terrestrial data centers spend on cooling over a comparable lifecycle.
If launch costs fall enough, the unit economics could favor space. Solar panels in dawn-dusk sun-synchronous orbit produce roughly 3–5× the energy of the same panel at a good terrestrial site. 6 Space-based solar becomes cheaper than the best off-grid terrestrial installations once launch costs drop below roughly $250/kg using Starlink -like solar arrays. At a launch cost of $50/kg (corresponding perhaps, to a Starship with full reuse as reliable as Falcon), space solar could fall to between $25–45/MWh, making it cheaper than any current terrestrial option available today. 7 Beyond the symmetric cost of chips, launch cost is the dominant line item for ODCs while power and op-ex dominate terrestrial costs but would be near zero in space.
The inability to do maintenance would be a large cost. Chips often fail and are swapped out in today’s data centers but a dead chip in an ODC would remain dead, wasting the parts of the supporting infrastructure (power, cooling) and diminishing overall compute. We model this below as a 9% annual bleed causing about 40% overbuy of launch and non-chip hardware over the data center's lifetime. 8 Below $100/kg launch cost this might net out against other savings from ODCs but this is a significant uncertainty since the actual rates of chip failure for ODCs could be higher or lower.
All-things-considered we think that, absent transformative AI, orbital data centers probably won’t make up a meaningful fraction of compute before 2030, but it's credible that space could house much or even the majority of compute buildout throughout the 2030s.
The core of the economic case is energy. A solar panel in a dawn-dusk sun-synchronous orbit 9 receives near-continuous direct sunlight, producing roughly 3 to 5 times the energy of the same panel at a good terrestrial site. 10 Space-based panels can also be lighter and cheaper than their ground counterparts, since they need no weatherproofing, grid inverters, or heavy mounting hardware. 11 But launching solar panels to orbit adds a fixed overhead, and at current prices, space solar doesn't pencil out. The question is: at what launch cost does space solar become cost-competitive with Earth-based power, and are those launch costs feasible within a few years?
To get a first sense of the answer, we can look at the levelized cost of energy (LCOE): the total cost of building and operating a power source, divided by its total lifetime energy output, expressed in dollars per megawatt-hour. This lets us compare across very different power generation technologies on equal footing. On this basis, space solar reaches cost parity with the cheapest present-day terrestrial energy sources at around $50/kg. 12
Space solar LCOE compared to terrestrial generation technologies. Dashed curves show space solar LCOE as launch cost falls from $550 to $10/kg. Horizontal lines show median LCOE for terrestrial technologies today (unsubsidized). We model two space solar configurations, current starlink-like efficiency as an upper bound on cost based on current technology (blue line), and an optimized lightweight solar array pushing the limits of packing efficiency and construction as a lower bound (purple line). 13
These LCOE figures, however, reflect the cost of energy at the point of generation; they don't capture what it actually costs to supply continuous, reliable power to a large data center operating off-grid. This distinction matters increasingly for hyperscale data centers, which are facing grid interconnection queues that are pushing operators toward building their own independent microgrids. A terrestrial solar facility supplying power 24/7 requires substantial battery storage and backup generation capacity to cover nights and weather interruptions. These are costs that aren’t accounted for in the LCOE figures shown above but would be a core need for off-grid data centers. When we include those system-level costs for the off-grid data center model, the picture for space solar actually looks better. 14
We estimate that in-space solar (like that used by Starlink) reaches cost parity with terrestrial solar at around $250/kg in launch costs, which seems achievable in 1–2 years from the time of writing (early 2026).
Solar Cost Crossover. Earth-to-space cost ratio for powering 1 kW continuously via solar panel as a function of launch cost. This compares space-based solar against two terrestrial baselines: a bullish solar+gas microgrid (solid) and a 100% renewable off-grid facility (dashed) with crossover points marking where space becomes cost-competitive. The lines give ratios of the cost of Earth over the cost of space solar. The blue lines compare the currently flown starlink-like array as a conservative estimate while the purple shows more lightweight, high performance panels for an upper bound. 15
Beyond energy costs, we'd like to know how ODCs compare to terrestrial data centers on cost all-told, line-item for line-item. On the build side, both architectures share compute hardware as their dominant cost, but diverge elsewhere: terrestrial facilities require power, cooling systems, physical buildings, land, and permitting, while ODCs replace these with space-specific hardware — solar panels, thermal radiators, satellite bus, and launch. On the operational side, terrestrial centers face ongoing energy bills, staffing, maintenance, and taxes, whereas ODCs largely eliminate these recurring costs by generating solar power freely in orbit. The operational liability for ODCs, however, is the inability to perform maintenance: hardware failures (routine in today’s data centers) would then result in permanent infrastructure loss. We think the business model for ODCs would be more fire-and-forget, accepting losses as they come and launching replacement satellites to compensate for in-orbit hardware failures. We model these failures as costing ~9% compute loss per year, based on estimates for chip death, radiation induced latchup, and mechanical failures detailed in subsequent sections.
| Earth | Space | |
|---|---|---|
| Build costs (CapEx) | Compute, Power (Solar+Batteries+Gas), Cooling Units, Building/Facility, Land, Permitting | Compute, Solar panels, Radiators, Satellite bus & structure, Launch |
| Operational costs (OpEx) | Energy, Staffing/Maintenance, Taxes | Replacement satellites (to compensate for chip bleed due to hardware failures) |
We can try to forecast total costs by modeling six scenarios (three for Earth and three for space). The three Earth scenarios span grid-connected construction with conventional cooling, off-grid microgrids with full battery autonomy, and a hybrid case using on-site solar with gas backup to bypass grid interconnection queues entirely. The three space scenarios are anchored to plausible Starship launch cost trajectories — conservative ($250/kg), median ($100/kg), and bullish ($50/kg) — with corresponding assumptions on thermal management, and server mass reduction. 16 Across all scenarios, IT hardware is held constant at $25.6B per GW, isolating infrastructure and operational costs as the key variables. For Earth, non-compute build costs are amortized over 20 years while orbital infrastructure is phased out after a 5-year lifecycle (matching current Starlink lifecycles). 17
| Scenario | Per 5 yr Cycle ($B) | Notes |
|---|---|---|
| Earth Grid | 37.6 | Grid-connected, conventional cooling |
| Earth Microgrid (Conservative) | 42.5 | Off-grid microgrid, full battery autonomy |
| Earth Microgrid (Bullish) | 36.8 | On-site solar + gas backup, bypasses grid queue |
| ODCs (Conservative) | 48.2 | $250/kg launch |
| ODCs (Median) | 35.0 | $100/kg launch, 17% mass reduction over terrestrial |
| ODCs (Bullish) | 30.3 | $50/kg launch, 54% mass reduction over terrestrial |
Our estimates suggest ODCs could approach cost parity with terrestrial builds at around $100/kg — a 15× reduction from today's ~$1,500/kg. Whether that's achievable, and on what timeline, depends largely on Starship's reusability trajectory, which we examine next.
The scalability of orbital data centers, and indeed a wide range of economic activity in space, depends on one vehicle. SpaceX's Starship seems to be the only launch system that could deliver the combination of low cost, high cadence, and large payload capacity that orbital data centers would require if they are to make up a meaningful fraction of additional data center capacity anytime soon.
As of early 2026, Starship has flown 11 times . It is a two-stage rocket: the bottom half (a booster called Super Heavy) launches the top half (the Ship) to orbit, then flies back to the launch site where a pair of mechanical arms on the tower catch it mid-air. This catching manoeuvre is now semi-routine, and SpaceX has reflown one booster, demonstrating that the hardware can survive reentry.
The next challenge is reusing the Ship, the upper stage which actually reaches orbit. After three consecutive failures in early 2025, the last two flights achieved controlled reentry and ocean splashdown , but the Ship has not yet been caught or flown twice. A recurring obstacle is the heat shield: reentering the atmosphere subjects the underside to temperatures exceeding 1,400°C, and the vehicle needs to survive this without needing expensive refurbishment. Elon Musk has called designing a reusable heat shield the "biggest remaining problem" for Starship. 18
China's Long March 9 , designed for 150 tonnes to LEO, is not expected to fly until 2030 to 2033 . ESA, JAXA, and ISRO have no comparable programmes. New Glenn , Blue Origin's heavy-lift vehicle, landed its first booster in November 2025 but carries just 45 tonnes to LEO versus Starships 150-200 tonnes, with a super-heavy 9×4 variant (70+ tonnes) announced for perhaps 2027. Notably, Blue Origin investigated upper-stage reuse from 2021–2025 but shelved the project , meaning without full reusability, there is no path for New Glenn to approach the launch costs that even partial Starship reusability enables. As best we can tell, these are the closest competitors to Starship and they appear to be 3-5 years on key milestones.
We estimate launch cost across several reusability scenarios, we assume the build cost remains constant at $90M build cost per Starship, and $5M in per-flight operations. 19
| Scenario | Booster life | Ship life | Amortized build | Ops / refurb | Per-flight cost | Payload (t) | $/kg |
|---|---|---|---|---|---|---|---|
| Expendable | 1 | 1 | $90M | $5M | $95M | 200* | ~$475 |
| Booster reuse | 10 | 1 | $6M + $30M | $5M | $41M | 180* | ~$228 |
| Full reuse (early) | 10 | 10 | $6M + $3M | $5M | $14M | 150 | ~$93 |
| Full reuse (like Falcon) | 25 | 25 | $2.4M + $1.2M | $4M | ~$7.6M | 150 | ~$51 |
| Full reuse (better than Falcon) | 50 | 50 | $1.2M + $0.6M | $3M | $4.8M | 150 | ~$32 |
| Full reuse (bullish) | 100 | 100 | $0.6M + $0.3M | $2M | $2.9M | 150 | ~$19 |
*Expendable ships offer greater payload to orbit since they don’t need fuel for landing, while grid fins and whole systems can also be removed.
The number of reuses a given Starship will be rated for is a variable on cost. We don’t know how many reuses to expect from Starship but a good point of comparison would be with SpaceX’s previous rockets. SpaceX’s best with the Falcon rocket is 33 reuses while typical numbers seem to be around 15 reuses . We set our median launch cost at $100/kg, corresponding to ~10 reuses and our bullish scenario launch cost at $50/kg corresponding to ~25 reuses. Notably, both of these launch costs are comfortably below the ~$250/kg threshold when space solar wins out over terrestrial power generation and based on our model it is at around $100/kg that ODCs could reach overall cost parity with terrestrial data centers. The (practically irreducible) floor for launch cost is set by propellant (roughly $900K per launch for 4,500 tonnes of liquid oxygen and methane) plus ground operations (perhaps $1.1M), giving about $13/kg at 150 tonnes to orbit. Though recent updates from SpaceX claim the eventual Starship (Block 4) will be capable of delivering 200 tonnes to orbit which would hypothetically set the mature floor for Starship around $10/kg.
Given the above, it looks plausible that space-based data centers could become cost-competitive with terrestrial data centers beyond ~10 reuses per Starship. If this is right, a further question is how long it would take for ODCs to actually become a meaningful fraction of total compute. We’ll look at the main inputs to launch cadence and outline what a slow and fast scenario could look like for scaling orbital compute.
The turnaround time for each Starship. This is the time to catch, restack, load cargo and refuel the Starship before launching again, where SpaceX targets 3x/day. SpaceX’s current record turnaround is 9 days, but this being with Falcon rather than with a fully reusable vehicle. As for a rough lower bound: commercial airlines typically run 3-7 flights a day, with turnaround times of perhaps 1–2 hours. Still the limits of reusable heat shields are not known and the floor for turnaround might be much higher.
We’ll use a 1x/day turnaround for our fast scenario and a 6 day turnaround for our slow scenario.
The time to construct new rocket factories and ramp their production. SpaceX has two Gigabay production facilities under construction (Boca Chica and Roberts Road, FL), both targeting completion by end 2026, but it's too early to tell what growth rates will be based on this. An apt comparison could be to Tesla, which opened 5 Gigafactories between 2016 and 2022, a pace of roughly one new major factory every 14 months. Construction times also fell sharply over this period: Giga Shanghai was completed in just 168 working days , roughly a third of the typical automotive factory build time.
We’ll assume SpaceX builds 1 new factory over the next ~4 years of Starship R&D for our slow scenario and that SpaceX builds 2 new factories over the next 2 years in our fast scenario.
The number of rockets/factory/year produced. SpaceX has discussed an eventual goal of producing ~365 Starships per year (~1/day). As a useful anchor, Boeing’s mature 737 program produces on the order of ~38–42 aircraft per month today, though this rate is currently capped by the FAA following quality issues, and historically has reached higher levels. An airliner contains on the order of hundreds of thousands of parts, whereas Starship’s stainless-steel architecture is relatively simpler. However, Boeing benefits from decades of production tooling and supply-chain maturity. SpaceX’s Falcon-9 ramp could also be illustrative. Early production went from about 25 rockets in 2020 to 165 by 2025.
We’ll assume SpaceX can build ~1–10 rockets every 2 months from a given factory floor for our slow scenario or ~1–20 starships per month for our fast scenario. 20
Musk has claimed ODCs will likely be the cheapest way to generate AI compute in 2.5–3 years , though a more calibrated adjustment on SpaceX’s intentionally ambitious timelines could be 3–5 years. Below we give two example scenarios, one conservative and one bullish. 21 In this way we try to give an upper and lower forecast for how quickly compute could be launched to orbit. Notably, there are relatively few good anchors for these timelines, so we’re especially uncertain about these estimates. Still we’re showing our best-guesses, for the sake of concreteness.
Slow ODC takeoff scenario. In this scenario, Starship reaches rapid reusability mid-2030 having suffered many setbacks. SpaceX builds just one additional gigabay over the ~4.5 year development cycle of Starship, then begins to ramp production. By 2031, 3 gigabays have produced a total of 18 Starships but turnarounds are slow, requiring 6 days of downtime after each flight. The first meaningful tranche of orbital compute is deployed throughout 2031 and totals around 1,095 launches amounting to roughly 4 GW of orbital compute. Meanwhile forecasts expect perhaps 100 GW of terrestrial data center buildout by 2030. Thus, orbital compute makes a negligible fraction of total compute until perhaps later throughout the 2030s.
Fast ODC takeoff scenario. In this scenario, Starship begins deploying Starlink V3 satellites in 2026 and reaches rapid reusability by 2027. SpaceX then builds out 2 new gigabays by EOY 2027 and ramps production variously across 4 facilities, producing at least 48 Starships by early 2028. By this point Starships are produced at one Starship per month on average, as contrasted with Boeing's ~38 planes per month or Tesla’s production of ~10,000+ cars per month from a single factory floor. Throughout the year, the growing fleet manages a total of 10,000+ launches. By EOY 2030, up to 100GW of orbital compute is operational. 22
On Earth, data centers stay cool by blowing air or pumping liquid coolant over hot chips, and then venting that heat into the atmosphere. Google and Meta, which have pushed cooling overhead to best-in-class levels, dedicate roughly 7–10% of their electricity and perhaps 15–20% of facility capital expenditure to thermal management. 23
In the vacuum of space, there is no air, so another method is needed. Liquid cooling can be used to pump heat away from chips, but that heat must ultimately be radiated away by emitting infrared light into the void. The physics governing this (the Stefan-Boltzmann law ) requires a large surface area to shed a modest amount of heat, so first-pass estimates suggest you'd need prohibitively large radiator panels to cool the heat generated by just a few GPUs. 24
On more careful analysis, however, the cooling problem seems both less important and more tractable than it first appears. Configured in the right way, it looks like relatively cheap and light radiators will be sufficient.
The radiators on the International Space Station, designed in the 1990s, manage an efficiency of about ~13 W/kg . But there has not been significant commercial pressure to optimize space radiators, since they’re currently a small fraction of the cost to launch and operate satellites. Thus, we expect some fairly low-hanging fruit for efficiency improvements. Compute modules would also escape needing the sprawling cooling loops and cold plates the ISS uses to sustain humans, and could run at much warmer radiator temperatures (panels at 25–45°C) than ISS radiators (whose ammonia outlet is controlled to about -40°C to stay above the freeze point), exploiting the T⁴ dependence in the Stefan-Boltzmann law.
A flat panel coated with standard off-the-shelf reflective paint radiating from both sides rejects a surprisingly large amount of heat. 25 Built from lightweight carbon fibre composites with fluid loops to carry heat from the chips to the radiating surface, these passive radiators achieve roughly 163 W/kg at the system level in our estimates, a 13× improvement over ISS heritage technology. 26 NASA Marshall's testing of High-Conductivity (Hi-K) carbon-composite radiators has demonstrated specific powers roughly 7× that of conventional metal fins (implying system-level specific powers of order ~90 W/kg at moderately elevated temperatures, using ISS-style metal-fin baselines), with hardware built and tested on the ground.
Crucially, the power rejected by a radiator scales to the fourth power of its temperature, per the Stefan-Boltzmann law . So moving from the ISS’s human-friendly temperatures, to industrial-grade rejection temperatures, allows ODCs to get notably more efficient at radiating heat.
Running a coolant loop at 25–45°C instead increases heat rejection per square metre by 2.7 to 3.5×. The practical ceiling is set by GPU thermal margins: modern chips throttle at around 83–85°C, and direct liquid cooling typically runs 15–25°C below the chip, capping useful coolant temperatures at perhaps ~60°C. At 25–45°C, the physics is sufficient to reduce radiator mass substantially. Lastly, this same T4 scaling means cooling could become even more efficient by actively pumping heat away from the chips and towards the radiators; though on our first-pass analysis, this looks like more hassle than it’s worth. 27
If this is correct, thermal management looks like a modest cost. In our conservative scenario, radiator hardware is about 14% of system mass and ~5% of total cost. In our median scenario, given a warmer operating temperature, it drops to 8% of mass and roughly 2% of cost. Strikingly, this is less than what terrestrial data centers spend on cooling over a comparable lifecycle. 28
That said, the kind of radiators we’re speculating about haven’t been flight proven, so we should also consider the more conservative scenario. Our estimates extrapolate from this baseline using thinner panels and higher operating temperatures, which is why we reach 163 W/kg and above. The most pessimistic assumptions we’ve seen have radiators accounting for as much as 60% of system mass. When launch costs are high, this is clearly a big deal. For example, if Starship indeed has a $250/kg launch cost because it is only partially reusable and there can be no improvement on the 1990s radiator design, then this would amount to an increase of over $8B per giga-watt. Compare this to ~$3B spent on cooling Earth-side. At our median launch cost $100/kg or bullish case of $50/kg this worst case scenario becomes a $3.5B increase or $1.7B increase respectively. This underscores how the most sensitive parameter by far for orbital data centers is launch cost. Making ODCs economical will require improving on existing radiator designs, but we conclude that cooling is unlikely to be a major bottleneck to ODCs becoming economically feasible, if they ever do.
A data center in orbit also faces a number of other difficulties that a terrestrial facility does not. We work through the most important ones here. Some of these appear manageable; others are unproven and uncertain.
We think chip failure and inter-satellite bandwidth are the hardest hitting challenges for ODCs. If solutions can’t be found, dead infrastructure due to chip failure could result in something like a 38% premium on non-IT infrastructure and launch costs (accounted for as ‘chip bleed’ in Figure 1); while low bandwidth may mean orbital data centers are useful only for inference and not competitive in frontier training runs.
On Earth, GPU failures are routinely handled. Meta's 16,384-GPU H100 cluster experienced 419 hardware failures in 54 days (roughly one every three hours), but a technician simply swaps the dead card while the training run continues via checkpointing. 29 In space, this kind of maintenance is not feasible for the foreseeable future. Failed chips stay failed, and you bleed compute from day one.
How bad is this? Based on Meta's observed annualised failure rate of roughly 9%, a space data center would lose about 38% of its initial compute over a 5-year lifecycle. 30 We accounted for this in the figures above by applying a 38% cost increase to all non-chip hardware, since a terrestrial operator would be buying the same replacement chips but could install them without losing any infrastructure. 31
That’s a significant penalty. It might be partially offset by factors favouring the space environment (i.e. no dust, no humidity, after launch, no temperature cycling from HVAC), but additional space-specific failure modes (radiation-induced latchup, thermal cycling from eclipse periods for non-SSO orbits) could push the rate higher. The net effect is uncertain, and we think this one of the larger unknowns regarding orbital data centers.
How you physically arrange compute in orbit matters a great deal, particularly for training workloads that require fast communication between GPUs.
At the modest end, individual “smart” satellites could carry a few kilowatts of onboard compute, for example enhanced Starlink V3 nodes doing inference , caching, or on-orbit data filtering. Starcloud-1 , a 60 kg test satellite launched in 2025 carrying an Nvidia H100, represents early hardware in this category. These are deployable today in principle, but the compute per node is small.
Illustration of two types of orbital data center architecture, the optically linked constellation model (most like today’s space tech) and the modular station model (most like traditional data centers).
At the ambitious end, two broad approaches are being pursued for data-center-scale compute, each with distinct tradeoffs.
Constellation model (SpaceX, Google, Blue Origin) . A fleet of individual satellites, each equipped with GPUs, orbiting independently. This leverages SpaceX's existing mass-production capability and could be relatively quick to deploy. The unsolved limitation is bandwidth: today's commercial inter-satellite optical links deliver on the order of 1 to 100 Gbps over thousands of kilometres, which is orders of magnitude short of what tightly coupled ML training clusters require. Google's Project Suncatcher proposes packing satellites into tight clusters (kilometre-scale or sub-kilometre-scale separations rather than thousands of kilometres) and using optical links similar to terrestrial fibre technology. At short distances, the physics of free-space optics improves somewhat, and Suncatcher suggests bandwidths on the order of 1–2 Tbps per transceiver pair may be achievable. This is an interesting idea, but it shifts the challenge to maintaining dense satellite formations with precise pointing and tracking.
Modular station model (Starcloud) . A central spine structure with docking ports, to which compute modules (roughly 40 MW each) are launched and physically attached, connected to a large solar array. This sidesteps the bandwidth problem entirely, since modules are physically connected. However, it is further from what existing manufacturing and launch capabilities can deliver so this is a longer term vision, and introduces engineering challenges around structural integrity at scale. We found Starcloud's published cost estimates to be overly optimistic compared to our assessment, though it’s possible Starcloud has one or more clever engineering tricks in mind while we did not try hard to optimize beyond today’s space hardware. The concept may also become more feasible after continued investment in space-based infrastructure.
The implications of the bandwidth constraint depends on whether ODCs are being used for training, or inference:
Inference is a natural fit for orbital compute. Modestly equipped satellites could serve inference workloads where each request is independent. Latency from LEO to the ground is also modest at a few milliseconds.
Training looks harder. Frontier runs synchronize gradients across thousands of GPUs at every step, demanding sustained bandwidth between nodes that dwarfs current inter-satellite links. Even Suncatcher's proposed 1–2 Tbps, if achieved, would need to connect enough satellites to match the bisection bandwidth of a terrestrial cluster. The modular station model avoids this by physically connecting modules, but at the cost of in-space assembly no one has yet attempted.
Radiation is substantially higher in orbit. Which causes two distinct problems: cumulative damage that permanently degrades chips over time, and transient bit flips that can corrupt data in memory. 32 At the altitudes relevant to the first orbital data centers (around 500-600 km), both effects appear manageable based on the limited testing data available, though relatively little research exists. We don’t include any loss of compute efficiency due to errors or chip loss due to radiation damage in our model.
Cumulative damage appears to be well within chip tolerances. Google tested their Trillium TPU and found no hard faults up to 15 krad , roughly 20 times the expected 5-year shielded dose at 550 km. 33 Shielding is cheap relative to what it protects. 34
Transient bit flips are more nuanced. Standard error-correcting codes handle virtually all single-bit errors, with uncorrectable errors estimated at roughly 0.01 to 0.1 per GPU per year. 35 For inference workloads, this seems likely to be negligible: model weights are read-only, can be periodically reloaded, and neural networks are inherently noise-tolerant. For training, the picture is somewhat murkier. Corrupted gradients might propagate through the model, and a single undetected multi-bit error during a long training run might in principle corrupt a checkpoint. On the other hand, no single node holds the full state during a distributed training run, which provides some natural resilience and errors could later be ironed out over the training run. Also, this may be simple to solve with error correcting codes. Overall, we don’t expect this to be a problem.
Error correcting codes can scale to ensure reliability, at the cost of redundancy. Standard SECDED codes add ~12.5% storage overhead and negligible compute cost, while stronger chipkill-class or symbol-based codes increase overhead by tens of percent to tolerate multi-bit or device-level failures. It seems likely that reliability can be ensured at low cost; but there is as yet little data, and we aren’t too confident.
Operating at scale in low Earth orbit introduces several related risks around debris, collisions, and crowding. Currently these issues are manageable, but they’ll grow with the scale of ODC deployment.
Debris and micrometeors pose a modest threat. Starlink's empirical record shows zero confirmed failures due to debris strikes across roughly 27,000 satellite-years of cumulative exposure. 36 SpaceX performs over 300,000 autonomous collision avoidance manoeuvres per year fleet-wide (around 35–40 per satellite per year), a capability directly transferable to space data center modules. And per-satellite risk doesn’t grow with the overall scale of ODCs; so we think this isn’t a meaningful issue.
Orbital crowding is a more systemic concern. SpaceX's FCC filing proposes up to one million satellites, roughly 50 times the current total number of satellites across all orbits — concentrated in sun-synchronous orbit, one of the most debris ridden orbital regions. 37 Today's debris tracking infrastructure and traffic coordination experience suggest this could be feasible. However, past collisions and anti-satellite tests have produced debris fields lasting decades 38 , and adding satellites at this scale raises the risk of Kessler syndrome, a runaway cascade of collisions that could render orbital bands unusable. We don’t think this is likely to be a major blocker to placing a meaningful fraction of AI compute in orbit, but it will require more effortful and sophisticated traffic management and eventually cleanup tech (see ‘ Space Debris and Launch Denial ’.)
No mass-production line for space-rated data center hardware exists today, and building one would take time and investment. SpaceX has demonstrated that space hardware can be manufactured at volume: Starlink launched roughly 2,500 satellites in 2025, and much of the production infrastructure (clean rooms, testing facilities, automated assembly) could in principle be adapted. Some commentators describe the path from here to orbital data centers as straightforward, essentially a matter of fitting more compute onto existing satellite platforms.
We think this understates the challenge. Communication satellites and compute-dense data center modules have different engineering requirements: higher heat loads requiring new thermal integration, power distribution architectures serving dense GPU arrays rather than modest communication payloads, and compute packaging at densities that have not yet been attempted in space. On the other hand, we’ve argued that viable launch-costs are at least 2-3 years away, and at least 3-5 years from reaching scale. Given those lead times, and the several companies facing massive economic incentives to solve these challenges, we think building out the ODC component supply chain is unlikely to be a major bottleneck.
The case for orbital data centers rests on accepting one of two distinct claims: that terrestrial buildout may eventually hit limiting constraints (land, permitting, grid capacity, water, community opposition), or that space may offer flatly superior unit economics once launch costs fall far enough. Both could be true simultaneously. In scenarios where the economics are roughly competitive rather than clearly favouring one side, several non-cost factors could tip the balance.
First, there is a straightforward strategic case for SpaceX in particular to invest in orbital data centers even at an initial loss: once Starship achieves full reusability, SpaceX will likely enjoy a multi-year window as the world's sole low-cost heavy-lift provider, and locking in the orbital data center market during that window — proving the architecture, building the supply chain, securing orbital slots — would create a structural moat that could persist long after competitors develop comparable vehicles.
As discussed, one key factor will be the speed at which new data centers can be built and launched, versus constructed on Earth. Permitting and regulation play a large role here. If the regulatory environment and build times on Earth look roughly like they do today, space may soon be the fastest place to build, whether or not it’s cheaper.
Traditional data centers face several regulatory and supply constraints but none are currently binding. On the terrestrial side, several frictions can slow deployment. Grid interconnection queues stretch to 5 years in many US regions. The most promising workaround appears to be on-site microgrids (solar, battery, and gas turbine systems that sidestep the grid queue entirely), combined with prefabricated modular construction. 39 This approach can compress lead times significantly, as xAI demonstrated by bringing its Memphis facility online in 122 days. 40 Community opposition has also become a factor, with one industry tracker estimating over $98 billion in US projects blocked or delayed by local resistance as of mid-2025. 41 In our cost comparison, we benchmark against this off-grid microgrid strategy as the most competitive terrestrial alternative, using one case with solar+gas, and another solar+battery storage for continued scaling in case gas turbine bottlenecks bite. Altogether, permitting and regulatory constraints don’t currently seem binding, but they are increasingly becoming a headache.
Orbital data centers could scale fast, but only if the regulatory regime looks as favorable in a few years as it does today. Orbital data centers sidestep terrestrial permitting entirely. The advantage of building satellites seems to be that you only have to deal with one regulatory regime once, and then you can launch satellites continuously on that basis; whereas every single terrestrial AI data center must be shepherded through many layers of regulatory approval. However: current FAA site approvals cap Starship at 145 launches per year This is well below what meaningful orbital buildout would require, amounting to perhaps ~0.5 GW/yr launched. 42 But we think it’s more likely than not that this doesn’t block ODC buildout, especially because the current US administration is actively favourable to commercial space. Two recent executive orders, Enabling Competition in the Commercial Space Industry (August 2025) and Ensuring American Space Superiority (December 2025), direct agencies to eliminate or expedite environmental reviews for launch licensing and to bolster the commercial space industry. Orbital deployment runs through a small number of federal agencies (FAA and FCC) moving to reduce friction, while terrestrial buildout must navigate a patchwork of local authorities. Of course, regulatory environments change. If the economic or strategic value of terrestrial data centers become politically salient, permitting could be expedited, or waived-permitting zones could be set up. On the other hand, even if the current FAA launch cap is lifted, raising by the order of 100x needed to compete with terrestrial data center buildout could spark new political opposition. And although the current US administration is sympathetic to space industry, a new admin and hence new FCC chair and FAA head may be more inclined to scrutinise SpaceX’s requested ODC waivers.
Another key consideration is physical and cyber security, especially as AI technologies become more strategically valuable. Orbital data centers would effectively eliminate physical access and insider threats, but they would become unusually easy to observe and destroy with anti-satellite weapons. As such, we conclude that orbital data centers would be substantially harder to exfiltrate data from, but easier to destroy.
For AI model weights, where theft is the primary concern, orbital hosting offers a genuinely stronger posture. For critical infrastructure where availability matters most, fragility against space weapons is a bigger liability.
ODCs eliminate several of the cyber attack vectors, but may still be vulnerable. RAND's framework for securing model weights identifies attack vectors for model security, with insider threats and physical access among the hardest to mitigate. No existing facility achieves the highest tier (SL-5, robust against top-priority nation-state operations), and the SL-5 Task Force estimates it would take at least five years and substantial government support to reach. ODCs remove the physical access and insider threat categories almost entirely, i.e. no humans on site, no USB ports, no maintenance visits. The ground segment remains the weak link however. Uplink stations, mission control, and the pre-launch supply chain are all vulnerable to the same cyber and supply chain attacks that threaten terrestrial facilities. The 2022 Viasat hack , which disabled thousands of modems across Europe via a single ground-segment exploit, illustrates how ODCs would not eliminate the threat of cyber attacks. 43
Jamming can limit communication with the ground, but there are defenses. Russia deployed battlefield jammers against Starlink in Ukraine in 2022, but SpaceX responded with software updates for hopping frequencies, largely neutralising the disruption. Iran's more sophisticated 2026 campaign combined GPS spoofing and multi-band RF jamming (using Iran's Cobra-V8 electronic warfare system , comparable to Russia's Krasukha-4), driving packet loss above 80%. SpaceX again adapted, reducing loss to around 10% in some areas, but this time they did not fully restore service. 44
The implications of kinetic strikes are severe. Presently, Anti-satellite weapon (ASAT) costs (tens of millions each) exceed satellite replacement costs (low millions each), and each intercept generates debris threatening the attacker's own assets (and international uproar). However, a sufficiently reckless actor (or an actor with little to lose in terms of space assets) could threaten to release debris in an orbital shell, taking out many data centers at once. This possibility argues for stronger international norms against kinetic ASAT weapons, which the US has endorsed via a 2022 moratorium on direct-ascent testing, but arms control negotiations around ASAT weapons have been mostly gridlocked in recent years. 45
EMP and nuclear ASAT weapons are possible, but drastic. A nuclear detonation in orbit might disable or destroy a number of satellites or even degrade an entire shell via artificial radiation belts. But this would also affect every nation's satellites indiscriminately, risk all-out Kessler syndrome, clearly violate the Outer Space Treaty, and likely trigger forceful retaliation. It is the orbital equivalent of salting the earth.
Close-range means of disabling satellites avoid debris but would require significant investment to scale to disable whole constellations. Both China, the U.S., and Russia are developing co-orbital vehicles capable of approaching satellites for inspection or close-range destruction, and the DIA assesses that China is actively pursuing directed energy weapons for counterspace applications, including high-powered microwave systems that could disable electronics without generating debris. The offense-defense balance at the constellation level appears to favour the defender, since each engagement requires dedicated orbital manoeuvring while the defender launches replacements in batches, but the margin depends on the attacker's willingness to invest in dedicated counter-space capability at scale. As for co-orbital exfiltration: ODC satellites can be designed with no docking ports, no external data interfaces, and no removable storage, we think, making physical data extraction fairly infeasible.
The pre-launch supply chain and ground-side connections remain a vulnerability but may be easier to secure than Earth-based data centers. Satellites must be assembled and integrated on Earth, exposing them to insider and supply chain threats that RAND's SL-5 framework is designed to address. A possible mitigation could be to launch satellites "empty" and train in space or upload weights via encrypted link after reaching orbit, then ensure the operational model never requires weights to be downlinked. 46
Orbital data centers look more viable than we expected going in and the case rests primarily on launch cost. The engineering challenges seem significant but none appear intractable. Commercial off-the-shelf solar, passive radiators, and standard error-correcting codes seem sufficient for a baseline architecture. We expect limited demos and shipments of compute to orbit in the coming years but our best estimate is that orbital data centers are unlikely to represent a meaningful share of compute before 2030. They might scale quickly thereafter however, and are more likely to be bottlenecked by chip production rates rather than by launch cadence. A generally important dynamic is that terrestrial data centers likely face headwinds that worsen as compute scales up while orbital data centers face constraints that relax with scale.
| Factor | Terrestrial Data Centers | Orbital Data Centers | Favors |
|---|---|---|---|
| Cost per GW | Lower today | Higher today; lower with Starship and investment | Earth today; Space later |
| Frontier training | Well suited | Potentially bandwidth-constrained | Earth |
| Inference | Well suited | Well suited | Neutral |
| Cooling | Mature but costly | Immature, likely modestly cheaper at scale | Neutral |
| Reliability / maintenance | Repairable and well understood | No practical servicing; true failure rates uncertain | Earth |
| Permitting / local opposition | A sizable and likely growing burden with scale | Currently very favorable; opposition may grow with orbital congestion | Space |
| Land use | Fairly small footprint | Minimal terrestrial footprint | Space |
| Carbon / local environmental burden | Can be low in principle, but likely depends on gas-backed buildout | Favorable vs gas-backed terrestrial buildout | Space |
| Security from exfiltration | Hard; insider and physical-access problem | Stronger | Space |
| Security from destruction | More robust | More vulnerable to counterspace attack | Earth |
| Long-run scaling | Earth-bound constraints tighten with scale | Can scale nine orders of magnitude higher than Earth ceiling | Space |
All in all we think a transition to space-based compute is credible and could happen soon but almost surely not before the decade is out. There are a few key uncertainties which we expect to get answers for within the next few years. What would need to be true for ODCs to become a substantial fraction of total compute?
Starship would need to achieve rapid reusability, and probably hit launch costs at or below $100/kg
The FAA would need to approve increases in annual launches, likely requiring new launch sites. The current 145-launch ceiling for Starship would need to increase at least 35-fold, plausible under the current administration's posture, but substantial.
Chip failure for ODCs would need to be comparable to Earth-based data centers. Early ground testing is encouraging, and we account for ~9% per year compute bleed in our cost breakdowns, finding space competitive at low launch cost despite this steep penalty. NVIDIA's Space-1 chip and subsequent generations may bring improvements; however, true failure rates in orbit are unknown and could be much worse than we estimate.
A space-based architecture with high-bandwidth interconnects for frontier training is demonstrated, or inference demand alone justifies the investment. Without high bandwidth interconnects, orbital compute may be limited to inference and loosely coupled workloads, which could be a large hit to the value proposition of ODCs.
Thanks to Margot Stakenborg, Anders Sandberg, Tom Davidson, Max Dalton, Stefan Torges, Linchuan Zhang, Gregory Lewis, Charity Weeden, Madeleine Chang, Jackson Wagner and many other reviewers for helpful comments and discussion.
If you notice an error in our analysis or an important missed consideration we’d love to correct it. Please contact avi@forethought.org with any suggestions or leave a public comment.
Two effects matter. Total ionising dose (TID) causes cumulative charge buildup in transistor oxide layers, leading to threshold voltage shifts, increased leakage current, and eventual device failure. This is largely irreversible. Single event upsets (SEUs) flip bits in memory and registers but leave hardware physically undamaged, and are correctable via error-correcting codes or rewrite.
Altitude is the dominant variable. Trapped proton flux drops roughly 10× per ~300 km altitude decrease in the low Earth orbit range, where you're on the lower flank of the inner Van Allen belt (which peaks around 3,000–4,000 km). The choice of orbital altitude is critical.
TID reference numbers at different altitudes, assuming 10 mm aluminium shielding:
~150 rad(Si) per year at 550 km sun-synchronous orbit (Google Suncatcher reference case), giving a 5-year mission dose of ~750 rad(Si).
~1–2 krad per year at 800 km, substantially worse.
~50 rad per year at 400 km (ISS-like), more benign.
The limited chip testing data we have suggests comfortable margins at 550 km. Google's Trillium TPU showed first high-bandwidth memory irregularities at 2 krad (2.7× the 5-year shielded dose at 550 km) but no hard faults up to 15 krad (20× margin), tested via 67 MeV proton beam irradiation. NASA tested NVIDIA GPUs at 6 krad with no permanent failures. The key vulnerability appears to be high-bandwidth memory, not the logic/compute die itself. Modern sub-7nm CMOS has actually improved in TID tolerance because thinner gate oxides trap less charge. That said, these are small-sample tests on specific chips, and orbital data centers would deploy hardware at much larger scale than has been radiation-tested.
At 800–1,000 km, the picture looks much less favourable: you'd likely hit degradation thresholds within 1–2 years even with shielding. But shielding is relatively cheap compared to the compute it protects: roughly $100,000 in launch cost (at $250/kg) for a 20 mm shell around the satellite bus, versus ~$9,000,000 for the chips inside.
SEU rates appear manageable, but data is limited. An H100-class GPU in low Earth orbit would see roughly hundreds of raw bit flips per day in high-bandwidth memory. Standard single-error-correcting, double-error-detecting codes handle virtually all single-bit errors. The estimated uncorrectable (double-bit in the same code word) rate is ~0.01–0.1 per year per GPU. Google measured roughly 1 uncorrectable error per 10 million inferences on their TPU, which is operationally negligible. These numbers come from a small number of tests and could look different at fleet scale.
Solar cell degradation
Solar cell degradation depends on which cells you use, and we think commercial crystalline silicon cells are the right choice. Traditional space missions use radiation-hardened triple-junction GaInP/GaAs/Ge cells, which are extremely durable but expensive (roughly $50–100/W). Starlink instead uses commercial off-the-shelf silicon cells similar to terrestrial panels, at a fraction of the cost (roughly $0.20–0.50/W). These degrade faster under radiation, but the cost difference is enormous.
For orbital data centers, we think the Starlink approach is correct. Chip depreciation (new chips deliver 5–10× performance per watt every few years) sets an effective lifespan of roughly 5 years on any given module. Put simply, paying a large premium for solar cells that last 15–20 years doesn't make sense when the rest of the hardware is being replaced on a 5-year cycle.
Triple-junction space-rated cells degrade very slowly. On-orbit data from the Gaofen-3 satellite shows roughly 0.18% per year power loss, or about 1.4% total over 8 years. These cells are designed for 15+ year missions.
Commercial silicon cells degrade significantly faster. Our model uses 8% per year compound degradation, consistent with Lupo et al. (2025) , who report 10–15% Si cell degradation in the first 6 months at ~500 km for CubeSats with minimal coverglass (annualizing into a multi-year compound average near our assumed rate). This gives an end-of-life power fraction of 65.9% after 5 years ((1−0.08)⁵ = 0.659). The array is oversized by 1/0.659 = 1.517× at beginning of life to guarantee rated power at end of life, with the excess energy in early years captured in the LCOE calculation.
The cost savings are roughly two orders of magnitude per watt, which at scale substantially affects the economics.
In principle, the array oversize could be reduced by co-optimizing against chip bleed: since a fraction of GPUs fail each year, end-of-life power demand is lower than beginning-of-life, and the solar array only needs to cover surviving chips at time t rather than the original total. We haven't modelled this interaction however it could offer modest savings.
Other forms of wear
Attitude control is the biggest mechanical reliability risk in typical spacecraft, contributing roughly 20% of all failures. Reaction wheels are the most common failure point due to continuous motor wear, though this is typically on longer timescales (Hubble's lasted roughly 15 years; commercial wheels are rated for 15+ years). Space data center modules would have simpler pointing requirements than a telescope, so this is likely no novel challenge over a 5-year lifecycle.
Batteries face extreme cycling in low Earth orbit (roughly 16 charge/discharge cycles per day, roughly 30,000 over 5 years), but if orbital data centers operate in near-continuous sunlight (sun-synchronous orbit), battery cycling demands drop dramatically.
Starlink uses argon Hall thrusters rated for their 5-year mission life. It seems similar systems could be adopted for space data center modules with comparable reliability profiles.
Space weather represents a tail risk. A handful of satellites (out of roughly 15,000) have been damaged or lost to space weather over the last 40 years, mostly in geostationary orbit, which is far more exposed than low Earth orbit.
Three main effects arrive in sequence after a solar event:
Electromagnetic radiation (X-rays/UV) arrives in roughly 8 minutes and can disrupt sensors.
Solar energetic particles (protons) arrive in roughly 1 hour and cause intense bursts of single event upsets and accelerated cumulative radiation damage.
The coronal mass ejection plasma cloud arrives in 18 hours to days and heats the upper atmosphere, increasing drag on low Earth orbit spacecraft.
The most concrete threat to orbital data centers is atmospheric drag from thermosphere expansion after a coronal mass ejection. In February 2022, a moderate geomagnetic storm caused 38 of 49 newly-launched Starlink satellites to reenter and burn up. Critically, these were at a vulnerable 210 km staging altitude, not their operational 550 km. At operational altitude the drag increase was manageable with active station-keeping.
A severe storm (e.g. a Carrington-class event, estimated recurrence every 150–500 years) could cause several simultaneous problems: a burst of single event upsets potentially overwhelming error correction temporarily, accelerated solar cell degradation, and significant drag increases. In the case of such an event global satellite networks and orbital data centers could power down and orient edge-on in their direction of motion to minimize drag but it is unclear how devastating versus endurable this would be.
We model two space solar configurations, both using commercial off-the-shelf silicon cells (the Starlink approach, not traditional radiation-hardened triple-junction cells). We use 20% cell efficiency (AM0), 1,361 W/m² solar constant, 95% capacity factor (for dawn-dusk SSO), with 8% per year compound degradation over a 5-year design life.
Oversize factor: To deliver 1 kW continuous at end of life, the array must compensate for both capacity factor and degradation:
EOL fraction = (1−0.08)⁵ = 0.6591, oversize = 1/0.6591 = 1.517,
BOL peak power per kW-continuous = 1,597 W.
S1: Starlink V3-class (91 W/kg derated). Back-calculated from Starlink V3 specifications (50,400 W from 554 kg array, 257 m² area). System derating 0.721 (empirical, includes packing efficiency, wiring, temperature, MPPT). Hardware cost: $0.75/W derated (commercial Si + 1.5× NewSpace qual premium). Mass per kW-continuous: 17.56 kg. Hardware cost per kW-continuous: $1,198.
S2: Optimised stripped Si (189 W/kg derated). Component-level build: 0.85 kg/m² cell assembly + 40% structure overhead = 1.19 kg/m² total. System derating 0.828 (better packing on flat substrate). Hardware cost: $0.471/W derated. Mass per kW-continuous: 8.43 kg. Hardware cost per kW-continuous: $752. 47
Similarly, we model two off-grid terrestrial solar setups, calculating the cost to deliver 1 kW continuously as in the space case. We do not add an oversize factor for the Earth case beyond what is needed to overcome the reduced CF and don’t account for solar cell degradation which is less severe than in space, but this somewhat disadvantages space solar.
Baseline A (100% renewable off-grid, $20,307/kW-continuous): Solar at 28% CF, $1.10/W installed, 4,643 W nameplate per kW-continuous ($5,107). Battery storage 80 kWh at $175/kWh ($14,000 or 69% of total). Other $1,200. 5-year LCOE: $463/MWh. Battery storage dominates because 99.9%+ uptime without fossil backup requires multi-day autonomy.
Baseline B (bullish solar + gas turbine, $5,590/kW-continuous): Solar at 32% CF, $0.85/W, 3,500 W nameplate ($2,975). BESS 12h at $125/kWh ($1,500). Gas turbine at $562/kW (EIA 2023 actual, simple-cycle; xAI Colossus uses Solar Turbines Titan 350) with 10% utilization and $153 fuel/O&M. Other $400. 5-year LCOE: $128/MWh.
Battery cost is the largest lever on Baseline A (69% of cost). If we allow for cost reductions to $50/kWh batteries (well below any 2025 projection), crossovers remain above $519/kg (S1) and $1,133/kg (S2). The space advantage is robust because the 95% CF advantage is structural.
Baseline B is less sensitive to battery cost since it leans on gas backup in cases of poor weather (storage is only 27% of total). In general, if building off grid to avoid grid interconnect wait times a reliable backup energy source can give large savings and should be the default for builders. We include Baseline A however, since backlogs for turbines versus the abundance of solar and battery available suggest that it may be the fastest way to quickly scale energy production on Earth.
In vacuum, heat can only leave a surface via radiation. The Stefan-Boltzmann law gives the total power radiated per unit area from a surface at temperature T
A radiator panel in orbit radiates from both sides, but also absorbs energy from three sources: direct sunlight, reflected sunlight (albedo) from Earth, and thermal infrared from Earth. The net power rejected per square meter is:
Where ε = 0.92, α = 0.09 (AZ-93 white paint), S = 1,366 W/m², Al =0.3, and T earth = 253 K. Then given a two-sided radiator at a worst case altitude of 550km, F IR = 0.50, F albedo = 0.25.
| Conservative | Mid / Bull | |
|---|---|---|
| Material | 1.5 mm CF composite | 1.0 mm CF honeycomb |
| Panel areal mass | 2.40 kg/m² | 1.60 kg/m² |
| System areal mass (incl. plumbing) | 3.60 kg/m² | 2.40 kg/m² |
| Operating temperature | 25°C | 45°C |
| Net rejection | 585 W/m² | 830 W/m² |
| System W/kg | ~163 | ~346 |
The environmental comparison between orbital and terrestrial data centers is often billed as favoring space unanimously, but the picture we found is a bit messier. Here we note some points of comparison.
Land use favours space, though orbital slots are a somewhat finite resource too. A solar-powered 100 GW terrestrial buildout would require roughly 5,000 to 10,000 km² of land, primarily for generation rather than the data centers themselves. 48 The same capacity in orbit implies a many-fold increase over today's active population of more than 11,000 satellites. Our guess is that such an increase in the satellite population would be sustainable with some concessions, like by placing satellites in (slightly more expensive) higher orbits to keep congestion manageable. 49
Water consumption is often cited as an advantage for orbital data centers but AI water usage seems relatively minimal. Space is somewhat advantaged with near zero water use. However, even if current data center capacity were scaled 100x in the US, it would likely still account for a relatively small fraction of total US water consumption. Claims about the environmental harms of data centers specifically relating to water use seem somewhat overblown (both in absolute terms, and compared to other environmental harms, like carbon emissions). 50
Carbon emissions favour ODCs over grid-powered terrestrial data centers, but not over renewable-powered data centers. The marginal carbon emitted by building and replacing an orbital constellation is roughly 20 to 45 times lower than the yearly operational emissions of a gas-grid data centre, but only around 2 to 5 times less carbon-intensive compared to off-grid solar with partial gas backup. 51 A fully renewable terrestrial facility would be cleaner still. In fact, for much of the undeveloped desert land where terrestrial solar farms would ideally be sited, the panels could even be a net environmental positive, since shade structures in arid environments increase total biomass and can help reverse desertification.
Stratospheric soot from rockets is negligible at current launch rates but may later become meaningful at the thousands of Starship-class launches required to build a 100 GW constellation, with full replacement every five years. 52 It’s worth noting that Starship is powered by methane and oxygen, which (although not as clean-burning as hydrogen and oxygen) produces less soot than most historical chemical rockets.
Satellite reentry pollution could pose a novel risk, if proven dangerous. Current mega-constellation plans consisting of thousands of satellites would deposit many tonnes of aluminium oxide per year in the stratosphere when deorbiting at the end of their life-cycle. Orbital data centers at scale, e.g. 100 GW imply 30 to 70 times that level, potentially with cascading effects on ozone, mesospheric temperatures, or polar vortex dynamics, according to a growing body of research (see here and here ). 53 If this threat proves credible, it may be necessary to maneuver decommissioned satellites into a graveyard orbit, either by towing them, or requiring them to boost themselves into the graveyard orbit. Towing has been demonstrated, but not at scale; while de-orbiting boosts would increase the propulsion requirements for the whole mission, especially from higher altitudes.
Sex and espionage – two of the world’s oldest professions – have long collided.
We have ourselves a good old fashioned spy scandal. Tabloids around the world are filled with salacious stories, with headlines such as the never-to-disappoint New York Post ’s ‘Huang For Her Buck’ and ‘Huang Huang Bang Bang’ running this week. Readers have been transfixed, as two of the oldest professions – sex and espionage – collide.
The practitioners of espionage – the second oldest profession – always seek to take advantage of a target’s vulnerabilities. An intelligence service seeks to recruit targets based on the ‘MICE’ principle, which includes Money, Ideology, Coercion and Ego as key motivating factors.
So let’s go back to the basic concept of the honey trap. And the history of such honey traps is rich indeed. Mata Hari , a Dutch exotic dancer who was convicted of spying for Germany during the First World War and accused of seducing the French elite, always comes to mind, as her name is synonymous with such techniques. And the famous East German spymaster Markus Wolf used male ‘Romeos’ to entrap West German secretaries during the Cold War. Honey traps are not solely carried out by female ‘sparrows’, but by males as well. The CIA website in fact has many accounts of such cases from the notorious East German Stasi . ‘Felix’ was one of the first ‘Romeos’, who moved to West Germany in the 1950s, and recruited ‘Norma’, a West German government employee, who passed him secrets from the West German chancellery. According to the CIA, 40 women were prosecuted in West Germany during the Cold War for espionage.
The history of honey traps has all sorts of different flavours. The Soviet KGB in the 1950s recruited John Vassall , an employee at the British embassy in Moscow, photographing him in compromising circumstances with men – by later accounts, after drugging him. They threatened him with exposure, and he ended up passing a great many documents to the KGB. And in the 1980s, a US Marine Security Guard at the embassy in Moscow, Clayton Lonetree , fell for a KGB honey trap. He was recruited by the Soviets and passed sensitive information to the KGB.
Do all honey traps work on all targets? Well, not really. Culture matters. The French are a perfect example. In the French documentary ‘The Making of Secret Agents’ , a French intelligence officer known as Nicolas states that the paradox for many French is that extramarital affairs are so commonplace that they provide a hostile service little if any leverage. It is slightly amusing that the threat of telling one’s spouse would result in a simple shrug. The French being the French, maybe other elements of MICE are more appropriate for them.
Here’s a small nugget for intelligence aficionados to chew on: as per opensource reporting, US intelligence is not fond of utilising such honey-trap tactics. No, it’s not because my old colleagues were ‘too woke’ to stoop to such unsavoury measures, a charge I saw recently bandied about on social media. Instead, there reportedly are practical reasons for this. Blackmail doesn’t make for productive long-term agents, many former case officers say. It is far preferable to gain an agent’s trust if they believe they are doing it for the right reasons, for example. Think back to the ‘MICE’ principle. An agent who hated communism , or an agent who needed money for one of his children’s medical bills, is always going to be more productive, more trustworthy, and more likely to remain in place for an extended period of time, rather than someone who is being blackmailed because of sexual proclivities.
Finally, every piece like this needs not just historical context, but a personal story. In the 1990s I was sent to the Balkans on behalf of the US government to help a friendly government in the counter-terrorism arena. This country had a communist past, and thus there were likely several holdovers from the old pro-Soviet era in their intelligence services. Well, leaving my hotel room one day, I walked down the hallway of a five-storey hotel, and lo and behold a door opened to the side of me. In the dead of winter, two young ladies in bikinis asked me by name to come into their room and ‘fix their broken minibar’. I laughed and, while I was impressed by their moxie to take a run at me, their crooked teeth (and my counterintelligence training) gave me enough of a pause to keep on walking. Later on, playing pool with a very senior member of that intelligence service which had just taken a shot at me, I asked what the hell had just happened. My counterpart smiled and said: ‘it’s the old guard, what can we do?’ as he calmly sank the eight ball in the side pocket.
Author
Marc Polymeropoulos served for 26 years at CIA, serving in a variety of operational and management positions in the Middle East before retiring in 2019 from the Senior Intelligence Service. He is a MSNBC on-air contributor, a non resident senior fellow at the Atlantic Council and an expert at the Agora Strategy Institute.
We have spent the last decade convincing ourselves that the cloud is a magical, weightless place. But it isn't. The cloud is a building. It has walls, cooling pipes, and power cables. And sometimes, that building gets too hot.
When a single AWS data center overheated last May, it didn't just take down some servers. It exposed the terrifying fragility of the modern internet. A broken air conditioner in Virginia meant Coinbase went dark, and a single typo in a Cloudflare script made thousands of websites invisible.
We traded the messy, decentralized web for the convenience of a few massive providers. Now, we are paying the price. This is a story about the hidden economics of the cloud, the illusion of resilience, and why the smartest engineers are quietly moving back to bare metal.
#CloudComputing #AWS #Cloudflare #SystemDesign #TechInfrastructure #BareMetal #DevOps #SoftwareEngineering #TechNews #Internet
...more
Why do I have to choose between my web app respecting people’s privacy and it, like… having basic functionality?
When I was working on Cheapskate , I realized after a few weeks that there was a fundamental issue. The app relies on Supabase for the unsexy parts of its architecture: authentication and a SQL datastore. All of it is bog-standard and all of it I happily handed off to be someone else’s problem. To be clear, I love Supabase – if I had to run all that boilerplate myself, I never would have made Cheapskate.
But… the shape of it is wrong. I don’t want to own this data. This is a person’s financial details! Shouldn’t that live with them, and not with me? Is it even possible to make a web app like this, with anything close to the same convenience and functionality (durable, works across devices, shareable with friends) as Supabase allows?
Well, I really wanted to. I spent a lot of time trying. Here are all the things that don’t work:
Besides, all of these options compromise on the data model anyway, being KV or blob storage when all I really want is an API to run SQL queries. You know, like any normal app?
Argh!
Let's say you want to create a system where each server can "join" a network and start exchanging something with other members within that network. How would you approach such a task? You could create a small centralized orchestrator that will accept join requests and handle that for the recipients, but that's not decentralized. What if we want a truly "plug and play" solution without any centralized servers? One such solution is federation .
A good example would be SMTP (the protocol for sending emails). It's mostly decentralized. Anyone can run their own mail server. There is no single central authority that says "yes! this server can have email, but that one? NOOO!". Each server communicates using a well-known protocol and exchanges information server-to-server. You can even call it an "API with known payload schemas", although that is a bit of a simplification.
Let's go with the email thing and start with the obvious. Have you ever considered why email addresses contain an
@<domain>
part? Why can't it just be
my_nick
?
It's necessary to know which domain is responsible for that identity! duh!
That domain plays a very important role in the whole federation exchange.
That's because if you write from your email, let's say
[email protected]
, to
[email protected]
, the sending mail server will take that
y.com
part, do DNS discovery for MX records, connect to the mail server responsible for that domain, and start exchanging messages.
This is the core idea of federation: servers talk to each other directly after some "discovery process". In our small email example, the discovery part would be a DNS lookup for MX records.
Ok, but we came here to create our own messenger protocol, so let's start.
First, we need to gather some requirements like good system (and in this case, protocol) designers.
That should be the basic minimum for our needs. So how do we even start doing it?
Let's start with the easiest, and then move to more complex stuff.
Let's also assume that every server already has some users with registration, login, etc. So we don't spend a million years doing everything from scratch.
We need to enforce that user identity will be like an email.
So
<nickname>@<domain>
, otherwise our federation will not know who to call.
The important thing here is that
[email protected]
is not an email address. It only uses the same shape because the shape is useful. The domain tells other servers where to discover federation metadata.
We could go with, for example,
x.com > adam
,
x.com#adam
, or
adam on x.com
. It's your call.
Now the first real work. Discovery is the part similar to the MX record lookup process mentioned earlier.
We have full freedom on how we want to handle this, so let's do it with a simple file on the server.
For this, we can use the typical
.well-known
directory.
In our case, we can call our protocol
lnchat
(from LearN chat).
This will be our first requirement for the protocol.
Server MUST provide a file under:
GET /.well-known/lnchat.json
Inside we can put the version and other important information that we will craft later in the article. For now, we can go with only the version:
{
"protocol": "lnchat.federation.v1"
}
By the way, it's good practice to always version protocols. It enforces the contract and saves you from a lot of headaches.
With this, servers can check if the servers we want to reach even support our protocol. If yes, they can pull all the necessary information from this one
.well-known
file.
Since we want to have end-to-end encryption, we need client-side encryption keys.
Usually that means one private key that stays with the client, and one public key that the user's server can share with other servers.
The private key MUST NOT be sent to the server as plaintext. If the server can read the private key, then the server can read the messages, and we don't really have end-to-end encryption anymore.
Important: if a server is responsible for publishing users' public keys, a malicious or compromised server could lie about a key. Real end-to-end encryption needs some way to notice that, for example contact key warnings, fingerprints, TOFU, or key transparency.
So we need an endpoint for sharing users' public keys. Every server should implement it as part of our protocol. So let's craft it!
First, let's add information to our discovery file about where to look for the endpoint. This gives every server the ability to choose its own URLs.
It's better not to enforce strict paths here as it may collide with already existing routes on the server.
{
"protocol": "lnchat.federation.v1",
"endpoints": {
"resolve_users": "https://example.com/federation/v1/users/resolve"
}
}
But the
resolve_users
URL could be a different URL on every server.
The
resolve_users
endpoint will be responsible for returning current public encryption keys for users from that server.
Other servers will call it before sending a message, so they know which key should be used for which recipient.
We can craft a schema for this endpoint like this:
{
"protocol": "lnchat.federation.v1",
"users": ["[email protected]", "[email protected]"]
}
Why an array of users and not just one? Let's imagine that it will be used in high-volume servers. We should offer a way to ease the performance. If the server can resolve several users in one request, it will be much more performant - fewer HTTP calls.
And for the response, let's do this:
{
"protocol": "lnchat.federation.v1",
"status": "ok",
"users": [
{
"user": "[email protected]",
"status": "ok",
"key": {
"key_id": "adam-enc-2026-07-a",
"public_key": "base64url-raw-32-byte-x25519-public-key"
}
},
{
"user": "[email protected]",
"status": "not_deliverable"
}
]
}
So the user can expose a key with a
key_id
and
public_key
.
Why do we need a
key_id
?
Well, imagine how the flow would look like.
The client gets the user's public key and probably stores it in some cache, then sends messages using that key.
What if that key changes? The receiver will never decrypt it. We need to have a way to distinguish keys from each other and even show a warning that the key changed! Maybe it was compromised!
I also added two statuses:
ok
and
not_deliverable
.
ok
is self-explanatory, but I added
not_deliverable
for cases where we don't have a public key for that user yet.
Remember that the user needs to generate those keys. We cannot safely do it on the backend if we want real end-to-end encryption.
So there is a chance that we already have users who never generated them. We should clearly state that this user is not a valid user for receiving encrypted messages.
For now, we only handled the endpoint for server-to-server key exchange. But how will that public key appear in the first place?
The user can use the Web Crypto API to generate keys, store the private key locally, and send the public key to the backend to keep it in the DB.
const keyPair = await window.crypto.subtle.generateKey(
{ name: "X25519" },
false,
["deriveBits"]
);
const publicKey = await window.crypto.subtle.exportKey(
"raw",
keyPair.publicKey
);
Generally, we should avoid exporting the private key outside of the client unless we really need to. Browsers can store
CryptoKey
objects in IndexedDB.
If the private key is non-extractable, it is harder to accidentally leak it as a string somewhere.
This key is not literally used to encrypt the text directly. It is used by the encryption method to create a shared secret between sender and receiver.
So how would the flow look from the user's perspective?
sequenceDiagram participant C as Client participant IDB as IndexedDB participant HS as Home Server participant ES as Someone Else's Server C->>C: generate encryption keys C->>IDB: store private key C->>HS: store public_key ES->>HS: get .well-known/lnchat.json ES->>HS: call resolve_users HS->>ES: user_public_key
Here we assume that our home server can store the
public_key
, and it will be exposed through the
resolve_users
endpoint according to our protocol schema.
Now we can resolve the recipient's public key. Great. But we still need to actually send something.
For the first version, let's keep the responsibility split simple:
sequenceDiagram participant SC as Sender Client participant SS as Sender Server participant RS as Recipient Server participant RC as Recipient Client SC->>SS: ask for recipient public key SS->>RS: resolve_users RS-->>SS: public key + key_id SS-->>SC: public key + key_id SC->>SC: encrypt message body SC->>SS: encrypted message SS->>RS: federation message RS->>RC: encrypted message RC->>RC: decrypt message body
First, the client encrypts the message locally. Then the client could send something like this to its own server:
{
"recipient": "[email protected]",
"recipient_key_id": "barney-enc-2026-07-a",
"encapsulated_key": "base64url-hpke-enc",
"ciphertext": "base64url-ciphertext"
}
We will talk about the
encapsulated_keyandciphertextin a minute. So for now let's just accept that it's a "secret message".
And the plaintext inside the ciphertext can be very small:
{
"protocol": "lnchat.message.v1",
"type": "text",
"body": "hello"
}
Or the actual message could be simple text, but it's better to pack it in some sort of format so we can send more metadata alongside the message itself. Maybe later this could be used for a simple version of attachments, etc.
The server then creates its own HTTP request and sends it to the
Recipient Server
. But to which endpoint?
Well, to achieve that we need to add one more endpoint to our discovery file.
{
...
"endpoints": {
...
"send_messages": "https://example.com/federation/v1/message"
}
}
Now
Sender Server
can take the encryption data and send it to
Recipient Server
.
Payload can look like this:
{
"protocol": "lnchat.federation.v1",
"message_id": "019f47a9-b138-79d2-8ec3-38a2a9326955",
"sender": "[email protected]",
"recipient": "[email protected]",
"recipient_key_id": "barney-enc-2026-07-a",
"encapsulated_key": "base64url-hpke-enc",
"ciphertext": "base64url-ciphertext"
}
Notice that we added
message_id
and
sender
, but they were not present in the client message. This is intentional. We shouldn't trust the client to provide the real
sender
id. The user is already authenticated, so we can always put their name there.
And
message_id
is there for idempotency. If the server sends the same message twice, and the first one was already processed, we should reject the second one.
The
message_id
should be a randomly generated string. We can go with
UUIDv7
, for example.
recipient_key_id
should be the same id we get from the
resolve_users
endpoint. It tells the recipient which key was used to encrypt the message.
What's up with the
encapsulated_key
, you may ask?
Well, for a modern messaging system it's good to use something called
HPKE
.
HPKE itself is a bit too heavy to explain fully in this post, so let's use a simpler mental model. Encrypting directly with asymmetric keys can be computationally heavy. So the idea is:
This is not a precise HPKE specification, but it is close enough to understand why the payload has two parts: the encapsulated key material and the ciphertext.
So how would we do it in JS? Better not to do it ourselves anymore using raw crypto methods. Let's delegate it to smarter people from GitHub, like this: https://github.com/dajiaji/hpke-js
For readability, let's assume that
recipientPublicKey
is already imported from the resolved base64url public key.
import {
Aes256Gcm,
CipherSuite,
HkdfSha256,
} from "@hpke/core";
import { DhkemX25519HkdfSha256 } from "@hpke/dhkem-x25519";
const suite = new CipherSuite({
kem: new DhkemX25519HkdfSha256(),
kdf: new HkdfSha256(),
aead: new Aes256Gcm(),
});
function b64url(bytes) {
return new Uint8Array(bytes).toBase64({
alphabet: "base64url",
omitPadding: true,
});
}
const plaintext = new TextEncoder().encode(JSON.stringify({
protocol: "lnchat.message.v1",
type: "text",
body: "hello",
}));
const sender = await suite.createSenderContext({
recipientPublicKey,
});
const ciphertext = await sender.seal(plaintext);
const payload = {
recipient: "[email protected]",
recipient_key_id: "barney-enc-2026-07-a",
encapsulated_key: b64url(sender.enc),
ciphertext: b64url(ciphertext),
};
So we can discover servers, resolve users, get users' keys, and send encrypted messages. Nice. But we still have one big problem.
How does
y.com
know that the message really came from
x.com
?
Anyone can send an HTTP request and put this in JSON:
{
"sender": "[email protected]"
}
That proves nothing. So federation requests need to be signed by the sending server.
We need a separate key pair. Do not mix it with user encryption keys.
So let's add yet another field to the discovery file. This time it will be the server's own public key.
{
"protocol": "lnchat.federation.v1",
"server_keys": [
{
"key_id": "2026-07-ed25519-a",
"public_key": "base64url-ed25519-spki-der-public-key"
}
],
...
}
To generate keys, you can probably use any modern cryptographic library. For example:
import { generateKeyPairSync } from "node:crypto";
const { publicKey, privateKey } = generateKeyPairSync("ed25519", {
privateKeyEncoding: {
type: "pkcs8",
format: "pem",
},
});
const publicKeyDer = publicKey.export({
type: "spki",
format: "der",
});
storage.savePrivateKey(privateKey);
discovery.storePublicKey(publicKeyDer.toString("base64url"));
Remember to save the private key somewhere safe on the server, and publish the public key in the discovery file.
Now when
x.com
sends a request to
y.com
, it also has to send a few headers:
LNChat-Source-Domain: x.com
LNChat-Target-Domain: y.com
LNChat-Key-Id: 2026-07-ed25519-a
LNChat-Timestamp: 2026-07-09T12:00:00Z
LNChat-Request-Id: 6fb10f56-7b5f-4f68-9b17-6c07cdb3c4d8
LNChat-Body-SHA256: base64url-sha256-of-body
LNChat-Signature: base64url-ed25519-signature
The idea is:
x.com
creates the request body.
x.com
hashes the body.
x.com
signs a strict text representation of the request using its private server key.
y.com
downloads the public server key from
x.com
discovery.
y.com
verifies the signature.
And here one boring detail matters a lot: both servers must build exactly the same string.
Same new lines. Same path. Same timestamp format. Same hash.
If one server signs a slightly different string than the other server verifies, verification will fail.
That strict text representation could look like this:
LNCHAT-FEDERATION-V1
POST
/federation/v1/message
x.com
y.com
2026-07-09T12:00:00Z
6fb10f56-7b5f-4f68-9b17-6c07cdb3c4d8
base64url-sha256-of-body
Why do we also have to send
version
,
method
, and
URL
? Well, the
send_messages
endpoint should enforce signing. But why not require all federation endpoints to require such a signature? It's good practice to have this concept that everything coming to your server can be verified as coming from the server it claims to come from.
By the way, notice that we signed a hash of the body, not the full body?
base64url-sha256-of-body
Well, it's faster that way to sign only a small text, not 20MB. Remember, this is signing, not encrypting.
The signature proves that the sender had the private server key and signed exactly this canonical request. The timestamp and request id are also important because they help the receiver reject old or replayed requests.
So on the sending server you sign:
import { sign, verify } from "node:crypto";
const canonicalRequest = [
"LNCHAT-FEDERATION-V1",
"POST",
"/federation/v1/message",
"x.com",
"y.com",
"2026-07-09T12:00:00Z",
"6fb10f56-7b5f-4f68-9b17-6c07cdb3c4d8",
"base64url-sha256-of-body",
].join("\n");
const signature = sign(
null,
Buffer.from(canonicalRequest, "utf8"),
privateKey
);
console.log(signature.toString("base64url"));
And on the receiving server you have to verify. But in order to do it, you first need to:
LNChat-Source-Domain
header to determine who is calling
.well-known/lnchat.json
file and get the public key from the domain of the
LNChat-Source-Domain
canonicalRequest
text
LNChat-Signature
header
Security note: avoid SSRF (Server-Side Request Forgery), where a remote server tricks your server into calling internal or private network addresses. When fetching
.well-known/lnchat.json, validate the source domain, require HTTPS with valid certificates, and do not follow redirects to private or local network addresses.
import { createPublicKey, verify } from "node:crypto";
const publicKey = createPublicKey({
key: Buffer.from(discoveryPublicKey, "base64url"),
type: "spki",
format: "der",
});
const signature = Buffer.from(signatureHeader, "base64url");
const ok = verify(
null,
Buffer.from(canonicalRequest, "utf8"),
publicKey,
signature
);
console.log(ok);
If
ok
is true, we know that this request was signed by someone who has the private key matching the public key from discovery.
That still does not prove that the user personally typed the message.
It proves that server
x.com
accepted the message and signed the federation request.
But in this simple version we already trust our home server to handle login, sender identity, and routing. So for now that is enough.
sequenceDiagram participant HS as Home Server participant ES as Someone Else's Server HS->>HS: keep server signing private key HS->>ES: send signed federation request ES->>HS: fetch discovery HS-->>ES: public signing key ES->>ES: verify signature using public key ES->>ES: process request if valid
And that's the basic shape of federation:
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.
We are deeply sorry for the disruption this incident has caused our customers and partners. We know the trust they place in our services and take that responsibility extremely seriously. We are seeing broad recovery and stability across our services. This was a technical issue not related to cyber or AI / agents. The incident was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change. We have addressed the underlying issue and continue to restore service to remaining customers and regions. Given the scale of demand, we restored services gradually, validating stability at each stage. While this took longer, it helped ensure a stable restoration. We will provide a full post-incident report once our review is complete.
Yesterday, we verified that known tax loopholes could be identified using a Lean search. Today, we set out to formalize the entire Internal Revenue Code to hunt for unknown loopholes (bugs).
Lean is a programming language whose type checker can also check mathematical proofs: if Lean accepts a proof, every step follows from the definitions, with nothing taken on trust. An earlier post discussed how far that kind of formalisation can reach in law, [ 1 ] and yesterday we used it on the retirement-account rules, where a blind search rediscovered the backdoor Roth. [ 2 ]
This work is part of global-law , a CC0 repository of versioned legislation and case law. [ 3 ] Our argument is that pointing AI and a proof checker at a versioned record of the law finds the contradictions and mechanical mistakes that people miss. In particular, we can catch mistakes in the text, and see what the rules allow, including what they allow by accident. To do so, we translated each section of the law into Lean, staying close to the statute’s own words, and tested it against the worked examples the IRS prints in its forms and instructions.
The tax law is Title 26 of the US Code. Its official text is published as structured data by the Office of the Law Revision Counsel, the office of the House of Representatives that compiles the Code. [ 4 ] We used the release current to 3 November 2026.
A parser then reads every cross-reference, including the ones written in words (“paragraph (2) of subsection (b)”, “such subparagraph”, “sections 922 through 927”), which carry no hyperlink. Lean checks each one. Does the provision it points to exist? Is it still in force? (verifiable via our versioned history) The checks run as a test suite, which fails whenever a new release adds a fault the last one did not have.
The suite reports 257 findings, each checked by an AI agent against the official text and its editorial notes: 98 intended (rules for past periods, and provisions enacted but not yet in effect), 21 false alarms in the editors’ own hyperlinks, and 138 real faults:
Each of the 138 has a certificate: a short Lean statement that carries its evidence from the official XML and proves the fault. For a dead reference, the evidence is the full list of what does exist under the cited provision. Lean re-checks all 138 in about two and a half minutes.
Our record of the US Code is a git history, one commit per public law, [ 5 ] so each fault can be traced to the law that wrote it. For Title 26 the record reaches back to the 1994 edition.
This check is cheap to repeat. Run against each new release of the Code, it flags a new mistake as soon as it appears, and names the law that caused it.
Next we wrote down what the law calculates: the 2025 federal income tax for one household, meaning the numbers on Form 1040, including the changes made by the One Big Beautiful Bill Act in July 2025. [ 6 ] , [ 7 ] We did it in four parts:
We used AI to translate the statute into Lean. This is the lossy step, therefore we reinforce it with the following measures:
What Lean ultimately adds is proofs that cover every input instead of a sample. For example, it proves that the SALT cap and the car-loan and overtime deductions never grow when income rises, at every income and for every filing status.
The comparison with other tax software helps us catch logical errors. That is how we caught two mistakes in our own model. It is also how we found bugs in the other tools that were logical rather than arithmetic: Tax-Calculator gives the EITC to separate filers without checking whether the spouses lived apart, and UsTaxes never attaches Schedule C to the 2025 return, so self-employment income disappears.
Writing the model turned up five things:
A model is only useful if it gives the right answers. To check ours, we built 5,000 sample households and worked out each one’s 2025 tax four ways: with our model, and with three tools built by other teams, independently of each other and of us:
Two thousand households were ordinary. The other 3,000 were deliberately awkward: couples filing separately, widows and widowers, students, people with tips or overtime, IRAs and health savings accounts, education and saver’s credits, and incomes over $1 million with large investment gains.
Our model and PolicyEngine-US agreed on every figure for 4,993 of the 5,000 households. The other seven differ by at most $11, all in the EITC: our model reads the IRS’s printed EITC table, while PolicyEngine-US uses the formula behind it. [ 11 ]
Tax-Calculator gave the EITC and the child and dependent care credit to married people filing separately without checking that the spouses lived apart, which the law requires. It also computed no AMT for one high-earning separate filer, where two other calculators computed $14,881.
UsTaxes had 14 bugs, each confirmed by recalculating an affected household. It drops self-employment income without a warning, because its 2025 return never attaches Schedule C, the form for business income. Its child-care credit never reaches the return. Its age test for the EITC always passes. And its self-employment tax counts a spouse’s wages against the cap on Social Security tax. Together, these bugs affect about one ordinary household in six.
The comparison caught two mistakes in our own model too. We had not counted self-employment profit toward the 20% deduction for small-business income. And we always took the larger of the standard and itemized deductions, although the law lets you choose to itemize a smaller amount, which can pay when it lowers the AMT. With that fixed, one household owed $2,070 less. Both mistakes showed up because two independent tools agreed with each other and not with us.
With a model that matches the reference software, we used it as we had used the retirement rules: as the oracle for a search that knows no tax planning. The first search tried ordinary choices for each of the 5,000 households, 195,787 returns in all:
The second search used a multi-year family model, which adds the kiddie tax, trust taxation, Roth conversions, required withdrawals, gifts and death. It tried about 30,000 plans for four families over 34 to 47 years. Everything large that the two searches found is already in the planning literature:
| What the search found | Best case | Already described by |
|---|---|---|
| A business owner files separately to get under the §199A threshold | $6,317 a year | Kitces [ 12 ] |
| The lower earner claims the children on a separate return | $3,090 a year | practitioner guides [ 13 ] |
| Realize less gain to stay under the EITC investment limit | $6,798 for $5,000 deferred | IRS Publication 596 [ 11 ] |
| Itemize a smaller amount to cut the AMT | $2,070 a year | Form 1040 instructions |
| Roth conversions in the gap years before Social Security | +$0.84M over a lifetime | Kitces |
| Pay your children wages, and open Roth IRAs for them | +$0.46M | Kitces [ 14 ] |
| Convert so the heirs do not stack ten-year withdrawals | +$0.43M–0.57M | Journal of Accountancy [ 15 ] |
As with the backdoor Roth, none of these was described to the search. It found them because the rules, written down plainly, permit them.
Three results did not turn up in practitioner sources, IRS guidance or tax-software forums.
Filing separately can cut tax on Social Security, even for a couple living together. The standard advice is that a couple living together should never file separately when one draws Social Security. [ 16 ] A separate filer who lived with their spouse gets no base amount at all. But taxable benefits are capped at the lesser of 85% of benefits or 85% of provisional income, [ 17 ] , [ 18 ] and the search found couples for whom that cap makes separate returns cheaper. On a joint return the working spouse’s wage counts in provisional income, so a moderate wage already pushes the benefits to the 85% maximum. On a separate return the retiree’s benefits are measured against the retiree’s income alone. With $48,000 of benefits and a $60,000 wage, the couple owes $7,050 jointly and $5,568 separately, $1,482 less. A second reviewer recomputed it by hand and got the same answer. At a $100,000 wage the result flips, so the window is real but narrow.
Wages on one return, investments on the other. The 3.8% tax on investment income applies to the smaller of the investment income and the excess of income over $250,000 jointly, or $125,000 on a separate return. [ 19 ] On a joint return, wages use up that threshold first. On separate returns the investing spouse’s income excludes the other’s wages, and their gains start in their own 0% band. With about $200,000 of each, that saves $1,621. Every explainer gives the threshold. We found none that describes the split or where it pays.
Schedule 8812 pays more than the statute allows. This is a gap between the IRS form and the law, not a plan. The statute caps the refundable child credit per qualifying child, computed without the $500 credit for other dependents. The form caps the combined credit instead, so in the phase-out range, with no tax left to absorb it, it refunds the $500 credits in cash. [ 20 ] , [ 21 ] Example: one child and one other dependent, $240,000 of income, no tax left. The statute gives $200, the form $700. Lean proves the form is never below the statute and agrees with it exactly when there are no other dependents.
The backdoor Roth is big because two provisions combine to remove an income limit entirely, and the money then compounds tax-free for decades. A single year of the individual income tax is full of cliffs and per-return thresholds, but each is bounded: the largest swing we found was a few thousand dollars. Over decades, the large gains come from moves that are already published. The one combination we could not find written up was paying the children in the same years as Roth conversions, which adds about 0.5%. Our guess is that anything Roth-sized and unpublished lives where value moves between entities and their owners: partnerships, S corporations and C corporations.
“The long-term problem is how this kind of bug-hunting can be done routinely, e.g. as part of a test suite. Some approaches aren’t really automatable, because they require a lot of both human and AI agent work.”
What still needs a person is deciding what a finding means. Some cliffs are deliberate. Others are in the IRS’s forms, not in the law, whilst others come from the way the official text is compiled, yet:
The code, the certificates, the comparison and the searches are in the lean-proofs folder of global-law. [ 3 ]
In July, we announced a series of planned updates to the PyPI user interface. Shaped by user research with members of the Python community , the updates aim to improve how we surface security signals and display package details.
We're pleased to share that this work is now complete and live on PyPI .
With the rapid growth of the Python ecosystem, PyPI has become an increasingly attractive target for malicious actors. In response, the PyPI team has delivered many security features while taking a more active role in helping PyPI users assess and understand package security.
Digital attestations , introduced in 2024, are an example of this effort, providing a verifiable record of a release file's provenance (where it came from). However, provenance and attestations are still unfamiliar concepts for many PyPI users, and PyPI's interface did little to communicate their meaning, importance, or limitations.
To address this, PyPI partnered with Kabu Creative to bring clearer security signals to the PyPI UI, implementing the recommendations developed in the OpenSSF Attestations Style Guide .
Here's a look at what's changed, what it means for you, and what actions you can take.
The new security tab communicates release provenance states and displays per-file attestations, giving you a dedicated place to verify where the release files came from.
PyPI calculates each release's provenance state by checking whether each release file has an attestation. Typically, a release will be in one of two states:
This means that 100% of the release files have attestations, carrying either or both of the supported attestation types:
PyPI Publish attestations confirm the file was published by a PyPI Trusted Publisher :
SLSA Build Provenance attestations link the file back to its exact source commit, build platform, and instructions:
You can review attestation metadata directly in the UI, or click on the transparency log link for more information.
"No provenance" simply means that no file in the release has an attestation. This is typical for older releases or projects that have not yet configured Trusted Publishing. No provenance does not necessarily indicate that a release or release file is malicious; it instead means that the file origin cannot be cryptographically verified .
When there is no provenance, you should rely on surrounding trust signals to assess security, such as maintainer history, release patterns, and repository activity. If you maintain the package, consider using Trusted Publishing with a publisher that generates attestations for your next release.
Provenance warnings are designed to help you identify when a file may not have come from the project's maintainers, for example, if an attacker has taken over an account or a publishing workflow.
When provenance metadata looks unusual or conflicts with a project's history, PyPI surfaces a prominent warning. Many warnings have legitimate explanations, but each one is worth checking before you install.
This means that some files carry attestations while others do not (e.g., wheels were published via Trusted Publishing, but the source tarball was uploaded using an API token).
Exercise caution if you see this warning. Check release notes for build issues or ask in the project's issue tracker before installing.
This warning indicates that files within the same release originate from different build systems or source repositories.
Check the attestation metadata to confirm whether all files came from sources controlled by the maintainers.
This warning tells you that the release files originated from a different repository or workflow than a previous release. While often legitimate (such as an organization name change or repository migration), it can also indicate a compromised pipeline or account takeover.
If you see this warning, check the project release notes or official channels to confirm that an infrastructure migration was planned.
This means that a project that previously published with attestations has changed to uploading release files without them.
Check whether the maintainers intentionally changed their publishing process, for example by switching back to API tokens, or by changing their publishing configuration so that it no longer generates attestations. If this is unexpected, treat the release with skepticism until verified.
To learn more about provenance and attestations, including provenance warnings, see our user documentation .
To support these changes, the project detail page has also been updated:
The redesigned release files tab helps you find the right file by searching and filtering long lists. You can also view the provenance state of each file within the table, and quickly identify late files, which are marked with an orange warning icon.
Late file warnings are shown when one or more files were uploaded more than 14 days after the initial release timestamp. These warnings only appear on releases prior to July 2026, when a policy was introduced to reject new files after 14 days .
The release history tab now also provides more details about each release, exposing file count, provenance state, and release status (i.e., quarantined, yanked, archived, or pre-release).
Alongside the interface updates, PyPI's user documentation has been extended to help you better navigate package security. Read our package security guide to learn about:
The new security tab gives PyPI a dedicated home for future attestation types and security notices. To help the wider open source ecosystem benefit from this work, we've also published a case study in the OpenSSF Attestations Style Guide detailing the design patterns and warnings developed during this project.
This initiative was funded by the Open Source Security Foundation and implemented by Kabu Creative . We would like to thank Dustin Ingram , Zach Steindler , and the members of the OpenSSF Securing Software Repositories Working Group for championing this effort. Special thanks to Mike Fiedler , Jacob Coffee , and members of the PyPI team for their thoughtful design feedback and code reviews, @cofiem for their contributions to the new release files tab, and our user interview participants and community testers for helping shape the final design.
Finally, we would like to thank the OpenSSF for its funding and continued partnership in securing the Python packaging ecosystem.
Perses is first and foremost a dashboard tool that you can use to display a variety of observability data. It supports all four observability pillars through Prometheus metrics, Tempo traces, Loki logs and Pyroscope profiles. Other supported datasources can be found here .
You can use Perses as-is or embed parts of it in your own UI as a single panel or a whole dashboard view.
Perses offers a complete static validation of the dashboard format. It also comes with a CLI,
percli
, that can be used to perform actions in CI/CD pipelines.
Perses dashboards can be written as code using the provided SDKs, enabling you to manage large numbers of dashboards at scale.
Use the Perses operator to manage your Perses deployments & dashboards as CRDs. Leverage on the datasource discovery to retrieve data from your datasource pods/services.
Perses, with its plugin-based architecture, offers effortless extension and reuse of plugins across different projects.
...and more to discover!
Perses provides comprehensive Prometheus support with specialized panels for metrics visualization. It also comes with a built-in metrics explorer and a PromQL debugger that mirror Prometheus's native UI experience.
Deep dive into your Tempo traces and display them in several ways: scatter plots, Gantt charts, or tables.
Visualize your Pyroscope profiling data through interactive flame graphs.
Prometheus, Tempo, Loki, and Pyroscope are just the start. Perses also supports other datasources. → See all supported datasources.
Perses is also an initiative to define a standardized dashboard specification, fostering interoperability across observability tools.
Perses provides various npm packages that allow developers to embed panels and dashboards into their own UIs, giving the flexibility to integrate Perses components without running the full application.
Perses supports multiple kinds of plugins, enabling users to extend the tool’s native capabilities to suit specific needs.
Perses comes with a native CLI,
percli
, which can be used to perform many kinds of actions in CI/CD pipelines.
Perses dashboards can be written as code using the provided SDKs. This enables you to define reusable components in libraries or leverage existing community libraries, from simple color codes to complex templates, for reuse across as many dashboards as you want.
Perses offers complete static validation of the dashboard format, which you can also extend with custom lint rules.
Deploy and manage Perses instances and dashboards declaratively using Kubernetes Custom Resources, enabling GitOps workflows and seamless integration with your existing K8s infrastructure.
Automatically discover and register datasources through HTTP services or Kubernetes API, eliminating manual configuration effort in dynamic environments.
Perses provides comprehensive authentication and authorization capabilities. Choose from native user management or integrate with external OIDC/OAuth identity providers. Control access with Kubernetes-inspired RBAC system featuring roles, role bindings, and fine-grained permissions across projects and global resources.
Seamlessly migrate your existing Grafana dashboards to Perses, using either the web UI to import JSON files directly or leveraging
percli
for batch migrations. The migration process translates Grafana definitions to their Perses equivalents on a best-effort basis.
Organize datasources and variables across three hierarchical scopes: global (available everywhere), project (shared within a project), and dashboard (specific to one dashboard). Lower scopes automatically override higher ones, enabling flexible resource reuse while allowing targeted customization for specific use cases.
Perses is 100% open source and community-driven. All components are available under the Apache 2.0 License on GitHub .
Perses is a Cloud Native Computing Foundation sandbox project.
The U.S. government has disrupted a North Korean social engineering campaign called ‘FaceStealer’, responsible for stealing more than $400 million in cryptocurrency.
The attacks used multiple social engineering techniques, including deepfakes and ClickFix, to target individuals in the cryptocurrency and Web3 sectors, as well as open-source developers.
The FaceStealer campaign ran for 18 months before the U.S. seized the underlying cloud-based infrastructure.
U.S. authorities identified more than 900 webcam videos that hackers secretly recorded of tech workers, who were deceived in the massive North Korean operation.
An FBI alert earlier this week notes that the North Korean threat actor hijacked accounts on Telegram, LinkedIn, Slack, and Discord, and used them to invite victims to video meetings under various pretenses.
During the video calls, the attacker showed recorded footage of people the targets knew and who had previously fallen victim, too.
The FBI explains that while the target waited for the meeting to start, the hacker secretly recorded a video, which was later used with other targets. The meeting sometimes featured recordings of multiple familiar individuals to add pressure on the current victim in the next stage.
Shortly after, the hacker claimed a technical issue and displayed a fake error message to justify delivering a malicious “fix.”
The target was then prompted to follow a link that purported to offer a fix, such as an update or installer, which infected their computer with malware that steals crypto data and account credentials for video meeting platforms such as Zoom, Google Meet, and Microsoft Teams.
The malware also provides access to the victims' contact lists, social media, communication apps, and webcam videos.
According to the FBI, attackers sometimes delayed targeting individuals for months or even more than a year after the initial compromise, likely waiting for their cryptocurrency holdings to grow.
ArticWolf researchers attributed the FaceStealer campaign to the BlueNoroff hacker group and listed additional lures , including financial documents, fake PDF viewer updates, identity verification prompts, and security audits, all designed to persuade the target to run a “fix.”
The researchers identified 677 targets across 58 countries, with a heavy focus on company founders and senior executives.
Huntress cybersecurity company attributed a similar campaign to BlueNoroff in 2025, where the attackers used Zoom calls to infect company executives with custom macOS malware.
The FBI bulletin highlighted an incident in which the hackers compromised the maintainer of a popular open-source JavaScript library with tens of millions of weekly downloads, after luring them into a fake Teams meeting with multiple participants, including one familiar to the developer.
The attack was thwarted thanks to quick detection, but the FBI says it confirmed multiple other attempts against developers in the npm and Rust crate ecosystems.
Amazon threat analysts also attributed several open-source software supply chain attacks to BlueNoroff in a July 2026 report .
To defend against these attacks, users are recommended to join meetings only through official apps using an invite code, verify unexpected invitations independently, and keep the webcam off unless explicitly needed. Finally, avoid running scripts offered as fixes to technical problems.
As a separate announcement, the U.S. Justice Department said that together with private sector companies, the U.S. government froze more than $2.7 billion from the 6.4 billion Binance crypto heist .
The DoJ has already "obtained court-authorization to seize or restrain in excess of $1.2 billion of that amount."
Adaptive Security's AI agents analyze email intent, context, and behavior to uncover phishing, business email compromise, and invoice fraud.
See what's getting through with a 14-day read-only scan of Microsoft 365 or Google Workspace, with no MX changes.
The architecture from the DeepSeek-V3 technical report in 190 lines of pure JAX , pretrained from scratch on a MacBook Air on public-domain detective fiction.
No Flax, no Equinox, no PyTorch. Params are plain dicts of arrays and every part of the model is a function you can read top to bottom in
deepseek_v3.py
.
Read the write-up: DeepSeek V3 in 190 lines of pure JAX , with diagrams, the code explained piece by piece, and the results.
| Idea from the paper | What it does | Where |
|---|---|---|
| Multi-head Latent Attention (MLA) | Caches one small latent per token instead of full keys and values: 480 → 144 numbers per token per layer here |
mla
,
init_cache
|
| Decoupled RoPE | One rotary key shared by all heads, kept outside the compressed latent |
rope
,
apply_rope
,
mla
|
| DeepSeekMoE | 1 shared expert that always runs + 16 routed experts, top-4 per token |
route
,
moe
|
| Auxiliary-loss-free balancing | A per-expert bias nudges routing toward idle experts; it changes which experts are picked, not their weights |
update_bias
,
route
|
| Sequence-wise balance loss | The small complementary loss from the paper (α = 1e-4) |
seq_balance_loss
|
| Multi-token prediction (MTP) | An extra module also predicts the token after next, weighted λ = 0.3 in the loss |
forward
,
loss_fn
|
| Training and generation | bf16 compute on f32 master weights; prefill + decode with the MLA cache |
make_train_step
,
generate
|
One run of the default config on a MacBook Air M5 (24 GB):
| Model | 36.2M parameters, 13.6M active per token |
| Data | 207 books, 21.7M training tokens (Hammett repeated 3×); validation is held-out crime fiction |
| Training | 12,000 steps, ~98M tokens (~4.5 epochs), ~2.6 h |
| Speed | ~10.7k tokens/s (median) |
| Validation loss | 5.02 (step 250) → 3.51 |
| Expert load, with bias | 5.7–6.9% per expert (even is 6.25%), at step 2000 |
| Expert load, without bias | 0.09–18.6% per expert, at step 2000 |
With balancing on and off, validation loss at step 2000 was the same (3.921 vs 3.923). The bias evens out the experts without costing anything, which is the paper's claim.
Its own words, from the prompt "The fog came in off the":
The fog came in off the bay, and the great trees were spreading and the stars were shining.
This is an architecture demo, not a strong language model. See the write-up for what worked, what didn't, and what's missing.
The v1.0 release has the exact checkpoint and data from the published run. After installing (step 1):
mkdir -p data runs/main curl -L -o runs/main/ckpt.pkl https://github.com/Vaibhaav-Tiwari/deepseek-v3-jax/releases/download/v1.0/ckpt.pkl # 138 MB curl -L -o data/tokenizer.json https://github.com/Vaibhaav-Tiwari/deepseek-v3-jax/releases/download/v1.0/tokenizer.json .venv/bin/python sample.py --prompt "The fog came in off the" --num 3
The checkpoint is a Python pickle, which can run code when loaded. Only load checkpoints from sources you trust.
You need an Apple Silicon Mac, Python 3.12 and uv . The published run used 24 GB of memory. No Mac? See Running on CPU .
1. Install
git clone https://github.com/Vaibhaav-Tiwari/deepseek-v3-jax.git && cd deepseek-v3-jax uv venv -p 3.12 .venv uv pip install --python .venv/bin/python -r requirements.txt
Every version in
requirements.txt
is pinned.
jax-metal 0.1.1
only works with
jax==0.4.34
, so don't upgrade JAX.
2. Check your setup
JAX_PLATFORMS=cpu .venv/bin/pytest tests.py -q # 39 passed .venv/bin/python smoke_metal.py # optional: what jax-metal supports on your Mac
In
smoke_metal.py
, "grad through 2-axis contraction" fails on jax-metal 0.1.1. That's expected, and the model is written to avoid it.
3. Build the dataset
.venv/bin/python prepare_data.py
This downloads the 207 books in
sources.txt
(~120 MB, about 7 minutes), cleans them, trains an 8,192-token BPE tokenizer and writes
data/train.bin
,
data/val.bin
and
data/tokenizer.json
. It should print:
train: 211 docs, 83.4M chars, 21.69M tokens
val: 4 docs, 1.1M chars, 0.30M tokens
The published run's data had these hashes:
shasum -a 256 data/train.bin data/val.bin data/tokenizer.json
d37aca97e707bb81b6e4d266cc1adfd1f3e3556457c6eb724e495118a734e0bb data/train.bin
b7ac285b115e6793b5d36aa5b4bc6e81a5fccfc7af0908a306d3828ebca9c31c data/val.bin
c5a142b4006a967c880dda44ad792719d53c16d947da3b6c2332d6132d9967cc data/tokenizer.json
You will most likely get different hashes. The Hammett books are pinned to exact Standard Ebooks commits and come out identical, but Project Gutenberg files can't be pinned, and Gutenberg has since re-issued 28 of the 203 books with small edits (mostly accents stripped, like "José" → "Jose"). The token counts come out the same, so training should behave the same.
To train on the exact same bytes
, skip
prepare_data.py
and download the published data instead:
mkdir -p data for f in train.bin val.bin tokenizer.json; do curl -L -o data/$f https://github.com/Vaibhaav-Tiwari/deepseek-v3-jax/releases/download/v1.0/$f; done shasum -a 256 data/*.bin data/tokenizer.json # should match the hashes above
4. Train
.venv/bin/python train.py # the main run: 12k steps, ~2.6 h .venv/bin/python train.py --steps 2000 --out runs/bias_on # balancing ablation, with the bias .venv/bin/python train.py --steps 2000 --out runs/bias_off --no-bias # ...and without it
Each run writes
metrics.jsonl
(loss, validation loss, per-expert load, biases, tokens/s) and
ckpt.pkl
(saved at every evaluation) into its
--out
folder, which defaults to
runs/main
. Seeds are fixed, but GPU math on Metal isn't bit-for-bit deterministic, so expect your numbers to land close to the ones above rather than match them exactly.
5. Generate
.venv/bin/python sample.py --prompt "The fog came in off the" --num 3
Defaults: temperature 0.8, top-k 50, 300 new tokens per sample (
--temp
,
--top-k
,
--n
).
6. Make the figures
.venv/bin/python plots.py # needs runs/main, runs/bias_on, runs/bias_off JAX_PLATFORMS=cpu .venv/bin/python charts.py # the rest of the write-up's charts
Both write into
post/figures/
.
To redraw the figures without training, download the logs from the release:
metrics-main.jsonl
,
metrics-bias_on.jsonl
and
metrics-bias_off.jsonl
go into
runs/main/
,
runs/bias_on/
and
runs/bias_off/
as
metrics.jsonl
.
charts.py
also needs the checkpoint and the data.
Everything runs without jax-metal. It's much slower, so use the smaller config:
JAX_PLATFORMS=cpu .venv/bin/python train.py --config small
--config small
(4 layers, 8 experts, top-2, 128-token context) is meant for 8–16 GB Macs too. It has only been checked for a couple of steps, not trained to the end.
| File | What it is |
|---|---|
deepseek_v3.py
|
The model : config, MLA, MoE, balancing, MTP, loss, train step, cached generation. The 190 lines. |
train.py
|
Training loop: AdamW with warmup and cosine decay, evaluation, checkpoints, logging |
prepare_data.py
,
sources.txt
|
Download, clean and tokenize the corpus |
sample.py
|
Text generation from a checkpoint |
tests.py
|
39 tests: causal masking, cache vs full forward, routing, balancing, MTP targets, NaN handling, bf16 master weights, and more |
smoke_metal.py
|
Which JAX operations work on Apple's GPU |
plots.py
,
charts.py
|
The figures, all drawn from the logs, checkpoint and corpus |
post/
|
Diagrams, figures and screenshots from the write-up |
"190 lines" counts the non-blank, non-comment lines of
deepseek_v3.py
after its docstring:
tail -n +5 deepseek_v3.py | grep -cvE '^\s*(#|$)' # 190
All training text is public domain in the United States: Dashiell Hammett's
Red Harvest
,
The Dain Curse
,
The Maltese Falcon
and Continental Op stories (CC0 editions from
Standard Ebooks
), plus about 200 detective and crime novels from
Project Gutenberg
. Every source is listed in
sources.txt
. Public-domain status outside the US may differ.
DeepSeek-AI, DeepSeek-V3 Technical Report , 2024.
Code: MIT . The training text is public domain in the US (see above).
Commercial phone unlocking tools are not magic. They exploit the same classes of vulnerabilities that security researchers publish about at conferences and in academic papers. What makes them distinctive is not the novelty of the techniques, but the systematic commercialization of exploitation: acquiring or developing exploits for each hardware and software combination, and reaching a certain degree of stability, packaging them into automated workflows that require minimal operator expertise.
This post aims to demystify the technical foundations of these tools. The attack vectors available to a forensic examiner with physical access to a device are constrained by well-understood boundaries: the boot chain, the trusted execution environment, the secure element (when present), and the kernel’s peripheral driver stack. This post mostly details Android internals, however iOS equivalent concepts are technically similar.
Much of the background research referenced here comes from Quarkslab , whose extensive publications on TEEs, and Android’s data encryption architecture have been invaluable to understand these tools. Their work, alongside reporting from Amnesty International’s Security Lab and other NGOs, and analysis by the GrapheneOS project, provides the empirical basis for the claims made in this post.
Before examining attack vectors, it is necessary to understand the hardware security architecture of modern Android devices. The following sections describe the components that forensic tools must eventually hack or bypass.
Modern ARM-based mobile processors implement TrustZone, a hardware security extension that partitions the processor into two execution environments: the Normal World and the Secure World . The Normal World runs the Android operating system, user applications, and the Linux kernel. The Secure World runs a separate, minimal operating system, the Trusted OS , along with small, specialized applications known as Trusted Applications (TAs) .
The two worlds share the same physical processor cores but are hardware-isolated: the Normal World cannot directly read or write Secure World memory. Communication between the two happens through a monitor, a piece of code running at the highest privilege level (EL3 on ARMv8), which handles context switches triggered by Secure Monitor Call (SMC) instructions. Each physical processor core effectively provides two virtual cores, with the Non-Secure bit in the Secure Configuration Register determining which world is active at any given time.
The Trusted OS hosts critical security services. Two are directly relevant to device unlocking:
Different SoC vendors ship different TrustZone implementations. Google (and AOSP in general) uses TrustyOS ; Qualcomm uses QSEE; Samsung uses TEEGRIS (on both Exynos and MediaTek SoCs in Samsung devices); Huawei uses TrustedCore; Trustonic’s Kinibi is also often found on MediaTek and Exynos SoCs. The security properties vary between implementations.
A Secure Element (SE) is a physically separate, tamper-resistant hardware chip that provides an additional layer of security beyond the TEE. Unlike the Secure World, which runs on the same SoC as the Normal World, a Secure Element is an independent processor with its own boot chain, its own firmware, and its own cryptographic key storage.
In the Android ecosystem, the Secure Element is exposed through the StrongBox API (introduced in Android 9). Google’s Pixel phones, starting with the Pixel 3, include the Titan M chip as their Secure Element, that was later upgraded with the Titan M2 from Pixel 6 onward. On Apple devices, the equivalent is the Secure Enclave Processor (SEP) .
The Secure Element’s role in device encryption is to hold key-encryption keys and enforce rate-limiting for credential verification in hardware that the main SoC cannot tamper with, even if fully compromised. This is an important distinction: on a device without a Secure Element, compromising the TEE is sufficient to extract or bypass credential-derived keys. On a device with a Secure Element, the attacker must additionally compromise a separate, hardened chip.
Unfortunately, only flagship devices typically include a Secure Element. Most mid-range and budget devices rely solely on the TEE for credential protection. This architectural gap is the single most important factor determining the chances that a device has to resist forensic unlocking when powered off.
The boot chain establishes a chain of trust from immutable hardware to the running operating system. Each stage verifies the integrity of the next before executing it.
The chain proceeds as follows:
Boot ROM : the first code executed at power-on. It is burned into silicon at manufacture and is, in principle, immutable and unpatchable (with a few modern exceptions to deploy patches for vulnerabilities ). The Boot ROM verifies and loads the next stage (the preloader or secondary bootloader). It forms the hardware root of trust.
Preloader/Secondary Bootloader (BL2) : loaded and verified by the Boot ROM. On MediaTek SoCs, this is often called the preloader . It initializes hardware, loads the Trusted OS into the Secure World, and loads the main bootloader into the Normal World.
Trusted OS : loaded into the Secure World by the preloader. It hosts Gatekeeper, Keymaster, and other Trusted Applications. Its integrity is verified by the preloader as part of the secure boot chain.
Bootloader (BL3) : the Normal World bootloader (e.g., Little Kernel on MediaTek, ABL on Qualcomm). It enforces Android Verified Boot (AVB), anti-rollback protections, and device-state checks before loading the Android kernel.
Android OS : the Linux kernel and userspace. Verified Boot (dm-verity) ensures the integrity of system partitions at runtime.
When a Secure Element is present, it runs its own independent boot chain in parallel: Boot ROM → Bootrom EXT → Bootloader → OS . The Secure Element’s boot chain is entirely separate from the SoC’s, providing the most isolation.
If any stage in the boot chain is compromised, all subsequent stages are untrustworthy. This is why Boot ROM vulnerabilities are so devastating: they are often unpatchable, they undermine everything built on top, and they affect every device using the vulnerable silicon for its entire hardware lifetime.
Understanding the attack vectors requires understanding what the attacker is ultimately trying to obtain: the decryption keys for the user’s data.
Android has used two encryption schemes over its history:
Full Disk Encryption (FDE) encrypts the entire data partition with a single key, derived from the user’s credentials. The key must be available before the OS can boot, so the user is prompted for their PIN or password at boot time. FDE was the default until Android 6 and has been deprecated since Android 13 .
File-Based Encryption (FBE) encrypts individual files with different keys, allowing more granular access control. FBE has been the default since Android 7 and is required since Android 10. It divides storage into two classes:
Quarkslab’s Android Data Encryption in depth provides the most detailed public analysis of how the CE key is derived. The process, in simplified form, proceeds as follows:
The user’s credentials (PIN, password, or pattern) are stretched using
scrypt
, a memory-hard key derivation function, with parameters and salt stored in DE-protected files under
/data/system_de/<uid>/spblob
. The scrypt step is intentionally slow: it introduces a negligible delay for a single authentication attempt but makes brute-forcing computationally expensive.
The stretched credentials are combined with other material to form a password blob , which is sent to the Gatekeeper Trusted Application in the TEE. Gatekeeper verifies the blob against a stored password handle using an HMAC with an internal key. If verification succeeds, Gatekeeper issues a signed authentication token .
The authentication token is presented to Keymaster , which uses it to unlock an authentication-bound key . This key is used to perform the first decryption of the Synthetic Password , an intermediate secret stored in encrypted form on the filesystem.
The Synthetic Password is decrypted a second time using a key derived from the user’s credentials (the
applicationId
). This second decryption uses AES-GCM, which provides authenticated encryption: if the wrong credentials are supplied, the GCM tag will not match and decryption will fail. This is the cryptographic check that ultimately binds the CE key to the correct credentials.
From the Synthetic Password, the system derives the CE file encryption keys used by the Linux kernel’s
fscrypt
subsystem to decrypt individual files.
The critical observation is that user credentials are cryptographically embedded in the key derivation chain . There is no way to bypass them purely through software attacks: an attacker who compromises the TEE can bypass the authentication token check, but they still need to brute-force the credentials through scrypt to derive the correct key material.
On devices with a Secure Element, the key derivation process includes an additional step. Instead of relying solely on Gatekeeper in the TEE, the system uses Weaver , a service running on the Secure Element. Weaver stores a secret value that is released only upon correct credential verification and enforces its own independent rate-limiting.
This means that even if an attacker fully compromises the TEE, or other Trusted Applications as shown by Synacktiv’s Kinibi TEE blogpost , they cannot extract the Weaver secret or bypass its throttling, if implemented properly. Brute-forcing must proceed online, at the rate the Secure Element permits, which, for a device like the Pixel with Titan M, means exponential backoff.
With the architecture established, we can now map the specific attack surfaces that forensic tools exploit. These fall into two main categories, corresponding to teo device states: powered off or powered on but never unlocked (BFU), and powered on and previously unlocked (AFU).
The most complete form of BFU attack targets the boot chain itself. If an attacker can compromise the Boot ROM or the preloader, they can break the entire chain of trust, including the TEE.
The attack proceeds as follows:
Boot ROM exploitation : the attacker connects to the device via USB and exploits a vulnerability in the Boot ROM (or uses a vendor-specific download/recovery mode, such as MediaTek’s Download Mode or Qualcomm’s EDL mode) to gain code execution before the bootloader runs.
Boot chain patching : with Boot ROM-level access, the attacker patches or replaces the preloader to disable secure boot verification of subsequent stages. This allows loading a modified Trusted OS and modified Trusted Applications.
TEE patching : the attacker replaces or patches Gatekeeper to accept any credentials and issue valid authentication tokens regardless of input. They also patch or extract keys from Keymaster. As Quarkslab demonstrated in their proof-of-concept on Samsung A22 devices (MT6769V and MT6833V SoCs), this involved patching Samsung’s TEEGRIS operating system: first disabling verification of the root filesystem, then disabling TA signature verification, and finally patching Gatekeeper’s credential comparison to always succeed.
Key material extraction : with a rooted Android system and a compromised TEE, the attacker extracts the encrypted Synthetic Password and the intermediate decryption result from Keymaster.
Offline brute force : the attacker now has all the material needed for offline brute-forcing. The brute-force loop is:
applicationId
Because this brute-force runs entirely offline, on the attacker’s hardware, it is bounded only by computational resources and password complexity. A numeric PIN of six digits or fewer is trivially recoverable. Even longer numeric PINs fall quickly on dedicated hardware. Only a strong alphanumeric and symbols password provides meaningful resistance.
MediaTek devices are particularly vulnerable to this attack. Multiple MediaTek SoCs contain Boot ROM vulnerabilities that are publicly known and exploited by open-source tools such as MTKClient . Because Boot ROM code is immutable, these vulnerabilities cannot be patched: every device using the affected silicon is permanently compromised, regardless of Android version or security patch level. Quarkslab’s proof-of-concept targeted exactly this class of device, demonstrating the full chain from Boot ROM exploit to CE key recovery.
When a Secure Element is present, the attack chain is fundamentally harder. Even if the attacker achieves everything described above, they still cannot extract the Weaver secret from the Secure Element, under normal circumstances. Chances of a Secure Element exploit are pretty low, especially as being distributed as part of a widely available forensics commercial suite.
As anticipated, the Secure Element runs its own independent boot chain on physically separate silicon. Its keys cannot be extracted by the main SoC, and its rate-limiting logic is enforced in hardware that the attacker does not control.
The result is that brute-force can often only proceed online : each attempt must query the Secure Element, which enforces some kind of backoff. This slows down the attack significantly. A ten-digit PIN that falls in seconds to offline brute-force may take a long time against a properly implemented Secure Element. An alphanumeric password becomes likely unbreakable.
This is why, according to Cellebrite’s own February 2025 support matrix, brute-force capabilities are generally not available for Pixel devices with Titan M. The Secure Element is doing exactly what it was designed to do.
That said, the Secure Element is not immune to vulnerabilities. Quarkslab demonstrated code execution on the Titan M chip through CVE-2022-20233 , a single-byte out-of-bounds write in the Keymaster task that could be exploited to hijack execution flow. This vulnerability has since been patched, but it demonstrates that Secure Elements, while vastly more resistant than TEE-only configurations, can still have issues. Google is offering up to $1,500,000 for a zero-click vulnerabilities on the Pixel Titan M2 .
After the first unlock, the threat model fully changes. In AFU state, the CE decryption keys are loaded in memory and remain there. The lock screen is no longer a cryptographic barrier, it is just a user interface element, a screen overlay that prevents interaction but does not re-encrypt data.
This means that an AFU attacker does not need to brute-force credentials at all. They need to achieve code execution in the kernel or a privileged process, at which point they have direct access to the decrypted filesystem. The lock screen is bypassed, and no encryption needs to be broken.
The primary attack surface in AFU state is the USB interface . When a device is locked but in AFU state, the USB controller remains active and exposes the device’s kernel to a substantial attack surface.
As the diagram illustrates, a peripheral emulator connected to a locked device’s USB port can interact with the kernel through approximately 200 reachable drivers, including MTP (Media Transfer Protocol), MSC (Mass Storage Class), HID (Human Interface Device), Audio, and CVC (Communication Voice Class) subsystems. Each of these drivers is a potential attack surface for memory corruption vulnerabilities.
The exploit used by Cellebrite against a Serbian activist’s device in December 2024, as documented by Amnesty International , attempted to use at least three Linux kernel USB driver vulnerabilities:
bNumConfigurations
value exceeding allocated memory. This vulnerability affects legacy code present since Linux kernel 2.6.26 (2008) and was confirmed by CISA to be actively exploited in the wild.
The Cellebrite Turbo Link device, a specialized hardware adapter that connects between the forensic workstation and the target device, likely functions as a peripheral emulator capable of presenting itself as multiple USB device types in rapid succession, probing for each vulnerability to achieve kernel-level code execution.
Many of these USB drivers are loaded by default and remain reachable even when the device is locked. The kernel does not distinguish between a legitimate USB accessory and a malicious peripheral emulator, thus this is the main weakness that AFU exploitation often relies upon.
Once the attacker achieves kernel code execution through USB driver exploitation, the lock screen is irrelevant. The attacker can:
As we already knew, a device in AFU state is fundamentally less secure than a device in BFU state , regardless of the strength of the user’s password or the presence of a Secure Element. The Secure Element protects credential-derived keys at boot; it does not protect already-decrypted data in memory after the first unlock.
This is confirmed by Cellebrite’s February 2025 support matrix, which shows AFU extraction capabilities even for devices (including recent Pixels with stock Android) that resist BFU attacks. Notably, according to the same documentation, GrapheneOS on Pixel devices resists AFU extraction, probably thanks to the attack surface reduction and the USB restrictions that are implemented beyond stock Android.
Apple devices face analogous attack surfaces. The checkm8 exploit, publicly released in 2019, targets an unpatchable Boot ROM vulnerability present in all Apple devices from the iPhone 4S through the iPhone X (A5 through A11 SoCs). Like MediaTek Boot ROM vulnerabilities, checkm8 cannot be fixed through software updates: every affected device is permanently exploitable.
For newer Apple devices, AFU attacks rely on USB-based exploitation. Apple introduced USB Restricted Mode in iOS 11.4.1 to mitigate this: if the device has been locked for more than one hour, the Lightning or USB-C port is restricted to charging only, disabling data connections that forensic tools require.
However, Quarkslab’s
analysis of CVE-2025-24200 (reported by CitizenLab)
revealed that USB Restricted Mode was bypassable. The vulnerability, reported by Citizen Lab and patched in iOS 18.3.1, allowed a physical attacker to re-enable USB data connections on a locked device by exploiting a flaw in the Accessibility framework. The
profiled
daemon, which handles device management settings, failed to check whether the device was locked before processing requests to disable USB Restricted Mode. In other words,
the USB port was only soft-disabled
: something as simple as a logic bug in the policy enforcement allowed it to be re-enabled.
Forensic vendors have already started producing countermeasures to Apple’s inactivity reboot. Cellebrite’s Spring 2026 release for Inseyets advertises a “Safeguard Mode” that “mitigates the impact of iOS inactivity reboot timers by preserving access to a device” — in practice, preventing the device from returning to BFU state once they have AFU access. Magnet Forensics ships a hardware product called GrayKey Preserve which similarly aims to suppress the auto-reboot, network wipes and remote wipes on captured devices. These tools likely ship the same AFU exploits in a different, locked-down chassis that performs only preservation rather than extraction, which is also why they can move faster than the full extraction suites.
The attack vectors described above lead to a clear set of defensive priorities.
The most impactful single action when facing potential device seizure is to power the device off . This returns it to BFU state, where:
iOS users should enable Lockdown Mode . It hardens the device against exploitation across messaging, web, and attachments, and there is public-record evidence of it stopping at least one extraction attempt: an FBI CART court filing on an iPhone 13 explicitly states that “Because the iPhone was in Lockdown mode, CART could not extract that device” . The mechanism is not officially documented, but it is consistent with what Lockdown Mode is known to do: shrink the reachable attack surface, restrict USB more aggressively, and block the configuration-profile and MDM enrollment that forensic and “jailbreak” tools have historically abused to sideload unverified components.
If a device cannot be manually powered off, an automatic reboot mechanism provides the next best defense. After a configurable period without user authentication, the device reboots, returning to BFU state and purging decryption keys from memory.
GrapheneOS has implemented this feature for years. Apple introduced it in iOS 18. Stock Android on Pixel devices gained a limited version in Android 15, but its implementation remains less configurable and less aggressive than GrapheneOS’s. The feature is the most useful if the timeout is short (2-4 hours) and loses its value when its multiple days, as Google enforces likely as a result of negotiation with law enforcement. GrapheneOS in particular allows the timeout to be configured very low, precisely because the team has long considered the risk of an exploit being produced to inhibit the reboot itself.
Disabling USB data transfer when the device is locked directly eliminates the AFU attack surface described above. Android 15 introduces USB restriction options; iOS has had USB Restricted Mode since version 11. GrapheneOS provides more trustworthy and configurable USB restriction.
The brute-force analysis makes the case for strong passwords unambiguous:
The password is only required at boot. Biometric authentication (fingerprint, face recognition) handles daily unlocking, unless the user is in a jurisdiction where physical coercion is likely, whether lawfully or not. The marginal inconvenience of entering a strong password once after each reboot is minimal compared to the protection it provides.
According to Cellebrite’s own February 2025 documentation:
A subsequent Cellebrite matrix leaked in October 2025 suggests Cellebrite has since also lost Full File System extraction support against unlocked GrapheneOS devices.
It is worth noting that alternative Android distributions such as LineageOS or CalyxOS, while valuable for other reasons, do not meaningfully change the forensic unlocking picture from the stock or vendor ROM.
Applications that implement their own encryption layer with a separate password can provide defense-in-depth against full device compromise. Password managers’ master password vaults are a good example: even if the entire device filesystem is extracted, the vault remains encrypted under a key that the forensic tool has not obtained.
However, the effectiveness of application-level protection depends on several factors: whether the app actually implements its own encryption independently from the OS credential protection, whether decryption keys remain in memory after first unlock (making them vulnerable to AFU extraction), whether the app relies on the system biometric authentication (which, without a Secure Element, is broken along with the rest of the OS key hierarchy), and whether notifications or message previews are cached in plaintext outside the app’s encrypted storage.
The way these tools operate is not magic nor secret. The more we collect samples, reverse engineer and read promotional and support material, the better we understand capabilities and defenses.
As we said many times these tools simply shouldn’t commercially exist. The companies that build these tools are active participants in the zero-day vulnerability trade, stockpiling security flaws that weaken every device, for every user, everywhere. The technical defenses described here are effective but place the burden on individuals and communities.
Update (20 May 2026): following feedback from Final of the GrapheneOS Foundation, this post was updated with information about iOS Lockdown Mode, forensic-vendor countermeasures to iOS inactivity reboot (Cellebrite Safeguard Mode and Magnet GrayKey Preserve), GrapheneOS’s auto-reboot design rationale, and the October 2025 Cellebrite matrix leak.
Running a frontier-scale model locally means keeping all its weights in GPU memory; the largest models no longer fit on one machine. Two NVIDIA DGX Stations connected over ConnectX-8 RDMA serve one model through a single endpoint, with tensor parallelism splitting the model weights and computation across both GPUs.
The NVIDIA GLM-5.3 NVFP4 model, a quantized version of Z.ai ’s mixture-of-experts (MoE) model, has 753 billion parameters, with 40 billion activated per token. Sparse activation reduces computation, but all model weights still need to remain available because each token can be routed to different experts. At about 464 GB, the checkpoint exceeds the 252 GB of HBM3e on a single GB300 GPU. This tutorial uses two DGX Stations to keep the weights in GPU memory, with CPU weight offload disabled.
Before starting, connect the two Stations with the Connect Two DGX Stations playbook .
This post shows how to serve GLM-5.3 locally across two NVIDIA DGX Stations with vLLM, send a request, and measure behavior under concurrent load. Tensor parallelism (TP=2) splits the model’s tensors across the two GB300 GPUs. Both Stations compute every request, and Station A returns the answer through one OpenAI-compatible API. By the end, you’ll have a working endpoint and a baseline for how it behaves under load.
The companion video follows the same workflow.
This tutorial uses a separate computer, such as your laptop, to manage both Stations. Start by opening an SSH session to each Station from that computer. Alternatively, work from a local terminal on each Station. Run every command in this step on both Stations unless it starts with “On A.”
The two Stations run the same container and checkpoint in different roles: Station A (rank 0) hosts the API, and Station B (rank 1) runs only a worker, with no API server.
First, check Docker access and collect the network values you’ll use later:
docker version ibdev2netdev ip -br addr
Note:
If the
docker version
output has no
Server
section, the client cannot reach the Docker daemon. If the error is
permission denied
, follow the
Docker post-installation procedure
: add your user to the
docker
group with
sudo usermod -aG docker "$USER"
, run
exit
, then reconnect and rerun
docker version
. The
docker
group grants root-level privileges.
|
|---|
The
ibdev2netdev
output lists the two direct rails,
cx8r0
and
cx8r1
. Pick one for serving traffic, for example
cx8r1
, and note two things for it on each Station:
ibdev2netdev
line that ends with the rail’s name. In
mlx5_1 port 1 ==> cx8r1 (Up)
, the device is
mlx5_1
.
ip -br addr
line that starts with the rail’s name. In
cx8r1 UP 192.168.101.1/24
, the address is
192.168.101.1
.
The rail name and device are the same on both Stations; only the IPv4 address differs.
Next, create
~/glm53.env
on each Station. This file stores the values that later commands use:
nano ~/glm53.env
Paste the following block and replace each
<...>
placeholder, keeping the quotes, with the values you noted.
RANK="<NODE_RANK>" # RANK="0" on Station A, RANK="1" on Station B
HEAD_IP="<STATION_A_IPV4_ADDRESS>" # IPv4 address you noted on Station A; same in both files
WORKER_IP="<STATION_B_IPV4_ADDRESS>" # IPv4 address you noted on Station B; same in both files
RAIL_IFACE="<RAIL_NAME>" # Rail you picked, for example cx8r1; same in both files
RAIL_HCA="<RDMA_DEVICE>" # RDMA device you noted, for example mlx5_1; same in both files
IMG=vllm/vllm-openai:v0.30.0-aarch64
IMG+=@sha256:4864d46625cbc3307623e29ac742030655e27249feba7b97ec925ce4cc4dfb56
MODEL_REPO=nvidia/GLM-5.3-NVFP4
MODEL_REV=e3b8f9f2fad29727dfa95e766c5cac18ea1414bf
MODEL_HOST="$HOME/models/GLM-5.3-NVFP4"
CONTAINER=glm53-full
PORT=8000
if [ "$RANK" = 0 ]; then
NODE_IP=$HEAD_IP; PEER_IP=$WORKER_IP
else
NODE_IP=$WORKER_IP; PEER_IP=$HEAD_IP
fi
GPU_UUID=$(nvidia-smi --query-gpu=uuid,name --format=csv,noheader |
awk -F, '$2 ~ /GB300/ {gsub(/ /,"",$1); print $1; exit}')
For example, with the default addresses on
cx8r1
, Station A’s file starts like this. Station B’s file is identical except for
RANK="1"
:
RANK="0"
HEAD_IP="192.168.101.1"
WORKER_IP="192.168.101.2"
RAIL_IFACE="cx8r1"
RAIL_HCA="mlx5_1"
MODEL_HOST
is built from your home directory, and Step 2 copies the checkpoint over SSH to the same path on Station B.
Note:
Later steps start with
source ~/glm53.env
to load these values.
Run this command again whenever you open a new SSH session.
|
|---|
On both Stations, load the values and check storage, connectivity, and baseline memory:
source ~/glm53.env
mkdir -p "$MODEL_HOST" && df -h "$MODEL_HOST"
ethtool "$RAIL_IFACE"
ip link show dev "$RAIL_IFACE"
ping -I "$RAIL_IFACE" -M do -s 8972 -c 3 "$PEER_IP"
timedatectl show -p NTPSynchronized --value
nvidia-smi
These checks catch cabling and addressing mistakes before they surface as NCCL timeouts. Expect a
400000Mb/s
link, MTU 9000, successful jumbo-frame pings, and synchronized time.
nvidia-smi
should show no compute processes on the GB300. On a Station with a display GPU, Xorg can appear on both GPUs with a few MiB.
Tip:
Note the GPU memory use shown by
nvidia-smi
; Step 4 compares it with the loaded model.
|
|---|
Step 2 copies the checkpoint from A to B over SSH, so A needs passwordless access to B. On A, create a key without a passphrase (see SSH keys for details), copy its public key to B after checking B’s host fingerprint, and confirm the login:
ssh-keygen -t ed25519
ssh-copy-id "$WORKER_IP"
ssh -o BatchMode=yes "$WORKER_IP" hostname
Tensor parallelism requires both ranks to run the same software against the same weights. Start by pulling the pinned image on both Stations:
docker pull "$IMG" &&
docker image inspect "$IMG" --format '{{.Architecture}} {{.RepoDigests}}'
The pull can take several minutes. Matching arm64 digests mean both ranks run identical software.
On A, download the pinned checkpoint. At about 464 GB, it takes roughly an hour at 1 Gb/s, or about six minutes at 10 Gb/s:
mkdir -p "$MODEL_HOST"
docker run --rm --network host -v "$MODEL_HOST:/model" \
--entrypoint bash "$IMG" -lc \
"exec hf download '$MODEL_REPO' --revision '$MODEL_REV' --local-dir /model"
When
hf download
prints
Downloaded
, copy the files to B. On A:
ssh "$WORKER_IP" "mkdir -p '$MODEL_HOST'" &&
rsync -aH --info=progress2 --exclude '.cache/' \
"$MODEL_HOST/" "$WORKER_IP:$MODEL_HOST/"
Each disk keeps the full checkpoint; vLLM partitions the weights across the GPUs at load time, with no further quantization.
On A, compare both copies (the check reads B’s file list over SSH), then validate the checkpoint:
(
set -euo pipefail
L=$(find "$MODEL_HOST" -path '*/.cache' -prune -o \
-type f -printf '%P %s\n' | LC_ALL=C sort | sha256sum)
R=$(ssh "$WORKER_IP" "set -o pipefail; find '$MODEL_HOST' \
-path '*/.cache' -prune -o -type f -printf '%P %s\\n' | \
LC_ALL=C sort | sha256sum")
test "$L" = "$R"
test "$(find "$MODEL_HOST" -maxdepth 1 \
-name 'model-*-of-00050.safetensors' | wc -l)" = 50
python3 -c "import json; c=json.load(open('$MODEL_HOST/config.json')); \
assert c['architectures']==['GlmMoeDsaForCausalLM']; \
assert c['quantization_config']['quant_algo']=='MIXED_PRECISION'"
echo MODEL_READY
)
MODEL_READY
means both Stations hold the same file names and sizes in the expected layout.
MIXED_PRECISION
is expected: NVFP4 quantization targets MoE-block linear weights and activations, not every tensor.
This step turns two machines into one service: the same launch script runs on both Stations, reads
~/glm53.env
, and starts one vLLM rank on each. Two settings matter most if you adapt it:
--max-model-len 98304
, the context ceiling in tokens, which covers input plus output, and
--gpu-memory-utilization 0.93
, which gives vLLM 93% of GPU memory. If you change other flags, change one at a time and test again.
For the latest recommended configurations, see NVIDIA’s Local AI recipe repository .
Security note:
--host 0.0.0.0
with
--network host
exposes the unauthenticated API on every Station A interface, including management. Firewall the port to intended clients, and add authentication and TLS before wider access.
|
|---|
On both Stations, create a file named
~/launch-glm53.sh
:
nano ~/launch-glm53.sh
The script enables multi-token prediction (MTP), a form of speculative decoding: the model’s MTP layer drafts four tokens per step, and vLLM verifies them with the full model before accepting them, so each step can produce several tokens. The gain depends on how often drafts are accepted, which varies with the prompt.
FP8 KV-cache storage halves cache memory compared with 16-bit storage, leaving room for more tokens. Prefix caching is enabled to avoid reprocessing prompt prefixes the server has already seen. Paste the script below; it checks your configuration, finds the RoCE GID index for the selected rail, and starts this Station’s vLLM rank in a container:
set -euo pipefail
source "$HOME/glm53.env"
case "$RANK" in 0|1) ;; *) echo "Invalid RANK" >&2; exit 1;; esac
test -n "$GPU_UUID"
test -f "$MODEL_HOST/config.json"
GID_INDEX=$(/usr/sbin/show_gids 2>/dev/null |
awk -v d="$RAIL_HCA" -v ip="$NODE_IP" \
'$1==d && $5==ip && $6=="v2" {g=$3} END {if(g!="") print g}')
test -n "$GID_INDEX"
HEADLESS=
if [ "$RANK" = 1 ]; then HEADLESS=--headless; fi
SPEC_CONFIG='{"method":"mtp","num_speculative_tokens":4}'
KERNEL_CONFIG='{"enable_flashinfer_autotune":false,"moe_backend":"flashinfer_cutlass"}'
COMPILE_CONFIG='{"cudagraph_mode":"FULL_DECODE_ONLY","cudagraph_capture_sizes":[5,10,20,40,80],"pass_config":{"fuse_allreduce_rms":false}}'
docker run -d --name "$CONTAINER" \
--gpus device="$GPU_UUID" --network host --ipc host --shm-size 32g \
--device /dev/infiniband --cap-add IPC_LOCK \
--ulimit memlock=-1 --ulimit stack=67108864 \
-v "$MODEL_HOST:/model:ro" \
-e RANK="$RANK" -e HEADLESS="$HEADLESS" \
-e MASTER_ADDR="$HEAD_IP" -e MODEL_REPO="$MODEL_REPO" -e PORT="$PORT" \
-e SPEC_CONFIG="$SPEC_CONFIG" -e KERNEL_CONFIG="$KERNEL_CONFIG" \
-e COMPILE_CONFIG="$COMPILE_CONFIG" \
-e NCCL_CUMEM_ENABLE=1 -e NCCL_IB_HCA="$RAIL_HCA" \
-e NCCL_IB_GID_INDEX="$GID_INDEX" \
-e NCCL_IB_TIMEOUT=22 -e NCCL_IB_RETRY_CNT=7 \
-e VLLM_ALLREDUCE_USE_FLASHINFER=0 -e VLLM_ALLREDUCE_USE_SYMM_MEM=0 \
-e NCCL_SOCKET_IFNAME="$RAIL_IFACE" -e GLOO_SOCKET_IFNAME="$RAIL_IFACE" \
-e NCCL_NET_GDR_LEVEL=5 -e NCCL_DEBUG=INFO -e NCCL_DEBUG_SUBSYS=INIT,NET \
-e NCCL_DEBUG_FILE='/tmp/nccl_%h_%p.log' -e VLLM_HOST_IP="$NODE_IP" \
-e VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS=1800 \
-e PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True \
-e VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 -e FLASHINFER_DISABLE_VERSION_CHECK=1 \
--entrypoint bash "$IMG" -lc '
set -euo pipefail
# Use NCCL 2.30.7 from the image: older versions can deadlock
# cross-node CUDA graph replays over RoCE (vLLM issue #52504).
export VLLM_NCCL_SO_PATH=$(python3 -c "import nvidia.nccl,os;
print(os.path.join(list(nvidia.nccl.__path__)[0], \"lib\", \"libnccl.so.2\"))")
test -f "$VLLM_NCCL_SO_PATH"
EXTRA=()
if [ -n "$HEADLESS" ]; then EXTRA+=("$HEADLESS"); fi
exec vllm serve /model --served-model-name "$MODEL_REPO" \
--host 0.0.0.0 --port "$PORT" \
--nnodes 2 --node-rank "$RANK" --master-addr "$MASTER_ADDR" \
--master-port 29501 --tensor-parallel-size 2 \
--speculative-config "$SPEC_CONFIG" \
--max-model-len 98304 --max-num-batched-tokens 8192 \
--block-size 128 --max-num-seqs 16 \
--trust-remote-code --disable-custom-all-reduce \
--kv-cache-dtype fp8 --enable-prefix-caching \
--gpu-memory-utilization 0.93 \
--enable-prompt-tokens-details \
--kernel-config "$KERNEL_CONFIG" --compilation-config "$COMPILE_CONFIG" \
--distributed-timeout-seconds 1800 \
--enable-auto-tool-choice --tool-call-parser glm47 --reasoning-parser glm47 \
"${EXTRA[@]}"
'
Run the script on B first, then on A:
bash ~/launch-glm53.sh
Each command prints a container ID and returns immediately; the service is not ready yet. B’s worker waits for A to join, then each Station loads its share of the weights from local storage, prepares kernels, and captures CUDA graphs. This takes several minutes.
On A, follow the log to see when the service is ready (
--since
hides output from earlier runs):
docker logs --follow --since "$(docker inspect \
--format '{{.State.StartedAt}}' "$CONTAINER")" "$CONTAINER"
When the log shows
Application startup complete
, press Ctrl+C to stop following it; the service keeps running.
At this point one model spans two machines. Neither GPU holds a complete copy, and neither can answer a request alone: every token needs both ranks to exchange partial results over the RoCE rail.
The remaining GPU memory holds the KV cache, which stores the context of in-flight requests. The startup log reports its
capacity
(GPU KV cache size). All requests in flight share it, so longer prompts or more users need more of it. If you run out, lower
--max-model-len
or send fewer requests at once.
On A, check the API (
127.0.0.1
is A itself):
docker exec "$CONTAINER" curl -fsS --max-time 10 \
"http://127.0.0.1:$PORT/health" >/dev/null && echo HEALTH_OK
HEALTH_OK
proves that Station A answers. Next, on both Stations, check that the ranks communicate over GPU RDMA rather than falling back to TCP sockets. The check reads the NCCL logs that the launcher writes through
NCCL_DEBUG=INFO
, and the same block shows the loaded memory:
docker exec "$CONTAINER" bash -lc '
set -euo pipefail
files=(/tmp/nccl_*.log)
test -e "${files[0]}"
grep -hE "NET/IB.*GDRDMA|GPU Direct RDMA Enabled" "${files[@]}" >/dev/null
grep -hF "$NCCL_IB_HCA" "${files[@]}" >/dev/null
if grep -hE "NET/Socket|NCCL WARN|NCCL ERROR" "${files[@]}"; then
exit 1
fi
echo RDMA_CHECK_OK
'
nvidia-smi
RDMA_CHECK_OK
means the check passed with no warnings. In
nvidia-smi
, A shows the
VLLM::Worker_TP0
process and B shows
VLLM::Worker_TP1
, one rank per GPU. The startup log reports about 218 GiB of weights per GPU, roughly half the checkpoint, which confirms that the model is split across the two GPUs.
| Measurement | Station A | Station B |
|---|---|---|
| GB300 GPU used (GiB) | 0.01 → 231.35 | 0.00 → 231.34 |
On A, send a chat request through the OpenAI-compatible API:
docker exec "$CONTAINER" curl -fsS --max-time 120 \
"http://127.0.0.1:$PORT/v1/chat/completions" \
-H 'Content-Type: application/json' \
-d '{"model":"nvidia/GLM-5.3-NVFP4",
"messages":[{"role":"user","content":"Quarterly units sold: Q1 = 120; Q2 = 180; Q3 = 150. Summarize the trend in one sentence and calculate the percentage change from Q1 to Q2."}],
"temperature":0,"max_tokens":4096,
"chat_template_kwargs":{"reasoning_effort":"low"}}' |
python3 -c 'import json,sys; c=json.load(sys.stdin)["choices"][0];
print(c["message"]["content"]); print("finish_reason:",c["finish_reason"])'
The response should look like this:
**Trend:** Units sold rose sharply in Q2 before partially declining in Q3, remaining above the Q1 level.
**Q1 → Q2 percentage change:** (180 - 120) / 120 × 100 = **50% increase**
finish_reason: stop
finish_reason: stop
means the model finished its answer instead of hitting the token limit. The request sets
reasoning_effort
to
low
in
chat_template_kwargs
. GLM-5.3 also accepts
high
and
max
, which let it reason longer before answering, at the cost of latency. Because the launcher enables tool calling (
--enable-auto-tool-choice
), agent frameworks that use the OpenAI tools API can call the same endpoint.
AIPerf , the NVIDIA benchmarking tool for inference endpoints, measures throughput and latency. Installing it inside the serving container can change vLLM’s dependencies, so on A, install it in its own virtual environment:
sudo apt update &&
sudo apt install -y python3.12-venv python3.12-dev build-essential &&
python3.12 -m venv "$HOME/.venvs/aiperf-0.12.0" &&
"$HOME/.venvs/aiperf-0.12.0/bin/pip" install 'aiperf==0.12.0' &&
"$HOME/.venvs/aiperf-0.12.0/bin/pip" check
The install should end with
No broken requirements found
.
AIPerf can send synthetic prompts or replay an existing dataset. This tutorial uses the 80 Coding conversations from SPEED-Bench, a set of real prompts built to evaluate speculative decoding, so MTP is measured on realistic text. SPEED-Bench’s preparation script fetches these prompts from several Hugging Face datasets, including the gated cais/hle : if you haven’t already, open its page and select Agree and access repository before you continue. Then, on A, log in to Hugging Face:
"$HOME/.venvs/aiperf-0.12.0/bin/hf" auth login
Next, download and prepare the dataset. See the official AIPerf guide for details:
SPEED_BENCH_DIR="$HOME/datasets/speed-bench"
mkdir -p "$SPEED_BENCH_DIR"
curl -fLsS https://raw.githubusercontent.com/NVIDIA-NeMo/Skills/refs/heads/main/nemo_skills/dataset/speed-bench/prepare.py | \
"$HOME/.venvs/aiperf-0.12.0/bin/python" - --config qualitative --output_dir "$SPEED_BENCH_DIR"
On A, check the dataset and service. Continue when the check prints
BENCHMARK_READY
:
(
set -euo pipefail
source ~/glm53.env
curl -fsS "http://$HEAD_IP:$PORT/health" >/dev/null
"$HOME/.venvs/aiperf-0.12.0/bin/python" - <<'PY_CHECK'
import json
from pathlib import Path
root = Path.home()
path = root / "datasets/speed-bench/qualitative.jsonl"
assert path.exists(), "Dataset missing: rerun the SPEED-Bench preparation"
rows = [json.loads(line) for line in path.read_text().splitlines() if line.strip()]
coding = [row for row in rows if row["category"] == "coding"]
assert len(coding) == 80, "Expected 80 Coding conversations"
assert sum(len(row["messages"]) for row in coding) == 89
assert all("FULL BENCHMARK DATA SHOULD BE FETCHED" not in message["content"]
for row in coding for message in row["messages"])
print("BENCHMARK_READY: dataset has 80 Coding conversations, 89 turns in total.")
PY_CHECK
)
The full sweep covers concurrency 1, 8, 16, and 32. At each level, AIPerf sends 3×C warmup requests, then measures 10×C requests, where C is the concurrency. Some conversations are sent more than once at higher concurrency.
Benchmark requests use the model’s default reasoning effort (max) and an 8,192-token output cap; responses can finish before reaching it. Full sweeps can take several hours.
A two-hour request timeout leaves room for long responses,
--server-metrics
collects server counters used to measure MTP acceptance, and
--export-level raw
keeps each response for inspection.
For a quick test, run the block below on A with both containers running and no other API traffic. It tests C1 and C8 with prefix caching enabled, as in the reference measurements in Table 2, below.
(
set -euo pipefail
source ~/glm53.env
CODING_DATASET="$HOME/datasets/speed-bench/qualitative.jsonl"
test -f "$CODING_DATASET"
export CONCURRENCIES=${CONCURRENCIES:-"1 8"} # Quick run: C1 and C8.
# Optional full benchmark: follow the reproduction instructions below.
# Step 3: --max-num-seqs 16 -> export CONCURRENCIES="1 8 16"
# Step 3: --max-num-seqs 32 -> export CONCURRENCIES=32
RUN_DIR="$HOME/aiperf-results/blog-coding-$(date +%Y%m%d-%H%M%S)"
for C in $CONCURRENCIES; do
ART="$RUN_DIR/c$C"
env -u HF_HUB_OFFLINE -u TRANSFORMERS_OFFLINE \
"$HOME/.venvs/aiperf-0.12.0/bin/aiperf" profile \
-m "$MODEL_REPO" --url "http://$HEAD_IP:$PORT" \
--endpoint-type chat --streaming --tokenizer "$MODEL_HOST" \
--custom-dataset-type speed_bench_coding --input-file "$CODING_DATASET" \
--request-count "$((10 * C))" --warmup-request-count "$((3 * C))" \
--osl 8192 \
--use-server-token-count --concurrency "$C" --random-seed 42 \
--request-timeout-seconds 7200 \
--server-metrics "http://$HEAD_IP:$PORT/metrics" \
--export-level raw --artifact-dir "$ART"
printf "Results: %s\n" "$ART"
done
printf "Results directory: %s\n" "$RUN_DIR"
)
AIPerf saves metrics, raw responses, and logs in the results directory. Warmup requests are excluded from the reported metrics.
Optional: Reproduce Table 2
. In
~/launch-glm53.sh
from Step 3 on both Stations, keep
--enable-prefix-caching
and set
--max-num-seqs
to 16 or 32 for the corresponding group shown in the comments above. Before each group, stop and remove the current containers on A, then B (
docker stop --timeout 60 "$CONTAINER"
, followed by
docker rm "$CONTAINER"
). Relaunch the updated script on B, then A with bash
~/launch-glm53.sh
and wait for
Application startup complete
. On A, run the matching
export CONCURRENCIES
command from the comments, then rerun the AIPerf block.
To test without prefix caching, replace
--enable-prefix-caching
with
--no-enable-prefix-caching
in the Step 3 script on both Stations, then recreate the containers as above. Performance may differ from Table 2.
Figure 2 compares overall output throughput across measured requests with mean per-user throughput. Token counts include reasoning.
Table 2, below, shows how throughput and latency change as more requests share the service.
| Configured concurrency |
Overall throughput
(tok/s) |
Mean request latency
(s) |
Mean TTFT
(ms) |
Mean inter-token latency
(ms/token) |
| 1 | 107.4 | 49.84 | 479.75 | 8.78 |
| 8 | 386.0 | 114.17 | 433.79 | 19.01 |
| 16 | 607.8 | 136.46 | 482.90 | 23.77 |
| 32 | 385.0 | 453.54 | 899.36 | 77.90 |
Overall throughput peaks at 607.8 tok/s at C16. It falls to 385.0 tok/s at C32, where mean request latency is 453.5 s. Higher concurrency also reduces mean per-user throughput, from 115.3 tok/s at C1 to 13.0 tok/s at C32.
After the requests finish, stop the vLLM container on A, then on B:
docker stop --timeout 60 "$CONTAINER"
docker inspect --format \
'Status={{.State.Status}} Running={{.State.Running}}' "$CONTAINER"
nvidia-smi
The status should read
Status=exited Running=false
, with no vLLM processes in
nvidia-smi
; the checkpoint, containers, and results stay on disk. To resume, run
docker start "$CONTAINER"
on B, then A, and repeat the Step 4 checks.
source ~/glm53.env
after reconnecting; verify A-to-B key authentication and B’s fingerprint.
docker logs "$CONTAINER"
on both nodes; verify the checkpoint and the GID, and rerun the playbook’s validation (script 07).
--max-model-len
or concurrency, then retest.
You now have a 753-billion-parameter model running behind one local API on two NVIDIA DGX Stations, with every weight in GPU memory. That opens up work that’s hard to do on a hosted endpoint: running inference on sensitive or proprietary data, prototyping agents locally, and iterating on prompts without per-token costs.
Connect your own application using the vLLM serving documentation , then rerun AIPerf with your prompts to find the concurrency that fits your workload. A frontier-scale model is now ready to build on, right from your desk.
A browser for coding agents on macOS, built on WebKit (Safari's engine). I run several coding agents at once, and Playwright's Chrome windows kept stealing my keyboard, while headless browsers got blocked by some sites and left me guessing what went wrong. agweb is one window that never takes focus: agents drive it from the shell with
agweb
, a playwright-cli-style command, and you watch them all live.
Idle tabs are suspended: on my Mac five open pages sit at 0% CPU, where Chrome's GPU process kept five to seven cores busy.
| Five idle pages | Memory |
|---|---|
| agweb | 590 MB |
| Headless Chrome | 730 MB |
| Playwright Chrome | 1.6 GB |
-p work
) keeps its logins and is shared by every agent using it, at the same time.
snapshot --diff
and
find
show only what matters, and every action reports what it changed.
fill --secret-cmd 'pass show site'
types a secret the agent never sees in replies. 1Password and Bitwarden CLIs work too.
agweb -w task adblock off
).
video-start
records a tab to MP4, with the pointer and clicks drawn in.
Needs macOS 26 or later. Download
Agweb.dmg
from
Releases
, drag Agweb to Applications and open it. Then Help ▸ Install Command Line Tool and Help ▸ Install Agent Skill (for Claude Code and Codex). Both are links into the app, so they update with it.
To build from source instead (Xcode 26 or later):
./scripts/build.sh build/Agweb.app/Contents/Helpers/agweb install-cli agweb install-skill
agweb -w task open en.wikipedia.org/wiki/WebKit # a workspace for this task; starts the app if needed agweb -w task snapshot # the page as a tree with [ref=eN] handles agweb -w task click 'role=button[name="Main menu"]'
The click's reply already says what it did, so the agent needs no second snapshot:
### Changes
- navigation "Site" [ref=e2]
- - button "Main menu" [ref=e3]
+ - button "Main menu" [checked] [expanded] [ref=e3]
+ - list [ref=e1167]
+ - listitem [ref=e1168]
+ - link "Main page" [ref=e1169]
agweb help
lists every command. Settings (⌘,) has text size, dashboard columns, a CPU and memory readout and the ad blocker switch.
Same commands where possible, so agents already know them; a Playwright name it lacks suggests its own (
scroll-to
→
scroll-into-view
). On top:
ask
hands the tab to you for a login, MFA code or CAPTCHA, without taking focus.
text
returns the page's article as markdown.
route
mocks fetch and XHR only;
requests
lists images, scripts and styles by URL only (
--static
).
./scripts/selftest.sh
runs every command against a local page in a separate instance;
swift test
runs the unit tests.
AGWEB_ROOT=/tmp/dir
starts a second instance beside your own that keeps everything in that folder.
Defuddle
(MIT) is bundled for
text
.
A 64-bit Out-of-Order Superscalar RISC-V Processor (
RV64IMAFDV + Zba + Zbb + Zicsr + Zifencei
) booting mainline Linux 6.6.50 and BusyBox userspace under Sv39 virtual memory.
Fursoy Slice-1 (
fursoy_s1_core
/
fursoy_s1_soc
) is a clean-slate 64-bit out-of-order superscalar RISC-V processor implemented in SystemVerilog, featuring Sv39 demand paging, machine/supervisor/user privilege separation, cycle-exact hardware performance telemetry, and 500 MHz Nangate 45nm standard-cell synthesis closure across 8 core functional blocks.
fursoy_s1_core
)
:
M/S/U
privilege modes,
medeleg
/
mideleg
,
WFI
,
MRET
/
SRET
).
ROB_DEPTH = 128
) with 4-bit wrap-safe epoch tags and precise exception/interrupt flush recovery.
PRF_SIZE = 160
,
128
speculative free-list entries) plus
8 branch checkpoints
(
NUM_CHECKPOINTS = 8
) for single-cycle speculative RAT rollback.
INT_IQ_DEPTH = 32
),
32-entry Memory IQ
(
MEM_IQ_DEPTH = 32
),
FP IQ
(
FPRF_SIZE = 64
), and decoupled
8-entry Vector IQ
(
VLEN = 256
,
ELEN = 64
,
48
vector physical registers).
fursoy_s1_alu
and
fursoy_s1_branch_unit
(single-cycle execution + carry-free target equality), 3-stage pipelined multiplier, and hardware divider.
64
-entry 4-way set-associative base TLB (
16
sets, Tree-PLRU) +
8
-entry 2 MiB / 1 GiB superpage CAM with
32
-entry Translation Request Table (
TRT_DEPTH = 32
).
64
-entry 4-way set-associative base TLB +
8
-entry superpage CAM.
fursoy_s1_ptw
)
: Walks Sv39 page tables with
non-destructive L1D dirty snoop coherency
so page-table writes sitting dirty in L1D are observed directly without eviction, paired with
SFENCE.VMA
store-queue drain and D-cache clean synchronization.
fursoy_s1_l1i
)
:
16 KiB
, 4-way set-associative (
64
sets ×
64 B
), VIPT-safe with conservative next-line prefetcher and
2
I-MSHRs.
fursoy_s1_l1d
)
:
16 KiB
, 4-way set-associative (
64
sets ×
64 B
),
8-bank
(
PA[5:3]
) non-blocking data cache with
16
-entry Load Queue,
16
-entry Store Queue,
4
MSHRs, and
2
-entry Writeback Buffer.
fursoy_s1_soc
)
:
256 MiB
DRAM interface (
0x8000_0000
),
CLINT
(
0x0200_0000
),
PLIC
(
0x0C00_0000
,
31
external sources),
16550 UART
(
0x1000_0000
), and custom minimal
SBI v2.0
M-mode firmware (
Base
,
TIME
,
SRST
,
DBCN
).
Evaluated standalone across 8 core functional blocks using
Yosys 0.33
+
sv2v v0.0.13
+
OpenSTA 3.1.0
on
NangateOpenCellLibrary (45nm Typical, 1.10V, 25C)
targeting
500 MHz (
2.000 ns
clock period)
(
tools/run_s1_synth.py --run-synth
, full report in
build/synth/s1_synth_report.json
):
| Module | Type | Cells | DFFs | Area (kGE) | Baseline Arrival / WNS | Optimized Arrival | Opt WNS @ 500 MHz |
|---|---|---|---|---|---|---|---|
fursoy_s1_branch_unit
|
Comb | 3,285 | 0 | 4.49 |
3.712 ns (
-1.712 ns
)
|
0.629 ns | +1.371 ns (MET) |
fursoy_s1_csr
|
Seq | 13,438 | 1,688 | 25.81 |
22.776 ns (
-21.120 ns
)
|
1.828 ns | +0.133 ns (MET) |
fursoy_s1_dtlb
|
Seq | 50,417 | 6,515 | 99.83 |
11.011 ns (
-9.211 ns
)
|
1.249 ns | +0.551 ns (MET) |
fursoy_s1_itlb
|
Seq | 36,238 | 6,304 | 77.12 |
4.057 ns (
-2.102 ns
)
|
1.198 ns | +0.602 ns (MET) |
fursoy_s1_agu
|
Comb | 321 | 0 | 0.66 |
2.301 ns (
-0.301 ns
)
|
1.901 ns | +0.099 ns (MET) |
fursoy_s1_ptw
|
Seq | 1,765 | 329 | 3.67 |
1.956 ns (
+0.005 ns
)
|
0.948 ns | +1.013 ns (MET) |
fursoy_s1_decode
|
Comb | 1,489 | 0 | 1.92 |
0.875 ns (
+1.125 ns
)
|
0.663 ns | +1.337 ns (MET) |
fursoy_s1_alu
|
Comb | 4,066 | 0 | 5.93 |
3.823 ns (
-1.823 ns
)
|
0.994 ns | +1.006 ns (MET) |
| Total (8 Core Blocks) | — | 111,019 | 14,836 | 219.43 | — | 8 / 8 MET | TNS = 0.00 ns |
Note: Total standard-cell area across these 8 standalone blocks is
175,106.74 um^2(NAND2_X1 = 0.798 um^2). Full-SoC place-and-route and SRAM macro compilation are not yet executed.
The Milestone 9 closeout (
tools/run_s1_m9_closeout.py
, saved in
results/s1-m9-closeout.json
) boots mainline
Linux 6.6.50
in Verilator with zero kernel panics, zero oopses, zero access faults, and
0
CPI conservation errors across
89,861,075
simulated cycles (
76,236,390
retired instructions,
2,227,761
U-mode commits,
2,255
demand page faults /
1,027
U-mode,
IPC = 0.84838
):
[ 0.000000] Linux version 6.6.50 ... (riscv64-linux-gnu-gcc 13.3.0)
[ 0.000000] SBI specification v2.0 detected
[ 0.000000] SBI implementation ID=0xf00501 Version=0x1
[ 0.000000] earlycon: uart8250 at MMIO32 0x0000000010000000 (options '')
...
[ 6.809584] Run /init as init process
[INIT] Fursoy Slice-0 Linux BusyBox Userspace active!
FURSOY_USERSPACE_BEGIN
[TEST 01] uname ... Linux (none) 6.6.50 riscv64 GNU/Linux
...
[TEST 20] repeated process creation/exit
[TEST 21] userspace memory stress
[MEM_STRESS_START] Running stack and heap multi-width memory validation...
[MEM_STRESS_PASS] All stack, heap, multi-width, and strided tests passed.
FURSOY_USERSPACE_PASS
Every cycle is mutually exclusively owned by one architectural bucket asserted continuously in hardware (
sum(C_k) == mcycle = 89,861,075
,
cpi_conservation_errors = 0
):
| CPI Category | Cycles | Share | Description |
|---|---|---|---|
C_productive
|
43,079,458 | 47.94% | Active useful graduation / commit cycles |
C_br_recover
|
15,024,530 | 16.72% | Branch misprediction & exception flush recovery |
C_idle_other
|
14,806,625 | 16.48% | WFI idle, non-stalled pipeline drain & other bubbles |
C_be_rename
|
5,709,439 | 6.35% | Rename stalls (ROB / Free List / checkpoint capacity) |
C_mem_stall
|
5,549,273 | 6.18% | L1D miss / bank conflict / DTLB-PTW memory stalls |
C_be_sched
|
2,736,785 | 3.05% | Issue queue scheduling / execution operand stalls |
C_serialize
|
2,450,147 | 2.73% |
CSR /
SFENCE.VMA
/
FENCE.I
/ trap serialization
|
C_fe_starve
|
504,818 | 0.56% | Frontend fetch queue empty (L1I miss / ITLB miss) |
Total (
mcycle
)
|
89,861,075 | 100.00% | 76,236,390 commits (IPC = 0.84838) |
sudo apt-get update sudo apt-get install -y \ verilator g++ python3 device-tree-compiler \ gcc-riscv64-unknown-elf gcc-riscv64-linux-gnu
(Optional, for physical synthesis & STA:
yosys
,
sv2v
, OpenSTA
sta
, and Nangate45
.lib
via
FURSOY_LIBERTY
or
tools/synth/lib/NangateOpenCellLibrary_typical.lib
.)
From the repository root:
# 1. Production RTL lint (Verilator --lint-only, expects 0 warnings/errors) python3 tools/run_s1_lint.py # 2. Fast Slice-1 verification regressions (runtime ~3-6 min total) python3 tools/run_s1_m9_phase_a.py # Interrupts, mideleg, WFI, precise trap boundaries python3 tools/run_s1_m9_phase_b.py # CLINT, PLIC, UART 16550 platform peripherals python3 tools/run_s1_m9_phase_c.py # 5-master crossbar, DTB, unmapped faults python3 tools/run_s1_m9_phase_d.py # SBI v2.0 firmware + mixed-privilege stress python3 tools/run_s1_m8_closeout.py # RV64FD + RVV 1.0 FP/Vector backend python3 tools/run_s1_m7_closeout.py # Multi-bank non-blocking L1D + coherency python3 tools/run_s1_m6_closeout.py # Frontend BPU / ITLB / L1I NLP # 3. Nangate 45nm @ 500 MHz synthesis & OpenSTA check python3 tools/run_s1_synth.py --run-synth # 4. Full Linux 6.6.50 + BusyBox boot closeout (~1.5-2 hours wall time) # Requires a built RISC-V Image at build/linux-6.6.50/arch/riscv/boot/Image # (kernel config/patches in software/linux/, initramfs helper in tools/build_initramfs.py). python3 tools/run_s1_m9_closeout.py
| Directory | Contents |
|---|---|
rtl/core/
|
Slice-1 64-bit OoO core SystemVerilog modules (
fursoy_s1_core
, ROB, rename, IQs, ALU/Branch/Mul/Div, FP/Vec, DTLB/ITLB/PTW, L1I/L1D)
|
rtl/platform/
|
Slice-1/Slice-0 SoC integration (
fursoy_s1_soc
), 5-master crossbar, CLINT, PLIC, 16550 UART
|
software/
|
Minimal SBI v2.0 M-mode firmware, Fursoy Slice-1 Device Tree (
fursoy_s1.dts
), Linux 6.6.50 defconfig/patches, BusyBox
/init
&
mem_stress
|
verification/
|
Verilator C++ self-checking testbenches (
s1_m9_closeout_tb.cpp
, M5–M9 phase/closeout benches, unit checks)
|
tools/
|
Python lint, regression, Linux closeout, synthesis (
run_s1_synth.py
), and analysis runners
|
docs/architecture/
|
Normative microarchitecture, MMU, cache, and SoC specification documents |
results/
|
Verified milestone JSON evidence reports (including
results/s1-m9-closeout.json
)
|
Licensed under the Apache License, Version 2.0 .
N othing says holiday cheer quite like panic-browsing websites in pursuit of the perfect gift , toggling between 47 open tabs, eyes straining against your screen’s harsh blue light. But finding an item that elicits a squeal of delight from its recipient is one of the best parts of this time of year, when you have a little help.
So we’ve curated 143 presents to reclaim holiday shopping as a joyous activity.
We recruited seasoned writers and shopping experts to get into the holiday spirit early, vetting gifts across categories such as kitchen, home, tech and more. For months, we cooked, ate, traveled, hiked, ran, showered and slept with test products by our side. And we roped in our mothers, cats, dogs and the kids in our lives to make sure these gifts really work for the people (and pets!) they are meant for.
Our comprehensive list spans safe bets (who doesn’t like chocolate ?) to niche recommendations ( butter-shaped candle , anyone?). You’ll find a range of prices from a $6 cleaning cloth for a notoriously dirty laptop owner to a sophisticated trenchcoat for your stylish sister. Happy gifting.
Don’t see anything that catches your eye? Email us at thefilterus@theguardian.com for help finding a gift for your trickiest recipient.
4 / 10
Curated by Emily Farris and Karen Yuan. Farris has been writing about food and lifestyle and testing cooking gear for nearly 20 years.
Yuan covers food, kitchen gear and lifestyle for the Filter US. Her dream Christmas gift is a lifetime supply of cheesy ramen , and she has never turned down an invitation to hot pot .
I’m a sucker for a great-smelling hand soap. (I definitely snapped a picture of the label after my first pump of Aesop’s Resurrection .) If you know a home cook who’s equally enamored with luxe smells, add a bottle or three of Naomi’s hand scrub to your cart immediately. Specially formulated for the kitchen, it’s made with bread yeast enzymes to neutralize cooking odors and leaves behind sophisticated notes of bergamot and pepper that give off high-end hotel vibes. Emily Farris
These tiny French spoons get more use than any other utensils in my kitchen. Technically called demitasse spoons, they are the “teaspoons” of many European flatware sets, but they’re much, much smaller. My sons and I use them daily for yogurt, dessert, ice-cream and even most of our cereals. They’re perfect for espresso drinkers, homes with kids and anyone who just really loves small spoons (which inexplicably includes many neurodivergent people). They’re dishwasher-safe too! EF
I lost half of my kitchen knives in my divorce and instead of overthinking individual replacements, I opted for this trio from Material Kitchen. The chef’s knife, serrated knife and paring knife cover the needs of most home cooks – and after more than a year of near-daily use, the Japanese steel blades on all three are still sharp. It’s a great starter set or starting-over set, and it’s available with or without a magnetic knife stand. EF
Equal parts form and function, this minimalist dish drying mat is made of diatomaceous earth, which can absorb up to 150% of its weight in water – and shockingly quickly. I started using one a few years ago and I’m sold for life. This thing dries itself even more quickly than it dries dishes (yes, it’s very fun to watch), so I no longer worry about standing water or musty microfiber. I’d recommend it for kitchen aesthetes, but honestly anyone who hand-washes even just a few dishes will love it. It’s foldable for storage and travel too. EF
I wasn’t really a wine glass snob until I ended up with a single Zalto Denk’Art Universal Glass . Many sommeliers will tell you that Zalto makes the best wine glasses money can buy, but at nearly $80 a piece, my money can’t afford a full set – especially because the thin glass is extremely delicate and we all know how things go when the wine starts flowing. But Fable’s versatile wine glasses are a visual dupe for Zalto’s and they are much more affordable. While the lead-safe crystal isn’t quite as thin, it’s durable enough that multiple guests have knocked over or dropped mine, and in two years, I’ve lost only one. (The other three go in the dishwasher regularly.) EF
OK, fine! No one needs $52 “resting stones” for cooking utensils. But these satisfyingly hefty pebbles make my cooking so much more convenient and delightful. One stone lives beside the stove, ready to receive a sauce-slick tasting spoon or chopsticks. Another sits on my kitchen island, where I can pop a lime wedge or cracked egg shell on it. Because they don’t look like kitchen tools, they double as minimalist-looking decor when I’m not cooking. You could also use one as a tray for rings or keys. Karen Yuan
I once spotted this mug at a painfully cool cafe in Brooklyn, which was very validating for me, a not particularly cool person who nonetheless appreciates a nice trinket. The translucent amber glass has a honeyed glow that’s even lovelier in person, especially when the light catches it, and the mug’s angular square handle is surprisingly comfortable to hold. I am telling you, this set makes my everyday cup of Trader Joe’s tea taste like artisanal brew plucked from the loftiest tea fields in China. Gift it to your favorite coffee or tea drinker. KY
When I’m craving hotpot but it’s too cold to venture out to a restaurant, I’ll pull this bright red set from my shelf. The electric cooker heats up quickly and the pot is just the right size for one or two. If you judge the idea of “personal hotpot” the way one judges “personal pizza”, I am sorry for the lack of joy and whimsy in your life. This starter set comes with chili crisp samplers to make your own hotpot base, though you can also buy Fly By Jing’s premade base , which produces a savory, tongue-tingling broth with a satisfying kick of Sichuan peppercorn. Give it to a homebody who loves to cook, then wait for the hotpot dinner invite. Everyone wins! KY
These are dinner plates that make me want to invite people over just to have an excuse to use them. Their gently undulating rims give them a hand-molded look, but they are not just decorative; they offer a secure grip when I’m ferrying a stack of dishes to the sink or rinsing off a slippery plate. Made in Mexico from high-fired stoneware, they are pleasingly substantial, and the colors are warm and slightly retro. The brand also offers bread plates and salad plates . Tortuga Forma is a woman-owned small business founded just eight years ago, so you can use this chance to support an independent maker while upgrading someone’s dining table. KY
Kitschy food decor is everywhere now , and this one is a classic example. This $22 candle looks like a block of fancy French butter, right down to the gingham wrapper and “beurre salé” label. It’s actually made of soy wax and smells of jasmine, neroli and orange blossom, so it can act as anything from a dinner party curio to a kitchen candle that reduces odors. Give it to your most butter-obsessed friend. (It’s OK if that’s yourself.) KY
Curated by Richard Baguley, who has tested and written about consumer technology for more than 30 years. His favorite gift would be a good night’s sleep.
Is the weight of your worries keeping you awake? Adding more weight might help: the Bearaby Weighted Blanket feels like a giant cuddle and the ventilated faux knitted design means you will not get hot. It is oddly soothing while snoozing or watching TV, making it a great gift for someone you live with, just so you can use it, too. Richard Baguley
I may not be pregnant, but I am a terrible sleeper who grabs on to things while sleeping like a drowning man with a life-saver. Body pillows including the Buffy Wiggle Pillow offer something for me to grab on to in my night-time desperation and replace my knee pillow, while still leaving enough room in the bed for my long suffering wife. This is a perfect gift for anyone who struggles with sleep and wants to try new ways to improve it (pregnant or not). RB
When I was three years old, I insisted on sleeping with a spanner (translation to US English: wrench), perhaps because Warmies hadn’t been invented yet. Now I have upgraded to this adorable plush Capybara Warmie. Microwave it a minute and it gets cozy and warm, or stick it in the freezer for a cooling cuddle on a warm night. Unlike a spanner, it offers a subtle scent from the grain and lavender stuffing. RB
Have a family member who suffers from aches, cramps or excessively grumbly guts? This cute heater bottle might help: pop it into the microwave for a minute and it provides comfortable, soothing and safe heat that helps ease the aches, cramps and pains of modern life. It’s the perfect size for shoulders, tummies and feet that need soothing warmth. RB
I love my dog Jasper, but he snores like a badly oiled diesel engine. The Alpine Silence are the best earplugs I have found for those nights when you just want him – or the person sleeping next to you – to stop. The V-shaped handle makes them easy to pop in, take out, and even holds them in place. They are easier to carry than earbuds, don’t need charging and cost a lot less if your dog decides they look like a tasty treat. RB
Sheets are the kind of gift that no one really thinks about giving, but their recipients will be touched (and happy) to receive. They are an essential component for a good night’s sleep, and these are the best. The 280-count percale cotton is smooth on the skin, hard-wearing and provides a little touch of luxury as you doze off. RB
Satin pillowcases help keep your skin smooth and your hair undamaged. This one is available in a Galactic Empire or Rebel Alliance theme, depending on your political orientation to the Force. Honestly though, they missed a trick by not doing a pillow with the empire on one side and the rebellion on the other and marketing it with a joke about turning to the cool, dark side … RB
The world is a noisy place when you are trying to nap and AirPods will jab you in the ear when you roll over. The Sleepcore A20 earbuds have a flat design that fits right inside your ears, plus a soft exterior and swappable ear tips that make for excellent sound blocking and all-night comfort. If your special someone spends their evenings doomscrolling with the sound on, slip these in their stocking and give yourself the gift of silence – the earbuds offer a 10-hour battery life when playing audiobooks from your phone and they come with a handy charging case. Alternatively, give them as a present to yourself to block the sounds of constant doom. RB
People spend more time in pyjamas than most clothes, so a decent set is an investment in the care and comfort of those you love. These Cozy Earth Bamboo pyjamas are wonderfully cozy, with a flexible fit and a wonderful feeling of smooth luxury. The breathable bamboo fabric also keeps things cool on a warm night. RB
Sleep rituals can help you wind down and relax after a head-spinning day. The Twilight gift set from Lush will help anyone develop this kind of routine. I’m normally skeptical of such potions, but I found the Sleepy shower gel and body lotion to be very effective: the lavender scent genuinely helps me to put the day behind and sleep better. RB
Curated by Jon Chan, who has been writing about home , outdoor and tech products since 2012. His favorite Christmas gift was a tie covered in crabs. No matter how dire the situation, a crab shuffle dance will make life a little better.
If you know someone who desperately needs a spa day but can never find the time, bring the spa to them. The Parachute Organic Super Plush towels are some of the best we have ever tested . Made of thick, squishy organic Turkish cotton, Parachute’s towels are soft from edge to edge, giving you a sense of coziness that other towel brands struggle to match. Yes, these towels are more expensive than those you will find at a big box store, but they are an attainable luxury – and a really good gift. Jon Chan
Bubble and faux-fur blankets such as the Lola got really trendy on social media , but they can be really expensive. The Bubble Blanket from Bedsure, made from the same Oeko-Tex standard 100-certified materials, is a better bet at a third of the price. Our testing found it’s warm and amazingly soft, like being wrapped in a teddy bear’s hug. JC
Give your household the gift of a permanent truce from the thermostat wars: a good space heater , specifically this one from Honeywell. Its HeatPhase Timer sets it apart from the competition: when activated, it lowers the power (and temperature) every 30 minutes until it hits the lowest tier and shuts off. You’ll feel cozy as you drift off to sleep and will not wake up a sweaty mess a few hours later. JC
A good throw pillow will inject color, energy and life into an otherwise ho-hum space. Piecework, a company best known for its intricate puzzles , has branched out into home goods, and these pillows are just as delightful as its mainstays. The cases are screen printed on to sturdy cotton, so the colors will stay bold, and the styles range from floral to geometric. They’re cheerful without being too maximalist, and you can find one to match any aesthetic. JC
As colder weather rolls in, so does the flu, flaky skin and dry air – bringing plenty of reasons to get a humidifier. The Levoit Classic 300S is small enough to fit on a desk or bedside table with a tank large enough to run for 16 hours straight on the highest setting. It’s easily refilled from the top, so you are not giving the gift of extra work and the control panel is dimmable and can act like a nightlight. JC
If the beach-goer in your life is sick of lugging a hard-sided cooler full of seltzer, give them (and their back) something that will help . MagPack’s backpack soft cooler has a magnetic lock and frame that helps ensure what’s inside doesn’t get crushed and will not leak out. And when it is sealed and packed with ice, it keeps drinks cold all day and through the night. JC
The best work gloves balance dexterity with protection. We found that Carhartt’s A518 gloves fit that bill. Double-stitched cowhide pads cover the fingertips, palm, part of the wrist and the knuckles, so all your bits are covered – and they’re flexible enough to allow you to open pocket knives and change drill bits with ease. Stuff these in a stocking for someone who is always working on a project in their garage or garden. JC
Know someone who is on the fence about bathrobes? They need a bath sheet – something that provides the coverage of a luxury robe with the ease of storage like a regular towel. American Linen has a great bath sheet that is 40in x 80in of plush Turkish cotton. JC
Between wildfire smoke and pollution, air quality is a rising concern . If you are interested in giving the gift of clean air to a loved one, this Shark air purifier is one of the best I have tested, with a Hepa and carbon filter that can last up to five years. JC
For someone who is constantly battling dust bunnies and pet hair, a robot vacuum can help win the war. The Eufy 11S Max is great entry-level model to give to someone curious about robot vacs, but unsure if they will jive well with their floor plan. At just under 3in tall, this short king can squeeze under a lot of furniture and the powerful motor is great at removing dust and debris. JC
Curated by Tim Stevens. Stevens travels 200,000 miles a year and has covered travel gear , consumer technology and everything in between since 1996. His favorite Christmas gift was a Sega CD in 1992 , and he considers himself lucky to have survived the console wars.
This super-simple solution to keeping a laptop display pristine makes for a great stocking stuffer. Laid over a laptop’s keys when closed, it protects the display from micro-abrasions while also providing a handy cloth to wipe away any dust. Perfect for the traveling perfectionist in your life. Tim Stevens
Socks are perhaps not the most exciting of gifts, compression socks doubly so, but deep-vein thrombosis is nothing to mess with. Compression is a great and simple way to minimize the risk. I have had a pair of these Wanderlust socks for five years now. They are still comfortable and look like new, perfect for the frequent-flying buy-it-for-lifer in your family circle. TS
I have found myself traveling with paper books again lately, partly because I enjoy the experience and partly because it is a lot less expensive to forget a book than a Kindle. Hotels rarely have good bedside reading lights and this tiny, long-lasting and rechargeable option is the best gift I have given myself so that I can read in bed. Any globe-trotting reader in your life will be similarly appreciative. TS
While it is not the most exciting thing on this list, I’m convinced this is the perfect bag for your carry-on liquid allotment. It’s sort of like a cross between a regular Ziploc bag and a storage container, but thick and stretchy enough to conform to whatever you are packing. It will not pop open and it even stands up, making it easy to access everything inside. It’s a great gift for any traveler looking to cut down on single-use plastic bags. TS
Anker has upped its charging game again, integrating a high-power USB-C charger and universal travel adapter into one. With four USB ports (three USB-C and one -A), it will charge everything from smartwatches to laptops and do it anywhere in the world. It is my new travel companion and a perfect gift for that friend who is always borrowing your charger. TS
Long hours on cramped airplanes do a number on your back. Yoga is a huge part of how I keep things limber, but yoga without a mat is a real challenge. These gloves and booties are like tiny yoga mats you can wear, surprisingly functional yet small enough to be easily packable. I was skeptical at first, but I bring these on every trip. Any yoga fan in your life will too. TS
Most hotels still don’t put enough outlets in convenient places. This cable is long enough to free you to work wherever you want in your room, but not so huge that it will take up half your bag. If you know a frequent traveler who spends lots of time working in hotel rooms, this gift will keep them from being tethered to the wall. TS
Smart packing means minimizing liquids, but saving your skin should take priority. This Dr Jart+ stick provides SPF 40 protection, goes on easily, smells nice and doesn’t need to fit in your little bag of liquids. It is ideal for anyone who needs some extra sun protection on the go, especially men who are not too keen on the whole daily moisturizing routine. TS
Speaking of gifts for men who don’t want any more liquids in their carry-on , a bar of shaving soap will surely be well received. This bar from Gentleman Jon smells great, lathers well and should last for at least a year of regular shaving. TS
Apple’s AirTags are button-sized pucks that wirelessly connect to Apple devices within Bluetooth range to report their approximate location. Put one in your bag, and you will always know where it is. If you have a forgetful friend or someone whose checked bags tend to disappear, they make a great gift. TS
Curated by Maria Ricapito, who has covered beauty and wellness long enough to see every makeup trend come around at least thrice. This Christmas, if someone gave her one of those Ocura Life Plasma Pens to remove random bits, bumps and skin tags, she would definitely try it out and let you know if it works.
I cannot wait to tell my nephews that I put some Cat Crap in their stockings. This would be great for a snarky and sporty teen (or adult). It’s a functional, basic and un-tinted lip balm with a vanilla mint flavor and SPF 15 from a company that makes a defogger for sports goggles. You may also find it by the register at your local hiking/climbing/biking/skiing shop. Maria Ricapito
When my friend with long, wavy hair bought me my first WetBrush, she told me that it would be life-changing. Eight years later, I agree – it is nice to brush out my curly, frizz-prone wet locks without pulling out a clump of strands every time. This version is tiny but mighty; it is small enough to tuck into a gym or travel bag. I prefer the open design versus the traditional cushiony paddle type because it dries quickly. Give it to someone who has been using the same ratty Goody brush since the early 2000s. MR
This travel-friendly set uses African botanicals to fight hyperpigmentation (AKA dark spots) and hydrate skin. The recently released line was developed by Sabrina and Idris Elba, in partnership with Farm Africa . It makes a lovely gift for the skincare -obsessive always looking for the next and newest thing. MR
For those of us who lack fireplaces, as I did for years living in New York City, this candle is the next best thing. Made in Bushwick, Brooklyn, DS & Durga’s scent really fits the brief – a heady mix of cedar, pine, oak and birch notes in a soy wax candle with amber-hued glass that does genuinely smell like a roaring, crackling fire. MR
Gnarly feet happen, especially in overheated, dry winter air. I have certainly tried every cream, lotion or salve that is meant to give you baby-soft soles. Those help, but this tool provides the finishing touch. It is like taking a (gentle) electric sander to your heels and toes – and is so much safer than aggressive cheese-grater foot files or, God forbid, the bloody callus shavers that are banned in salons in some states. Give it to someone who prides themselves on their DIY pedicures. MR
I have had my Dyson blowdryer for several years with no signs of needing to replace it. I like it for the results: quicker drying and lots of adjustable levels of heat and blowage, plus less-fried hair. But as time and tech have moved on, the brand’s latest versions have new features such as “pause detect mode”, “attachment learning” and “scalp protect mode”. This model comes with the aforementioned bells and whistles as well as five magnetic attachments for different styling needs (to smooth flyaways, pouf up curls, concentrate air flow and detangle). Give this to someone whose janky old drugstore hairdryer is on the fritz – it’s worth it. MR
Introduce your favorite perfume-lover to Leland Francis, a brand founded by Dillon Peñas, an Oklahoma-native makeup artist, with this rollerball trio. It offers an oil-based, alcohol-free combo in three personalities: El Santo (citrus and wood), La Reina (rose and herb) and Stoner (smoke and leather). The brand is gender-inclusive, so each fragrance is unisex and the products are made in small batches and packaged with recyclable materials. The trio can also be bought separately as an eau de parfum or scented candle. MR
Nearly everyone you know probably has some kind of retainer, aligner or night guard that could use a good (and quick) cleaning. The fizzy tablets are fine, but you can’t live with others and leave your retainer soaking by your sink. Bad things happen: imagine your night guard falling off the sink edge into the toilet (and the guilty party just … putting it back). This gadget works by creating high-frequency ultrasonic waves that create bubbles to gently break down the gunge. Upgrade someone’s oral care – you may even be able to pay for it with your HSA account! MR
The colorful packaging and fruity flavors make this a stocking stuffer that is sure to impress anyone who is a tween (or tween at heart). Starface is the brand that made pimple patches an accessory for the gen Z set, but the lip balm also won the best flavored balm in our roundup. Choose a bundle of like-minded flavors or pick from the full list. (Purists, never fear: there’s an unscented version.) The goop itself is a soothing, hydrating mix of shea butter, cocoa butter and coconut oil that is vegan, cruelty-free and safe for sensitive skin. MR
When I want to air-dry my hair without dripping water on to my shoulders, I pop on one of these. These scrunchies are made from a microfiber towel material that supposedly speeds drying time and looks nice enough for the beach or poolside. The brand uses almost 100% sustainable, eco-friendly and recycled materials and partners with 4Ocean to remove plastics from the sea. It is a great gift for anyone with a dedicated air-drying hair regimen or anyone who wants the ease of a towel without wearing one in public. MR
I love these pencils for their ability to make even the most inelegant application look intentional. You don’t need to blend; the thick rounded pencil is a multitasker, and can do anything from a barely noticeable line to full-on smokey eye glam. It comes in a range of 16 shades, including Iced Latte (a pinkish-tan) or Matcha (lime green shimmer that is not too try-hard). And at just $6 each, they are a great stocking stuffer for anyone who watches makeup tutorials or wants to try out colorful eye looks. MR
Silk bonnets and satin pillowcases are great for waking up with smoother morning hair – but don’t overlook the humble scrunchie. Kitsch’s satin version is Oeko-Tex certified and the brand’s dedication to sustainability makes this an easy buy for anyone with hair longer than a kicky little bob. MR
This Japanese skin ritual in a very giftable bamboo box aims to fix dryness and uneven texture. The Silk Rice makeup-removing cleansing oil, Citrus Glow vitamin C and hyaluronic acid serum, Matcha Boost eye serum and Mochi Mochi luminous plumping moisturizer contain traditional Japanese ingredients including shiso (antioxidant and rich in fatty acids) and matcha extract (helps shield against sun damage), plus vitamin C to brighten skin. It is an easy gift for skincare fanatics looking to expand their horizons beyond Tatcha, another popular Japanese skincare brand. MR
This funky-looking portable system is not just a keychain – it is a detachable cube filled with solid fragrance. It is great for travel and also makes for a nice accessory: when assembled, the cube looks functional and unisex, like a sporty bag charm. The scents themselves are meant to be unisex – Heroic Dose is a herbaceous aromatic with a whiff of salt air and Altered States is a woody scent with spicy nutmeg, cardamom and tonka. This will be an unexpected gift for a perfume lover’s collection – or just a nice treat for yourself. MR
Curated by Lauren Gould. She has covered style for the Filter US for the past year, from bravely asking New Yorkers about their outfits to interviewing stylists . Her favorite Christmas gift was a Tiffany & Co silver necklace with her initials, which made her feel like Blair Waldorf from Gossip Girl.
This purse’s appearance will deceive you – it looks far more expensive than its $98 price tag. I use the red version to hold my cards, work ID, makeup, Kindle and of course, my daily GoMacro bar. It adds a fun pop of color to any outfit, and I love to style it with an all-black ensemble or a simple sweater. My one quibble is small but mighty: the removable drawstring pouch tends to crinkle up in the purse, which is quite annoying, as it has a handy zipper compartment that I use to stash my credit card. While this is not the right present for a luxury bag fiend, it is a solid option for anyone in need of a purse for storing their essentials. Lauren Gould
Last year, my mom gave me the black and white colorway of these pyjamas – a smarter choice than, say, a holiday-themed set that I would neglect come New Year’s Day. Nearly 12 months and many washes later, these still feel silky soft. Wearing this matching set makes me feel put together at 10pm on a weekday, which I cannot say for the oversized designated sleep T-shirts I also rotate between. If you’re shopping for a picky person, a matching pyjama set is a universally appealing gift they will actually use. LG
This bracelet goes with everything, from workwear attire to loungewear. Like the earrings I tested from Mejuri (scroll below), it is so lightweight that I forget it is on my wrist. I also appreciate that it is adjustable, which reduces the chance the recipient will have to return it. It’s more personal than any old bracelet. You can grab the one that matches their birthstone (I’m an Aries diva, and tested the white diamond one ). LG
Everyone seems to own J Crew’s trendy rollneck sweater. However, I rarely see anyone rocking the reversible iteration, which feels more unique and doubles as a cardigan. I have worn this with a simple black skirt, baggy jeans and even culottes . I bought this for my mom for her birthday this year, and she says it is the ideal piece for anyone who has hot flashes, thanks to its button-down design, which makes it less constricting than a regular sweater. LG
Last winter, I wrote about all the ways I style this small triangle scarf , including in my hair and around my waist. Nearly a year later, I am still wearing it to inject a little fun into the sea of neutrals I often wear. And while I have noticed a small thread has come loose, it otherwise remains in great condition. It is made of 100% merino wool, which makes it ideal for dressing up a basic coat in the winter or adding a pop of color to a simple sweater. Give this to someone who always looks put together and refuses to wear boring outfits, even when the weather is below zero. LG
“The quarter-zip has come roaring back into view as preppy has overtaken streetwear and athleisure as the fashion vernacular,” wrote Jess Carnter-Morley, the Guardian’s associate fashion editor. So, I knew my (mostly) stylish 23-year-old brother was the perfect candidate to test Sézane’s 100% wool quarter-zip sweater, which he said felt “warm and extremely comfortable”. This is a wonderful present for someone whose winter uniform is a sweater and jeans. LG
Made of 100% Italian wool, Sézane’s Stratford Square Scarf adds a touch of interest and extra warmth to an outfit. My brother, who tested the heather brown shade, found the scarf soft. I personally think the purple option, one of the trendiest colors of the season , would make a great gift for the man in your life not afraid to experiment with his look. Grab this for a stylish relative or significant other who usually compromises warmth for style (now, they will not have to). LG
To keep warm, Boston-based style coach Kin Moy suggests these men’s leather gloves for adding “a bit more gravitas than if you were stuffing your hands in your pocket”. This pair from Hestra is an ideal gift for a rugged guy who still loves a bit of luxury. “It manages to be really robust and sturdy,” which Moy said is great if your recipient is usually on snow shoveling duty. “They actually add a lot to an outfit,” Moy said.
These sweatpants are Moy’s tried-and-true Christmas present for men whose partners are fed up with their sloppy sweatpants. He says they are just as comfortable as a basic pair, but look more put together. “Everyone, client and friend or family who I’ve managed to convince to buy, they are like: ‘This has changed my life.’” LG
Buck Mason Seafarer Cotton Beanie
Moy personally owns Buck Mason’s 100% cotton beanie. “It fits really well,” he said, noting that it sits closer to your head unlike other, bulkier beanies. Gift this to the person whose winter hat could use a sleeker upgrade. LG
This trenchcoat is confidence in a jacket. Whenever I wear it, I feel like the most sophisticated, put-together version of myself. It has an oversized fit, but the collar and buttons lend it a bit of elegance. The cotton feels warm and thick and is the right weight for the tricky transitional months between seasons. I opted for classic camel, so as to let the rest of my outfits shine, but if you want a wintery version, it also comes in wool . As this runs large, I would recommend sizing down (especially if you are in between sizes). This would make a memorable gift for someone starting a new corporate job or building a capsule wardrobe . LG
Any Anthropologie employee knows about the Alani sweater – and anyone who receives this as a gift will be happy to – whether it be your stylish mom, in-law or friend who hates spending money on themselves. As a former sales associate, I can attest: this bestselling cashmere style was beloved by customers and staff alike. Even after testing far pricier sweaters, I still have not found something softer than this one. While I have a crewneck version that’s not currently sold, the mockneck design is an equally great gift. It’s also not too heavy, which makes it a wonderful transition piece come spring. LG
From the minute I brought this claw clip home, my roommate fell in love. She uses it to style her luscious, curly hair in a cute half-up, half-down look. And yes, $36 is a hefty price for a single claw clip – but it is the sort of frivolous item that makes a wonderful gift for a trendy tween or fashionable in-law. LG
I’m always disappointed when all my Bombas socks are in the laundry, forcing me to wear my inferior pairs. The ruffles help these strike a lovely balance between practical and fun, making them more exciting than a plain pair of tube socks. Gift these and a chocolate bar to a friend who constantly misplaces their socks. LG
I swear by scarves for elevating an otherwise bland outfit. This one, from J Crew, is a good entry-level option for the scarf-curious. It is made of 100% silk and comes in an array of colors, such as the classic smoked walnut one that I have styled with wide-leg jeans and a basic black top, around my purse and around my neck. If you need a present for a fashion lover who already has a closet full of denim, this is a fun accessory your giftee can use to spruce up their stuffed wardrobe. LG
If you are searching for jewelry for someone who refuses to let anything less than solid gold touch their earlobes, they will probably like this 10K yellow gold pair from Mejuri. These hoops are so tiny, I forget I am wearing them and unlike brass-plated ones I have tried, they don’t irritate my ears. Gift them to anyone building their solid gold jewelry collection or a minimalist who abhors flashy earrings. LG
Curated by Karen Yuan, who has covered food, kitchen gear and lifestyle for a decade. Her dream Christmas gift is a lifetime supply of cheesy ramen , and she has never turned down an invitation to hot pot .
These wobbly, jiggly fruit gels are made with gelatin and fruit purees such as guava, passion fruit, pineapple and coconut. They are sweetened with allulose and stevia instead of sugar, with some apple cider vinegar in the mix for gut health. They taste like a grown-up fruity vitamin gummy turned dessert and their whimsical gift box is decorated with the included molds (“square”, “orb” and “bundt”). KY
If they say they have everything , well, do they have a whole leg of Fermín Jamón Serrano? This variety comes from older, fattier pigs raised in Spain, and it is dry-cured for at least 18 months using artisanal methods in La Alberca, a Unesco World Heritage site. The result is a showstopper with deeply savory meat. If a gigantic leg of ham feels like too much of a gift (boo!), grab the Fermín Serranía sampler instead, which is sliced and ready to eat. KY
This California rosé forgoes alcohol in favor of a hemp-derived THC infusion; each pink bottle contains 15mg (about 3mg per glass), which gives you a nice, mellow buzz. Fair warning: its slightly tart, sour-beer-ish taste is a departure from traditional rosé, but it grew on me after a few sips. One for the friend who is drinking less but doesn’t feel like giving up wine entirely. KY
You probably know someone who has been really into sourdough since 2020. Get them Mark Bittman’s new whole-grain sourdough box, in which each loaf is made with just flour, water and salt, then frozen so you can finish baking it at home in about 20 minutes. There is even a small tub of salted butter included. The Half Wheat was my favorite, with a crackly crust and soft, chewy middle that fluffed right back up in the oven. The croissants stayed a little limp despite reheating – but their beautifully buttery flavor made up for it. KY
I spend an embarrassing amount of money on matcha lattes every month, so I have been trying to make them at home. The first-harvest, single-cultivar matcha in Muracha’s set comes from a family-run tea farm in Yame, Japan, and it is gloriously green with a bold, earthy taste. You also get a bamboo measuring spoon and a whisk, plus instructions that walk you through measuring, sifting and whisking in an “M” shape, which is fun to do. I pour it over soy milk for a latte that would cost at least $8 before tax and tip in a cafe. Rescue someone else whose matcha habit is getting out of hand. KY
Juno DeMelo, a Filter contributor, does not leave home without one of these tiny tins of Oregon sea salt. “I keep one in our camping bin and another in my purse so I can dial in the salt level of whatever I’m eating no matter where in the world I am,” she wrote . The sliding lid makes it easy to sprinkle salt wherever you happen to be eating. This trio includes flake salt, kosher salt and pinot noir-infused salt, each in a tin illustrated by an Oregon artist for a thoughtful stocking stuffer. KY
Fishwife took top honors for its tuna in our tinned fish taste test , but this brightly illustrated gift box contains 10 bestselling tins. Gould, the Filter editorial coordinator, also enjoyed its rainbow trout in chimichurri, giving it a 10/10 for flavor and texture. “This trout blows me away with its addition of grilled red pepper and herbs,” she wrote, praising how much flavor was packed into the little tin. KY
Did you forget a gift? Make it right with one of these dazzling charcuterie boards that ship overnight and arrive fully arranged and chilled. You can choose from the Classic holiday board (cheeses, meats, dried cherries, salted caramel walnuts, rosemary crackers and more on a reusable acacia board), the Thanksgiving board (nearly identical, except the big cheddar is shaped like a leaf instead of a candy cane), or the Jewish holiday board (not certified kosher, but cheeses are rennet-free). Nice for a host who does not need another bottle of wine as a gift, or someone far away you wish you could share a cheese plate with. KY
Some nights I want a bowl of pasta but have absolutely no interest in making a sauce. Pasta Dust offers a shortcut inspired by aglio e olio: cook pasta, save some of the starchy water and toss everything together with olive oil and a generous shake of the stuff, which combines garlic, herbs, spices and a little chili heat. It is like a fancier version of the packet of dried herbs that comes with instant ramen. Give this to the friend whose idea of cooking is boiling boxed pasta. KY
Tilden’s award-winning non-alcoholic cocktails are as complex as their boozy counterparts. The Lacewing combines cucumber, basil, lychee and juniper with a tingle of Sichuan pepper, while the Tandem leans moodier, with tart cherry, bitter orange, smoky lapsang tea and ginger. This six-pack includes three bottles of each. It is perfect for anyone who loves ordering a fancy bev, whether or not it is alcoholic. KY
These five little fish look convincingly like something you would find in the canned seafood aisle. Instead, they are made of 39% cacao milk chocolate. Buy it for the presentation more than the chocolate, which is smooth and creamy enough, but not best in class. It is a sweet gift for a tinned fish enthusiast or you could bring it to a white elephant exchange as a coveted prize. KY
I don’t really trust myself around a jar of this stuff. Made with California pistachios and organic oat milk powder, Pistakio’s rich spread tastes great on toast or swirled into Greek yogurt, though I also like to eat spoonfuls out of the jar. Give it to someone whose favorite gelato flavor is pistachio, or a home baker who could use a delicious shortcut. KY
Joy Supply, a small business launched this year, makes thin, buttery oat cookies with regeneratively farmed ingredients and a family recipe dating back to 1908. The White Chocolate Raspberry was a knockout flavor for me, equal parts sweet and tart, though all the cookies are extremely crumbly (eat them with great caution in a car, on the couch, etc). Gift a few boxes to someone who appreciates a good holiday cookie and a good backstory. KY
Curated by Juno DeMelo, who has covered health and fitness since 2007. If someone gave her a horse for Christmas, she would never ask for another gift for as long as she lives.
When my husband bought this gadget, I figured it would end up collecting dust in the back of a closet. But the pressure – delivered via 16 heated orbs that rotate in two directions at three speeds – is deep-tissue level, earning it a permanent place near the couch. I drape it over my neck and shoulders and press it into my lower back. Have a partner who is always begging you for a quick shoulder massage? This will make both of your lives better. Juno DeMelo
Made of BPA-free plastic and insulated with foam, the statement-making 64oz Silo is for anyone with lofty hydration goals. It weighs just more than 2lbs – or about half as much as Yeti’s metal jug of the same size – and keeps drinks cold for hours. Plus, it is dishwasher-safe, leakproof and virtually indestructible. JD
The muscles that support your head and neck are tough to reach without the help of a massage therapist ... or this tool. All you have to do is lie back and let the specially shaped nodules melt away stiffness at the base of your skull. Know someone who is tight from upper-body workouts, stress or just looking down at their phone too often? Of course you do – and this is the gift for them. JD
This set is great for giftees dedicated to their at-home workout regimen. It includes five latex bands spanning 3lb to 80lb of resistance, two clip-on handles, two ankle straps and a doorway anchor – and it is dead-simple to use. I keep the red band anchored in the doorway of my home office, where I use it for physical therapy exercises and accessory strength movements. JD
I am a longtime fan of Skida’s original brim hat for everyday wear. But for the runner or hiker in your life, the outdoor brand’s ventilated version can’t be beat. The featherweight hat has a crushable brim that packs down easily, UPF 50+ protection built into the brim and sides, and a moisture-wicking sweatband. JD
For the loved one who would never treat themself to a massage, but desperately needs one, there’s the Thera Cane. Six strategically placed treatment balls let you dig deep into otherwise hard-to-reach neck, back and shoulder muscles. Just find a knot and get to work, or try one of the easy-to-follow exercises in the accompanying instruction manual. JD
The Everywhere bag accompanies me, well, everywhere. You can style it as a fanny pack or crossbody bag, and it is the perfect size for holding a phone, keys, snack or a wallet. It is also the perfect prezzie for almost anyone: I have seen the bag (which comes in a dozen colors) on the shoulders and waists of teens, moms, dads and even celebs. JD
The ultra-lightweight, minimalist Xinglet relies on high-brilliance panels rather than battery-powered LEDs to keep you visible in low-light conditions. The stretchy waist and shoulder straps are fully adjustable, which makes it a thoughtful present for runners, cyclists and walkers of all ages and sizes. JD
I bought my first pair of Mexico 66s in 2009 and have been replacing them with a new pair roughly every eight years since. Originally developed for runners competing in the 1968 Summer Olympics, the go-with-anything sneakers have a soft leather upper and thin, flexible soles that make them comfortable right out of the box. And yet they are surprisingly sturdy, which is why I pack them on nearly every trip. Treat yourself or a frequent traveler to a pair. JD
Made from super-soft microfleece and available in men’s and women’s sizing, Stio’s Turpin joggers provide the exact right amount of warmth for light hiking in cool weather, aprés-ski and camping. Flatlock seams and a wide, low-profile waistband make for easy layering under ski pants or over wool tights – but honestly, even a couch potato would appreciate these cozy bottoms. JD
After running in these socks for nearly a decade, I can confidently say they hold up exceptionally well. I own four pairs, and here’s why: they have a right- and left-specific fit for a locked-in feel, a double-thick heel tab that prevents blisters, and a seamless toe box and heel cup that keep friction to a minimum. Stuff them in the stocking of a loved one who loves to run. JD
In my seemingly eternal quest to find the perfect workout leggings, I have often been disappointed. These holy grails offer just the right amount of compression, stay up and cost half as much as my “premium” leggings made from the exact same 77% nylon and 23% spandex blend. And because they come in eight colors and two lengths, I can’t think of a gym rat who wouldn ot be delighted to find these under the tree. JD
Curated by Heather Balogh Rochfort , who has covered hiking, camping and outdoor gear since 2005. Her favorite Christmas gift was technically her sister’s: a Creepy Crawlers oven. She can still conjure the smell of scorched plastic goop, which is either nostalgia or the fumes talking.
A water bottle with a built-in purifier sounds kind of gimmicky, but it turns out to be quite useful. It goes fly fishing with my family which means I don’t have to pack a separate filter and bottle: just scoop up some water from the river, press down on the internal chamber, and you’ve got a bottle of drinkable water ready to go. From anglers to rafters and backpackers, it’s a great gift for anyone who spends a lot of time on (or near) fresh water. Heather Balogh Rochfort
Kari Traa is perhaps the best-known name in women’s base layers and for good reason. The fun patterns and colors give women a chance to show off their style. The Smekker is one of my favorite layers to wear during my 50-plus ski days each season in Aspen because I can take it from the chairlift to the après and still look good. HBR
The MegaMat is the most popular car-camping pad on the market, most likely because it turns sleeping on the dirt into a cloud-like experience. At 4in thick, it is so comfortable that my 70-year-old mother doesn’t mind using it. And it is reasonably priced compared with its plush competitors, making it a great gift for outdoorsy folks who want to camp without back pain. HBR
The Redwood reminds me of sleep away camp with the Girl Scouts ( ah, memories! ) , but – unlike the sleeping bags of my youth – also insanely warm. It is my go-to when I sleep in the back of my Subaru Outback at trailheads, and it is so toasty. Fair warning: it is the heaviest sleeping bag I have ever picked up. That makes it the perfect gift for a car camper or van lifer, since it will never leave the trunk. HBR
When plans change by the hour, the R1 Air Fleece keeps up. This shirt is warm, cozy and versatile. I wear it for shoulder-season hikes and ski days, and I will throw it on with jeans in my small mountain town. My husband wears his on cold-weather fly-fishing trips, and I recently spotted a friend wearing hers at a Red Rocks concert. If you have a sweatshirt lover on your list, this is the one to replace it. HBR
Mountain Hardwear’s hooded jacket is like yoga pants for your arms. You get the warmth of a down jacket, but it is super stretchy thanks to flexible fabric and welded (instead of stitched) seams. I have broader shoulders and it makes the jacket far more comfortable when I am hiking. HBR
This long-handled titanium spoon is the best tool for digging into dehydrated meal bags without getting food all over your sleeves. It weighs less than an ounce, making it an easy stocking stuffer for anyone who spends nights on the trail. (Every backpacker I know has one or wants another.) HBR
I will die on this hill: every person who squats when they pee needs a pee rag. The Kula Cloth has an absorbent, antimicrobial side for wiping and a waterproof side that keeps your hands dry and it snaps right on to your pack. No more drip-drying or packing out soggy toilet paper. HBR
These bendable, rubber-coated twist ties can do no wrong. I take a few on every single trip, whether I’m backcountry skiing, backpacking or mountain biking. I have used them to fix pulk sleds, shoes, busted tents, backpack straps and more. Stocking stuffer price, MVP-level usefulness and there is not a single outdoorsy person who doesn’t need a few. HBR
Curated by Adam Doud, who has been covering tech of all shapes and sizes for 15 years. His favorite Christmas gift is always Lego : any Lego, all Lego, nothing but the Lego. A close second is the Stargate SG-1 boxed set.
This little speaker is surprisingly powerful considering its size and the rainbow lights add a fun touch anywhere – my daughter stole mine to hang from the handlebars of her bike. It is also great for backpackers who want to bring along big sound without the weight. Adam Doud
The Amazfit Active 2 gives you all the best functionality of a more expensive smartwatch – step tracking, exercise detection and even a very good AI assistant – in a design nobody would guess is a smartwatch. Get it for someone who is just starting to take exercise more seriously or someone who is always misplacing their phone. You can ring it from your wrist. AD
Our pick for best seat cushion is a great gift for anyone who regularly logs eight hours or more sitting down – whether that is working at their laptop or playing a game. It eases back pain and turns any chair into the best seat in the house: I use mine every day at my kitchen table and I love it. AD
Magnetic battery packs are getting thinner and lighter these days, and this one is so petite you will forget it is there. Press it into the hand of your teenager whose phone is dying all the time or a construction worker who spends all day away from an outlet and give them the gift of an extra half a day of juice. AD
The little light on a cellphone can’t compare to a proper flashlight like Olight’s ArkPro, my personal favorite. It has a powerful spotlight, flood light, UV light and even a laser pointer, which makes it a fantastic gift for pet owners whose fur babies love chasing the magic dot. AD
Know an older relative who has not taken the plunge on streaming yet? Roku makes the easiest way to get them up to speed. The simple interface will feel familiar to the cable remote they are used to and the feature-packed 4K version will not need replacing for years. Just budget in some time to help grandma set it up – that is part of the gift. AD
For nearly $80, these earbuds are a really good value, with a fun, transparent design, excellent sound and very decent active noise-cancellation. If your teenager’s AirPods are always dying or your spouse spends hours on the train every day, give them the gift of reliability – you also get a solid eight-hour work day on a single charge with a couple more charges in the case. AD
Even Amazon’s most basic Kindle is a phenomenal e-reader that the bookworm in your life will welcome with open arms. And they are not stuck buying books from Amazon. Pairing it with the Libby app makes it easy to borrow ebooks from your local library in seconds, totally free. AD
This car power outlet plug has two retractable power cables that extend up to 3.1ft, then neatly coil up inside to tidy the tangle. It as a fantastic all-in-one solution that makes a great gift for anyone who spends a lot of time driving – or chauffeuring a kid who can never seem to stay charged. AD
This mouse folds into a tiny cube, then it unfolds into an arch for a cute little ergonomic mouse with two buttons and a touch sensitive slider/scroll wheel. It is great for someone who works remotely and is always on the go – never working in the same place twice. AD
If you know someone nostalgic for the BlackBerry days, or just hopelessly clumsy with a virtual keyboard, this is an easy buy. This magnetic keyboard attaches to the back of your phone and slides down for when you need to pound out a quick email or text message. True to its name, it also has a power bank that can top off your phone at the same time. AD
My go-to travel bag, the TomToc T24 sling holds a surprising amount of stuff inside its main pouch, and has multiple pockets inside for a laptop, a tablet, a water bottle and several other small pouches. Give it to a friend who never leaves home without too many gadgets in tow. AD
Give your own household the gift of organization. The Skylight Calendar 2 is a 15in display that hangs on your wall and syncs with Google, Outlook and most other calendars. Besides displaying upcoming events, there are some neat features including meal planning (which can populate your shopping lists) and the ability to add events to your calendar by taking a photo of an event poster. AD
Curated by Lauren Gould, who interviewed multiple tweenagers to find out what they really want.
Charlie, a 12-year-old, wants clothing from Free People Movement. “I think it’s a really good brand. It’s fashionable and sporty,” she said. LG
“That seems to be popular. I think everyone, mostly friends at school, wants to listen to music, and they are just the popular brand,” said Ollie, a 17-year-old. LG
“I’m asking for a lot of sweatshirts from this one brand called Madhappy. I love sweats and anything comfortable,” said 14-year-old Riley. LG
“This is a me thing, though. I used to watch the show a lot and I like seeing them hit each other,” said 10-year old Axel. LG
I first visited the Miffy store on a recent trip to Kyoto, Japan, and fell in love with this cartoon bunny. My sample of its Advent calendar, postcards, stickers and playing cards are all decorated with delightful illustrations of Miffy and her friends, and would make a great gift for a tween or teen who loves cute cartoon characters. LG
Curated by Tracy Allison and Nick Mokey. As Tux the tuxedo cat’s human , Allison has covered countless cat products . Her favorite Christmas gift she got was a multipack of Scotch tape at age five, which she used to try to fix a broken vintage doorknob.
Mokey is forever battling a plume of pet fur from his dog Marty and two cats, Daphne and Niles. His favorite Christmas gift was a Radio Shack RC truck he got when he was 10. Waiting for a battery to charge has never been more agonizing.
I have had enough pets over the years to know that an animal’s aches and pains are not always obvious. Now that my cat Tux is officially in the double digits, I am becoming more proactive about making his long-term comfort a priority, particularly considering how active he has been throughout his life. Made with contoured memory foam for orthopedic support and with a heated cover for gentle warmth, this therapeutic bed is my top pick for cats with aging joints. It may be on the pricier side, but for a cat who spent his youth sleeping under cars, I figure he has earned a little luxury. Tracy Allison
My cat is a window napper, which means his favorite sleeping spots can get extra chilly in the winter, so I bought him this heating pad before a big snow storm. After some trial and error with the settings, I discovered he is happiest with it on the lowest heat and an extra towel layered on top. TA
This is my go-to affordable gift for cat lovers. It mounts to the corner of a wall or door frame, avoiding the tripping hazard some other cat products create. Tux uses his whenever he’s vying for a little extra attention or looking to self-soothe. If a cat doesn’t take to it right away, a spritz of catnip spray can help pique their interest. TA
I switched to this elevated dish after Tux kept managing to push his lightweight bowl under a nearby bar cart. This sturdier bowl stays put more easily and means less crouching for a more comfortable mealtime. TA
I have dreamed of being an automatic litter box person, but my cat refused any enclosed box I tried to introduce. This stainless steel litter box has been the best compromise I have found: it helps keep odors in check, and the high sides give him something to wipe his paws against instead of using the wall. TA
Tux had already taken to kneading on a black fuzzy throw when I came across the concept of a “mama blanket” on Reddit. Essentially, it is any soft, fluffy blanket your cat likes to knead on for comfort. It’s a rare cat gift we can both enjoy equally: he is not a particularly cuddly cat, but on cold winter nights, he will curl up close if I am using “mama blanket” too. TA
My 105lb Pyrenees mutt Marty shreds garden-variety dog toys into heaps of stuffing within minutes, but Tuffy toys somehow survive for years, even when left in the Pacific north-west rain. The Ultimate Ring is easy to toss like a frisbee and the chain link offers a nice handle for tug of war. But if I am feeling generous this year, Marty may find Destructosaurus under the tree. Nick Mokey
Look, I don’t eat lamb, but somebody does, so our dogs might as well enjoy their (apparently delicious) leftover lungs. These dehydrated delights have a light, foam-like texture that snaps cleanly to whatever size you want and crucially, leaves no smell or residue on your hands. Every dog I have met adores them. NM
A solid dog treat pouch is a dispenser of good-boy affirmations for dogs and a reprieve from crumby pockets for humans. Marty has easily destroyed half a dozen treat bags in his lifetime, giving me an opportunity to test plenty. This is the one I keep coming back to. It clips to a belt or pocket effortlessly, the drawstring keeps treats from bouncing out, and the poop-bag pocket has room for two rolls, so you are never caught empty-handed. NM
Curated by Yuan and Gould based on our readers’ most beloved items of the past year.
When we blind taste-tested 10 premium chocolate bars, Hu’s vegan bars were a hit. We especially love the rich cashew butter folded into dark chocolate with raspberry filling, but Hu also offers bars with hazelnut butter, almond butter with puffed quinoa and more. KY
A cleaning brush may be an odd choice, but at just over $4 per scrubber, this is one of our most popular budget recs of all time, plus it has plastic-free, natural coconut fibers. Give your friends and family the gift of peace of mind that comes with avoiding microplastics. KY
Our priciest but prettiest stocking stuffer (and it lasts much longer than chocolates and drinks): this oyster has a hand-stitched felted wool shell and a little white pearl tucked inside. The wool is fairly traded and made in Kyrgyzstan and the whole thing is ready to hang with a string attached. KY
In testing, this sleep mask beat out 31 competitors to become our overall favorite, then went on to become one of our most popular recommendations of all time (our readers are a sleepy bunch). It gives total blackout coverage and stays comfortable enough to wear all night or a whole plane flight. KY
Last winter, I tried No Particular Order’s acquaintance cards, a dating app alternative that forces you to get off Hinge and approach someone in real life. They make a fun stocking stuffer for a friend tired of swiping or a newly single family member eager to reenter the dating scene. The cards recently got an updated design with a more durable tin and an included pencil. LG
Sipped from a festive can, this alcohol-free Negroni has all the bittersweet notes of the real thing, plus a little bit of juniper and citrus. I find it less sweet than the other NA-gronis in the beverage aisle. KY
Other pieces you might enjoy from the Filter , the Guardian’s guide to buying fewer, better things:
The nine best personalized gifts, from a timeless tote bag to custom stationery
The 17 best gift ideas for the person who already has everything
German knives, English socks: 13 gifts beloved globally that Americans are missing out on
Published on 2026/09/05
If you spend enough time in online developer circles, you’ll eventually run into a specific, recurring complaint: Software is being radicalized.
This whole argument usually goes something like: once upon a time, open source was a pure, objective meritocracy. Code was just a utility. Tools were neutral, like hammers or electricity. But now, the SJWs (there’s always venom in the way they say SJW lmao) are making software political and ruining the careful meritocracy by bringing in things like codes of conduct and bringing attention to problematic individuals within the projects.
To a certain subset of developers, this feels like an existential crisis. A sudden, trend-driven corruption of a sacred technical sanctuary.
Now, what if I told you that this nostalgia for a simpler time was never actually based in reality at all?
What people are calling the “radicalization” of software isn’t a new thing at all. I think what we’re seeing is that developers are rediscovering the foundational DNA of the software liberation movement and realizing that the “politically neutral” open source ecosystem they miss was a temporary corporate anomaly all along.
I feel like a short history lesson is in order to fully appreciate how we got to where we are.
In the 1980s, when Richard Stallman launched the GNU Project and published the GNU Manifesto, the movement was explicitly moral, ethical, and anti-authoritarian.
Note: Acknowledging RMS’s historical role in launching the Free Software movement is a matter of factual history, not an endorsement of the man.
History, however, requires us to document his foundational ideas while rejecting his personal conduct.
Stallman built free software because he saw proprietary software as a direct threat to human freedom, individual autonomy, and social solidarity. In the FSF worldview, software freedom was a fundamental social right.
Then came 1998.
As Linux gained traction, a group of prominent figures in the community realized that enterprise corporations - the IBMs and Microsofts of the world - were terrified of Stallman’s rhetoric. Phrases like “moral duty” and “user liberation” sounded too much like an anti-capitalist crusade to corporate boardrooms.
So, they engineered a rebrand. On February 3, 1998, Christine Peterson coined the term “Open Source” , and weeks later, Bruce Perens and Eric S. Raymond launched the Open Source Initiative .
The goal of this rebrand was explicit: strip away the moral, ethical, and philosophical language of Free Software and replace it with a pragmatic, business-friendly narrative. It was a textbook example of capitalism absorbing a radical critique of itself, sanitizing the politics, and repackaging it as an efficiency metric. As the OSI’s own historical account notes, the strategic pivot was designed specifically to “distinguish it from the philosophically-and-politically-focused label ‘free software’” and pitch the pragmatic business advantages of open development. Software wasn’t about pesky things like “human rights” or “ethics” anymore; it was about “superior engineering models”, “faster bug fixes”, and “economic efficiency”.
For twenty years, this sanitized version of open source reigned supreme. It built the modern internet. It also tricked a whole generation of developers into believing that tech had always been apolitical.
When you look closely at the modern nostalgia for “neutral software”, a striking double standard emerges.
When GitHub enforces U.S. export control laws and suddenly strips developers in sanctioned countries like Iran, Syria, or Crimea of access to their private repositories , the tech world generally shrugs. It’s treated as an unalterable reality of corporate existence: Welp, GitHub is a U.S. corporation bound by U.S. trade laws. Business is business.
But when a community-funded, non-profit forge like Codeberg sets transparent, democratically decided rules - such as their recent community membership vote banning predominantly AI-generated slop repositories to prevent severe server strain and maintain code safety - the reaction is drastically different. Suddenly, it’s labeled a “moral panic”, a “loss of software freedom”, or the “radicalization of tech”.
Why the discrepancy?
Because for twenty years, developers were conditioned to accept corporate and state governance as an invisible default. Corporate terms of service, venture capital incentives, and state sanction laws were treated as “neutral baseline reality”, while human and community governance was labeled “political interference”.
A platform that enforces zero community standards isn’t neutral. It simply chooses to prioritize the comfort of bad actors over the safety of everyone else. Total unmoderated “neutrality” on a platform just means forcing volunteer maintainers to absorb abuse, spam, and server costs for free.
Regardless of what people tell you, what we are witnessing today isn’t the death of open source - it’s the collapse of the illusion that tech can exist in a vacuum separate from human labor and human consequences.
Software is built by people, maintained by people, and hosted on infrastructure funded by people. Much like art, it cannot and does not exist in a vacuum.
If a maintainer decides that they’re done spending their nights and weekends handing free labor to a company or user actively harming them, using “cancel culture” terms to label that is stupid. They’re exercising basic individual agency.
The same goes for platforms. A non-profit forge restricting automated slop repos isn’t “censorship”; it’s basic resource management so that their servers aren’t overwhelmed.
Funnily enough, back when Linux adopted the Contributor Covenant in 2018 , it kicked off a discourse that was nearly identical to today’s LLM discourse with “apolitical” developers claiming that they’d be witch-hunted and driven out of developer spaces (which obviously never ended up happening, but reactionaries gonna reactionary, I guess).
In classical open source, freedom was always a two-way street. You have the absolute freedom to write and release whatever code you want, but everyone else has the exact same freedom to say “Nope, I don’t want this anywhere near me or my platform”.
The idea that software was once this pure, objective utility that has been ruined by modern social politics is a myth.
We are not watching the corruption of an apolitical ideal (which, let’s be honest, does not exist). We are watching a generation of developers realize that the corporate-friendly, business-sanitized era of open source mostly served to extract billions in free labor for massive corporations while leaving communities defenseless against burnout, abuse, and exploitation.
By re-establishing boundaries, demanding ethical accountability, and taking control of community spaces, developers (and users) are simply rediscovering open source’s first principles: that software freedom is, and always has been, deeply tied to human values.
You can comment on this blog post by replying to this post using any ActivityPub/Fediverse account!
Please enable JS and disable any ad blocker
November 13th, 2026
Something weird happens to people who are successful. They start to think they're gods.
Actually accomplishing anything is obviously no strict pre-requisite of success. And maybe it's not so much "being successful", but rather "being rich". How do you become rich? Some people are just lucky. Lucky to have a physical talent, lucky to have parents able and willing to nurture your talent, and of course quite often lucky to have been at the right place at the right time 1 .
Being lucky doesn't mean they didn't also work hard. But even—especially!—the Paris Hiltons of the world, the children of Hollywood superstars, the crooks starting their corrupt empires with " a small loan " (or a share of an emerald mine) from their fathers—they all strongly believe that they deserve their success and then conclude that anybody not as successful only has themselves to blame.
This is especially the case for people in tech, where for years and years being good at programming has been equated with overall (and often: superior) intelligence 2 , and those illusory superiority effects then amplify rampant Dunning-Kruger to quickly turn " I am good at writing code, and with some luck, I managed to be successful " into a train of thought that goes more like " I am successful. Success is not random, so I must deserve my success. I appear to be a genius, I've mastered coding, anything else is trivial. Ergo, I am good at everything . "
Let's take Bill Gates as an example. Now, mind you, Bill Gates certainly has accomplished a lot, and his skillset and professional background includes without a doubt a lot of computer programming and various ruthless monopolistic business tactics. In a recent New York Times interview , he describes how he evaluated OpenAI's level of progress (emphasis mine):
And I was going down to see OpenAI on a regular basis to see the work they were doing, and I challenged them, saying: Hey, if you can read a biology textbook and pass the advanced placement exam — getting a perfect grade, which is a 5 — then you will have proven that you are reading. That is, encoding knowledge in an accessible form. And so it’s six months before the public release that Sam Altman, Greg Brockman and Ilya Sutskever come to my house and demonstrate to me getting a 5 on the A.P. exam, even on questions that I had made up that it couldn't possibly have seen — very complex biology problems . It was nearly perfect. So that was shock No.1.
Now Bill Gates surely has shown an interest in biology and, through his work with the Bill & Melinda Gates Foundation, has probably read a lot of articles and research in this field. But the hubris to think himself a subject matter expert able to make up advanced, novel questions in a scientific field outside his own and suitable to assess AI's true capabilities and then being "shocked" that it could answer these questions makes my point.
Although, what really cooks his noodle is the idea that AI can do what he used to do: write code.
And then late last year, when Anthropic's Claude coding models got super good, I could see that they are as good as I am — it’s significantly my most developed talent, because I was obsessed from age 13 to 24 as to whether I could write code as good or better than anyone. That’s another moment where I went: This is incredible . That the capability of doing long-running, complex tasks has now gotten to the point that they are superhuman at writing code and in finding flaws in code.
Take note of the emphasis I added: the very notion that something else could be " as good as I am " is, first of all, hard to believe and secondly necessarily means that it's " superhuman ". That man is not lacking self-esteem, no sirree, Bob.
Likewise, this is also where many of the tech bros appear to be losing their minds , and this thinking ("Anything approaching my skill level is superhuman.") explains a lot about how we ended up with both stories of ultimate doom and human extinction as well as the utopian nirvana where AI solves all of mankind's problems (well, all of the billionaires' problems, which appear to largely converge on pesky mortality ).
For most tech nerds, being good at programming computers was a differentiating skill. It was weird, normies didn't understand it at all, you spoke your own language (languages!), you could make a computer do things . You understood how the internet works, and anything that's not working was clearly written by complete and utter morons, and you could easily write this yourself in an afternoon if you wanted to.
So now you've created a computer program that can do the same thing. Your mind boggles! And it speaks! It confirms you, it praises you, it tells you that you're brilliant—clearly evidence that it is infallible itself. But now imagine if it was better than you. What at first seems inconceivable then must strike fear and awe in your heart, for you have created a powerful monster with direction and purpose all its own . (And you sure have consumed enough pulpy science fiction to know that your creature is coming for you eventually.)
"Can you imagine a Beowulf cluster of these?" was an old Slashdot meme before memes were a thing. But the notion of having an army of minions to do your bidding has always appealed to the nerds looking to assert their superiority, and thus we arrived at "agents". "Swarms" of "autonomous" "agents".
This narrative of agency conveniently also relieves you of responsibility. You didn't fail to properly restrict a potentially malicious program you trained to hack other systems with persistence. No, the "agents" went "rogue". You have summoned powerful daemons indeed. Daemons that can produce code faster than you (gasp!), code you don't fully understand (although of course you could, you just don't want to, you don't have time, you have too much going on, what with your homegrown heavily customized harness). It becomes obvious quite quickly that this, then, must be SUPERINTELLIGENCE. Superintelligence that COULD KILL US ALL!
I picked on Bill Gates above to illustrate the overconfidence effect , but of course there is no shortage of much more exaggerated egos making bold statements outside of (or even within ) their purported area of expertise, reflecting a complete and utter inability to relate to other people. To them, we're all just NPCs .
The more powerful people are, the less empathy they exhibit. This is neither news nor limited to tech; dog knows there are countless rich assholes outside of tech doing asshole things . But few outside the tech sector suffer the same level of delusion, of thinking themselves solely and uniquely qualified to decide mankind's future, to claim to have birthed a digital Prometheus, to boldly declare (and use as a perpetual shield) a literal Deus ex Machina to cure all diseases —if only they could find the time to prioritize that sort of work over, say, their military contracts .
Pretending to even remotely care about climate change 3 while at the same time undoing " 15 years' worth of greenhouse gas reductions " and then listing environmental concerns as a risk factor in your S1 is just the cherry on top.
If these are the new American Gods... well, je n'ai jamais eu besoin de cette hypothèse-là .
November 13th, 2026
Footnotes:
[1] The actual citation for " Bill Gates went to one of the only high schools in the world that had a computer " is " The Psychology of Money by Morgan Housel; Malcolm Gladwell discusses this in Outliers as well. ↩
[2] The entire interview circus in the tech world revolved around this notion of exclusivity and brilliant jerks: " Google hires geniuses " was an oft-repeated mantra in Silicon Valley, so logically, if you were hired by Google, you were a genius. (Yes, all >180,000 of Google's employees.) This translates to the other big or exclusive companies, and explains why everybody leaving will always note that they were always surrounded by the most brilliant minds. It's Inverse Groucho Marx Bias . ↩
[3] And hey, we really don't need AI to "figure out how to combat climate change". We already know how to do it. We just have to actually show any willingness to stop it. Unfortunately, that's also exactly where these megalomaniacs get in the way. ↩
Links:
How does your brain help you learn a new skill?
To try to answer this question, we’ll build a digital being with a simple brain, and watch it learn a new behavior.
In our previous article , we created a creature called a spark that could steer towards light. And we saw how small changes to its neural circuitry gave rise to very different behaviors.
Back then, we’d wired these circuits into the spark’s brain by hand. But now, we want it to learn the same behaviors by itself .
After all, you didn’t come into this world knowing how to walk, talk or read. While some of your abilities, such as breathing or swallowing, are wired by evolution, you gained others through an arduous process of trial and error.
We want our spark to do the same. To give you an intuition for this learning process, we’re going to hand over the controls to you. We’d like you to wire the spark’s brain.
But first, we need to tell you what you’ll be wiring. The spark’s brain has just four neurons — two neurons serving as its eyes, and two neurons that wiggle its flippers.
There are straight connections between neurons on the same side of its body, crossed connections between neurons on opposite sides, and drive , which controls the spark’s speed when there’s no light.
So its brain wiring boils down to just three numbers — the strength of each kind of connection, and the drive.
Now let’s set this spark loose. Use the sliders below to wire its brain as it moves. We’ll keep score.
Your goal: Make the spark love the light by getting a score above 0.5.
Neural
circuit
Tries
Finding the right configuration takes a lot of trial and error. (If you get stuck, click the hint button above for a nudge in the right direction.)
Let’s visualize what you just did. To guide the spark to the light, you tweaked three numbers. We can represent these numbers as the three axes of a cube.
The payoff of this picture is that we can visualize your spark’s learning trajectory as a path within this cube.
To guide the spark, you probably nudged a slider one way, saw whether this made things better or worse, and then used this feedback to decide your next move.
Let’s distill this into a learning algorithm — a step-by-step procedure by which the spark can rewire its brain through practice.
Here’s how it’ll work: The spark gets many tries to steer towards the light. Before every trial, its brain wiring will change a little at random, just like you wiggled the sliders to and fro.
If the trial goes better than previous ones, then the spark gets a reward and its wiring shifts in the direction of this random change. And if the trial goes worse, the spark gets a punishment, and its wiring shifts the other way.
This isn’t that different from how you learned how to walk or ride a bike. Falling down was your punishment, and the thrill of balancing was your reward.
Can this simple algorithm help the spark find the light?
In the beginning, the spark is a novice, with a brain that’s wired together at random. Unsurprisingly, it doesn’t get very far.
The baby spark can spin in place, but it can’t yet move around. But it’s about to get better…
After 50 tries of this learning algorithm, our infant spark has taken its first steps. And while it won’t break any speed records, it’s now on the move…
After 250 tries, our juvenile spark has picked up speed. But it veers away from the light at the last moment.
After 500 tries, our adolescent spark boldly charges towards the light. But it hasn’t yet figured out how to slow down or stop.
After 2,000 tries, our spark is now an adult — an expert at seeking and following the light. It clings to the light and can turn on a dime. (Try moving the light to see the spark follow it.)
Like before, we can visualize this learning process as a path.
This isn’t a path through physical space. Instead, it’s a path through the space of possible brains . It shows how the spark’s brain changed as it learned.
Other novice sparks would start from different points, and they would each trace out their own learning trajectory.
This tangled web illustrates the learning paths of hundreds of novice sparks, each starting with a differently wired brain. As if by magic, all of these threads converge to the point marked ♥︎ .
The paths aren’t straight lines: Learning isn’t linear. There are setbacks, wrong turns and mistakes along the way. And it isn’t necessarily fast. Some of the learners took thousands of tries to reach their goal.
You’ll notice that the paths are all jittery. That’s because every step involves randomness. We can smooth out this jitter by averaging over many trajectories at every point, revealing a map of the flow of learning.
It’s worth taking a moment to appreciate how surprising this is — given enough tries, the same learning process turned every novice into an expert light seeker.
Of the myriad possible arrangements of this spark’s brain, only a tiny fraction generate the behavior that we want. There are far more ways to fail than to succeed.
And yet, you’ve just witnessed a small miracle. The spark navigated this labyrinth of dead ends and rewired its brain to find the light, guided by nothing but reward and punishment.
Learning doesn’t stop once you become an adult. We learn throughout our lives and adapt to changing circumstances.
Our sparks can do this too. For example, what if the light represents a harmful chemical or a dangerous predator instead of a food source?
The spark is now rewarded for avoiding the light rather than for seeking it, and this leads to new behaviors:
If the light is harmful, then LOVE becomes the worst strategy, and the sparks learn to FLEE (escape as fast as possible) or to FREEZE (play dead).
If instead the spark is rewarded for approaching the light with high speed, then it learns to charge towards the light, i.e. to FIGHT .
Much like a child learns from its environment, the spark can learn very different behaviors — fleeing, freezing, fighting or following the light — depending on how it’s rewarded.
· Spark is shown moving at two-thirds speed.
You’ve now seen how a novice spark can rewire its brain and learn new behaviors through a process known as reinforcement learning.
Biological brains also learn through reinforcement. For example, baby songbirds learn to sing by babbling. They try out random variations of their song. If a variation gets closer to their memory of an adult’s song, they get a burst of dopamine (and if it gets further away, the dopamine dips). Guided by these rewards and punishments, they can recreate the song from memory, even with no teacher present !
Now, we do have to come clean about something. This spark’s brain had just four neurons and three numbers that determined how these neurons were connected. This simple structure allowed us to watch its brain learn in three dimensions.
Your brain has around 86 billion neurons and over a hundred trillion connections. The space of possible ways in which it could be wired is therefore unimaginably vast.
But while the details are much more complicated, the underlying idea is the same: Learning is how you navigate this vast internal space. And feedback is the compass that points the way.
Thanks for reading chapter two of Myriad , a series exploring how minds emerge from matter. Myriad is a collaboration between Arkarup Banerjee , a neuroscientist who studies behavior, and Aatish Bhatia , a physicist turned science journalist.
The sparks in this article are inspired by the work of the neuroscientist Valentino Braitenberg . We implemented their neural circuitry as follows:
where and are the left and right flipper speeds, and are the brightness levels at the left and right eyes, and are the straight and crossed connection strengths between the eyes and the flippers, and is a drive that sets the spark’s speed when there is no light. is the ReLU function . The spark’s forward speed is the average of the two flipper speeds, and its turning speed is proportional to their difference.
There are three parameters in our simplified setup: and The spark learns values for these parameters using a version of the REINFORCE algorithm published by Ronald Williams in 1992.
Each trial, the parameters were wiggled by a small random amount and the spark moved for 500 time steps, starting from a random point on the edge of the arena. Its reward was the average brightness along its path.
This reward was then compared to a running average of recent rewards. If the spark did better than usual, its parameters were nudged in the direction of this random change. If it did worse, its parameters were nudged in the opposite direction. The size of the nudge was proportional to how much better (or worse) it did:
Here is the change in the three parameters, is the learning rate, is the random wiggle, and is how much better or worse than usual the spark did. We repeated this thousands of times.
Williams’ original approach adds randomness to each neuron’s output. We add it to the weights and biases instead, an approach known as weight perturbation . A similar idea, called evolution strategies , was used by OpenAI in 2017 to teach AI models to play Atari video games.
Sign up below for more rigorously researched visual explanations of neuroscience, and share this article with others who might enjoy it.
Over the past several weeks, teams across Google and academic partner institutions have tackled open problems in math, science, and complex systems engineering that had remained open for years. Using Gemini 4 Argon , Gemini 4 Carbon , Gemini 4 Hydrogen and multi-agent workflows such as Antigravity’s /teamwork (building on various Gemini models), these collaborations have produced new innovations across information theory, formal verifications, molecular structure discoveries, and kernel optimization, along with several production infrastructure gains at Google. We are making these agentic tools available in Antigravity’s /teamwork (alongside /boost and other agents) so that researchers and developers can apply them to their own work.
Frontier research and systems engineering require navigating vast literature, building custom computational pipelines, testing against physical measurements, and verifying every step. Progress comes from an interactive discovery loop where researchers frame questions and define the theoretical or physical constraints, while long-horizon agents write custom solvers, explore large search spaces, test candidate designs, and check long chains of logic.
Two limits of current language models motivate /teamwork's design . First, model generation can be unpredictable, leaving a gap between a single attempt and finding the correct answer. The system bridges this gap by pairing parallel exploration with dedicated falsifiers (e.g., the Lean 4 proof checker, unmodified software test suites, execution simulators, web search, or hardware counters) to automatically verify which candidate solutions work.
Second, AI models often lose track of details over multi-day tasks because attention disperses across growing context windows. To prevent this, /teamwork partitions context by construction: each specialized agent receives only the exact files and tools it needs for a specific step. Coordinators hand off tasks to fresh successors, while critics and auditors challenge and verify results from clean contexts without the original producer's reasoning.
Teamwork expresses these workflows as declarative self-improving natural-language patterns and dynamically routes each user prompt to the pattern best suited to the task. These patterns range from distributed coding and iterative problem-solving (packaged standalone as /boost , a sequential solve-and-verify loop refined from prior trajectories) to specialized research workflows like long proof and document review, all of which are available in Antigravity today. This allows teams to design custom specifications from past run transcripts routing across different harness patterns and dynamically improving agentic harness. While many of these features are available in Antigravity, we will provide more updates in the coming weeks providing all the features to our external users on Antigravity. Following our previous posts on Antigravity /teamwork , we provide new results to open challenges empowered by new variants of /teamwork and Gemini 4 models.
Across mathematics and theoretical computer science, researchers paired with Gemini 4 and /teamwork harnesses to collaborate on large-scale proofs and generate complete algorithms and proofs directly from open problem statements. We present several examples.
Researchers from Google, CUHK , USC , and CMU used /teamwork's Long Proof pattern (implementing Stellar Colosseum in Antigravity) to prove information theory's 2013 Courtade–Kumar conjecture in full generality. The result confirms that when a random bit string passes through a noisy channel, no compression of the input to a single bit preserves more information than a "dictator function", which just copies a single input bit. Gemini first found counterexamples to a generalized conjecture from the CUHK team's earlier paper . The CUHK team then proposed a new candidate function that reduced the conjecture to a 14-variable optimization problem, along with a key analytical lower bound. Gemini 4 Argon and earlier Gemini models then partitioned the parameter space and developed most of the new analytical bounds and interval-arithmetic certificates. They also extended the proof from balanced to unbalanced functions without human input. The team formalized the entire proof in Lean 4, producing 50 million lines of code.
Researchers also posed open problems directly to Gemini 4 and to multi-agent harnesses such as Stellar Colosseum and /teamwork , receiving end-to-end algorithms and proofs (often with Lean 4 formalizations) that the authors verified, simplified, and edited for publication. In adaptive data analysis, a multi-agent harness running on Gemini 4 Argon independently proved and Lean-verified near-optimal sample bounds for statistical queries chosen adaptively from earlier answers, closing a gap open since 2014. These bounds yield the first nearly space-optimal algorithm for data streams with both insertions and deletions that stays accurate against adaptive adversaries. In quantum computing, a new construction settled a 2014 open question by finding the first n -bit Boolean functions needing strictly more than n /2 quantum queries at constant error, while pinning down the exact query overhead across symmetric functions.
Several results break long standing barriers in processing and compressing large matrices and graphs. For fifty years until STOC 2024 , combinatorial algorithms for Boolean matrix multiplication and triangle detection (avoiding the algebraic cancellations of fast matrix multiplication) saved only logarithmic factors over cubic time. A new deterministic algorithm resolves STOC 2024's main open question, achieving its target speedup over cubic time. In high-dimensional geometry, a new lower bound resolves an open problem on sparse networks, proving that approximating all pairwise distances among n points within any constant factor can require polynomially more than n edges, even with extra Steiner points and arbitrarily many hops. In randomized linear algebra, stacked sparse sketches resolve a 2025 open question by breaking the classical sparsity barrier for compressing a matrix to linear dimension without collapsing any direction of an r -dimensional subspace, needing only √log r nonzeros per row (quadratically fewer than the log r required to preserve all lengths) and nearly matching a new lower bound. For weighted graphs under dynamic edge-weight insertions and deletions, Stellar Colosseum resolved an open question left by FOCS 2022 , developing the first single-pass streaming algorithm for cut sparsification that achieves near-optimal memory, update time, and reconstruction time simultaneously.
Our results also span optimization, arithmetic, data structures, and statistics. In optimization, resolving an open question on online inverse linear optimization (inferring an expert's hidden objective from decisions over time), the approach gave a deterministic algorithm achieving optimal regret while cutting runtime from exponential in the dimension to polynomial time. For n -bit integer multiplication , multi-agent campaigns simplified the theoretical Turing-machine bound below n log n , while a separate effort gave a new O ( n log n ) algorithm on a single two-dimensional grid whose C implementation matches the GNU Multiple Precision Arithmetic Library (GMP) bit-for-bit up to a billion bits. In data structures, another result made significant progress on Tarjan's 1985 Deque Conjecture (whether self-adjusting splay trees handle insertions and deletions at both ends in constant amortized time), proving a new upper bound on the per-operation overhead that simultaneously beats every finitely iterated inverse-Ackermann function, verified in Lean 4 . Finally, in high-dimensional statistics, the approach proved that approximate leave-one-out cross-validation , which avoids refitting the model from scratch, remains accurate for non-smooth sparse penalties like elastic net .
Checking a computer-assisted manuscript by hand places a heavy burden on peer reviewers, and subtle flaws can hide inside long calculations. Formalizing mathematics in Lean 4 turns a proof into code that a computer kernel checks line by line. Once human mathematicians confirm that the formal theorem statement matches the original problem, the proof only compiles if every logical step holds.
Many of the deepest open problems in mathematics govern how physical waves propagate, how dynamical systems evolve, and whether polynomial equations have integer solutions. Working directly from informal proofs, our multi-agent framework, LEAP , developed with colleagues in Google Cloud AI and paired with Argon, has made progress in these core areas.
Notably, /teamwork -LEAP fully autonomously produced an end-to-end, machine-checked formalization of the Weil conjectures , the landmark results on counting solutions of polynomial equations over finite fields that culminated in Pierre Deligne 's 1974 proof. This formalization spans about 1.8 million lines of Lean, produced across 28,800 subagent invocations. The system also synthesized over 919,000 lines of Lean to produce the first formalization of a recent proof of Hilbert's tenth problem over general rings of integers. It also independently reproduces an end-to-end formalization of a recent proof of finite-time blowup for the 3D Navier–Stokes equations with smooth forcing, part of one of the seven Millennium Prize Problems and open for about 90 years.
Beyond these, it also generated the first formalization of the Birkhoff conjecture , a dynamical-systems problem open since 1927. Moreover, it formalized for the first time the 3D Bochner–Riesz conjecture , a central problem in harmonic analysis open for more than 50 years, finding and fixing a gap in a recently released informal proof along the way. Additional machine-checked breakthroughs include resolving the C¹ regularity of infinity-harmonic functions in three and higher dimensions (an open question for about 20 years), formalizing Killip and Vişan's theorem that the KdV water-wave equation is well-posed in H⁻¹ and verifying a UCLA group's informal proofs of the 40-year-old Jamison Caterpillar Conjecture, the Ağırseven-Ollis conjecture, and an improved upper bound on Erdős Problem #1063.
Finally, we provided Deep Review for authors of another CS conference: ahead of STOC 2027 , authors of 578 submissions (over a third of all submissions) opted in to receive Deep Review feedback on their drafts. In an ongoing author survey (N = 70), 90% of respondents rated the feedback mostly or almost all factual and 90% said they would use the tool again. Over 30% said Deep Review caught substantive proof bugs or mathematically significant typos, and 14% said it found technical gaps that took more than an hour to fix. Surveyed authors shared that “Tools of this kind can help produce cleaner and more precise research, faster” and that DeepReview provides peace of mind on scientific discovery”. We provide users two weekly calls to Deep Review for free. Deep Review is also implemented as /teamwork's document review pattern and available in Antigravity. Read more about DeepReview in our recent blog post .
Beyond formal proofs, pairing specialized generator agents with independent verifier agents enables discovery workflows in experimental laboratory science.
Determining a molecule’s structure from experimental nuclear magnetic resonance data is one of chemistry’s hardest puzzles. For example, in HIV protease inhibitors , one misplaced bond separates an inactive look-alike from a drug. By organizing 30 specialized agents into a self-correcting loop with /teamwork and a physics-informed spectral simulator, we achieved 95% top-1 exact match and 100% top-3 accuracy on complex benchmark molecules, nearly doubling single-agent performance. Beyond teaching Gemini to reason over structure, this lays the groundwork for ongoing works on 3D protein and complex structures dynamics.
Beyond this example, science problems including applications in nuclear fusion and quantum algorithms reported in the Gemini 4 blog post benefited from /teamwork and the Argon model.
We also applied a similar multi-round auditing workflow to build empirical benchmarks. Starting from five human-specified acceptance criteria like data anonymization, 29 agents running on Argon over 11.5 hours turned 13 public tables into a 50-task causal inference benchmark. In these tasks, models must determine whether a causal effect can be identified and estimate it against a known answer. After initial checks, separate reviewer and auditor agents caught shortcuts, flagged wording hints, and vetoed hallucinated scripts, turning each into a permanent test. Automating this heavily manual task generation supplies the hard problems needed to help Gemini answer counterfactual "what-if" questions.
When paired with objective evaluators such as network benchmarks, game engines, unmodified test suites, and hardware timers, /teamwork campaigns can execute multi-day software and hardware engineering projects.
Using /teamwork and Argon, we built FarArray , a low-latency kernel-bypass Partitioned Global Address Space based on the SNAP microkernel . Applications built on FarArray include lock-free Connected Components , which scale to 1-trillion-edge graphs with 60x to 90x throughput gains and 40x to 180x speedups at 6x lower RAM over TCP key-value stores. Similarly, InstantEmbedding (Personalized PageRank) reduced peak DRAM by up to 14x and runtime by 11x to 27x over accelerated MapReduce implementations. The team also used /teamwork and Argon to create custom TPU kernels for Graph Neural Networks, delivering up to a 185x High Bandwidth Memory reduction and 8x to 15x speedups in forward and backward passes. Further details are available in our recent Antigravity blog post .
To test autonomous optimization over long horizons, hill-climbing teams on Argon trained a 9x9 Go engine from scratch starting from a basic AlphaZero implementation. Human researchers set the chip allocation and evaluation setup, while the harness ran autonomous campaigns for faster self-play (achieving a 2,300x speedup) and faster Elo readings, promoting champions strictly via statistical tests on locked records. In under eight days, the engine gained roughly 2,600 Elo, reaching 1,885 Elo, placing it between KataGo at 16 and 32 visits per move.
Large code migrations fail when agents stub out dependencies or alter tests to make a broken port pass. A new /teamwork rewrite pattern, soon to be available in Antigravity, solved this by scheduling each module only after its dependencies compile, linking every leaf module against the original, unmodified test suite. Building on the initial 25% port of the Zircon microkernel , a two-week Argon campaign rewrote the remaining C++ code, adding about 800,000 lines of safe Rust that pass all kernel unit tests and boot on arm64 hardware. /teamwork also rewrote libgav1 , Google's AV1 video decoder, from C++ into around 170k lines Rust, achieving 100% bit-exact parity across a broad conformance test suite. Initially, the port was around 4x slower than the original C++ code. However, after giving /teamwork access to profiling tools and a mandate to maximize speed on sample video clips, the Rust port became 20-30% faster than the original C++ and hand-optimized assembly code on both x86_64 and ARM.
For day-to-day coding tasks, the Antigravity /boost command packages /teamwork's iterative coding pattern . A long-running /teamwork campaign analyzed past run trajectories and found that tightly coupled code is best handled through sequential implementation and revision stages rather than parallel splits, improving /boost on coding tasks. This is an example of a harness optimizing another harness for token efficiency.
For machine learning systems, full hardware evaluations of custom JAX and Pallas TPU kernels take 7 to 32 minutes, limiting how many candidates prior optimization agents can explore. Using /teamwork's DuoDiscover pattern on Argon, four parallel agents identified performance bottlenecks and constructed fast, 23-second proxy evaluators called yardsticks. These yardsticks produce candidate orderings that are continuously validated against periodic full hardware runs using Kendall's rank correlation . DuoDiscover achieves a 4.09x geometric-mean speedup over reference implementations across 17 JAXBench kernels and a 2.99x geometric-mean speedup across 7 hand-optimized vLLM TPU-Inference Pallas kernels for frontier open-weight models.
We have also applied /teamwork and /boost to many production infrastructure and hardware modeling problems across Google. Examples include:
External scientists and developers can use Gemini 4 models with /teamwork and /boost in Antigravity and Deep Review today. We have also opened applications giving 10,000 academic researchers six months of free access to our highest usage tier. Upcoming updates will bring our formal proof pattern and additional specialized workflows into Antigravity. These features will be accompanied by deep-dive tutorials on the Antigravity blog in the coming weeks, ensuring that developers and researchers have the resources needed to generate, inspect, and iteratively refine custom multi-agent teams. We are excited to make our tools (in addition to our models) available for everyone.
Antigravity’s
/teamwork
feature is a result of a Google-wide effort with many contributors and ongoing explorations. Contributions include: Yuan Deng
Several academic collaborators contributing to the research papers: Zijie Chen, Amin Gohari, Chandra Nair (CUHK), Songbin Liu, Arian Maleki, Chen Shang, Hanbo Yang, Wenjin Zhang (Columbia University), Zihan Hao, Qipeng Liu, Jianan Shao (UCSD), Lorenzo Beretta (IBM Cambridge), Simone Bombari (BYU & Flatiron Institute), Mahbod Majid, Margalit Glasgow (MIT), Raphael Arkady Meyer (UC Berkeley, ICSI, & LBNL), Kijun Shin (CMU), Huacheng Yu, Elena Gribelyuk (Princeton University), Xin Lyu (UCB/ ByteDance), Samson Zhou (Texas A&M), Erik Waingarten (UPenn ) , and Sorrachai Yingchareonthawornchai (ETH-ITS).
Welcome back to the Abstract! These are the studies this week that watched movies, made sacrifices, got crafty, and aged backwards.
First, scientists learn how primates make meaning out of visuals by peeking into the brains of monkeys as they watch Despicable Me . Then: human sacrifice as climate “crisis rituals,” the fingerprints of prehistoric children, and the longevity secrets of ants.
As always, for more of my work, check out my book First Contact: The Story of Our Obsession with Aliens , or subscribe to my personal newsletter The BeX Files .
Settling down to watch a film is often viewed as a way to relax and shut our brains off for a while. Our brains, however, beg to differ—they are as busy as ever when interpreting videos, according to a new study based on brainwaves of humans and primates as they watch movies and short clips.
To better understand how primate brains make meaning out of visual scenes, researchers studied eye movements and electroencephalogram (EEG) readings of neural activity in dozens of humans, as well as two macaques, as they watched videos.
“Primate vision relies on eye movements to sample the world, yet how the brain integrates high level meaning across these ‘snapshots’ remains a mystery,” said researchers led by Vinay Raghavan of the City College of New York. The new results hint that “visual processing is not a series of independent glimpses, but a continuous process,” the team said.
Human participants with EEG electrodes attached to their scalps (the “scalp movie dataset”) watched a selection of films including The Big Sick , The Peanut Butter Falcon , Whiplash , Room , Me and Earl and the Dying Girl , The Tomorrow Man , Dom Hemingway , Life After Beth , Woodshock , and The Comedian.
“Participants were instructed to watch the movie as they would normally watch a movie,” the team said.
A different “intracranial dataset” included several human patients and two rhesus macaques, the latter of which had electrodes implanted inside their skulls. This group watched shorter videos, including 10-minute clips of Despicable Me in both English and Hungarian, a 4.3-minute clip of the short film The Present , and three 5-minute clips of documentaries featuring macaques.
Taken together, the datasets revealed that the brain responds to “semantic novelty”—meaning new semantic or conceptual information that crops up over the course of a video—which is measured through patterns of short-gaze “fixations.” The study also suggests that many brain regions beyond visual processing are involved in this ability to draw meaning from scenes.
“These results challenge traditional vision models that treat fixations as independent snapshots and highlight the importance of considering the temporal dynamics of eye movements and the predictive nature of visual processing,” the team concluded.
In addition to opening a new window into the mind, the study raises the irresistible yet unanswerable question of what macaques make of Minions. Alas, here we must confront the limitations of the knowable universe.
In other news…
When climate-related disasters struck ancient Peru, some cultures responded with mass human sacrifices to appeal to the cosmos. For example, at least 107 adult men were sacrificed in six closely-timed events at Huaca de la Luna around 550–600 CE, and more than 140 children and 200 juvenile camelids were sacrificed at the Huanchaquito-las Llamas site around 1450 CE.
These ritualized killings often coincided with flooding and freak weather related to the El Niño–Southern Oscillation, the natural climate phenomenon in the Pacific Ocean that cycles through a warm “El Niño” phase and a cooler “La Niña” phase. The Huaca de la Luna sacrifice, for instance, occurred during a so-called “mega-Niño.” This connection inspired researchers to determine if environmental conditions were also linked to interpersonal violence outside of these ceremonial “crisis rituals” that were organized by elites.
The team conducted a meta-analysis of the skeletal remains of 1,633 individuals that lived in Peru’s Lambayeque Valley over the course of 3,000 years before the arrival of Europeans. The remains presented “no strong evidence for an association between environmental factors and interpersonal violence” and suggested “that non-ritual violence in the Lambayeque Valley Complex was rare (1.6%),” according to the study.
The mass sacrifices reflect “the sometimes lethal relationships between human behavior, cultural norms, and the environment—and are frequently used as cautionary allegories regarding the ongoing climate crisis,” said authors Thomas Snyder of New York University and Haagen Klaus of George Mason University.
Time to add “prevention of ritualized human sacrifice” to the list of reasons to address climate change. Worth a shot?
The fingerprints of children who lived 15,000 years ago in the southern Levant are preserved on clay artifacts, a discovery that exposes “a rare direct testimony of inter-generational knowledge transmission in a hands-on apprenticeship,” according to a new study.
Archaeologists studied 154 clay figurines that were unearthed across three archaeological sites in Israel, including a subset depicting birds, a gazelle, and two human forms. Crafted by the Natufian culture, these artifacts represent “the earliest evidence of a figurative clay tradition in Southwest Asia where it marks an important step in the evolution of human technology,” said researchers led by Laurent Davin of the Hebrew University of Jerusalem.
Because these people sculpted the artifacts by hand, fingerprints are occasionally spotted on the clay, revealing the contributions of children and adults. In some cases, a preserved “succession of gestures on the wet clay suggests that, during the modeling sequence, an adult passed on the figurine to a pre-pubescent child,” the team said. “Therefore, these artefacts could be interpreted as portable figurative mnemotechnic devices related to children’s learning of traditional beliefs and ethno-ornithological knowledge.”
It’s so evocative to see the preserved touch of a child who lived so long ago, capturing a moment of skill-building and, perhaps, play. While we don’t know exactly what these figurines meant to their crafters, their survival is a testament to human creativity and imagination.
We humans are used to a pretty standard life cycle: Birth, reproductive years, a decline in fertility, and an inevitable slide toward mortality. But a multi-decade study of ants reveals that some colonies operate as “superorganisms” that display increased reproduction and decreased mortality rate with age, reversing the course of normal senescence.
Researchers who gathered 34 years of data on 3,285 colonies of the western harvester ant ( Pogonomyrmex occidentalis ) discovered that these groups “display reverse aging,” according to their new study.
“We will show that colonies of P. occidentalis not only have extraordinary longevity, but that their pattern of aging differs dramatically from that of most insects,” said authors Blaine J. Cole and Diane C. Wiernasz of the University of Houston. “Colonies exhibit negative senescence—increased survival and reproduction with greater age.”
This finding does not mean that individual ants are aging in reverse; worker ants live and die normally in these colonies. However, the larger superorganism becomes an unusual “non-senescing form.” While the ants go marching one by one, the colony’s lifespan adds up to a larger sum.
Thanks for reading! See you next week.
Microsoft has said its service has been fully restored after a massive outage that saw widespread disruption to governments, businesses and public services around the world.
The technology company said on Saturday morning it had restored service to the remaining customers affected by one of the worst IT failures in years. On its Microsoft 365 status page, the US-based firm said: “We have completed our efforts to address the underlying issue of the incident and restored service to the remaining impacted customers and regions.
“Further updates can be found at MO1550821 in the Microsoft 365 admin center.”
The outage, which began on Thursday, affected governments, courts, healthcare services, businesses, airlines and banks. Governments including those of Japan, Singapore and Australia reported that the hours-long episode had affected some of their operations.
In the UK, where NHS England has a five-year deal to use Microsoft 365, vital public services were hit, with hospital staff resorting to paper records and one union reporting that ambulance services had suffered a “serious impact”.
The already backlogged court system was also hit, with juries in some cases being sent home early or prisoners not being sent to court, while at Minshull Street crown court in Manchester staff scrambled to locate a fax machine.
In the US, school districts told parents they must reach out by phone or online apps to contact their child’s school, while staffers at the House of Representatives told Politico they had lost a day of work.
One detention facility in Colorado said they were unable to take online bond payments to release detainees and told anyone needing to post bond for immediate release to do so in person at the jail.
In Australia, many people who rely on Microsoft 365 reported being unable to access their inboxes, including at councils, courts and schools. The federal police and Asio, Australia’s national domestic security and intelligence agency, were also affected by the outage.
Asio’s director general, Mike Burgess, said the agency’s systems “operate on multiple levels”, adding that they had been affected “on one level, yes, but not completely”.
Across Europe, government agencies in the Netherlands, Belgium and France reported problems, with a French municipality instructing citizens to use the phone instead of emailing.
In Japan, government email services became unavailable and staff resorted to text messaging. The shipping firm Sagawa Express was unable to accept some online reservations while Taisho, a major pharmaceutical company, said it was having to handle orders by phone.
The Indian airlines IndiGo and Akasa Air said their email support services were affected, and Taiwanese security firms, life insurers and investment trust companies told Reuters that fund management services had been disrupted.
Users reported that Microsoft 365 services, including Outlook, Teams and the AI assistant Copilot, were interrupted. Downdetector, an online tracker, said it received outage reports from users in more than 70 countries and territories.
Approximately 430 million people use Microsoft 365 apps, Microsoft said on its website. Problems began at about midday on Thursday in the US and at 6pm in the UK.
after newsletter promotion
The Washington-based company apologised on Friday for the disruptions and said the outage was “not related to cyber” or artificial intelligence agents. It said the incident “was introduced by an issue during an earlier network capacity upgrade that surfaced” after a recent network change.
The disruptions offer the latest example of the cascading problems that can erupt when multiple communications and technology platforms depend on the same provider. The outage has fuelled concerns in the UK about an overreliance on a small number of tech companies.
Steven Murdoch, a professor of security engineering at University College London, told the Guardian an outage of this size was usually “the result of some surprising interaction between systems. Each of the systems is normally quite well understood but interactions between them are complex and frequently the cause of large outages like this.
“It’s very hard to build a complex system without there being some risk of some failure.”
Tim Clement-Jones, a former chair of the House of Lords artificial intelligence select committee, said the widespread outages of vital government services were an “I-told-you-so moment” highlighting Britain’s dependence on US tech.
Jeremy Singer, a professor at the University of Glasgow’s School of Computing Science, said: “This problem serves to emphasise the dependence we have built on one company’s digital infrastructure, and may lead us to question whether we need more resilience in our IT ecosystem.”
The total number of people affected was not clear, but Microsoft said in January it had more than 450m paid commercial subscriptions to its 365 services.
Since 2021, Project Zero has followed a “90 + 30” vulnerability disclosure policy, allowing vendors up to 90 days to remediate a vulnerability plus an extra 30 days “soak time” for patch rollout. Our goal was to encourage faster patching and give vendors time to deliver patches to users. The advent of AI-assisted vulnerability discovery and exploitation has changed the threat landscape such that the vulnerability remediation timeline encouraged by our disclosure policy is clearly insufficient.
LLMs have increased the speed at which attackers can find and exploit vulnerabilities, alongside the risk that multiple parties, including malicious ones, discover the same bug. A vulnerability reported today presents a much higher immediate risk to users than one reported last year. In this new environment, it is crucial that vendors move towards remediating vulnerabilities faster.
LLMs have also decreased the time it takes for attackers to reverse engineer and exploit a vulnerability based on a patch, to the extent that zero patch-to-exploitation time is a reasonable, though imperfect, model of attacker behavior. Patch soak time is no longer meaningful in a world where attackers can almost immediately determine bug details from a patch, and can put users at risk by creating a false sense of secrecy. “Patch gap” is the time between a fix being released for a security vulnerability and the user installing the relevant update. It is equally crucial that vendors reduce patch gap, either by reducing patch rollout time or using other strategies to protect users while remediation is in progress.
LLMs have also increased the volume of vulnerabilities that Project Zero reports. We are finding several vulnerabilities a week in targets where we once found a few vulnerabilities a year. Aspects of our policy that require vendor negotiation or agreement, including determining whether a bug is fixed and whether grace period applies, are quickly becoming unmanageable.
Today, we are announcing a new vulnerability disclosure policy, created with the following goals in mind:
Vulnerabilities will be disclosed X days after they are reported to the vendor.
Starting today, our policy is “Full 90”, i.e. vulnerabilities will be disclosed 90 days after they are reported to the vendor.
On February 2, 2027, we will move to a “Full 60” policy where vulnerabilities are disclosed after 60 days.
On January 3, 2028, we will move to a “Full 30” policy where vulnerabilities are disclosed after 30 days.
We are also removing most ‘special cases’ from our disclosure policy, including grace period and variant policy. The only exceptions to our new policy are:
Project Zero solicited feedback from the vendors we report the most vulnerabilities to as a part of developing this new policy. An overarching concern was that immediately changing the policy could harm users by making unfixed vulnerabilities available to attackers while vendors are in the process of improving their remediation processes and technology. While the benefits of delaying disclosure are declining due to the increased probability that attackers will discover a vulnerability during the embargo period, we still feel there are benefits in the short term.
In addition, vendors mentioned two more subtle concerns. One was that an overly-aggressive disclosure policy would encourage fixing bugs reported under the new policy with more priority, even if they are less severe than other reported vulnerabilities. The other was that immediately enforcing a policy that some vendors aren’t equipped to meet might lead to a state where vendors accept that they cannot fix bugs within the deadline and don’t attempt to.
We decided on a policy that encourages vendors to improve remediation time on a schedule that is challenging but realistic, with the hope that this will lead to vendors broadly improving their remediation processes and infrastructure in a way that eventually enables them to fix all reported vulnerabilities quickly.
While our analysis isn’t always perfect, Project Zero only reports vulnerabilities with substantial severity and demonstrated security impact in our tracker. That said, we don’t feel severity is an effective metric for making disclosure decisions, especially in the current environment. A vulnerability’s severity does not affect the likelihood that it will be discovered by attackers, only its impact on users.
When vendors determine severity and use it to prioritize bug fixes, they are making decisions about what risks they are willing to expose their users to, and it is reasonable to accept the risk of low-severity bugs, like unexploitable null pointer crashes or minor info leaks in a lot of circumstances. But this doesn’t change the availability of these vulnerabilities to attackers, and we want our policy to reflect this reality.
It’s also important to acknowledge that Project Zero holds itself to high standards with regards to the reproducibility, readability, reachability and reported security impact of the vulnerabilities we report. This policy assumes bugs reports are of this quality, and it is reasonable for vendors to treat low quality-bug reports differently.
We encourage all vendors to consider how they would respond to imminent disclosure of a serious vulnerability, including non-patch strategies , as there is no guarantee that defenders will be the first to find a bug. That said, Project Zero has occasionally granted exceptions to our policy on rare occasions, including Spectre and Meltdown, and will continue to do so in the future.
The question of whether a bug is fixed for the purposes of our policy has always been challenging and somewhat unresolved, particularly with regards to code that is not shipped directly to users and not publicly available. It is not unusual for Project Zero to communicate with vendors multiple times for each bug report to come to an agreement on whether a vulnerability is fixed. As more vendors experiment with vulnerability remediation strategies that are not patching like temporarily disabling code paths, we expect this to become even more complex.
We still plan to track whether bugs are fixed and communicate if they are not, however, this will not be a decision point in our policy. This will enable us to share technical details of how users are protected without needing to make a binary judgement with consequences for the vendor.
Back to the Blog Index
So, after a debugging session the other day, I was having some shower thoughts regarding early userspace and initrd.
Linux initramfs supports unpacking CPIO, a stupid, simple, standardized format. In the discussion on whether to support TAR instead, much emphasize has been put on the fact that CPIO is standardized and less fragmented.
Luckily, Linux (the kernel) includes its own tool to produce the specific variant of the standard that it happens to implement. The standard CPIO tool is possibly the most cursed archiver under the SUN.
In the old DOS/WinDOS world, ZIP was probably the most wide spread and well known archive format, being displaced to some extend by the rise of RAR during the 2000s.
Because of the design of the format, ZIP lends itself to all kinds of polyglot trickery. Way back when, self extracting ZIP archives where a thing, EXE/ZIP polyglots that can be run and unpack themselves, which is useful if you don't have an archiver installed.
I don't think I need to explain where I am going with this, here is the resulting ZIP archive I built:
Download boot.zip
It is a completely normal ZIP archive, containing its own source code needed to build itself from scratch:
$ unzip -t boot.zip
Archive: boot.zip
testing: boot/ZIPHEAD.COM OK
testing: boot/MESSAGE.TXT OK
testing: common/asm.h OK
testing: common/multiboot.h OK
testing: common/zip.h OK
testing: multiboot/console.c OK
testing: multiboot/console.h OK
testing: multiboot/multiboot.c OK
testing: multiboot/string.S OK
testing: setup/a20.S OK
testing: setup/disk.S OK
testing: setup/entry16.S OK
testing: setup/entry32.S OK
testing: setup/mbload.S OK
testing: setup/mem.S OK
testing: setup/setup.ld OK
testing: util/fixhdr.c OK
testing: util/zipglue.c OK
testing: util/zippack.c OK
testing: mk.sh OK
testing: README.txt OK
testing: MESSAGE.txt OK
testing: LICENSE.txt OK
No errors detected in compressed data of boot.zip.
A particularly interesting file here is boot/ZIPHEAD.COM , that contains executable code that is run when booting the archive.
You need to fix the execute permissions of mk.sh after unpacking, and you will need a copy of Zlib installed for the tools. Running mk.sh from it's directory should leave you with a fresh copy of the bootable ZIP archive.
The simplest way to run it, is to just pass it to Qemu direct kernel boot:
$ qemu-system-i386 -kernel boot.zip
"That's easy" you might say, "Qemu supports Multiboot, that ZIPHEAD.COM is uncompressed, at the beginning of the archive and has a Multiboot header in it!"
Yes, that's all true! But this ZIP archive also brings it's own boot loader along. You can try putting it on a floppy and throw that in front of Qemu:
$ dd if=/dev/zero of=floppy.img count=2880 $ dd if=boot.zip of=floppy.img conv=notrunc $ qemu-system-i386 -fda floppy.img
The first 512 bytes of the archive contain a valid boot sector that loads some more code from the second sector and then bootstraps itself into highmem with the A20 enabled and 32 bit protected mode set up.
You can also put it on a hard drive too, it detects what INT 13h drive it's been loaded from and dutifully queries the disk geometry.
If you care to try, you can also dump it on a real floppy and stuff it into a PC:
That's a Pentium MMX by the way, but I also tried an i486 DX2 and an Am386DX-40, just to be sure. My 486 had me hold my breath for a moment, it has a spectacularly slow floppy drive. The text on screen is from the file boot/MESSAGE.TXT
"But that's not special either" you might respond, "ZIPs are read from the back, you can just put anything you want in front, so you put a boot sector there!"
That is sadly not quite true anymore, I'll get to that. But for now, lets take a look at the first couple bytes of that archive together and we'll see the real party trick:
$ xxd -g 1 -l 128 boot.zip 00000000: 50 4b 03 04 0a 00 02 80 00 00 eb 44 e4 2e 41 0f PK.........D..A. 00000010: 01 8f 0a 09 00 00 0a 09 00 00 10 00 00 00 62 6f ..............bo 00000020: 6f 74 2f 5a 49 50 48 45 41 44 2e 43 4f 4d 00 90 ot/ZIPHEAD.COM.. 00000030: 02 b0 ad 1b 03 00 01 00 fb 4f 51 e4 30 00 10 00 .........OQ.0... 00000040: 00 00 10 00 bd 72 10 00 bd 72 10 00 31 03 10 00 .....r...r..1... 00000050: fa fc 31 c0 89 c4 8e d8 8e c0 8e d0 ea 61 7c 00 ..1..........a|. 00000060: 00 bf 00 06 b9 00 02 f3 aa 88 16 98 06 be 0f 7d ...............} 00000070: e8 8c 00 b8 00 f0 89 c1 50 9d 9c 58 a8 02 74 4a ........P..X..tJ
The ASCII P stands for Phil ( not Picard ), as in Phil Katz , followed by 03h and 04h . What you are looking at, is a completely valid ZIP local file header for boot/ZIPHEAD.COM
Oh, and those other bytes there after the ZIP header: 02 b0 ad 1b , if you flip them around to human endian, it reads 1BADB002 . That's the Multiboot magic :-)
The 16 bit real mode code starts right after the Multiboot header, at offset 00000050 . If you are feeling a little confused, so is the file utility:
$ file boot.zip boot.zip: DOS/MBR boot sector; partition 1 : ID=0xd, active 0xcd, start-CHS (0x7 2,19,7), end-CHS (0x388,254,6), startsector 2147916342, 243810273 sectors; parti tion 2 : ID=0x60, active 0x9c, start-CHS (0x366,6,3), end-CHS (0x3f7,49,18), sta rtsector 2298911798, 4154016209 sectors; partition 4 : ID=0xf8, active 0xe1, sta rt-CHS (0x2,184,1), end-CHS (0x313,6,13), startsector 3277940231, 0 sectors
If you take a closer look at the first line of the hex dump, you might be able to spot the jump instruction that makes this little magic trick possible. Luckily, Phil Katz' initials are valid opcodes. The Multiboot entry point is much further into the file at offset 00000331 .
Here's a picture you probably recognize from the Wikipedia article about the ZIP format . This here is a local copy, Wikimedia Commons hosts the original with attribution and licensing information .
Much like a TAR or CPIO archive, a ZIP file is an amalgamation of tightly packed files with a short header in front, specifying the full file path and other meta data:
typedef struct { uint32_t magic; uint16_t version; uint16_t flags; uint16_t method; uint16_t modtime; uint16_t moddate; uint32_t checksum; uint32_t compsize; uint32_t origsize; uint16_t namelength; uint16_t extralength; char name[namelength]; uint8_t extra[extralength]; } __attribute__((packed)) zip_entry_t;
The timestamps are DOS datetime, the checksum is a CRC-32, there are no attributes or permission bits, we are thoroughly in DOS land. Directories are implied by the file paths.
Unlike TAR or CPIO, there is a central directory in the end, with a listing of all of the file headers and back references to the file in the archive. Unlike traditional file formats that have are started by a header , ZIP is terminated by a footer .
The reason for this is twofold:
That last part was especially important in the days when ZIP archives would be split over several floppies. To access a file, just scan the directory on the last floppy, then tell the user what floppy to insert to get the file.
By comparison, accessing a file in a tarball requires linearly scanning over the whole thing (which, on the other hand, is preferable for tape drives , where TAR originates).
ZIP archives are meant to be read from the back, the footer points to the central directory, the directory points to the files. In theory , the archiver shouldn't care if there happens to be a gap between two files, containing something else or if there is something else in the front of the archive, like a file header for a different file format.
The local file headers also supports up to 64k of "extra" stuff between the header and the file data, the footer has "comment" at the end, also up to 64k.
If you look at the footer for a second, you might spot an interesting design flaw:
typedef struct { uint32_t magic; uint16_t disknum; uint16_t diskstart; uint16_t num_dir_entries; uint16_t total_dir_entries; uint32_t dir_size; uint32_t dir_start; uint16_t comment_length; uint8_t comment[comment_length]; } __attribute__((packed)) zip_end_t;
it is variable size, an archiver needs to find it looking from the back, but the magic and the size are both stored before the variable sized comment field. Ask yourself this for a moment: how would you implement this in an archiver? Demanding that there is no comment? Reading the last 64k plus some change and scanning it? From which direction? What if there is another valid footer inside the comment field of the footer? Depending on how an implementation deals with this, a specifically crafted archive can appear to contain different files when viewed with different archivers.
Trying to make the format extensible ended up building a whole lot of foot guns in there. And we are not even talking about the plethora of extensions that have been tacked on to the official specification over the years.
Many modern implementations decided to save themselves a lot of headaches and just treat ZIP archives the same way as tarballs, linearly scanning them from the front instead. They expect the archive to start with a local header, skipping by the size MUST lead to the next entry or finally, the central directory. They reject any archives where this is not possible. This effectively prevents a lot of polyglot trick fuckery, but at the cost of rendering possibly valid archives unreadable.
For the self booting ZIP archive, the challenge thus becomes: the archive MUST start with a local file header, there cannot be any gaps, everything must be properly contained inside files.
Anybody who has ever looked at a DIY toy OS tutorial has probably stumbled across The Multiboot Specification , the possibly easiest and most beginner friendly way to get a program running on bare metal x86.
The multiboot spec originates in the GNU/FSF ecosystem and is implemented by boot loaders like GRUB or Qemu direct kernel boot. SYSLINUX supports it via a plugin. There is a draft for an over engineered 2nd version, that also supports MIPS, but this is of no concert to us here.
A Multiboot 1 compliant kernel simply contains the magic value 0x1BADB002 somewhere in the first in the first 8k. This is followed by flags and a checksum (all 3 must add up to zero). Depending on the flags, additional fields may follow.
The kernel itself can be an ELF file from which the loader extracts load address and entry point. The kernel is run in 32 bit protected mode with flat segments (base=0, limit=4G) and the A20 gate enabled.
Alternatively to a plain old ELF file, the kernel can also specify the memory layout manually (indicated via a flag), allowing flat binaries or other file formats to be loaded. The extended header looks like this:
typedef struct { uint32_t magic; uint32_t flags; uint32_t checksum; uint32_t hdr_addr; uint32_t load_addr; uint32_t load_end_addr; uint32_t bss_end_addr; uint32_t entry_point; } mb_header_t;
The hdr_addr specifies the in-memory address of the header after loading the file, using this and the file offset where the header was found, the other addresses can be converted back to file offsets by the loader.
This way, the load_addr and load_end_addr are used to figure out what parts of the file to load where into memory. If the bss_end_addr is past that, the loader zero-fills it, before finally jumping to entry_point to run the kernel.
The Multiboot compliant loader also sets up a structure with system information (e.g. memory map, APM tables), kernel command line, etc… and passes the pointer to the kernel (via register EBX , magic value 0x2BADB002 in EAX ).
Making a Multiboot bootable ZIP archive is trivial. Simply pack a flat binary with a Multiboot header as uncompressed file binary, make sure it is at the beginning and the addresses line up. An external tool can then fix up the headers, so that the whole archive is loaded.
For any practical applications, it would make sense to stop right here, but we're not here for "practical" or "sane".
On an IBM compatible machine, the BIOS iterates over the installed drives, loads the first sector from each (to location 0x7c00 ), until it finds one where the first sector ends with 0xaa55 . It then jumps to the first byte.
Disks that are formatted with a filesystem, typically have a header in the beginning that starts with a jump instruction across the header into the bootstrap code that follows. The DOS MBR format opts to instead store the partition table at the end of the first sector and all the code in the front.
If we stuff a BIOS boot signature into the ZIP archive, at least parts of the ZIP local file header will be executed, the first few bytes are a mandated magic value and we cannot just put a jump instruction there.
The puzzle exercise now becomes, filling the header fields with values that make sense but also happen to be valid 8086 opcodes. At least, until we hit something that can be abused as a free-form field that we can stuff a jump into.
Let's take a look at that hex dump again:
00000000: 50 4b 03 04 0a 00 02 80 00 00 eb 44 e4 2e 41 0f PK.........D..A. 00000010: 01 8f 0a 09 00 00 0a 09 00 00 10 00 00 00 62 6f ..............bo 00000020: 6f 74 2f 5a 49 50 48 45 41 44 2e 43 4f 4d 00 90 ot/ZIPHEAD.COM..
I've tried to highlight the relevant header up to the jump instruction: 0xeb is a relative jump with a single byte immediate argument.
If we take a look again at the header structure, we can make out what fields those bytes correspond to:
typedef struct { uint32_t magic; uint16_t version; uint16_t flags; uint16_t method; uint16_t modtime; ………
The timestamp is the first best place where we can put a jump instruction. The 0xeb relative jump works out to 8:30-ish in the morning, give or take the jump distance.
The two bytes in front of the modtime are compression method . We really, really want to have 0x0000 here, i.e. uncompressed , so that an archiver doesn't choke on the file data.
The first four bytes are the magic value of the format, we don't have any choice what to put here either, it has to be " PK\03\04 ". The version and flags fields are the only places where we have some creative freedom.
If we run the file through a dissassembler and take a look at the first few bytes, we'll end up with this:
$ objdump -D -m i8086 -b binary ./boot.zip
./boot.zip: file format binary
Disassembly of section .data:
00000000 <.data>:
0: 50 push %ax
1: 4b dec %bx
2: 03 04 add (%si),%ax
4: 0a 00 or (%bx,%si),%al
6: 02 80 00 00 add 0x0(%bx,%si),%al
a: eb 44 jmp 0x50
This is AT&T syntax, source operands are left, destination on the right. We use GNU tools in this household, deal with it.
Anything that just fiddles around with a register doesn't really hurt us. Same goes for memory reads . We don't have memory protection, no matter what we access, there won't be any faults, the only memory mapped hardware around should be the frame buffer.
Memory writes are another story. Worst case, we could shoot up the interrupt vectors, the BIOS RAM areas (BDA, EBDA), or shadowed option ROMs.
The P for Phil also happens to also decode to push %ax . If the BIOS leaves us with a somewhat sane stack pointer, the push instruction should hopefully not mess anything up. It is part of the ZIP magic and thus unavoidable.
The version field is itself actually structured , containing a decimal encoded version number, followed by an OS ID byte. If we set it to 0x000a (stored as little endian), this decodes to version 1.0 on MS DOS .
0x0a is an orb , version 1.1 would be double byte sized, version 0.8 and 0.9 would be register direct and not touch the memory. An address of BX + SI is the result of a mod-reg-r/m field with all zeros.
We could try to code golf our way into consuming at least part of the flags as well, but low-valued, "harmless" opcodes that result in sane versions are sparse. Also, some version numbers change the meaning how an archiver is supposed to interpret the file. Also also, mod-reg-r/m combinations in the OS code field quickly end up as an undefined OS ID. Also also also, we have the method as well, that has to be 0x0000 , which would result in a memory write if executed. We have to consume that somehow, rather than running it.
So for the flags , I came up with 0x8002 (stored as little endian). The lowest, set bit has a compression method dependent meaning, currently only defined for LZMA (14), deflate (8) and implode (6). For uncompressed (method 0) there is no defined meaning (the specification just ignores that part, it doesn't use nasty words like undefined ). For deflate it would mean that maximum compression was used.
The MSB is specified as "reserved for use by PKWARE", whatever they chose to put there, if they ever chose anything at all. Most imporanly, the opcode 0x02 decodes to a single byte, indirect add, and in the mod-reg-r/m , the MSB tells the CPU to consume another 2 bytes of immediate DISP lacement. This is how we can get rid of the compression method.
At this point, we've made it! We reached the modtime field that we can just stuff a jump into.
Once we've made it past the header, we are in 16 bit real mode. We just need to go through all of the neccessary steps to set up the environment that the Multiboot code expects:
This might sound like a lot, but in the current version, the actual code boils down to 817 bytes. That includes all the headers (ZIP, multiboot), the rather bulky GDT. But it is still quite a lot and outside the scope of this post anyway, I might pick some interesting parts out of it for some follow-up posts (watch this space?).
The Multiboot entry code re-loads the GDT, but this time using the highmem location, and sets up a stack after the archive. The size is extracted from the Multiboot header. Knowing the start address, the C code can then iterate over itself to locate and access files in the archive.
Some linker script trickery is used to tie it all into one blob, but with the GDT and Multiboot header visible from both lomem and highmem code at different locations.
At this point, you might be inclined to actually read the source code in the ZIP archive. There are lots of comments trying to explain what is going on.
There's a README that points out the structure of the code with suggestions where to start reading. I decided to keep it readable rather than stuff it all into a single sector. Self-modifying trickery is kept to a minimum (to safe some space, the function to enter unreal mode modifies itself, the code is run twice, courtesy of a misdirected ret , entering protected mode the first time round, leaving it again and restoring the segment registers on the second run, before returning for real).
Code in the archive and this blog posts have been written with assistance from:
If you poke around in the code and have any suggestions for improvements, or otherwise do anything interesting with it, please let me know.
Have fun!
A proposed “buffer zone” around religious facilities across the country — touted as protecting the right to worship — is alarming free-speech advocates who say the Trump administration could use it to crack down on protests.
The new bill, a national version of a controversial law passed in smaller jurisdictions, could hamper demonstrations against illegal sales of land in the West Bank to Jewish settlers that occur inside U.S. synagogues , the advocates say.
The bipartisan legislation could face another layer of opposition from a surprise corner, however, in the form of reproductive rights groups worried it would undermine an existing law that protects abortion clinics.
“Protecting religious freedom must not come at the expense of other Constitutional rights.”
Called the Right to Worship Act, the bill cosponsored by Sens. Ted Cruz, R-Texas, and Elissa Slotkin, D-Mich., will be the subject of a Tuesday hearing in the Senate Judiciary Committee.
The bill has drawn backing from Christian, Jewish, and minority religious leaders who say it could be used to prevent hate crimes. Major Muslim groups, however, have been notably absent from supporter lists.
That isn’t just because Cruz regularly demonizes Muslims . Muslim leaders also worry that while in theory the law would be used to promote religious freedom, in practice it would be used to punish non-violent, pro-Palestine protesters, said Dahlia Taha, the director of the First Amendment Center at the Muslim Public Affairs Council.
“Protecting religious freedom must not come at the expense of other Constitutional rights,” she said. “We believe that this can have very detrimental and long-term impacts. And under this administration, specifically, we’re concerned about those long-term implications.”
Slotkin and Cruz’s offices did not respond to requests for comment.
Under the bill, the Department of Justice could seek civil fines or injunctions against anyone who engages in a “course of conduct” that disrupts religious services, or disrupts access to them, within 100 feet of a church, mosque, synagogue, or other religious facility. Worshippers and state attorneys general could also file lawsuits.
Numerous states have already passed similar legislation creating “buffer zones” around religious buildings. In New York City, Mayor Zohran Mamdani vetoed a buffer zone for protests near schools and colleges, while allowing another one for religious institutions to pass.
Supporters of the federal bill argue that it is needed to protect worshippers from harassment or worse.
“Attacks on synagogues, mosques, churches, and other houses of worship are unfortunately on the rise in Michigan, and across the country,” Slotkin said in an August press release. “No one should ever fear going to their house of worship. Period.”
The law’s authors tout it as a narrowly tailored guardrail, but critics say that the “course of conduct” subject to fines and lawsuits is so ill-defined that the Trump administration could use it to target peaceful protesters.
“There is no relationship between this legislation and the prevention of violent acts at synagogues, mosques, or churches.”
One of critics’ top fears is the “religious services” protected by the law could be defined to include real-estate pitches for land illegally seized from Palestinian people in the West Bank. In a press release, the Anti-Defamation League cited two West bank land-sale protests in New York City as examples of the need for the legislation, along with the March ramming attack on Temple Israel in West Bloomfield, Michigan.
When it comes to violent attacks, argued Eli Williams-Szenes, the director of advocacy and political affairs at the progressive Jewish group Bend the Arc, synagogues are better protected by an existing federal law called the Freedom of Access to Clinic Entrances Act. The FACE Act makes a federal crime out of force, threats, or physical obstruction near both religious institutions and abortion clinics.
“There is no relationship between this legislation and the prevention of violent acts at synagogues, mosques, or churches,” Williams-Szenes said of the new bill. “The idea that telling someone that if they wave a pamphlet 97 feet from the entrance to a synagogue, they’ll get a $10,000 fine would be the reason that someone didn’t try to drive a car into Temple Israel is crazy.”
The Right to Worship Act faces long odds in the final weeks of the Republican-controlled Congress. Still, Williams-Szenes said he is concerned that even a hearing could set the stage for eventual passage.
Abortion rights groups are also worried. They fear that if the Right to Worship Act passes, Republicans will be inclined to repeal or weaken the FACE Act because of its protections for abortion clinics.
One of President Donald Trump’s first actions upon taking office last year was to pardon anti-abortion rights protesters convicted of blockading a clinic under the FACE Act.
“The Right to Worship Act is a wolf in sheep’s clothing,” Kelsey Ryland, a policy counsel at the National Abortion Federation, said in a statement. “The impact of this policy could become a backdoor FACE Act repeal, weakening enforcement against violent disruptors at abortion clinics.”
Blog / IPv4 economics
12 November 2026 · Guide · By Mohammad AlSaraf
Our cheapest plan costs $1.00 a month. That's less than the rent on a single IPv4 address at many providers. So how does it work? The short answer: you don't get an IPv4 address of your own. You share one, and here are the numbers behind that.
There are only about 4.3 billion IPv4 addresses, and the free pools ran out years ago. Today they are bought, sold and rented like property:
These figures come mostly from brokers and vary by source and block size, so treat them as a range, not an exact price. The point stands either way: if every $1 server came with its own IPv4 address at retail prices, the address alone would cost several times the whole plan.
Each of our hosts has one public IPv4 address. Every server on that host gets its own block of ports on it: 5 on the free trial, 10 on Nano, 20 on Box and Box CPU, 30 on Box Plus. The first port goes to SSH, the rest go straight to the same port numbers inside your server. On 9 November 2026 our three addresses carried 56, 31 and 14 customer servers.
So the cost of one address is split dozens of ways. Even at Contabo's retail €3.50, that's well under 10 cents a month per server on our busiest host. That is most of the trick behind a $1 plan.
Ports 80 and 443 can't be split into blocks, because every website needs them. So we share those by domain name: you link your domain in the client area, and our proxy sends each visitor to the right server without decrypting anything ( we load-tested it ).
IPv6 has so many addresses that nobody needs to share. Every natbox server, including the free trial, gets its own routed /80 : 2 48 addresses, every port open, port 22 and 443 included, no proxy in between ( how it works ). As more of the internet speaks IPv6, the shared IPv4 address matters less and less.
If you need a full IPv4 address with every port, a NAT VPS isn't the right tool, and that's fine. If you want a real Linux server for a bot, a small website, a VPN, a monitoring tool or for learning, sharing an IPv4 address is what lets it cost less than a coffee. See the plans .
Get new tutorials in Telegram. Follow @natboxio : every new post, plus short server tips.
More from the blog: We made disk writes on natbox over 100 times faster. Here's the trade-off , Restarting for a kernel update: what happened, minute by minute , Why one new server took two minutes, and how we made setup faster . RSS feed .
|
|
Ask HN: What are the most useful, concrete AI skills to independently learn? | |
| 20 points by shnock 3 hours ago | hide | past | favorite | 22 comments | ||
|
Specifically, what are the most useful, concrete skills to learn as an individual to take economic advantage of the advances in LLMs, agents and associated new technological capabilities? What is accessible to learn just from the internet and experimentation, without a degree program, assuming a preexisting moderately technical background? The clearer and more specific (eg. “Learn how-to x with y”) the better. Thank you! |
||
|
|||
|
|||
|
|||
|
|||
|
|||
Abstract: This book provides a compact, derivation-oriented introduction to the mathematical foundations of modern generative artificial intelligence. Rather than surveying every recent architecture or implementation detail, it develops a coherent route through the ideas connecting major families of generative models, from PCA, probabilistic PCA, variational autoencoders, and diffusion models to normalising flows, autoregressive factorisations, GANs, Wasserstein GANs, and energy-based models. The aim is to make the structure of generative modelling more accessible without removing the mathematical substance needed to understand how these models are derived and related. The book is intended as a foundation-building primer for mathematically curious researchers, practitioners, and students.
From: Tianhua Chen [
view email
]
[v1]
Thu, 28 May 2026 10:12:00 UTC (125 KB)
[v2]
Tue, 8 Sep 2026 07:17:36 UTC (1,168 KB)
Large language models today can recall obscure facts from every corner of the world. Most recently, I was running late for a friend’s board game night, so I asked Astra to remind me the rules to Dune: Imperium. It gladly narrated them to me as I drove over and helped me remember the rules well enough for me to play again. We’re so used to asking models about anything that we take their vast knowledge for granted.
How do models remember so much information? And how much can they store?
In this post, I’ll go through an intuitive way to look at linear maps, MLPs, and self-attention as different kinds of memory stores. From this intuition we can derive some heuristics for how much memory each layer can store.
The key property that characterizes a “good” memory store is its ability to recall what it stored. After all, even if we could store infinitely many facts, it’s not very helpful if we can’t recall them when we need to. The more memories we store, the more they interfere with each other when we try to recall one. So throughout the post we’ll focus on one quantity, the interference-to-signal ratio, which measures how much the other memories get in the way during recall. The number of memories a store can hold before the interference grows as large as the signal is its capacity .
We’ll develop this perspective and show how you can go from a linear layer to something better, an MLP, which improves both capacity and recall, and then all the way to self-attention, which has very good recall and can store a potentially unbounded number of memories. With 64-dimensional keys, that’s a jump from about 64 memories, to about 2,700, to over a million.
Here are the terms we’ll use throughout. A memory store is a function $f$ that holds $M$ memories, for $i = 1, \ldots, M$. A memory is one key-value pair: a key $k_i \in \reals^{d_k}$, used for lookup based on similarity, and a value $v_i \in \reals^{d_v}$, which is what we want to retrieve. To use $f$, we query it with an input $x$, and it recalls an output $f(x)$. A good memory store recalls $v_i$ when we query it with $k_i$, or with another vector similar to $k_i$. In the literature, a memory store that recalls by similarity is called an associative memory .
The most basic memory store is linear: it simply accumulates memories via outer products,
$$W = \sum_{i=1}^{M} v_i k_i\transpose = V\transpose K$$
where the rows of $K \in \reals^{M\times d_k}$ and $V \in \reals^{M\times d_v}$ are the keys $k_i\transpose$ and the values $v_i\transpose$. 1
To store a new memory $(k, v)$, we simply add $vk\transpose$ to the existing weights. 2
Take a linear layer $y = Wx$ inside a network with a scalar loss $L$, and let $\bar y = \grad L(y)$ be the gradient of the loss with respect to the layer’s output. The gradient with respect to $W$ is $\bar y x\transpose$, so a step with learning rate $\eta$ is
$$W \leftarrow W - \eta\, \bar y x\transpose.$$This recurrence is a memory update: it updates the weights with a new memory with key $x$ and value $-\eta\bar y$. For more on this view, see Irie, Csordás & Schmidhuber , who express a linear layer trained by gradient descent as attention over all of its training inputs.
To query the memory store with an input $x$, we multiply the input by the matrix:
$$f(x) = V\transpose K x = \sum_{i=1}^{M} v_i\,(k_i\transpose x).$$
So recall is a lookup by similarity to the stored keys: we compare the query with every key, and return the sum of the values weighted by those similarities.
So storing memories is easy: just keep adding outer products to the weights. But what happens when we try to recall one?
Let’s assume for simplicity that every key is normalized to have length 1, i.e. $k_j\transpose k_j = 1$. Then
$$f(k_j) = \underbrace{v_j}_{\text{signal}} + \underbrace{\sum_{i\neq j} v_i\,(k_i\transpose k_j)}_{\text{interference}},$$
meaning we get back the value of the target memory , the one whose key we queried with, plus interference from every other memory whose key is similar to the query.
If the keys were all orthonormal, the interference would be zero and recall would be exact. But $\reals^{d_k}$ only has $d_k$ orthogonal directions, so we cannot get perfect recall once we store more memories than the key dimension: $M > d_k$.
What is the outer-product store’s capacity? Here’s an intuitive argument. There are $M-1$ interference terms. If the keys are random unit vectors, each similarity $k_i\transpose k_j$ is about $\pm 1/\sqrt{d_k}$. If the values are random too, with similar lengths, the $M-1$ interference terms add up like a random walk, so the interference’s squared length is about $(M-1)/d_k$ times the signal’s, and
$$\frac{\norm{\text{interference}}}{\norm{\text{signal}}} \sim \sqrt{\frac{M}{d_k}}.$$
Setting this ratio to 1 gives a capacity of
$$M \approx d_k,$$
once we store as many memories as the key dimension, the interference is as large as the signal, drowning it out.
Each bar below is one stored memory’s weight in a single recall, relative to the target memory’s weight (in red). Every bar adds a bit of its value to the recall. Drag $M$ past $d_k = 64$ to watch the small bars pile up until recall fails. The other buttons switch to memory stores we’ll build later in the post.
the target memory each other stored memory, weight relative to the target memory
interference / signal = recall fails
Even below its capacity of about $d_k$ memories, the outer-product store produces significant interference during recall. 3 To raise the capacity, or recall more cleanly below it, we need to reduce interference .
The brute-force way is to make the key dimension $d_k$ larger, since a linear store’s capacity grows with $d_k$. How large $d_k$ can be is governed by hardware constraints.
Alternatively, we can make algorithmic improvements. We can store memories more carefully: the outer-product store adds each memory without looking at the others, so it does nothing to cancel their interference. Or we can recall more selectively: every memory in a linear store contributes interference, even when its key has low similarity to the query, so we can improve recall by suppressing the less similar keys.
In the rest of the post, we’ll see that storing outer product memories more carefully gives us the optimal linear memory store, which has about twice the capacity. Recalling selectively via nonlinearities gives us MLPs and self-attention.
The outer-product store writes each memory without regard to the others. Instead, we can choose the weights $W$ so that recall fits all of the stored memories at once. This is a linear regression problem: 4
$$\operatorname*{minimize}_W \sum_{i=1}^M \norm{W k_i - v_i}_2^2.$$
When we store more memories than the key dimension, $M > d_k$, the least-squares solution is
$$W = \parens*{\sum_i v_i k_i\transpose}\parens*{\sum_i k_i k_i\transpose}\inverse = V\transpose K\,(K\transpose K)\inverse.$$
This is the outer-product store $V\transpose K$ with one change: before we compare the query with the keys, we multiply it by $(K\transpose K)\inverse$, which undoes the keys’ covariance $K\transpose K$. This whitens the keys, so the store no longer overweights directions that many keys share.
When $M \leq d_k$, the regression can fit every memory exactly, as long as the keys are linearly independent. So the optimal store recalls with no interference at all, even when the keys aren’t orthogonal.
When $M > d_k$, we start to get interference, since there are only $d_k$ directions for the memory store to work with. For random keys and values, our interference-to-signal ratio becomes
$$\frac{\norm{\text{interference}}}{\norm{\text{signal}}} \approx \sqrt{\frac{M}{d_k} - 1}.$$
This ratio equals 1 at
$$M = 2d_k,$$
so the optimal store’s capacity is twice as large as before!
When $M \leq d_k$. If the keys are linearly independent, the $M\times M$ matrix of inner products between keys, $KK\transpose$, is invertible, and
$$W = V\transpose (KK\transpose)\inverse K$$fits every memory exactly. When $M < d_k$, the problem is underconstrained and has infinitely many solutions, and this one is the min-norm solution. The rows $\tilde k_i\transpose$ of $(KK\transpose)\inverse K$ are known as the dual basis for the rows of $K$: by construction, $(KK\transpose)\inverse KK\transpose = I$, so $\tilde k_i\transpose k_j = \delta_{ij}$. Then $f(k_j) = \sum_i v_i\, \tilde k_i\transpose k_j = v_j$, so there is no interference and we have perfect recall.
When $M > d_k$. Setting the gradient of the objective to zero gives $W K\transpose K = V\transpose K$, so $W = V\transpose K\,(K\transpose K)\inverse$. Both solutions are $W = V\transpose (K\transpose)\pinv$, where $A\pinv$ denotes the pseudoinverse of $A$: $(K\transpose)\pinv = (KK\transpose)\inverse K$ when the keys are linearly independent, and $(K\transpose)\pinv = K(K\transpose K)\inverse$ when they span $\reals^{d_k}$.
Now we can analyze the interference of $f(k_j) = V\transpose K\,(K\transpose K)\inverse k_j$. For a stored key $k_j$, the weight on each value $v_i$ is $k_i\transpose (K\transpose K)\inverse k_j$, which is exactly entry $(i, j)$ of the $M\times M$ matrix $P = K(K\transpose K)\inverse K\transpose$:
$$f(k_j) = \sum_{i=1}^M v_i\, P_{ij} = \underbrace{P_{jj}\, v_j}_{\text{signal}} + \underbrace{\sum_{i\neq j} P_{ij}\, v_i}_{\text{interference}}.$$$P$ is the projection onto the column space of $K$, a $d_k$-dimensional subspace of $\reals^M$. Two facts about projections help us analyze the interference-to-signal ratio:
If the values are random with similar lengths,
$$\frac{\norm{\text{interference}}}{\norm{\text{signal}}} \approx \frac{\sqrt{P_{jj} - P_{jj}^2}}{P_{jj}} = \sqrt{\frac{M}{d_k} - 1}.$$Compared to the outer-product store’s $\sqrt{M/d_k}$, the $-1$ is the $d_k$ memories’ worth of interference that the optimal store cancels.
We can check our predictions numerically. We randomly sample $M$ memories with unit-length keys in $d_k = 64$ dimensions, query the memory store with one of the stored keys, and measure the interference-to-signal ratio:
The outer-product store reaches its capacity at $M \approx d_k = 64$. The optimal store recalls exactly up to $M = d_k$. Past that, its interference rises from zero like $\sqrt{M/d_k - 1}$, and the store reaches its capacity near $M = 2d_k = 128$, as predicted. Since it cancels a fixed number of memories’ worth of interference, the gap between the two stores shrinks as $M$ grows.
This optimal memory store is still linear in the similarities though. It must scale small and large similarities by the same factor. To do better, we need to change how the store recalls.
A linear memory store recalls
$$f(x) = \sum_{i=1}^M v_i (k_i\transpose x).$$
If we had a way to suppress the weight when $k_i\transpose x$ is small, then we can reduce the amount of interference from low similarity keys.
Let’s pass each similarity through a nonlinear function $\sigma$ before computing the weighted sum of values:
$$f(x) = \sum_{i=1}^{M} v_i\,\sigma(k_i\transpose x) = V\transpose \sigma(Kx).$$
We just rediscovered a two-layer MLP from first principles! The rows of the first weight matrix are the keys, the columns of the second weight matrix are the values. Sukhbaatar et al. pointed out this resemblance between feedforward layers and memory stores, and Geva et al. found that the feedforward layers in trained transformers often work this way, with keys firing on recognizable patterns in the input.
Ideally, the gating function $\sigma$ is chosen such that when the similarity is low ($k_i\transpose x \sim 0$ or even when $k_i\transpose x < 0$), its corresponding term in the sum gets suppressed to reduce interference. A ReLU activation zeros out keys with negative similarities, and adding a bias allows shifting that threshold 5 . A squared ReLU activation further suppresses the keys with similarities close to zero. A similarity of 0.1 becomes 0.01, while a similarity of 1 stays 1. In fact, squared ReLUs are one of the lesser known but established-at-scale improvements to MLP activations ( So et al. ).
A squared ReLU MLP is a GLU MLP whose gate and input projection share weights, since $\operatorname{ReLU}(Kx)^2 = \operatorname{ReLU}(Kx) \odot Kx$. The SwiGLU MLPs in today’s language models give the gate its own weights and use a Swish activation in place of the ReLU.
In practice, MLPs store facts in superposition: many facts share the same weights, and the output is a blend of many memories. Garcia et al. build one explicitly: the hidden units of a GLU MLP compute random features $\phi(x)$ of the input, the second weight matrix is an outer-product store $\sum_i v_i \phi(k_i)\transpose$ over those features, and the MLP stores far more facts than it has hidden units. Still, trained transformers’ ReLU MLPs can activate as few as 1% of their hidden units for a given input, so each recall draws on a small fraction of the memories ( Li et al. ).
The original transformer paper made this connection too, but only in v2 and v3 on arXiv. There, Vaswani et al. describe the feedforward layer as “a kind of attention,” with the rows of its two weight matrices as the keys and values, and ReLU in place of softmax. They even tried replacing the feedforward layers with attention over learned key-value parameters, and got about the same translation quality: one version did slightly worse, another slightly better, though the first one trained about 30% slower. The passage is gone from every later version of the paper. We’ll get to how self-attention relates to all this below.
Squaring the similarities works because it shrinks low similarity weights much more than large ones. We can push this further with $\sigma(s) = \operatorname{ReLU}(s)^p$. The signal stays the same, since $1^p = 1$, while an interference term with similarity $1/\sqrt{d_k}$ shrinks to $d_k^{-p/2}$. The $M$ interference terms add up like a random walk, so the interference-to-signal ratio is
$$\frac{\norm{\text{interference}}}{\norm{\text{signal}}} \approx \sqrt{\frac{M}{d_k^p}}.$$
This means the capacity is about
$$M \approx d_k^p$$
memories, geometrically more than before!
To check this, we run the same experiment as before for five choices of $\sigma$:
Since the interference grows like $\sqrt{M}$, the lines are nearly parallel on a log-log plot. Only their height changes, and with it the capacity, where each line crosses 1:
Raising the weights to a power increases the capacity to about $d_k^p$. But what if we could push this to the limit? Rather than pick one power, we can use infinitely many of them. Indeed, the exponential is a weighted sum of every power,
$$e^{\beta s} = 1 + \beta s + \frac{(\beta s)^2}{2} + \frac{(\beta s)^3}{6} + \cdots = \sum_{p=0}^{\infty} \frac{(\beta s)^p}{p!},$$
with the sharpness $\beta$ setting the weight on the higher powers. Here is the same experiment with $\beta = \sqrt{d_k}$, the value self-attention uses, 6 for the exponential and its series truncated after 2, 3 and 4 terms:
With 2 terms, the capacity is about 40, below the linear store’s, since the constant term gives every key a weight of about 1. With 3 terms it’s about 450, and with 4 terms about 3,100, close to the squared ReLU’s. The full exponential stays far below the dashed line, so its capacity is past the edge of the chart.
To find the exponential’s capacity, we query with a stored key $k_j$, so the target memory has similarity 1 and weight $w_j = e^{\beta}$. Every other memory has weight $w_i = e^{\beta s_i}$, where for random unit keys the similarity $s_i$ is roughly Gaussian with mean 0 and variance $1/d_k$. With random values of similar lengths,
$$ \begin{aligned} \frac{\norm{\text{interference}}}{\norm{\text{signal}}} &\approx \sqrt{\sum_{i\neq j} \parens*{\frac{w_i}{w_j}}^2} && \text{interference terms add up like a random walk} \\ &= \sqrt{\sum_{i\neq j} e^{2\beta (s_i - 1)}} && w_i / w_j = e^{\beta s_i} / e^{\beta} \\ &\approx \sqrt{M\, e^{-2\beta}\, \ev{e^{2\beta s}}} && \text{average over the } M \text{ other memories} \\ &= \sqrt{M\, e^{-2\beta}\, e^{2\beta^2/d_k}} && \ev{e^{ts}} = e^{t^2/(2d_k)} \text{ for } s \sim \mathcal{N}(0, 1/d_k) \\ &= \sqrt{M}\, e^{\beta^2/d_k - \beta}. \end{aligned} $$
Setting the ratio to 1 gives a capacity of
$$M \approx e^{2\beta(1 - \beta/d_k)},$$
growing exponentially with $\beta$ as long as $\beta$ is well below $d_k$, rather than polynomially in $d_k$ like before! With $\beta = \sqrt{d_k} = 8$, the capacity is about $e^{14} \approx 1.2$ million memories, nearly 20,000 times the linear store’s. A longer run of the same experiment puts the capacity at about 1.2 million too.
In practice, we may not want to naively exponentiate numbers in our implementation, since small numbers can underflow and large numbers can overflow. Fortunately, the interference only depends on the ratios between weights, as the chain above shows, so we can divide every weight by their sum without changing the interference-to-signal ratio, while ensuring numerical stability:
$$f(x) = \sum_{i=1}^{M} v_i\,\frac{\exp(\beta\,k_i\transpose x)}{\sum_j \exp(\beta\,k_j\transpose x)} = V\transpose \operatorname{softmax}(\beta K x).$$
This is self-attention . 7
Unlike an MLP, whose keys and values are trained weights, self-attention computes its keys and values from the tokens in its context. Each token stores one memory, so the number of memories $M$ is the context length. That’s what makes self-attention non-parametric: its memories aren’t parameters, and the store grows with the context.
Here’s the bar figure again, starting with softmax. At $\beta = 8$, recall never fails within the slider’s range, so lower $\beta$ to 2 and raise $M$: recall fails after a few dozen memories. Each doubling of $M$ needs a bit more $\beta$ to keep recall working, which is the idea behind the next section.
the target memory each other stored memory, weight relative to the target memory
interference / signal = recall fails
Since $\beta$ determines how hard we suppress less similar keys, we can increase $\beta$ as the number of key-value pairs increases. Why not just make $\beta$ huge? As $\beta \to \infty$, softmax becomes a hard argmax that picks only the most similar key, which isn’t differentiable, and a very large $\beta$ already makes training work poorly, since the softmax saturates and the gradients to every other key vanish. So we raise $\beta$ only as much as $M$ requires. Scaling the attention logits with $\log M$ is a trick for long contexts that does this. There are a few versions of it, and each sets $\beta$ relative to a fixed reference length $L$, usually the training length, so that $\beta$ keeps its trained value when $M = L$:
Here’s how each rule does in our experiment, with $\beta = \sqrt{d_k} = 8$ at $L = 1024$ memories:
Qwen’s rule and Su’s rule coincide past the reference length $L$, where the interference-to-signal ratio falls as the store grows, to about 0.004 at 2 million memories. YaRN’s faster-growing scale pushes the ratio down to about $10^{-4}$. In each case, scaling $\beta$ with $\log M$ allows for essentially an unbounded number of memories with distinct keys to be stored.
Here are the memory stores we visited, with their capacities when we query with a stored key and the keys and values are random:
| Memory store | $f(x)$ | Capacity | Capacity at $d_k = 64$ |
|---|---|---|---|
| Outer product | $V\transpose K x$ | $d_k$ | 64 |
| Optimal linear | $V\transpose K (K\transpose K)\inverse x$ | $2d_k$ | 128 |
| ReLU MLP | $V\transpose \operatorname{ReLU}(Kx)$ | $2d_k$ | 128 |
| Squared ReLU (GLU MLP) | $V\transpose \operatorname{ReLU}(Kx)^2$ | $2d_k^2/3$ | about 2,700 |
| SwiGLU MLP | $V\transpose \parens*{\operatorname{Swish}(Kx) \odot Kx}$ | about $2d_k^2/3$ | about 2,900 |
| Cubed ReLU | $V\transpose \operatorname{ReLU}(Kx)^3$ | $2d_k^3/15$ | about 35,000 |
| Self-attention, $\beta = \sqrt{d_k}$ | $V\transpose \operatorname{softmax}(\beta K x)$ | $e^{2\sqrt{d_k} - 2}$ | about 1.2 million |
| Self-attention, $\beta \propto \log M$ | $V\transpose \operatorname{softmax}(\beta K x)$ | not reached in our experiments | more than 2 million |
We started from a heuristic memory store, the outer-product memory, and gradually built our way up to all the standard layers we see today in modern transformers. This perspective also allowed us to estimate how they differ in their capacity, their ability to act as vector-valued key-value stores.
I should mention that this capacity estimate is only one way to look at the architecture of modern neural networks. Our capacity estimate only counts how many random vectors a single layer can recall before the interference dominates the signal. In fact we haven’t actually considered the training data at all, which affects what actually is being represented in the keys and values! There are other works which account for the trained layers, measuring stored information in bits. Morris et al. estimate that GPT-style models memorize about 3.6 bits per parameter, and find that once a model fills its capacity, it starts to generalize and memorizes less of each training example. Allen-Zhu & Li find that language models store about 2 bits of factual knowledge per parameter, even when quantized to int8.
From here, there are many related directions which are also fascinating:
I’ve always been drawn to memory, maybe because I viscerally feel how limited my own is. Perhaps part of me hopes that by understanding how machines remember, I’ll learn something about myself too.
README.TXT
Every screen was captured in ScummVM, except the Atari ST monochrome screens, which come from the Hatari emulator. Each capture was scaled to 1600x1200 with nearest-neighbour pixels and 4:3 aspect correction, so every original pixel keeps the shape it had on a period monitor.
The twelve moments are the same in every version, with the same framing, so switching versions changes the machine, not the moment. The PC 16-color screens come from a Spanish copy and the Atari ST mono ones from a French copy; all the others are in English.
Drag a title bar to move a window. Press Esc to go back to the viewer.
Sources
ScummVM source, SCUMM palette code Sega CD shadow mode The Secret of Monkey Island CD VIDEO FIX Linkuei, 2022 MacTech, Fast Blit Strategies EPX by Eric Johnston Aaron Giles LucasArts Mac and Windows ports MobyGames, Amiga credits Chris Hülsbeck, Rudolf Stember The Ultimate Oldschool PC Font Pack VileR, int10h.org DOSBox Staging, CRT shaders crt-hyllian and the VGA 1080p shaders libretro slang-shaders, crt-guest-advanced-hd guest(r), Dr. Venom: curvature, corners, vignette
ASCII chart · IBM VGA 9x16
Char: Decimal: 0 Hex: 00
PxPlus IBM VGA 9x16 by VileR (int10h.org), CC BY-SA 4.0. Stretched x1.35 here for 4:3, shared under the same licence.
Capture settings
[ X ] Nearest-neighbour scaling
[ X ] 4:3 aspect correction
[ X ] The same 12 moments in every version
The Mac draws a 640x400 picture inside a 640x480 screen, so it shows black bars. The Hercules picture uses the middle 640 of its 720 columns.
CRT shader · DOSBox Staging
The CRT monitors of DOSBox Staging, ported to WebGL2: its presets for Hyllian's CRT shader, and its own VGA shaders where a screen has few pixels. Each version is drawn from its native pixels on the monitor closest to its own, with a whole number of screen pixels for every scanline where the size allows.
[ X ] On in the viewer: the CRT button under the picture, or R
[ X ] Scanlines need pixels: zoom in where the window is too small
[ X ] Every setting in the CRT lab, on the menu bar
crt-hyllian and its presets: Copyright (C) 2011-2020 Hyllian, Copyright (C) 2020-2024 The DOSBox Staging Team, MIT. VGA 1080p shaders: Copyright (C) 2020-2024 The DOSBox Staging Team, GNU GPL v2 or later. Curvature and corners from crt-guest-advanced-hd: Copyright (C) 2018-2025 guest(r); its vignette: Copyright (C) 2019-2025 guest(r) and Dr. Venom; GNU GPL v2 or later. The port, crt.js , is shared under the GNU GPL v2 or later ; here are all the notices .
Who we are
We are The Paninos off-line : two brothers, and that's the whole team. We made this site, with the help of AI.
We are also remaking Sierra's The Black Cauldron (1986) in Adventure Game Studio, free and non-commercial. Its website opens soon.
Small print
A fan-made reference. Not affiliated with or endorsed by Lucasfilm Games, LucasArts or Disney.
The following is part of a series of posts about 2026 summer intern projects—for more, see “What the interns have wrought, special jumbo 2026 edition”
We have a lot of performance-critical SIMD code (single-instruction, multiple-data) running on CPUs across the firm. These are highly parallel programs where you run the same computation across arrays of data, in our case for options pricing or for low-latency risk checks. Because OCaml hasn’t historically exposed SIMD instructions, these programs often involve an inner loop written in fairly esoteric C. Writing these loops requires implementers to think carefully about hardware, and doing performance tuning, such as modifying unroll factors or vector widths, can require major changes to the code. Moreover, these programs are constrained to a specific instruction set. If we were to target a different architecture or a newer processor, we’d have to rewrite the program.
For his summer internship, Sai Konkimalla built a compiler for a domain specific language (DSL) that makes SIMD more ergonomic and widely accessible. The compiler takes advantage of OxCaml features that were only very recently added to the language, such as runtime metaprogramming, to enable users to write a kernel just once as a regular-ish OxCaml function, then compile and run it on multiple architectures.
To help solve the problem of SIMD code being rather difficult to write and maintain, our DSL uses the S P MD, or “single program , multiple data” programming model. As opposed to SIMD intrinsics, SPMD is higher level and not tied to a specific instruction set. We might normally think of higher-level languages as slower, but with SPMD, a higher level of abstraction lets the compiler make better decisions about how to optimally use the underlying hardware. This ability can lead to significantly faster code.
SPMD was popularized by CUDA (for Nvidia GPUs) and ISPC (for Intel CPUs). In this model, you write a program describing what happens at each index of a loop, then the compiler converts it into a parallel computation. For example, in CUDA:
__global__ void kernel(const float* x, float* out, int n) {
int idx = blockIdx.x * blockDim.x + threadIdx.x;
if (idx < n) {
out[idx] = 2.0f * x[idx] + idx;
}
}
Notice how there’s no loop here: you only define the loop body, and the compiler decides how to run it. In CUDA, when you launch a kernel on a GPU, you can declare how many blocks of threads to run and the GPU will schedule them accordingly.
In ISPC,
foreach
also abstracts away how the loop is actually executed:
export void kernel(uniform float x[], uniform float out[], uniform int n) {
foreach (i = 0 ... n) {
out[i] = 2.0f * x[i] + i;
}
}
In both cases, the compiler translates the code into low-level SIMD instructions. Not specifying the exact instructions also means SPMD programs can benefit from future hardware improvements. If we get a new, faster CPU with a different instruction set, the SPMD compiler can seamlessly compile existing code to it.
Let’s go over an example of the DSL that Sai implemented. We start by defining the kernel’s signature, including its output type, input types, and the dimension of the output:
Spmd.Kernel.create
F32 (* output element type *)
[ F32; F32 ] (* input slice types *)
[ () ] (* one output dimension *)
(fun graph [ x; scale] [ Dim i ] -> exclave_
...)
In this example, we’re writing a kernel that takes in two
F32
slices and returns one
F32
slice.
Future work on a ppx syntax extension will make it possible to rewrite the above simply as:
let%spmd kernel (x : f32 slice) (scale : f32) (i : dim) : f32 =
Next, we write the actual computation:
Spmd.Kernel.create
F32 (* output element type *)
[ F32; F32 ] (* input slice types *)
[ () ] (* one output dimension *)
(fun graph [ x; scale ] [ Dim i ] -> exclave_
let open (val Spmd.open_ graph) in
let i = index i in
F32.((x.!(i) *. broadcast scale.!(I32.lit #0l)) +. of_i32 i))
Note the
let open (val Spmd.open_ graph) in
. This brings the DSL operations which
construct a computational graph into scope. You can think of the
graph
value as proof
that you’re in the graph-construction phase, not the runtime of the generated program.
(
Bonsai
uses a
similar
trick
for creating its incremental graph.)
Like CUDA, we don’t write the kernel as a loop. Instead, the developer writes a function that computes a single entry of the output slice, and the SPMD compiler generates code to loop over the output slice and compute the value at each index.
You may wonder why we loop over the output and not the inputs. Looping over the output is easier to model because each iteration writes to exactly one location, so iterations can be easily vectorized, reordered, or parallelized. If we were to loop over the inputs, different iterations could write to the same output entry. The compiler would then have to reason about whether the writes could be re-ordered. By guaranteeing that each output entry is written exactly once, we can avoid this complexity.
One wrinkle with Sai’s project is that we wanted to execute the SPMD compiler at runtime. Runtime compilation (often called just-in-time or JIT compilation) is when the compiler generates code while the program is running. This gives us two main advantages: we don’t have to worry about building for all potential target architectures at compile time, and we can use data obtained at runtime for optimizations.
That latter point is especially important for generating high-performance code. When executing at runtime, the compiler has more data that it can use to optimize the code than it would when executing ahead-of-time. For example, our compiler can use runtime data to compile away branch instructions, which can slow down execution by consuming CPU resources.
To implement our JIT compiler, we used runtime metaprogramming, a feature that lets us generate, compile, and evaluate OxCaml code at runtime by using the OxCaml compiler as a library. As far as we know, Sai’s project was the first real program at Jane Street to use it. (He discovered some bugs in its implementation and helped report/reproduce them for the OxCaml team.)
Let’s take a look at an example that illustrates the power of compiling at runtime. In
this code, we match on the
metric
to choose which algorithm to execute:
type metric =
| Euclidean
| Manhattan
let measure ~metric =
Spmd.Kernel.create
F32
[ F32; F32 ]
[ () ]
(fun graph [ samples; targets ] [ Dim i ] -> exclave_
let open (val Spmd.open_ graph) in
let sample = samples.!(index i) in
let target = targets.!(index i) in
let diff = F32.(sample -. target) in
match metric with
| Euclidean -> F32.(diff *. diff)
| Manhattan ->
let zero = broadcast (F32.lit #0.s) in
select F32.(diff >=. zero) ~pass:diff ~fail:F32.(zero -. diff))
;;
With a normal OCaml program, this would create a branch and two code paths. Every time we execute this code, we’d have to spend time evaluating the branch and picking the right code path.
With the SPMD compiler, we can compile
after
we know the value of
metric
. Then the JIT
compiler can evaluate the branch during compilation and produce more efficient code. For
example, here’s the intermediate representation that the code gets compiled into:
let%expect_test "IR: euclidean" =
let lowered = For_testing.Ir.of_kernel (measure ~metric:Euclidean) in
print_string (For_testing.Ir_body.to_string lowered.body);
[%expect
{|
let n = shape[0]
for i in n (normal) {
let v = load_f32 in0[i]
let v1 = load_f32 in1[i]
let v2 = f32_sub v v1
let v3 = f32_mul v2 v2
store out[i] = v3
}
|}]
;;
let%expect_test "IR: manhattan" =
let lowered = For_testing.Ir.of_kernel (measure ~metric:Manhattan) in
print_string (For_testing.Ir_body.to_string lowered.body);
[%expect
{|
let n = shape[0]
for i in n (normal) {
let v = load_f32 in0[i]
let v1 = load_f32 in1[i]
let v2 = f32_sub v v1
let v3 = f32 0.
let v4 = f32_ge v2 v3
let v5 = f32_sub v3 v2
let v6 = select v4 v2 v5
store out[i] = v6
}
|}]
;;
Notice how we don’t branch on
metric
in the emitted code. Because the compiler knows the
value of
metric
, it can emit just the chosen algorithm.
Sai started his project by working on the compiler’s front end. The front end takes the kernel definition that we saw above and translates it into the following GADT that models a directed acyclic graph (DAG):
type (_ : any, _) node =
| Literal : 'a Literal.t -> ('a, uniform) node
| Broadcast : ('a, uniform) t -> ('a, varying) node
| Load : { storage : 'a Storage.t; idx : (i32, 'u) t } -> ('a, 'u) node
| Dimop : { op : ('a, 'u) Dimop.t; dim : 'd Dim.t } -> ('a, 'u) node
| Binop : { op : ('o, 'x, 'y) Binop.t
; x : ('x, 'u) t; y : ('y, 'u) t } -> ('o, 'u) node
| Unop : { op : ('o, 'x) Unop.t; x : ('x, 'u) t } -> ('o, 'u) node
| Select : { cond : (bool#, varying) t
; pass : ('a, 'u) t; fail : ('a, 'u) t } -> ('a, varying) node
| If : { cond : (bool#, uniform) t; then_; else_ } -> ('a, 'u) node
| If_var : { cond : (bool#, varying) t; then_; else_ } -> ('a, varying) node
and ('a : any, 'u) t = { node : ('a, 'u) node; ty : 'a Ty.t; id : int }
(The
'u
type variable in this GADT declares the expression’s
rate
, which indicates
whether an expression is the same for every index in the entire output slice (
uniform
)
or may change at each element in the slice (
varying
). In other words, it signals which
pieces of your computation only need to be computed once and which pieces need to be
computed per index.)
Sai’s first task was to add support for numeric data types such as
I8
,
I16
,
I64
,
U8
–
U64
and
F64
, including arithmetic operations and conversion operators. After
that, he started implementing booleans and control flow constructs. Unlike most
conventional programming languages, SPMD has some nuances to its control flow. Instead of
a single
if
construct, SPMD has three separate constructs all designed for parallel
execution:
| form | condition | semantics |
|---|---|---|
select
|
bool# varying | The selected branch can vary per index. Both branches are always evaluated. |
if_
|
bool# uniform | Every index picks the same branch. The untaken branch is not executed. |
if_var
|
bool# varying | The selected branch can vary based on index. The untaken branch is not observable, but may or may not be executed. |
if_var
lets you branch on data that varies per index (i.e., per SIMD lane). In the code
below, the
if_var
allows the user to guard code that should only be run when
g
happens
to be positive:
(fun graph [ group; totals; counts ] [ Dim i ] -> exclave_
let open (val Spmd.open_ graph) in
let g = group.!(index i) in
let zero = broadcast (I32.lit #0l) in
if_var I32.(g > zero)
~then_:F32.(totals.!(g) /. of_i32 counts.!(g))
~else_:(broadcast (F32.lit #0.s)))
The plain
if_
can’t do that, because the condition is a
bool# uniform
and therefore it
must be the same value for all lanes.
select
and
if_var
are similar in that they both take in a condition of type
bool#
varying
. Where the two constructs differ is in how the branches are evaluated. With
if_var
, the compiler can decide whether to execute the branch that is
not
chosen by
the condition, whereas with
select
, both branches are always evaluated. Further,
if
if_var
executes an untaken branch, any potential side effects, such as raising
exceptions, will not be observable. So
select true 1 (1/0)
will raise an exception,
but
{
if,if_var
}
true
1
(
1
/
0
)
will not.
Usually, a high-performance JIT compiler would target a low-level language such as assembly or LLVM IR, which necessitates thinking quite hard about complicated details such as registers, pointers, and so on. Luckily, we didn’t have to do this, since we could use metaprogramming to emit OxCaml code. This also lets us rely on optimizations in the OxCaml compiler, saving us from having to implement them ourselves.
OxCaml’s metaprogramming features let us explicitly generate OxCaml code at runtime using
quotes
and
splices
. A quotation represents an OxCaml expression that is created at
runtime and will be evaluated at a later time. For example,
<[if Random.bool () then 42
else 5]>
represents an unevaluated expression of type
int
, so the quotation itself has
type
<[int]> expr
. Once this expression is evaluated, its result will be an
int
.
Quotations can be interpolated into other quotations by splicing (
$
):
# let quote = <[2 + 3]> in <[$quote * 4]>;;
- : <[int]> expr = <[Base.( * ) (Base.( + ) 2 3) 4]>
So rather than writing the standard recursive
power
function that computes
x^n
:
# let rec power n x =
if n = 0 then 1 else x * power (n - 1) x;;
val power : int -> int -> int = <fun>
you can write a
power_expr
function that creates a quoted expression that will compute
x^n
for a given
n
, effectively inlining and optimizing the recursive function into a
single expression. This is a form of
partial
evaluation
where we’re able to take a
function and produce a much faster version specialized to a particular value of
n
.
# let rec power_expr n xq =
if n = 0 then <[1]>
else <[$xq * $(power_expr (n - 1) xq)]>;;
val power_expr : int -> <[int]> expr -> <[int]> expr @ once = <fun>
# <[ fun x -> $(power_expr 5 <[x]>) ]>;;
- : <[int -> int]> expr =
<[fun x -> Base.( * ) x (Base.( * ) x (Base.( * ) x (Base.( * ) x (Base.( * ) x 1))))]>
Sai’s backend walked the DAG and emitted OxCaml code for each node. For instance, the backend emits the following quoted OxCaml code for arithmetic expressions:
let rec emit node =
match node with
| Add (x, y) -> <[ F32.O.( + ) $(emit x) $(emit y) ]>
| Mul (x, y) -> <[ F32.O.( * ) $(emit x) $(emit y) ]>
| Load (input, idx) -> <[ Slice.Imm.unsafe_get $input $(emit idx) ]>
If we were to compile a basic kernel such as:
(fun graph [ a; b; c ] [ Dim i ] -> exclave_
let open (val Spmd.open_ graph) in
let i = index i in
F32.((a.!(i) +. b.!(i)) *. c.!(i)))
we’d get a DAG that represents the arithmetic operations, and use that to generate quoted OxCaml code:
emit (Mul (Add (Load a, Load b), Load c))
= <[ F32.O.( * ) $(emit (Add (Load a, Load b))) $(emit (Load c)) ]>
= <[ F32.O.( * )
(F32.O.( + ) $(emit (Load a)) $(emit (Load b)))
$(emit (Load c)) ]>
= <[ F32.O.( * )
(F32.O.( + )
(Slice.Imm.unsafe_get a (I32.to_i64 i))
(Slice.Imm.unsafe_get b (I32.to_i64 i)))
(Slice.Imm.unsafe_get c (I32.to_i64 i)) ]>
Sai implemented these emitters for all of the node types in the DAG, such as the
if_
,
if_var
and
select
control flow constructs.
At this point, Sai needed to validate that his JIT implementation was both fast and correct. One strategy he used was to compare the JIT against a reference implementation. We had previously implemented an interpreter that took the front-end representation and directly executed it. While extremely slow, we could be fairly confident that the interpreter would have the correct behavior, so could be used to verify that the JIT was also correct.
Sai wrote four example programs, including an implementation of Newton’s square root algorithm and a kernel adapted from some production code, in plain OxCaml, C with AVX2 intrinsics, C with AVX512 intrinsics, and as an SPMD kernel (which could be either executed by the interpreter or JIT compiled). Each combination was benchmarked on inputs of various sizes.
Sai also worked on an extensive test suite for all of the different language features and edge-cases. This suite included a test that generated random inputs with Quickcheck generators, then ran those inputs on the four example programs. Their outputs were cross-checked and compared bit by bit. He also wrote tests confirming that the code didn’t allocate on the heap.
The benchmarks found that the JIT was much faster than the interpreter. However, the JIT was about the same speed (or slightly slower) than the manual OxCaml code and significantly slower than the C implementations. This wasn’t that surprising, since we hadn’t implemented any real optimizations or tuning in the compiler. Naturally, this needed to change if we wanted to catch up to the C implementations.
Sai then started looking at adding optimizations to the compiler. With the current compilation pipeline, this would have been slightly painful. Our front end representation was not designed to be easily analyzed or optimized. While that wouldn’t have necessarily stopped us from doing analysis, it’s often a better idea to add an intermediate representation (IR) that is more amenable to optimization. Sai implemented an IR based on A-normal form (ANF), a format where each intermediate value gets its own variable. This is the IR that we saw in the previous section about optimizing away control flow:
let%expect_test "IR: euclidean" =
let lowered = For_testing.Ir.of_kernel (measure ~metric:Euclidean) in
print_string (For_testing.Ir_body.to_string lowered.body);
[%expect
{|
let n = shape[0]
for i in n (normal) {
let v = load_f32 in0[i]
let v1 = load_f32 in1[i]
let v2 = f32_sub v v1
let v3 = f32_mul v2 v2
store out[i] = v3
}
|}]
;;
let%expect_test "IR: manhattan" =
let lowered = For_testing.Ir.of_kernel (measure ~metric:Manhattan) in
print_string (For_testing.Ir_body.to_string lowered.body);
[%expect
{|
let n = shape[0]
for i in n (normal) {
let v = load_f32 in0[i]
let v1 = load_f32 in1[i]
let v2 = f32_sub v v1
let v3 = f32 0.
let v4 = f32_ge v2 v3
let v5 = f32_sub v3 v2
let v6 = select v4 v2 v5
store out[i] = v6
}
|}]
;;
The IR is more verbose but easier to analyze. For example, because all intermediate values are assigned a variable, it becomes easy to remove dead code; just look if an intermediate value is used anywhere after its definition.
Sai designed this IR with a key design principle in mind: Generating the final OxCaml code from the IR should be a trivial process. Any interesting compilation logic should end up explicitly represented in the IR.
One instance of this principle shows up in how we model loops. As we mentioned before, kernels only declare what we do on each loop iteration, not how we loop over the code itself.
(fun graph [ x; scale ] [ Dim i ] -> exclave_
let open (val Spmd.open_ graph) in
let i = index i in
F32.((x.!(i) *. broadcast scale.!(I32.lit #0l)) +. of_i32 i))
But in the IR, we explicitly specify the loop, as well as load/store logic. That way, the optimizer can reason about how to re-order or unroll loops. For example, the above kernel would produce the following IR:
let n = shape[0]
for i in n (normal) {
let v = load_f32 in0[i]
let v1 = i32 0
let v2 = load_f32 in1[v1]
let v3 = f32_mul v v2
let v4 = f32_of_i32 i
let v5 = f32_add v3 v4
store out[i] = v5
}
The optimizer can analyze this IR and see that
v1
and
v2
do not depend on
i
and
therefore can be lifted out of the loop:
let n = shape[0]
let v1 = i32 0
let v2 = load_f32 in1[v1]
for i in n (normal) {
let v = load_f32 in0[i]
let v3 = f32_mul v v2
let v4 = f32_of_i32 i
let v5 = f32_add v3 v4
store out[i] = v5
}
It can also rewrite the loop to process 4 elements at a time, which reduces the amount of branching in the code.
let n = shape[0]
let v1 = i32 0
let v2 = load_f32 in1[v1]
for io in div n 4 (normal) {
let i_0 = add (mul io 4) 0
let i_1 = add (mul io 4) 1
let i_2 = add (mul io 4) 2
let i_3 = add (mul io 4) 3
let v_0 = load_f32 in0[i_0]
let v_1 = load_f32 in0[i_1]
let v_2 = load_f32 in0[i_2]
let v_3 = load_f32 in0[i_3]
let v3_0 = f32_mul v_0 v2
let v3_1 = f32_mul v_1 v2
let v3_2 = f32_mul v_2 v2
let v3_3 = f32_mul v_3 v2
let v4_0 = f32_of_i32 i_0
let v4_1 = f32_of_i32 i_1
let v4_2 = f32_of_i32 i_2
let v4_3 = f32_of_i32 i_3
let v5_0 = f32_add v3_0 v4_0
let v5_1 = f32_add v3_1 v4_1
let v5_2 = f32_add v3_2 v4_2
let v5_3 = f32_add v3_3 v4_3
store out[i_0] = v5_0
store out[i_1] = v5_1
store out[i_2] = v5_2
store out[i_3] = v5_3
}
By making the IR fairly explicit, we’re able to reason about—and therefore optimize—the code effectively.
Like with the previous backend implementation, Sai put in a lot of work to validate the correctness of the new compilation path. He added the new backend to the existing cross-validation logic across the test suite, then added expect tests that printed the IR and the emitted OxCaml for various examples, which helped us confirm that the behavior was exactly as expected.
Once we were confident that the new IR-based path was correct, Sai deleted the previous backend.
With the current implementation, the IR backend generates essentially the same code as the first JIT, so the two perform about the same.
However, optimizations are now significantly easier to add. We’re currently working on adding vectorization and constant hoisting to the compiler. Preliminary benchmarks have found that these changes result in code that is on-par with our C AVX2 implementation.
We’re also working on adding scheduling. Scheduling lets users customize how the kernel loops over the code with a sophisticated set of transformations like “split this loop into 8 piece chunks, vectorize these chunks, then unroll by 4”. Intelligent scheduling is important for getting the maximum possible performance out of the kernel. Eventually these schedules could also be auto-generated and benchmarked, so that the compiler can find the optimal one for your kernel.
Nicholas is a software engineer and technical writer at Jane Street. He has written multiple blog posts about chili oil.
Following the departure of now-former NVIDIA CEO, Jensen Huang , a new report by The Wall Street Journal (via Wccftech ) has emerged alleging that NVIDIA artificially inflated the ongoing GPU and memory shortage by investing in AI startups that would go on to buy NVIDIA GPUs and build data centers. The reason behind this was to maintain the perception of ongoing high demand and to move an oversupply of semiconductors from TSMC.
The WSJ report cites an August meeting between Huang and his senior finance team, including NVIDIA's CFO and acting CEO, Colette Kress, during which Kress pushed for a reduction in circular financing agreements, in response to which Huang allegedly lay into Kress, calling her a "deer in the headlights," after she had pushed to scale back NVIDIA's $250 billion deal with OpenAI . Jensen's push for further investment into small-scale cloud providers was seemingly in response to the changing tide that saw AI hyperscalers move away from off-the-shelf components in favor of custom solutions.
The situation described in the report saw NVIDIA on the hook for an "avalanche" of GPUs from TSMC, for which it would have no immediate buyers. Part of the issue highlighted by Kress was also that these small-scale cloud providers NVIDIA was investing in could not afford to buy NVIDIA GPUs, meaning they, too, could be a financial dead end.
ggml 1.0.0 prunes the deprecated public API and the legacy
DIAG_MASK
ops, adds configurable YaRN truncation and FP8 support, and brings broad performance work across backends: few-row quantized matmuls and MoE fusion on CUDA/Metal, a Vulkan prefill FlashAttention path, a device-side MoE scheduler on SYCL, decomposed Adreno FlashAttention in OpenCL, new WebGPU kernels, expanded Hexagon op coverage, and scheduler improvements that avoid uploading unused inputs.
DIAG_MASK_INF
/
DIAG_MASK_ZERO
ops, bumping the RPC protocol to reject incompatible peers (
llama/29801
,
llama/31946
)
ggml_rope_set_truncate
/
ggml_rope_get_truncate
to control YaRN correction-bound rounding (
llama/30206
,
llama/30802
)
TRI
(
llama/30712
)
MUL_MAT
src1 precision tests and gating for
ggml_prec_set_acc
(
llama/31896
,
llama/31851
)
417a024
ggml : bump version to 1.0.0 (
#1690
)
771b3d9
requirements : fix numpy for python 3.14 (
#1691
)
f154959
sync : llama.cpp
ec04faf
fix(hexagon): make host build work with clang-cl on Windows ARM64 (llama/32011)
b45738e
examples : adapt to removal of ggml_diag_mask_inf
1514439
sync : llama.cpp
5f29555
ggml : prune (llama/29801)
076861c
hexagon: add Q5_0 and Q5_1 support (llama/32094)
63ec52d
Title: CUDA: few-row MMQ for BS 2-24 (llama/31533)
c6fe796
ggml : route GATED_DELTA_NET to the SpacemiT RVV kernel (llama/31897)
4ae6e72
vulkan : Intel FA kernel for prefill. (llama/29357)
b22071c
ggml-cpu: use the 4x4 simd_gemm tile on ARM NEON (llama/32128)
ba8b013
CUDA: Optimize prefil via fuse of w_s scale in epilogue MMQ for nvfp4 checkpoints (llama/26048)
05f605a
ggml-backend : prefetch only inputs computed by earlier splits (llama/32100)
b8a5b87
ggml : dispatch SpacemiT Q4_1 32x256 through the HP kernel (llama/31929)
7a8cef5
sycl: make oneDNN FA cache thread-safe and memoize runtime failures (llama/31138)
6dfea1a
sycl : fix AOT for more than 4GB (llama/31873)
012ff44
sycl : use cached device-id in set_main_device (llama/32013)
2f9d47b
CUDA: add cuda debug buffer pool (llama/31919)
522d257
opencl: add bin kernel
kernel_gemm_noshuffle_q4_0_f32_32b_trans_ila_a7_bin
(llama/30947)
0f9dcb7
CUDA: skip empty MoE tiles in MMQ stream-k fixup (llama/32067)
6bed9a8
opencl: add decomposed FA for Adreno (llama/32046)
a357e7b
metal : prevent out-of-bounds reads in SOLVE_TRI kernel (llama/32103)
c36ccd8
vulkan: support batched tensor copy API (llama/31418)
1bffc59
backend : re-instantiate CUDA graphs when the cluster dims of a kernel change (llama/31284)
8153155
ROCm/HIP: fixed BLAS workspace instead of rocBLAS allocating one per call (llama/31838)
ad7d200
cpu: accumulate flash attention V in F32 (llama/29810)
7f4a2db
webgpu: add PAD_REFLECT_1D support (llama/31877)
0f51454
vulkan: allow dequantized KV optimization with CM2 (llama/31526)
eb4de49
vulkan: allocate the device fault vendor binary buffer (llama/32008)
6b7f47a
cuda : use MMVF for BF16 matrices of few rows at small batch sizes (llama/31959)
77d01f1
cuda : add sm70 FlashAttention config case for DKQ=256, DV=256, ncols=64 (llama/27997)
bd37ba0
cuda : fattn mma head sizes 40 72 (llama/30285)
161ca15
CUDA: Add OCP FP8 support (llama/28413)
06faf80
sycl : fixed sycl CLAMP to actually support strided view (llama/31784)
a986181
cuda : remove unused ids and type_src0 parameters (llama/32018)
55104b2
llama : Add FP8 KV-cache support (llama/28392)
0753641
ggml : add MUL_MAT src1 precision tests and gating (llama/31896)
1cd16bd
cuda : remove unused quantize_cuda_t typedef (llama/31884)
4a18cdd
cuda : halve VMM pool reservation size and retry on cuMemAddressReserve failure (llama/30542)
1c9ac9d
CUDA: skip graph compat check when graph is being reused (llama/32004)
999c725
ggml : fix FreeBSD Vulkan build by setting _XOPEN_SOURCE=700 (llama/31701)
47bc1d8
CUDA: move graph and concurrent stream state out of common.cuh (llama/32001)
df70e12
cann: fail early when checking if buffer type is supported (llama/31270)
e447eb5
sycl: Add device-side MoE scheduler (llama/30156)
9a1c582
vulkan: add tiled-transpose concat shader for Qwen models (llama/30591)
8b3c8cf
ggml-rpc : fail gracefully on unreachable endpoints and failed handshakes (llama/30415)
f860f1d
vulkan: Divide GROUP_NORM workgroup to 2D to avoid maxComputeWorkGroupCount limit (llama/31930)
eb5571a
vulkan: Fix out of bounds reads/writes on MoltenVK (llama/31890)
5a9a264
vulkan: cap scalar flash attention at 8 rows for large heads on Qualcomm (llama/30829)
5610f41
sycl: un-gate oneDNN fused SDPA for Alchemist at head_dim=64 (llama/31574)
487cadf
hexagon: fix 64-bit FastRPC handle truncation on close (llama/30952)
be37c9c
ggml-zdnn: accept non-zdnn tensors, invalidate compute tensors after every op (llama/31824)
294d5fc
ggml : implement the backward pass for TRI (llama/30712)
e18c2c6
ggml-backend: don't upload inputs that are not read (llama/31419)
e84d36b
metal : prevent out-of-bounds writes to the Metal FA output buffer (llama/31662)
0dd184f
metal : make ggml_tri select instead of scaling by the comparison (llama/30711)
b6d482c
opencl : include climits (llama/31935)
62de780
RPC: Improve loading times (llama/29413)
a7276d0
ggml : support YaRN truncation config on openvino, sycl, vulkan, webgpu, rpc (llama/30802)
da89459
sycl: cache device-id (llama/31126)
fb57085
tests: bound the test_rope tolerance by the f32 angle resolution (llama/31874)
e43d847
opencl: add f32 MUL_MAT_ID (llama/31783)
d1c1e4b
ggml-zdnn: fix release binary not detecting backend lib (llama/31905)
7e7b6e9
mtmd: refactoring: remove clip.h, consolidate code into mtmd (llama/31865)
5a0e536
cpu: enable SpacemiT IME2 MXFP4 dense repack (llama/31776)
7f4b25f
llamafile: impl bf16 and q8_0 vxe (llama/31866)
f22fc6a
ggml : update CUDA/Metal radix Top-K to make tied selections deterministic (llama/31084)
47b8b4f
ggml-cuda : add d_state=64 fast path to SSM_SCAN kernel (llama/31818)
b524960
webgpu : add COUNT_EQUAL support (llama/31578)
75a4f5a
ggml : switch to F32 src1 in the CPU backend (llama/31854)
6cddab2
llama, mtmd: follow the reference precision of ggml_prec_set_acc calls (llama/31851)
7353275
opencl: improve q8_0 and MoE small-n verification for spec (llama/31831)
8f1404e
hexagon: support for automatic loading of libhtp without legacy env vars (llama/31781)
91c102a
sycl: exact rounding in CPY to Q4_1, Q5_1 and Q8_0 (llama/31465)
8cf32bc
sycl: refuse device buffers that would exceed VRAM (llama/31285)
d969b07
hexagon: n_hvx and n_threads cleanup (llama/31857)
5746ebd
llama_moe_cache: run missed experts on CPU, add tuning script (llama/30966)
a49f174
sycl: add f16 support for SWIGLU_OAI (llama/30857)
c6a0780
metal : fix GROUP_NORM for ne03 > 1 and non-contiguous inputs (llama/31852)
1e5c3e0
webgpu : Implement group norm kernel (llama/31490)
37ecdca
vulkan: Add 'readonly' to decodeBuf declarations. (llama/31833)
c08538b
CUDA: fix shared memory bank conflicts in the lightning indexer (llama/31803)
07b8362
opencl: add arange (llama/31829)
f55a504
meta : raise the compute view limit for buffers with few tensors (llama/31447)
2870133
hexagon: fuse post-norm residual add into RMS_NORM_MUL (llama/31822)
a135ec6
hexagon: conv_2d optimizations and support for conv_3d (llama/31814)
e3d3633
tests : qualify isnan and signbit with std:: (llama/31791)
a7d3330
tests : override hardware_concurrency in CI (llama/31797)
ab7ca9c
opencl: support repeat for f16, i32, i16, bf16 (llama/31782)
9290392
webgpu: add batched tensor API (
get_tensor_n
and
set_tensor_n
) (llama/31473)
f594fed
vulkan: detect ReBAR support, avoid BAR allocations if unavailable (llama/31658)
38e4be2
CUDA: fix Maxwell build (llama/31787)
8bd6b61
opencl: add q6_k multi column tiled GEMV for speculative verification and refactoring (llama/31758)
d3ce63d
hexagon: Implement set_tensor_n and improve repacking/tiling robustness (llama/31744)
9b1880f
ggml-cuda: sanitize post-bias NaNs in MoE selection (llama/31005)
7e607b8
vulkan: Implement test-fusion interface (llama/30769)
2188d13
CUDA: use highest compiled arch in get_mmvq_mmid_max_batch (llama/31679)
114ce5e
vulkan: RDNA3/4 Large-Tile Split-K Optimization (llama/30280)
e074347
metal : fuse DeepSeek-V4/V4.1 and GLM MoE routing (llama/31615)
f0f5b42
CUDA/HIP: matrix-core (MFMA) lightning indexer for CDNA2 (gfx90a) (llama/29050)
fa8c617
CUDA: linearize MoE data layout for MMQ/MMF (llama/31047)
1690d2e
vulkan: FWHT kernels for block widths above 512 (llama/29772)
40278c4
vulkan : check combined K+V f16 scratch size in FA dequant path (llama/30487)
2dccfdb
sync : llama.cpp
25b845e
ggml : support
truncate=false
for YaRN (llama/30206)
accf2a1
sync : llama.cpp
b2ce926
metal : use mul_mm for 32 <= K < 64 (llama/30982)
1a5f477
webgpu : add MEAN support (llama/31591)
2ab6d6c
vulkan: Re-enable large coopmat matmul configuration on AMD proprietary driver 26.10.1+ (llama/31587)
19df6cf
tests: fix CI flakes of TOPK_MOE caused by near ties (llama/31426)
a0df99d
metal: keep fusable node groups inside one command buffer (llama/31688)
3a996db
opencl: enable f32 and q5_k multi column GEMV by default for Adreno X2 (llama/31694)
d75184e
opencl: support non-contig sigmoid (llama/31687)
c634501
opencl: add DSV4_HC_PRE and DSV4_HC_POST (llama/31623)
0816137
Title: CUDA: fuse NVFP4 gate/up matmuls and GLU in MMQ (llama/31296)
4ac0dae
opencl: improve decode perf with FA (llama/31633)
4f681f2
webgpu: return maxBufferSize from get_max_size and avoid whole-buffer bindings in memset/clear (llama/31348)
cd6d2b7
docs : sync ggml_type enum in gguf.md (
#1685
)
Nvidia's second-largest shareholder sold about $946 million in company stock in the months leading up to CEO Jensen Huang's resignation on Nov. 12.
Nvidia [NASDAQ: NVDA] Board Director Mark Stevens was one of the top AI sellers in Q3 2026, selling roughly 4.2 million shares , according to filings with the Securities and Exchange Commission. There were three separate batches of stock sales from Stevens, who joined the Nvidia board in 2008 following an earlier stint as a director from 1993 to 2006.
Jeff Bezos backs a platform that lets anyone invest in rental homes for as little as $100 — 5 ways to build wealth like a landlord without actually being one
Dave Ramsey warns nearly 50% of Americans are making 1 big Social Security mistake. Here's what it is and 3 simple steps to fix it ASAP
A single line on your car insurance policy could be inflating your premium by up to 30% — here's what to change
The first common stock sale took place from Aug. 31 to Sept. 2 at equity prices ranging from $220 to $226, generating $411 million in new cash. The second sale stretched from Sept. 3 to Sept. 4 at prices ranging between $227 to $234 per share, garnering about $236 million. The third sale occurred on Sept. 18 at roughly $220 per share, netting roughly $300 million.
Prearranged trading plans are used by executives to buy or sell shares of their firm on specific dates or target prices. It's a mechanism to wall off company employees from insider trading accusations as long as they stick to the automatic plan.
The SEC first instituted the practice in 2000 and modified it in 2022 to include a 90-day waiting period for starting trades. In some cases, the plans were abused by executives in instances like executing share sales just before an earnings report.
In Stevens's case, he didn't have such a trading plan, but that's not necessarily a red flag on its own. Insiders cashing out of their stock will do so for a variety of reasons that aren't always tied to a company's performance, such as quickly raising liquidity. In Nvidia's case, the move could pour water on the enthusiasm of retail investors to buy into an AI titan that has also attracted short sellers .
The first two stock sales in late August and early September followed a robust Q2 earnings report that caused Nvidia shares to jump about 10% in valuein the following week. Stevens still holds about 27.5 million shares in Nvidia, a colossal position.
Opens in a new window Opens an external site Opens an external site in a new window
An investigation by Bloomberg into Penlink’s ad-based surveillance system Webloc builds off Citizen Lab research, identifying additional customers of the tracking technology. The findings that Webloc has been acquired by security agencies in a number of countries aligns with potential customers we identified in our April report.
Senior researcher Wolfie Christl notes that Webloc “is a powerful mass surveillance tool that’s trickling down from military and intelligence agencies to federal law enforcement and then to state and local police.”
Our report used open source research, freedom of information requests, and server infrastructure mapping to identify Webloc customers in the US, El Salvador, and Hungary. Since then, the Austrian Ministry of the Interior has also been confirmed as a customer. The Bloomberg investigation identified customers in additional countries including the UK, Netherlands, Germany, Mexico, Singapore, Saudi Arabia, UAE, and Israel.
The lawfulness of using these systems in Europe and the UK is highly controversial . While intrusive and disproportionate ad-based mass surveillance is problematic everywhere, its use in authoritarian countries identified by reporting is particularly dangerous.
In collaboration with the SHARE Foundation, we found with high confidence that Professor Vladan Đokić, Rector of the University of Belgrade, and prominent supporter of the Serbian student movement, was hacked with NSO Group’s Pegasus spyware in 2026. Additionally, we note that Rade Bajić, who, as a prosecutor, investigated official corruption in a failed project in Belgrade, received an Apple Threat Notification. These notifications are high-confidence indicators of targeting with mercenary spyware such as Pegasus. Our investigations into these cases are ongoing.
With a troubling decline in the population, researchers warn of a tipping point for the highly social animals
Humans and many other social animals thrive in well-established community networks. Asian elephants are one example of a species that flourishes in groups that work together to access food and care for their young, among other social bonds.
University of California San Diego scientists in the School of Biological Sciences studying the intricacies of Asian elephant community structures have documented a troubling downturn in the population of the animals resulting in fractured social communities. Their study is published on the cover of the November 12 issue of Science .
Analyzing the social dynamics of more than 440 wild female Asian elephants over 12 years at the Udawalawe National Park in Sri Lanka, the researchers studied key shifts in the demographics of the elephants that seemed to trigger social communities becoming smaller and more isolated.
“We found that gradual accumulation of losses from turnover preceded sudden change in the social networks among females in a wild population of Asian elephants,” the researchers explained in the study, which was led by Postdoctoral Researcher Anastasia Madsen from the laboratory of Associate Professor Shermin de Silva in the Department of Ecology, Behavior and Evolution. de Silva also serves as president and founder of the conservation nonprofit Trunks & Leaves Inc.
The researchers’ analysis indicates a social structure tipping point. As the number of elephants in the population decreased over time, due to a combination of likely deaths, permanent emigrations of elephants and fewer incoming individuals, the population as a whole appears to have crossed a critical threshold that resulted in a shift from large, densely connected social communities, to smaller and less-connected social groupings.
Asian elephants thrive in groups that work together to access food and care for their young. Credit: Udawalawe Elephant Research Project, CC BY-ND
“We see individual elephants leaving and possibly dying at accelerating rates, but new individuals are not coming into the population,” said Madsen. “With fewer individuals in the population, those who are left will naturally have fewer relationships. However, the remaining elephants are also changing their relationships with each other.”
This new dynamic is a cause for concern, says Madsen, since the animals leverage their social groups and connections to forage, acquire information and raise young.
“We can probably all relate to the feeling of social isolation brought about, paradoxically, with the advent of digital communications that seem to remove the physical constraints of needing to be in the same place at the same time,” said de Silva. “But for many social species, which includes ourselves as much as elephants, we have to remember that social connectivity is very much a matter of sharing space and building relationships throughout our lives. Crucially, in order to have resilient communities, we need to be able to replace the relationships that are lost over time.”
Many elephant populations are already impacted through deaths resulting from poaching and conflicts with humans. Other contributing factors may be disruptions in habitat connectivity and less food available for the elephants as ecological conditions change across the 119-square-mile park and surroundings.
The new social fracturing structure observed by the scientists may not be easily repaired, the researchers warn.
“In general, we need to be more aware of these types of tipping points where we see sudden shifts after changes have been slowly building up,” said Madsen. “Once we move past the tipping point, it’s much harder to go back to previous states.”
"We are gaining more evidence that studying social patterns is an important tool for us to see when things are going wrong in natural populations and, hopefully, to be able to do something about it."
Credit: Udawalawe Elephant Research Project, CC BY-ND
The new findings will serve future studies seeking to understand shifts in animal society structures, how to detect such tranformations and the factors responsible for vulnerabilities. The study also stimulates ongoing discussions for conserving elephant populations as humans expand into areas where elephants historically thrived.
“We are gaining more evidence that studying social patterns is an important tool for us to see when things are going wrong in natural populations and, hopefully, to be able to do something about it,” said Madsen.
The researchers of the study were: Anastasia E. Madsen, T.V. Pushpakumara, U. Sameera Weerathunga, Devaka K. Weerakoon and Shermin de Silva.
Funding for the research was provided by the U.S. Fish and Wildlife Asian Elephant Conservation Grants (F11AP00258, F14AP00256 and F17AP00308); National Science Foundation (grant DBI-2305860); University of Pennsylvania; UC San Diego; and Trunks & Leaves Inc.
Keep up with all the latest from UC San Diego. Subscribe to the newsletter today.
'Get Ready, We're Coming' | Richard Ojeda on Hegseth. Only a Pawn in Their Game | Bob Dylan. Why Forcing Ukraine into a Peace Deal Won’t Work. Why Hasn’t Abdul El-Sayed Accomplished Any of his Campaign Goals? Electoral College On Life Support.
Portside Portside
| ATCSCC Advisory | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||
As impressive, and perhaps more important, than the overall Democratic sweep in this month’s midterm election was the location of its epicenter: the South. After the 2030 census reapportions the number of congressional districts and electoral votes that each state will be given, Democratic strongholds will see their representation and electoral clout shrink to the point that even a Democratic sweep of the blue-wall states of the postindustrial Midwest won’t be able to guarantee the 270 electoral votes needed to elect a president.
This year’s midterms, however, provided the Democrats with a very surprising Plan B. By sweeping the table in three of the four largest Southern states—Georgia, North Carolina, and Texas—Democrats realized they’d stumbled upon another route to national political power.
To be sure, these victories were products of the conditions peculiar to the year: a wildly unpopular president whose unjustifiable war and arbitrarily applied tariffs stretched millions of Americans’ finances to the breaking point, whose deportation raids and financial corruption offended his compatriots’ moral sensibilities, and whose fiddling with D.C. monuments while the economy burned saddled him with disapproval ratings that rivaled Richard Nixon’s lowest points. That the Republican Congress consistently failed to rein in Donald Trump’s malignant idiocies saddled them with approval ratings even lower than his. Asked in the networks’ exit poll if Congress had provided an acceptable level of checks and balances to Trump and his administration, a whopping 71 percent said they’d not done enough, against a paltry 9 percent who judged they’d done too much.
The abdication of Republicans at both ends of Pennsylvania Avenue from attending to the country’s business has cost the party its edge over the Democrats on topics that Republicans usually dominate. Not only did the exit polls show that voters preferred to have the Democrats handle the economy, but they even gave Democrats higher marks on handling taxes (40 percent preferred the Democrats, while 38 percent went with the Republicans), a perennial GOP strong point. Moreover, the kinds of issues that Republicans generally put before the public to highlight the Democrats’ shortcomings simply didn’t register this year. Asked what they considered the most important issue, voters led with the economy (39 percent) and the state of American democracy (33 percent), with a bare 3 percent citing crime (see: Democrats soft on).
Then there were the Trump policies that specifically afflicted the regions that turned against him. States with heavy concentrations of Latinos, like Texas, saw massive flight from the Republican column, powered not just by the cost of living but also by the costs of the deportation sweeps that had devastated their families and communities. Agricultural states, like Kansas and Iowa, which rely on tractors and trucks to shape and move their goods, found the price of diesel prohibitive, even as Trump’s trade wars curtailed their markets for exports. Southern states with high percentages of Black voters, like Georgia and Mississippi, saw high Black turnout in response to the Supreme Court’s gutting of the Voting Rights Act and its unleashing of partisan Republican gerrymandering intended to diminish Black political power and interests.
Finally, from Ken Paxton to Vivek Ramaswamy to Darline Graham, the Republicans asked voters to support a bevy of certifiable lulus, while the Democrats ran a crop of compelling, or at least normal, candidates.
So yes, there were reasons very particular to year six of the Trump presidency that set the table for the Democrats’ wave. And yes, some of those shifts may be short-lived phenomena connected directly to tariff wars and the high price of gas. But beneath these particularities, there were also tectonic shifts in the demographics and political economy of the three key Southern states that Trump brought to the surface. There are deeper reasons why Texas, Georgia, and North Carolina have become politically purple, and understanding them can help the Democrats create what might become a new political majority.
TO BEGIN WITH, ALL THREE ARE STATES increasingly dominated by metropolitan areas, populated by racially diverse professionals, even more racially diverse service-sector workers, young newcomers from neighboring states and distant lands, and the steadily more cosmopolitan cultures coming along with them. Houston, Dallas, and Austin meet all those criteria in Texas, as Atlanta does in Georgia, while Charlotte and the Research Triangle play a version of that role in North Carolina. Young people move there for career reasons and to find housing more affordable than it is in the Northeast and the Pacific Coast. While the border communities in Texas are among the most venerable, settled, and traditional of any American regions, most Latino immigrants live in the state’s considerably more heterogeneous big cities.
Diverse by their very nature, and easier terrains to organize in than suburban or rural areas, cities invariably tend toward social liberalism and the formation of movements (planned or spontaneous, daylong or permanent). This year’s exit polls tell us that city dwellers voted for Democrats over Republicans 72-27, while 59 percent of suburbanites voted for Democrats, and only 41 percent of small-town and rural residents did. Georgia, North Carolina, and Texas are now sufficiently urban, with all that entails, to require the Democrats to target their efforts there.
Texas, with its 40 Electoral College votes, has long been the anchor state of the modern Republican Party and American conservatism more generally. But it is not only increasingly urban and racially diverse; it’s also increasingly young. The median age of Texans is 36, the lowest of any state except Utah.
Understanding why Texas, Georgia, and North Carolina have become politically purple can help Democrats create what might become a new political majority.
One reason why Texas had a Democratic sweep, while the second-largest Southern state of Florida remained largely Republican, is the anti-Castro, anti-socialist, anti-Democratic politics of its own Latinos, chiefly of Cuban and South American extraction. But in addition, the median age of Floridians (42.6) is the fifth-oldest in the country behind Maine, New Hampshire, Vermont, and West Virginia, states that young people leave in search of work. Florida doesn’t have an equivalent out-migration of the young; it has long been defined, though, by an in-migration of the old.
In this month’s election, the share of voters in the Senate race under the age of 45 in Texas was 36 percent. In Florida, it was 25 percent. (Nationally, it was 31 percent.) That 11-percentage-point difference was also true for voters 65 and older: In Texas, they constituted 30 percent of the Senate-race voters; in Florida, 41 percent. These are numbers that can define a state’s politics, because the young generally vote more liberally than the old, and even more so when the early-career and family formation costs of college, child care, and housing become prohibitive.
At certain times, generations can be distinct political cohorts, and this is one of those times. In Texas, 79 percent of voters under 30 voted for the Democratic Senate candidate this November; between 30 and 45, the percentage drops to 66 percent, and among seniors 65 and older, only 44 percent. In Florida, the Democratic percentages for the two under-45 age groups were about 5 points lower than in Texas—74 percent and 61 percent, respectively—but they still were well left of Florida’s seniors, who gave just 41 percent of their votes to the Democrat.
While many anchor Democratic states—California, New York, Illinois, Minnesota, Rhode Island, Oregon—are poised to lose electoral votes and members of Congress after the 2030 census, Texas is projected to gain four new seats, while the purple states of Georgia, North Carolina, and Arizona are projected to each gain one. Right now, the combined electoral votes of Texas, Georgia, and North Carolina come to 72, while those of the three most Democratic blue-wall states (Pennsylvania, Michigan, and Wisconsin) come to 44 (likely 42 after 2030). As the South’s major cities grow with in-migration of young people from other states and immigrants from other lands, Democrats would do well to specifically address the economic concerns of these young, majority-making voters: higher wages, legally mandated wage and benefit standards for gig workers, affordable colleges and trade schools, job creation in construction (which could serve multiple needs if those jobs built housing), and the extension of Medicare coverage to children and young adults. None of these policies can be accused of “wokeness,” nor is their appeal at all limited to self-designated liberals.
WHILE NOVEMBER’S ELECTION MARKED a clear swing leftward by the electorate, the ideological self-definitions of American voters did not swing left. The exit polls found that 26 percent of voters called themselves liberal, 41 percent called themselves moderate, and 33 percent called themselves conservative. What Americans mean by these terms has never been all that clear; for many years, they’ve seemed to reflect people’s stances on cultural issues more than on economic ones. Sixty-one percent of these same respondents also said that they wanted the federal government to take a bigger role in helping Americans get health care, which is a liberal and social democratic position if ever there was one.
The point for Democrats is that the level of support for progressive populist economics extends well beyond the ranks of liberals, much less socialists. Asked whether the American economy favored the wealthy, or was generally fair to all, 70 percent of midterm election voters said it favored the wealthy. The exit poll didn’t pursue the implications of that assessment, but other polls have made clear both the widespread support for higher taxes on the wealthy and corporations, and for legislation that would curtail the domination they exert over politics and policies.
I’m pleased to report that Montana voters passed by a wide margin (65-to-35) an initiative that requires the state to amend its corporate charters so that corporations would be forbidden to participate in or contribute to political campaigns, elected officials, candidates, and ballot measures—which would apply to all corporations doing business in the state and to their activities in every other state as well. (The status of this backdoor repeal of Citizens United will eventually wend its way to the Supreme Court, of course.) And it was enacted by the same electorate that was casting 52 percent of its vote for Republican House candidates.
Populism cuts across nearly all ideologies; ensuring that populism focuses on progressive economic targets and goals is the task of the left and, when it can be roused, the center-left. In his election night victory speech, Texas Sen.-elect James Talarico made clear that the real opponent whom he’d defeated wasn’t poor Ken Paxton but rich Elon Musk, who’d sunk more than $200 million into beating him. Talarico added that the problem wasn’t just Musk; it was the billionaires investing huge sums into AI with no regard for what it means to the future of human employment and human life, and into the purchase of politics and government. Talarico is not necessarily a man of the left, but he is a sentient liberal aware that our reigning plutocracy is a threat to both democracy and our livelihoods, and he has connected with a public that shares his belief.
Beneath the backlash against Trump and all his works, beneath even the growing rage at our new-age oligarchs, the tectonic plates of American politics are shifting in the increasingly urban South. The Republicans’ anchor state is now a fuzzy purple, joining Georgia and North Carolina in what may prove to be a fundamental change in the American political landscape. Democrats, take heed.
Used with permission. The American Prospect, Prospect.org, 2024. All rights reserved. Click here to read the original article at Prospect.org.
Click here to support The American Prospect's brand of independent impact journalism.
Pledge to support fearlessly independent journalism by joining the Prospect as a member today.
Every level includes an opt-in to receive our print magazine by mail, or a renewal of your current print subscription.
Published November 13, 2026 7:17 PM EST
article
People wait to board an Amtrak train bound for New York City as it pulls into the station on September 20, 2026, in Lancaster, Pennsylvania. (Photo by Gary Hershorn/Getty Images)
WASHINGTON - Amtrack's ticket booking system is reportedly down Friday evening, as thousands of travelers across the U.S. deal with a nationwide FAA ground stop.
An error message on Amtrak's website while attempting to book a ticket on Friday, Nov. 13, 2026.
What we know:
Users on social media started sharing frustrations over ticket reservations Friday afternoon, with travelers showing error messages on Amtrak's website and app.
Hundreds of users have reported issues on DownDetector , beginning shortly before 5 p.m. Friday, with another surge just before 6 p.m.
What they're saying:
In response to a request for comment, Amtrak's Communications Director W. Kyle Anderson said that "Amtrak service is operating normally, and we are seeing increased demand for travel across our network."
Responding to a frustrated customer Friday, Amtrak officials said in a post on X that the booking issues were related to a system-wide update, but did not elaborate.
FOX 5 DC attempted to call the support number listed with the error message. An automated message said officials were unable to take calls due to "unusually high call volume."
The backstory:
The outage comes as thousands of travelers across the country are scrambling for new plans, after the Federal Aviation Administration issued a nationwide ground stop — the first since January 2023 and just the second since the Sept. 11, 2001, attacks.
The FAA has said that the ground stop was ordered due to a "temporary telecommunications outage."
The Source: Information in this story is from social media posts commenting on the ticket booking outage, error messages on Amtrak's website and app, phone calls to Amtrak's support and media relations lines and previous FOX reporting on the Federal Aviation Administration's nationwide ground stop.
The old rule of American politics was simple enough to fit on a cheque: the candidate with the most money wins. On November 3, 2026, voters in some of the most expensive races in American history tested that rule — and, in race after race, broke it. (Results cited here reflect November 7, 2026, with a few races not yet called; official certification follows later.)
This was not a narrow or regional verdict. Democrats took control of both chambers of Congress. But the most instructive results were not in the safest blue states. They were in the South, in Texas, in Georgia, in Kansas — places where money, incumbency and habit were supposed to be decisive, and where voters chose something else.
Start with the three governorships that, taken together, answer the question of whether the South can change.
In Georgia , former Atlanta mayor Keisha Lance Bottoms , a Democrat, defeated Republican businessman Rick Jackson and became the first Black woman ever elected governor of any U.S. state — also Georgia’s first woman governor, its first Black governor, and its first Democratic governor since 1998. The Associated Press count put her at about 54.3% to 45.7%.
In Texas , state representative Gina Hinojosa , a Democrat, defeated three-term Republican Governor Greg Abbott , who had been in office since January 2015 and was seeking a record fourth term. She becomes Texas’s first Latina governor and its first Democratic governor since Ann Richards left office in 1995; no Democrat had won statewide office in Texas since 1994, the longest such drought in the nation.
In New Mexico , in the broader South and Southwest, former Interior Secretary Deb Haaland , a Democrat and a member of the Pueblo of Laguna, became the first Native American woman elected governor of a U.S. state.
Black, Latina and Native women, in other words, did not merely run in the South. They won its governorships.
The Senate map told the same story in a different register. In Texas, state representative James Talarico , a Democrat, defeated Republican Attorney General Ken Paxton — the first Democratic Senate election victory in Texas since 1988. In Kansas , Democrat Adam Hamilton defeated Republican incumbent Roger Marshall, 50.9% to 46.1%, the first Democratic Senate win in Kansas since 1932. Democrats also flipped Senate seats in Iowa, North Carolina, Ohio and South Carolina.
Florida did not flip, but it moved sharply blue: the governor’s race narrowed from a 19.4-point Republican win in 2022 (59.4–40.0) to 50.0–48.7, and the Senate special from a 16.4-point win (57.7–41.3) to 50.9–48.0 — shifts of about 18 and 13.5 points toward the Democrats. Oklahoma did not flip either, but its Senate race narrowed from a 32-point Republican win in 2022 (64.3–32.1) to 57.3–39.2 — a shift of about 14 points toward the Democrats.
The second lesson is about the instrument money buys most directly: advertising.
Voters arrived at this election already sceptical of the medium. A 2026 survey analysis reported that 51% of potential voters named social media as the top source of fake or misleading information, while a mid-year trends report found 87% of likely voters questioning the credibility of campaign messaging. Those are attitudes, not proof that any particular ad failed — but they describe an electorate primed to discount a paid message, especially one that arrives in saturation.
That is what saturation looked like in 2026. OpenSecrets projected total spending for the midterms at a record $11.9 billion , against $8.9 billion in 2022. Outside spending alone was projected at $3.9 billion , up 85% from $2 billion in 2022, and dark-money contributions had already reached a record $1.47 billion , above the $1.35 billion record set in 2024 — a presidential year. Elon Musk had given about $445 million to federal committees, including $215 million to his own America PAC.
And yet, in the races where the spending was heaviest, it did not buy the result.
Georgia. Jackson, founder of the healthcare staffing firm Jackson Healthcare, put more than $200 million of his own fortune into his campaign — the largest self-funding figure ever seen in a Georgia governor’s race — and lost by roughly eight to nine points. One pre-election accounting put pro-Jackson airtime at nearly $76 million in the general election against about $8 million for Bottoms and her allies. The money did not merely fail to persuade; at that scale, it became the story, and the story was a billionaire trying to buy a statehouse.
Texas, governor. Abbott spent $100 million defending his governorship. He lost it.
Texas, Senate. OpenSecrets, analysing Federal Election Commission data through October 13, found that outside groups had spent $130.4 million opposing Talarico — the largest amount spent for or against any single candidate — against only about $14.1 million supporting him. The Senate Leadership Fund alone, through its Texas PAC affiliate, had spent $181 million on the contest since September 11, with Musk’s money flowing into that effort. Talarico won anyway, and made the spending itself an issue, running an ad accusing Musk of trying to buy his own senator.
Michigan, Senate. Outside groups spent $92.4 million opposing Abdul El-Sayed . In the primary, groups aligned with the American Israel Public Affairs Committee (AIPAC) and others poured more than $60 million into advertising supporting his rival, Representative Haley Stevens, or opposing him. El-Sayed beat Stevens by about a point, 48.5% to 47.5%, and then beat Republican Mike Rogers in the general election, about 53.6% to 46.4% in the Associated Press count.
Ohio, Senate. The third name on OpenSecrets’ list, Sherrod Brown, faced $110 million in outside opposition. He won too. Together, the three Democrats — Talarico, Brown and El-Sayed — absorbed more than $330 million in outside opposition, nearly 14% of all outside spending in federal races to that point, and all three won.
New York City, a year earlier. The pattern did not start in 2026. In the 2025 Democratic mayoral primary, super PACs spent $26.7 million supporting Andrew Cuomo or opposing Zohran Mamdani — $18.4 million in direct support and $8.2 million in opposition — while pro-Mamdani PACs spent just over $1 million supporting him. Mamdani won the primary by 12.8 points after ranked-choice tabulation, and then won the general election despite more than $40 million in super PAC support for Cuomo.
This is the sense in which the spending “failed.” It did not fail to be spent, and it did not fail to be heard. It failed to do the one thing it was bought to do: stop these candidates. In Georgia, Texas and Michigan, the heaviest-spent races produced the opposite of the spender’s intention.
That resentment is the fourth lesson, and it concerns the groups doing the spending.
Special-interest money has always been defended as speech. In 2026 it increasingly functioned as evidence — evidence about the candidate it was spent for. When a single donor gives $445 million in one cycle, when a Senate leadership fund spends $489 million, when a billionaire puts $200 million of his own money into a governor’s race, the spending stops being background and becomes a character in the campaign. Opponents no longer have to argue that the money is corrupting; they can simply name it, show the cheque, and let voters draw the inference.
How many progressives were elected, and what is the total now?
Progressives, House: The Congressional Progressive Caucus had 101 members as of September 25, 2026–99 voting House members, one non-voting delegate, and one senator, Bernie Sanders of Vermont — making it the second-largest Democratic caucus in the House. Pre-election analysis projected that, if all 23 progressive primary winners won the general election and joined the caucus, it would grow by eight, offsetting fifteen departures through retirement, defeat or runs for other office. That is a bloc, not a majority — and in a closely divided House, a bloc that votes together can matter out of proportion to its size, as the House Freedom Caucus has long demonstrated on the other side.
This next claim is one the numbers can support only indirectly, and it should be stated as what it is: an inference from the pattern, not a line item in a filing.
None of the winning campaigns above won on advertising. They won on the thing advertising is supposed to substitute for: people, organised, in a place, over time. Mamdani’s campaign was built on small donors averaging $88 and on volunteers who turned each escalation of billionaire spending into a fundraising clip within hours. Talarico turned Musk’s $445 million cycle into a one-minute ad about a billionaire buying a senator. El-Sayed survived $60 million in primary opposition by naming it directly and daring the spender to “come for me.”
That is why the prescription that follows from this election is not “spend more, better.” It is: start the grassroots networking for 2028 now. Not in 2027, not after the next fundraising quarter, but now, while the volunteers from 2026 are still organised and before the next cycle’s money has had time to define the race. The advantage of a grassroots network is that it compounds; the disadvantage of a television buy is that it evaporates the day after it airs. The 2026 results suggest voters can now tell the difference.
Congress, now under Democratic control of both chambers, should pass bills on the subjects the electorate actually cares about: affordability and the cost of living, healthcare coverage, and the economic security that dominated the 2026 campaign. It should pass them without regard to whether President Donald Trump will sign them, because he will not. He will veto them.
That is the point. A veto is not a failure of the strategy; it is the strategy’s second act. Each veto should be publicised — which bill, what it would have done, who voted for it, and whose signature stopped it — so that, over the two years to the 2028 election, the pattern becomes impossible to miss: Congress delivered, the presidency blocked. By the end of that period, the argument for the presidency is no longer abstract. It is a list.
This requires one piece of candour. A veto override needs two-thirds of both chambers, which Democrats do not have. These bills will not become law in 2027. Their value is as a public record and as a campaign: proof of what a Democratic presidency would sign, demonstrated bill by bill rather than promised in the abstract. Anyone who sells this as a legislative programme is misleading the reader; as a political programme, it is coherent, and it is the only one that turns a midterm majority into a presidential argument without pretending the veto does not exist.
Perhaps this is the first clear sign that the amount spent on elections did not scale with votes — quite the contrary. The myth — that American politics cannot change because of money — has, for the first time in a form voters can see and count, been tested against the evidence and found wanting. Knowledge, organisation and a candidate voters trust beat a chequebook. The task now is to build the organisation before the chequebook gets its next chance.
shasum -c
works next to a download.
White Sands National Park has the largest collection of fossilized human footprints | National Park Service
Most humans walk without thinking too much of it. We put our foot down, heel first , and keep moving. But new work suggests this adaptation could be a uniquely human trade-off.
A team of researchers captured high-speed, high-resolution videos of three chimps walking along a runway and analyzed existing walking data from 18 other chimps. When the animals walk on all fours, the team found, their foot position is variable—they might land heel first or touch down closer to their little toe. But when the chimps walk upright, they tend to favor midfoot strikes. In comparison, nine human study participants consistently walked heel first.
Other research on bonobos and orangutans suggests that those animals don’t consistently walk heel first. In fact, no other biped is known to walk that way, implying that “walking with a heel strike is a uniquely human thing,” says Pennsylvania State University and University of Buffalo anthropologist Nicholas Holowka, lead author of the study, published in Proceedings of the National Academy of Sciences USA .
The researchers then measured the impact forces on both humans’ and chimps’ feet and found a higher impact force with heel-first upright walking than with midfoot-first. But humans gained a measurable benefit from this movement strategy, too: walking midfoot first used 26 to 41 percent more energy than a heel-first gait.
Neelima Sharma, an evolutionary biologist at University College London who was not involved in the research, finds it interesting that human walking prioritizes energy savings, in contrast to running, during which humans typically avoid a heel-first stride “because your joints would be under much more impact force.” When we run, the peak load on the knee can be up to three times higher than it is while we’re walking .
By digging into the fossil record, the researchers tracked widening heel bones and growing lower-limb joints in bipedal human ancestors, beginning about three to four million years ago. By around two million years ago hominins consistently had wider heels and joints. Along with attributes such as longer legs and a modern pelvis, “the ability to heel strike safely is part of this suite of features that appears around two million years ago,” Holowka says. This time period also marks the emergence of hunting and gathering, with its long, energy-intensive journeys.
The human heel bone is the largest and “most remarkable bone in the foot,” says biomechanist Ali Yawar, who was not involved in the work. “We should look at our heel and think of it as what makes us, among many other things, uniquely human.”
is a biologist turned science journalist. She loves writing about interesting creatures on our planet. Subrahmanyam received a Ph.D. from the National Center for Biological Sciences at the Tata Institute of Fundamental Research in India. Follow her on X (formerly Twitter) @rohsubb and on LinkedIn , and see her portfolio here .
Founded 1845, Scientific American is the oldest continuously published magazine in the United States. It has published articles by more than 200 Nobel Prize winners.
Scientific American covers the most important and exciting research, ideas and knowledge in science, health, technology, the environment and society. It is committed to sharing trustworthy knowledge, enhancing our understanding of the world, and advancing social justice.
Sign up for the Scientific American daily newsletter.
Anthropic has updated Claude Code Projects with proactive coordinator messages, read-only thread sharing, reminders, branching commands, and improved artifact navigation. The changes reduce the monitoring required when several cloud sessions work in parallel.
Each project is a long-running conversation with a coordinator that assigns work to threads. Every thread runs as an independent Claude Code cloud session with its own repository copy and Git branch. The coordinator directs the project from thread reports, while overlapping code changes surface as standard Git merge conflicts when branches are combined.
The coordinator now answers questions directly in project chat and posts status updates as threads progress. Previously, developers had to monitor the thread list to find sessions waiting for input. The updated behavior brings pending decisions, completed tasks, and blocked work into the main conversation.
Individual threads can now be shared through read-only links with anyone signed in to Claude. A developer can open the thread menu, select Share , and send the generated URL without exposing the rest of the project.
Threads that accessed a local computer remain unshareable. The restriction prevents shared transcripts from exposing local file contents, shell output, or other machine data gathered during the session.
The two slash commands were already available in regular Claude Code sessions. Their addition to Projects brings the same branching workflow to coordinated, multi-thread work.
The threads panel now places recently opened, updated, and pinned threads in a row at the top. Each thread can also display thumbnails for generated documents, diagrams, and other artifacts, with the previews controlled through view settings.
The redesign simplifies project settings and local-folder access as well. Anthropic has released the changes on the web, desktop clients, and the latest mobile app.
Anthropic introduced the public beta on September 17 for Pro and Max subscribers who joined the waitlist. Team and Enterprise plans remain unsupported. Eligible subscribers who lack access can still join the waitlist .
Projects carry no separate fee, but every worker consumes the subscriber’s existing Claude Code allowance. Anthropic limits accounts to 200 new threads per day across all projects. A thread that reaches a usage limit pauses and resumes automatically when capacity becomes available.
Project usage appears separately in the usage controls, and developers can choose the model and effort level for the coordinator and worker threads. New projects default to Opus for both roles, with low effort for the coordinator and high effort for workers. Several high-effort sessions running at once can exhaust plan limits faster than a single Claude Code session.
Projects fit engineering work that can be divided into independent tasks and reconciled through branches and pull requests. Anthropic’s examples include:
Tasks with strict dependencies still require developers to sequence pull requests and resolve conflicts. Projects also remain cloud-only and limited to Claude Code, while parallel workers draw from the same plan limits. Small changes that fit one branch and one context window generally consume fewer resources in a regular Claude Code session.
In 2003, Philip Roth turned 70, a strange age for an enfant terrible. To his early admirers, Roth meant chutzpah, rude energy, sly comic mischief. Slowly, improbably, that changed. Roth’s work deepened. Awards piled up. Respectability—the fate of all successful rebels—followed. By 2003, Roth had come full circle: The rebel was revered; the iconoclast, an icon.
And so, celebrations were planned, tributes drafted. Generally, Roth shunned interviews—he preferred silence, exile, and cunning—but this time, he welcomed a BBC camera crew to his spare, wood-paneled studio (“where I really wish I lived,” he once said). As winter light streamed in, he serenely answered questions from a friendly inquisitor: The New Yorker’s David Remnick.
Theirs was a subtle yet strong rapport. Beneath Remnick’s customary poise, his deliberate, thoughtful air, was an intense, fervent devotion. Growing up, he worshipped Roth. He had read Portnoy’s Complaint around twenty times (a novel about compulsion, devoured compulsively). He seldom traveled without packing one of Roth’s novels in his luggage.
When Roth’s biographer, Blake Bailey, was accused of sexual assault, Remnick worried about Roth. Would his prestige decline? “What a shame that would be,” he told Cynthia Ozick. Some years earlier, Remnick favored his “favorite living writer” with an open invitation to the New Yorker. “You’re mine (favorite, that is),” he told Roth.
In publishing, such flattery is hardly unusual. Editors cultivate writers. It’s an art form practiced shamelessly and vigorously. Roth, for his part, thrived on praise, and tended carefully to his career. To some degree, Remnick’s flattery speaks to the transactional nature of journalism.
Still, their long partnership might surprise people, even veteran Rothologists, who pour over Roth’s marginalia and plunder his archives for hidden treasures. Over a decade, as I toured Rothworld—visiting archives, quizzing scholars,pondering Roth’s friendships—I kept brooding over Roth and Remnick. There was an obvious story about literary power—who wields it, and how. A story about fandom—its pleasures and risks. Soon enough, a third story, with less obvious contours, began to emerge—in some ways, a cautionary tale.
Theirs was a fruitful if complex alliance. In 2000, Remnick attempted to profile Roth. “Truth is, I probably should have written about something else, anything else,” Remnick later said. Having courted Roth, he wrote cautiously—“maybe that made the whole thing untrue,” he fretted. Soon, though, such worries vanished. Remnick and Roth continued working together, eventually producing enough pages to fill three-quarters of a New Yorker.
At times, their partnership took unusual forms. When a critical biography of Saul Bellow appeared, threatening Bellow’s reputation, Roth was furious. (“Bullshit,” he wrote in his galley. “PURE IDIOCY.” “No! No! No!”) To undermine the book—to counter its portrayal of a selfish, womanizing dandy—Roth turned to Remnick, who cleared space in the New Yorker for an interview with Bellow.
Indeed, when Roth needed a platform—to honor Bellow; to dispute a Wikipedia entry—he turned to Remnick. “Just know,” the editor told him, “these pages are as open as can be to you.” And so they were, and would remain, until Roth’s death.
In a way, it seems ordained. Two smart, bookish Jewish boys, sons of New Jersey, who found their vocation early. When, in 2003, Remnick trekked to rural Connecticut, he was following a Rothian plot. In The Ghost Writer, Nathan Zuckerman meets his hero, L. I. Lonoff, a famous literary recluse. In real life, Remnick approached Roth with nervous teenage excitement. “One of my great heroes, I got to meet,” he said of their first encounter in the 1990s. “It was like meeting Lou Gehrig.”
Though different in temperament, their backgrounds rhymed. Remnick, a dentist’s son, and Roth, whose father sold life insurance, both came from secure, close-knit Jewish homes. Both absorbed Yiddishkeit, the atmosphere of Jewish home life. (For both, Chazerai—trashy food—was strictly forbidden. Roth’s mother spat the word with disgust, while Remnick learned it from his great aunt—“the half-baked Dietician of Coney Island.”)
Roth’s Jewishness was secular but deeply felt; he was obsessed with Jewish wounds, Jewish history, and, not least, Jewish responses to his writing. Remnick, also secular, wore his Jewishness lightly without ever denying it (“a Malawi tribesman could take one look at me and say, ‘This man is a Jew’”). His Jewish passions focused on literature and Israel. In time, he came to despise Israel’s illiberal right-wing tendencies.
Both men contained multitudes. “I lead a tidy life,” Roth once wrote, “but have a strong taste for disorder and its excitements.” Likewise Remnick, who enjoyed boxing and politics, and whose pulse quickened to deadlines and scoops. Both were liberals with a conservative streak. Roth deplored crude American philistinism, while the younger Remnick mocked his generation’s vulgarity and hollow ambition.
Each crafted a public image—Roth especially. But Remnick also had “my bullshit”—charming, polished stories about his life and career. “It’s all true—or true-ish,” he once said. This wasn’t lying, he thought, merely “what we do in life.” Some of his favorite writers, from Roth to Walt Whitman, had this quality of performance. Yet he was earnest—indeed, pious—about literature and language. He and Roth were idealists.
There, perhaps, the similarities ended. Roth was an individualist; Remnick adapted easily to institutions. Roth wrote slowly, with great precision; Remnick wrote easily, with phenomenal speed. (As a foreign correspondent, he sometimes filed several stories a day.) When Roth let loose, his comedy reached zany, demented heights. Not so Remnick. He had the calm self-possession of a man who long ago tamed his spikier impulses.
Long before they met, Remnick knew Roth like the rest of us: as a reader. “I was a Jewish New Jersey kid reading [Portnoy’s Complaint] and discovering this thing,” he said. It happened in, of all places, a church basement book sale. (“Fifty cents, I spent on it,” he said.) That was it, the gateway drug, leading to Goodbye, Columbus and the rest. “Philip Roth was like finding home,” he recalled. At the same time, Roth was “utterly exotic” to a callow high schooler.
Over the years, Remnick’s admiration deepened. He loved Roth’s wacky baseball satire, The Great American Novel. He considered The Counterlife “a modern classic on the theme of Jewish rootlessness.” He dreamed of meeting “the master,” and when an opportunity arose, he was agog. “I hope and pray he will call,” Remnick told a friend, vowing “not to hock him about signing my thrice read Counterlife .” But providence didn’t intervene. (“Alas, no sign of Roth,” he sighed.)
Indeed, he had to wait several more years, but after that, Remnick sometimes resembled Roth’s Zelig. He attended Roth’s 60th birthday party. He interviewed Roth before his 70th. He cheered for Roth at the Philip Roth Society’s “Roth@80” celebration. He was among the mourners at Roth’s burial, a private ceremony for friends and family.
As Remnick’s early devotion increased, Roth’s ties to the New Yorker gradually frayed. He published little in the 60s, though he remained a loyal reader throughout William Shawn’s editorship. When Shawn’s replacement, Robert Gottlieb, was fired, Roth was disgusted. “But Shawn is certainly dead and so is the New Yorker,” he told friends. He couldn’t believe Tina Brown, of Vanity Fair , was taking over. “This woman sees the world through the lens of CELEBRITY, and that’s the death of everything.”
Roth and the New Yorker went back decades. The young Roth drew confidence when his provocative story “Defender of the Faith” was published. But the magazine proved fickle. “We love this first section of Philip Roth’s novel,” an editor told Roth’s agent in 1961 before rejecting the story. Chapters of Portnoy’s Complaint were declined; they wound up in Esquire , New American Review , and an unusually popular Partisan Review issue. The editors “didn’t care for my stuff,” Roth assumed. He wasn’t wrong. In simple terms, Roth’s intense, seething novels didn’t suit the genteel, decorous New Yorker .
Luckily for Roth, new editors, long-time admirers, arrived. “Welcome back,” the editor Veronica Geng wrote Roth, accepting The Ghost Writer , his near-perfect novella. As the story goes, Geng strode into William Shawn’s office flourishing the manuscript (“We should publish the whole thing”). That did the trick. To Roth’s delight, The Ghost Writer ran in its entirety, with Shawn’s enthusiastic blessing.
Around that time, several states away, a precocious Remnick bounded into journalism, eager and ambitious. “The thing I always dreaded in life,” he once said, “was waking up in the morning and not knowing why I was doing what I was doing.” At the Washington Post , he covered everything from crime to boxing to book publishing; he was a vapor trail with a notebook. “You will go as far as you want to go in this business,” the Post’s legendary editor, Ben Bradlee, told him.
Beneath his calm, steady demeanor, Remnick was intense, with sharp instincts and a keen alertness. Reporting from Russia, he worked tirelessly, filing stories by phone and Telex. He sometimes clashed with his editors (“his precocity sometimes masks an understandable immaturity,” one editor noted), but his talent was obvious. Remnick wanted a Pulitzer, and expected one. “I suppose it’s dark Jewish neurosis, but I somehow feel like I lost something,” he sighed when his Pulitzer went to a rival (at the New York Times, no less).
Pulitzer aside, Remnick was highly regarded. (“He, although on the young side, is considered the hottest, etc.,” the publisher Roger Strauss noted.) Some reporters are brilliant fact-finders; others write stylishly, with literary flair. Remnick had both talents, and could adapt himself to any situation. After joining Tina Brown’s “hot” New Yorker , he profiled Howard Stern and Dennis Rodman. When, in 1998, Brown jumped ship, Remnick took over. “I had never edited anything ,” he later said. “I was an absolute novice.”
Truth be told, he was already an editor. (“He edited pieces. He edited some of my pieces,” Hendrik Hertzberg recalled.) He was also a consummate office diplomat. Under Brown, he pulled off “an amazingly skillful political high wire act,” a colleague said. Somehow, he pleased Brown, served her vision, and impressed her detractors. He possessed an easy humor, a practiced modesty, and a confidence befitting his stature.
Vaulting from Brown’s inner circle into the editor’s job, Remnick projected humility. He was merely “impersonating the editor of the New Yorker ,” he told Roth. Meanwhile, he made the magazine his obsession, working frantically, voting yea or nay on every article, short story, and cartoon. That part was “agony,” he told Epstein: “one begins to feel like a decision-making machine.”
One decision, however, was simple: publishing Roth. After 1979, Roth again vanished from the New Yorker . That was understandable—he seldom published short stories anymore. Yet his absence was striking. One of the country’s finest authors wasn’t writing for its most storied magazine.
Remnick sought to rectify that. By chance, Roth’s latest novel, I Married A Communist , was in galleys. It was a fine book, hardly Roth’s best, but Remnick found it “absolutely, bottomlessly fascinating.” That week, he spiked the short story his editors had selected and published Roth instead. “Even if this madness ends in a week,” he told Roth, “I’ll have published something—someone—supreme.”
Remnick was amazed. The editor’s powers were vast. There were no meddling owners or advertisers. “This is really cool!” Remnick thought, instructing his fiction editor, Bill Buford, to work closely with Roth. (He agreed, writing Roth “in some haste” about an excerpt.) In matters of taste, Remnick was utterly confident, and he slowly recast the magazine. More politics. More arts criticism. Fewer glitzy profiles. His control was “really quite breathtaking,” he said. He welcomed back Woody Allen, a personal favorite.
Even as he reshaped the magazine, Remnick avoided any perception of favoritism. “It would be insane for the editor of the New Yorker to name favorite writers,” he told a reporter. That same autumn, he reached out again to Roth. “I suspect an editor of the New Yorker… is not supposed to have a favorite living writer,” he wrote, imagining people’s objections. “Too bad,” he wrote. They were free to find it “indecent, indiscreet, unfair, vulgar.”
Of course, Remnick wasn’t only wooing Roth. Joan Didion loved Remnick’s “fantastic extravagant gift”—a large shipment of caviar. Saul Bellow had to settle for flattery. “The truth is I’ve always thought it was wrong, criminal really, that the New Yorker published so little of you,” Remnick told Bellow. As an editor, Remnick had a remarkable gift for channeling writers, matching their moods, fostering kinship. “What can I tell you?” he wrote Roth, sharing boyhood memories of shabbos lights and spitzel. “I was raised on a rhetoric not unfamiliar to you.” He complained about “the misbegotten Netanyahus”—an opinion he thought Roth would share.
That September, at long last, a private meeting was scheduled. Although Remnick had acquired an aura of power and celebrity, he felt like an eager schoolboy. That day in New York, an “awestruck” Remnick greeted Roth at the New Yorker’s offices. For fifty minutes, they did what writers do when they meet: chat amiably, while quietly sizing each other up.
At first, Remnick was rattled—“you knew that there was not one goddamn thing lost on him.” Indeed, Roth was a fierce listener; he could bore into you with his attention. That day, Roth discussed Clinton/ Lewinsky. (“His dark, expressive eyes were deadly serious.”) In lighter moments, the room filled with laughter and convivial complaint. “Why don’t you get a bunch of novelists to write about this?” Roth suggested. Journalists were hacks, he said. Novelists were adults. They understood betrayal and human desire.
In fact, Remnick already agreed. Earlier that month, he bashfully sent Roth a proposal: might he “review” the Kenneth Starr report? It seemed possible, given Roth’s interest in Clinton, and, more generally, adultery, that he would bite. “Oh, hell, please don’t blame me for asking,” Remnick added. That didn’t entice Roth, but Remnick persisted. “Rumor has it you have finished something called The American Stain,” he wrote Roth in 1999, hoping to score an excerpt. “My book is called The Human Stain ,” Roth replied, and warmly agreed to share a copy. By that point, Remnick was signing his letters “Yours always.”
As Remnick hoped, their letters grew warmer and looser. Having won Roth’s trust—no small accomplishment—Remnick proposed a bolder idea: a full-length profile of Roth. Since the 1960s, there had been few, notably Life magazine’s article, “A Comedian of Guilt,” written at the height of Portnoy-mania. But its author, Albert Goldman, was a personal friend and confidante.
At first, Roth had misgivings. He disliked—really, scorned—literary journalism. He resisted attempts to wrest control of his story. (Which was, after all, his material, grist for his novels.) Long into adulthood, Roth was bedeviled by the competing needs of adolescence: to be left alone, and to be understood. A part of him favored seclusion. Another part sought attention, the better to explain himself and his writing.
For his part, Remnick was a seasoned profiler. He veered toward figures of pathos—aging athletes, defeated politicians—and shape-shifters like Bob Dylan and Bruce Springsteen. Like all good profilers, he leaned on classic plots, familiar stories. (“Mostly, they are the same stories over and over.”) He was a sharp and pitiless observer. He captured Al Gore’s flickering smile (“Gore smiled. Then he un-smiled”). He noted Tony Blair’s “Halloween rictus…a practiced yet futile attempt to mask embarrassment or anger.”
But even a shrewd, confident profiler would find Roth difficult. For one thing, Roth had secrets: his health, his depressions, his romantic life. There’s no harder subject than a fiercely private person, except, perhaps, a private person prone to mischief. As Roth teased readers, he toyed with journalists, feeding them half-truths and coy evasions. In one interview, Roth claimed to be a Mossad agent, while the reporter—who happened to be Remnick’s wife, Esther Fein—slowly came around to the impish conceit.
In the event, Roth soon relaxed around Remnick. Before long, he was lightening the mood with impressions of Harold Pinter and Mike and the Mad Dog, the sports-radio kibitzers beloved of New York commuters. Remnick was aware that “Philip Roth doing shtick in a car” was a performance—for him, yes, but also his readers. Roth was a savvy subject “who didn’t just fall off the publicity turnip truck.” Meanwhile, Remnick employed “all the strategies involved” to keep his subject talking (“acting dumb, not quite going away…”). It was all part of “this very strange transaction” between reporter and subject.
The result, published in May 2000, was a remarkable snapshot, shrewd, revealing, yet somewhat mythopoetic. It nimbly avoided Roth’s divorces, his troubled friendships, but didn’t skirt Roth’s depressions and physical breakdowns.
Above all, it captured a moment:
Roth is no longer the wunderkind; he is sixty-seven, and the books reflect it.His voice isstill charged,anendlesslypliable instrument of comedy and impersonation, but that voice has also darkened, its comedy is deeper, the story it tells is more tragic and painful.
It also captured something more elusive: Roth’s powerful charm, a curious blend of humor and sternness, aloofness and intensity. Throughout his life, people adored and forgave Roth—the special grace we grant those who relieve us of life’s boredom. In Remnick’s profile, Roth’s electric current, his ability to charge the air around him, was captured brilliantly.
If the profile was a success, it was also something less. At one point, Remnick describes a simple, spartan life, utterly sealed off. (“Nothing gets in,” Remnick writes of Roth’s studio.) Like the legend of an isolated Thoreau, this was an exaggeration. Outside his studio, Roth saw friends, had affairs, and, that spring, was interviewed by CBS Sunday Morning and the New York Times Book Review . And he traveled. As Remnick notes, Roth took the Concord to France for a multi-day festival, “The Roth Explosion,” where he mingled with thousands of fans in lovely Aix-en-Provence.
Equally dubious were the well-polished stories from Roth’s vault. 1959: A furious rabbi demands, “What is being done to silence this man?” 1969: Jacqueline Susann tells Johnny Carson that she admires Roth, “but wouldn’t want to shake his hand.” 1962: Roth, speaking at Yeshiva University, is harassed, and practically ambushed, by angry students. “That night at Yeshiva was a slaughter,” Remnick wrote.
Wonderful stories, all. Yet few would survive later scrutiny. Take the Yeshiva incident. “Roth was thus less victim than star of the evening,” claims Steven J. Zipperstein, a Roth biographer. As for that rabbinical fatwa—“What is being done to silence this man?”—it, too, is suspect. Maybe it happened, maybe it didn’t; in the end, we just don’t know. Unfortunately, we have only one source: a 1963 essay by Roth. Beyond that? Nothing.
At various times, Remnick’s profile has an air of credulity common to journalists who have gotten too close to their subjects. Even the famous Jacqueline Susann story is slightly off. It was comedian Flip Wilson who interviewed Susann. Johnny Carson had the evening off.
How common were Remnick’s mistakes? Extremely common. A profile is, in a sense, a first draft, subject to later revision by scholars. (“I’m a journalist—I’m not Robert Caro,” Remnick once said.) Indeed, Roth’s Yeshiva fable was widely repeated in journals, magazines, even his New York Times obituary.
The obvious lesson is for greater skepticism. The first rule of literary journalism might be: never trust a novelist about his personal life . That went double for Roth. “I say one thing to David, and I say one thing to you,” Roth told Robert Siegel, the NPR reporter, who interviewed them both. When Siegel shared that story with Remnick, both men laughed.
There was an irony to these mistakes. Error, misjudgment—this was Roth’s subject. “The fact remains,” he wrote in 1997, “that getting people right is not what living is all about anyway. It’s […] getting them wrong and wrong and wrong.” It was a belief Remnick shared. “Writing is about getting it wrong,” he said in 1998, “over and over and over again.” Remnick, working quickly, often made mistakes, relying on fact-checkers as a safety net. “I don’t know about you,” he once said, “but I make a lot of mistakes.” It was something he harped on. “It’s stunning how many mistakes you make.”
Whatever its flaws, the profile shows how Roth’s public image was shaped. Roth had vented his woes: bad health, bad marriage, bad reviews. That fed the conceit Remnick supplied: an embattled writer’s triumph. Roth had managed “to pull himself out of [crisis] and onto a plane of mastery.” He had resumed writing “with greater concentration than ever before.” Crisis and renewal. Suffering and redemption. In Remnick’s hands, Roth’s story acquired mythic overtones.
One wonders, though, what other stories were possible. Life supplies myriad plot lines; in journalism, a few are chosen, woven together, and the rest are discarded. What “facts” pass through the reporter’s sieve are invariably the ones that serve a chosen narrative. Roth knew this, which is what made him such a powerful narrator of his own life. But such stories are necessarily incomplete, and, at worst, misleading.
As it happens, Remnick was well aware of this. In a sense, he had delivered what Roth wanted: a smart and admiring portrait free of moral judgement. Roth read it; his friends read it; everyone liked it. Everyone, that is, except Remnick.
“Truth is, I probably should have written about something else, anything else,” he confided to Barbara Epstein. Normally, Remnick relished publication, but now he felt uneasy. He didn’t really know Roth. He had ignored Claire Bloom, whose memoir alleged mistreatment and deceit.
Ignoring her was his choice—“but maybe that made the whole thing untrue,” he now worried; “I don’t know.”
It’s hard to read this without wincing. Truth, after all, is everything, a writer’s north star. “I think […] you have your ambivalences about him,” he told Epstein, suggesting he might, too, if he knew Roth better. As things stood, he was glad not to. He had avoided “the marriage minefield.”
Remnick’s letter is a curious document. It suggests a process of reasoning hidden to readers, and perhaps to Remnick himself. Why hadn’t he quoted Bloom? Or reported rigorously? Obviously, there was much at stake: Roth’s trust, his affection, his future with the New Yorker . Remnick had worked hard to cultivate Roth; now that was in jeopardy. Plainly, he had less avoided a minefield than stumbled into one.
It was a minefield familiar to literary journalists. When profiling authors, one often learns secrets, things you wish you didn’t know. What then? In theory, it’s all fair game. In practice, such inconvenient facts are often discarded, and the problem goes away. This happens often with information that’s puzzling or offensive, and which, if published, would upset the subject and his admirers. Such quandaries test one’s integrity—a test most journalists flunk at one time or another.
Remnick’s profile has an easy, confident air, a steady voice, and great authority. His letter shows how that effect was achieved: by limiting its scope and avoiding “minefields.” In the end, Remnick chose caution—a partial portrait. And his decision paid off.
“So good on Philip R.,” Epstein cheered. “He has to like it.” Indeed he did, and the partnership flourished. For the next 18 years, Roth published in only one magazine: Remnick’s New Yorker .
As a rule, Remnick didn’t befriend his subjects. “It’s kind of not kosher for me,” he once said. Philip Roth was “a happy exception”—happy for Roth, too. As they bonded over jokes and literature, they slipped easily into something resembling a friendship.
Soon it was Roth who proposed a New Yorker piece. Back in 1998, James Atlas was finishing his long-awaited biography of Saul Bellow. “The book is lively, intelligent, and as readable as it is thorough,” one reviewer wrote. Bellow’s admirers disagreed. Roth, who had acquired a galley, saw malice and rancor in Atlas’ portrait. He particularly hated “all that righteous, boring pseudo-p[s]ychiatric moralizing.”
And he worried about Bellow, whom he admired greatly. “Don’t look at the Atlas book,” he urged. As publication neared, Roth overflowed with protective advice. Be stoical. The best response was no response. “DON’T SHOW THE WOUND TO A SOUL,” he implored. “THIS IS THE DISCIPLINE REQUIRED.”
Biography has been called a small person’s revenge against a greater person; and that was Roth’s considered view. Disgusted, he threw considerable energy into sinking Atlas’s book. His plan was simple: he would interview Bellow, collect his answers, and have Remnick publish them—a preemptive strike. “Yours, not Atlas’s, should be the last word on what you’ve done,” he told Bellow. He would avenge Bellow in advance of the attack.
Remnick, who may have gleaned Roth’s motives, was eager to proceed. He certainly admired Bellow, whom he had wooed as a reporter. (“I’ve just consumed with relish your latest book,” he told Bellow; “the essays are just a delight in every way.”) On top of that, he disliked Atlas, whom he had fired from the New Yorker. (Remnick had been encouraging—“You work here, you belong here”—until the moment the guillotine fell.)
It was a reasonable plan, and, through no one’s fault, it didn’t succeed. Roth prodded Bellow to write, write. But Bellow, frail and scattered, couldn’t, or wouldn’t. “Saul tells me he’s working on my questions,” Roth wrote Remnick in fall 1999. “We’ll see.” Months passed; the calendar turned. Roth exhorted Bellow to finish. “If it is, we can then get it to Remnick for publication in the New Yorker in October.”
But the task proved futile. The interview never materialized. In a pinch, Roth drafted a long, appreciative essay about Bellow, which the New Yorker ran instead. “Remnick must know that he struck it rich,” Bellow told Roth, and indeed, the result pleased everyone. The piece appeared in October 2000, just before Atlas’ biography.
Having returned to the New Yorker, Roth again vanished. Neither The Human Stain (2000) nor The Dying Animal (2001) appeared in the magazine. Remnick still looked forward to Roth’s “periodic raids on Babylon,” when Roth might be available for dinner (conveniently, they lived around ten minutes apart), yet the men saw little of each other. For his part, Roth was tending to health problems and struggling with The Plot Against America. (“It wasn’t a book I wanted to write,” he told a friend, “and twice I abandoned it for a month and longer.”)
In winter 2003, Remnick trekked to rural Connecticut for their BBC interview. Since 1969, when a fame-bedeviled Roth fled New York, few journalists had visited his refuge or even seen photographs. Inside his writing studio were his stand-up desk, a large fireplace, and a long leather couch; outside were apple trees, manicured meadows, and his large clapboard farmhouse facing the woods.
With the cameras rolling, Remnick had a wonderful ability to elicit candor. When he asked why Roth devoted himself single-mindedly to writing, Roth seemed perplexed. Softly, he said, “I don’t know what else to do.” His eyes twinkled a bit sadly. “If it were taken away from me, I think I would die.” For a brief moment, Roth appeared uncertain and undefended. The interview aired the night of Roth’s 70th birthday.
By that point, Roth was entering a season of losses. Both his parents were gone, and his literary generation was thinning. In 2005, Saul Bellow died, and the New Yorker published Roth’s old interview (such as it was). Meanwhile, the pesky Atlas returned, now as Bellow’s public eulogist. “To read Atlas in three different venues, one dumber than the next, was at least something [Bellow] could miss,” Remnick wrote Roth.
For five years, theirs had been a fruitful partnership. Roth had been Remnick’s favorite writer, a New Yorker contributor, and a profile subject. Inevitably, the roles blurred, and two of them—literary hero and journalistic subject—were in obvious tension. That nobody cared, or even seemed to notice, was a mark of Remnick’s discretion up until then, and his reputation for decency and integrity.
Any conflicts of interest were soon resolved—somewhat. In 2010, Roth retired. From fiction, at least. In truth, he continued writing: long memos to his biographer; an angry rebuttal to Claire Bloom’s memoir; and a “hilarious screed” (in Remnick’s words) about Wikipedia for newyorker.com. Around that time, he foreswore readings. He was finished—finished!—with public events. He preferred “sequestered Salingerism” to “exhibitionistic Mailerism.”
Remnick’s admiration was still boundless. “He’s as good as it gets,” he told Charlie Rose. In 2006, Remnick read Everyman, Roth’s sober meditation on mortality, and was bewitched. (“If that had been available to us…we would have published it straight through.”) In an interview, Remnick was asked for his dessert island author: Roth, Bellow, or Updike. Easy. He loved Bellow, “but I grew up on Roth,” whose books “meant and mean everything to me.”
In 2013, Remnick attended Roth’s 80th birthday celebration at the Newark Museum. The following day, he recalled “the most astonishing literary performance I’ve ever witnessed.” After tributes by Edna O’Brien and Jonathan Lethem, the elderly Roth read confidently from Sabbath’s Theater. Remnick was transfixed. (“These were not his last words—please, not that!”) It was, for Remnick, an iconic moment—“a triumphal lope around the bases, like Ted Williams did on his last day in a Red Sox uniform.”
After the evening ended with birthday cake and champagne toast, Remnick rushed home to write. Appearing on newyorker.com the next day, his article had the zest and lyricism of deadline writing mixed with teenage wonder. “I saw and heard something remarkable just a few hours ago, something I’m not likely to forget until all the mechanisms of remembering are shot and I’m tucked away for good.”
Five years later, Roth was tucked away for good, felled by heart disease. He had prolonged his life through swimming, an abstemious diet, and numerous cardiac stents, but the end came swiftly. In Sabbath’s Theater, the rowdy hero considers burial in the quiet country. “But whom would he talk to up there? He had never found a goy yet who could talk fast enough for him.” A serious problem, given how long eternity could last. Eventually, Roth chose Bard College’s cemetery, where he had Hannah Arendt for company, and chose to be buried next to the eventual grave-site of his very-much-alive friend, the Romanian writer Norman Manea, so that he and Norman could “continue their conversations.”
At Roth’s funeral, a close circle of friends, including Remnick, watched his coffin lowered into the ground. Remnick was struck by the austere, secular service (“no Kaddish, no God, no speeches”). Later that week, Roth received a hero’s farewell in the New Yorker . In The Counterlife , Roth mocked pious, fulsome eulogies. “Where was the rawness and the mess? Where was the embarrassment and the shame?” A few places, actually, but not newyorker.com, where nearly a dozen grateful tributes appeared.
Remnick added his own eulogy. The Roth he remembered was indomitable (“Roth’s vitality never dwindled, particularly on the page”). He was a survivor who, after illness and divorce, “redoubled his sense of discipline and set himself free.” In Remnick’s eulogy, Roth acquired a purity, a saintliness. Here again was Roth as literary ascetic, “living alone in the woods,” shunning modern blandishments. In the literary pantheon, he ranked with Hemingway, Bellow, and Melville—“but he was funnier, more spontaneous, than any of them.”
Roth’s life had ended, but his afterlife was just beginning. According to Remnick, “Roth long resisted the idea of a biography,” then finally “relented.” In fact, Roth courted biographers, seeking a loyal, sympathetic Boswell, but every candidate, including Judith Thurman, had demurred. (“I didn’t think the friendship would survive,” Thurman said. “And I didn’t think I would survive.”) Later, Roth enlisted Ross Miller, his closest friend, but after two failed attempts, Roth gave up.
Around 2010, with time scarce, Roth made his final, fateful selection. To many, Blake Bailey seemed a strange choice: a midwest Gentile with a slick, to-the-manor-born mien. Could he understand Jewishness? Or working class Newark? Roth didn’t much care. “He doesn’t judge his protagonist,” Roth said after reading Bailey’s biography of John Cheever. “That is the kind of moral latitude I need in a biography.” It was that approach, and his just-us-guys bonhomie, that won Roth’s favor.
Biography has several tasks. In chronicling a life, it locates patterns, teases out meanings, and reveals someone’s layers, their human flaws. In so doing, it often complicates our feelings toward our heroes. Such was the fate awaiting Roth’s readers when Philip Roth: The Biography arrived.
How would Roth’s admirers react? Bailey, to his credit, didn’t ignore Roth’s darker side. He gives us Roth’s lechery (“I was forty and she was nineteen. Perfect”) and general selfishness with women. (“A mature woman wouldn’t take your shit,” Roth’s therapist says.) To balance the moral scales, Bailey emphasized Roth’s generosity and loyalty. In short, we get all of it: Roth’s anger, selfishness, and compulsive womanizing, but also his warmth, generosity, and menschlicheit .
Remnick’s review, which ran that April, and read like a mini-biography, struck a similar balance. It didn’t attempt to untangle Roth’s contradictions, but instead sketched a brilliant but confounding figure who can’t seem to separate from his problems, particularly those that fueled his writing. Though suspicious by nature, he seems unable to sever bonds of trust and dependence, even after profound betrayals.
Though written gracefully, with characteristic ease, the review has its awkward notes. In Remnick’s words, the young Roth was “determined to live unfettered.” Translation: he shunned marriage and monogamy. As a middle-aged professor, Roth “availed himself of what he viewed as the perquisites.” In simple English, Roth slept with his students. At times, a protective note creeps in. We’re reminded of Roth’s “remarkable service” to writers and his “many close and enduring friendships with women.” As for Roth’s biographer, “Bailey is industrious, rigorous, and uncowed.”
Not everyone found Bailey “uncowed.” The critic Laura Marsh called him an “adoring wingman” and a misogynist. The New York Times noted Bailey’s “complicity” and found his book “a sprawling apologia for Roth’s treatment of women.” In the book, Roth’s first wife is branded “a bitter, impoverished, sexually undesirable divorcée.”
Before long, Remnick’s endorsement would seem like one of the great critical misjudgments of the year. “I don’t know what David was thinking,” an acquaintance of his (and Roth’s) told me. In short order, Bailey was disgraced, his book withdrawn, following sexual assault charges. “Mein gott,” Remnick wrote Cynthia Ozick. He seemed shocked by Bailey’s undoing. But he also feared Roth’s. His chief concern, “in the unreal and unfortunate world of ‘one thing equals any other thing,’” was that Roth’s reputation might suffer.
He was right to worry. Roth’s reputation was declining. But it wasn’t the defamation-by-association that Remnick feared. By 2021, a variety of factors, from #metoo to a broad reappraisal of the “great male narcissists” (as David Foster Wallace branded them), had tarnished Roth. In college courses, Roth went unassigned. (At Yale University, Roth, Bellow, and Malamud had practically vanished from the syllabus.)
And yet, Roth wasn’t cancelled—far from it. As of 2023, nearly all his novels remained in print. The academic journal Philip Roth Studies kept chugging along. Roth’s good name was still good enough for the New Jersey Performing Arts Center, which hosted “Philip Roth Unbound,” a three-day festival of panels and performances.
Indeed, Roth’s place in literary history was fixed, as it had been since the 1970s. Why, then, had he needed the New Yorker? Despite his fame, Roth’s sales were generally modest; of his 32 books, very few were bestsellers. The New Yorker, on the other hand, had both prestige and a readership above a million. Indeed, it’s likely that more readers encountered Roth’s writing through the New Yorker than through his books.
But there was something Roth needed more than readers and prizes. “He values complicity very highly,” his friend Judith Thurman once said. As time passed, Roth felt increasingly embattled—betrayed by friends, besieged by critics, brought low by illness. More and more, he sought allies, supporters, defenders. He was, said Thurman, “the greatest seeker of complicity as a friend.”
Indeed, that’s what his literary allies provided: sympathy, at the deepest level; good company; unconditional loyalty. To accuse them of mere opportunism would be cynical. Their admiration was sincere. Yet many operated shrewdly. They sought favors and jacket blurbs. They exploited Roth’s connections, and eventually published memoirs quoting private letters and conversations. For decades, Roth suffered the curse of fame: everyone wanted something from him, if only proximity, a chance to bask in his celebrity.
Then there were the journalists. In their strange pas de deus, journalists seduce subjects, who seduce them back. Both sides win—and lose—to varying degrees. With Roth and Remnick, there were only winners. Remnick offered praise and the huge readership of the New Yorker. In return, he received access—the reporter’s holy grail—and Roth’s writing, a greater bounty of words than any other magazine. All the while, Remnick promoted “a literary genius” who managed to “portray Jews in all their human variety.”
That sounds flattering, but in a curious way, it diminishes Roth. After all, Roth didn’t merely “portray” Jewish Americans. Nor did he render anything so vague as their “humanity.” We likely wouldn’t care about such a writer. In book after book, Roth probed, provoked, and pushed Jewish-America’s pressure points. He was a dangerous writer, his fiction fed by strong, dark emotions, chiefly anger—his lifelong muse and tormentor.
Even as Remnick flattered and lionized Roth, some part of him surely knew better. Back in 1995, he faulted Ben Bradlee, his former boss at the Washington Post , for a lapse in judgement. “He had lost, if only for a moment, his instinct for skepticism, his bullshit meter.” Many years later, Remnick criticized Bradlee’s closeness to presidents and politicians.
“I learned something from that,” Remnick said, referring to journalists who befriend their famous subjects: “Ultimately, they come and bite you in the ass. They can compromise you. They can dull your judgement. I’m very wary of it,” he added.
Coming out of Democrats’ wild success in the midterms, there were the winners who had fought heated battles in the glare of the national spotlight. And then there were those who had just barely registered on the national radar. When Slate wrote of Texas’ 23 rd district, for example, we wrote of the boorishness of the Republican nominee and barely mentioned the Democrat, Katy Padilla Stout, given that the district had voted for President Donald Trump by a 15-point margin in 2024. Padilla Stout won by 8 points.
Many of these long-shot candidates weren’t blessed by the resources of the national party until late in the game, if at all. They were left to launch quixotic bids in districts thought to be immovable, and in districts that in some cases had been redrawn to give Republicans easy victories. And against all odds, some of these candidates succeeded.
In the days since the election, the rest of the country has scrambled to learn who these newcomers are and how they managed to flip their seats. Others chuckled at the thought that some everyday people in red states launching symbolic challenges with no actual expectation of winning would suddenly find themselves part of Congress. But if you talk to the candidates, you’ll find something striking: confidence, and a decent amount of disdain for the doubters.
Paul Barringer, formerly a healthcare lawyer in D.C. who unseated a Trump-backed incumbent in North Carolina’s gerrymandered 13 th District, ran after moving back to rural North Carolina to care for his ailing mother. He had been a Republican, but he was galled by what he saw as the corruption and chaos and excesses of the Trump administration. We reached him Friday, as he was still trying to catch up on all his messages from election night. (“You ever had 600 text messages come into your phone?” he said. “How ’bout that boss that was really terrible to you, and told you you’d never amount to anything because you were too nice, reaching out to you?”) He knew he could win, he said. When pressed, he doubled down, insistent that he had always been confident.
“Yeah, I mean, I felt that,” he said. “Maybe I was deluded.”
Most people in his position would probably not have felt so confident. Trump won Barringer’s district by 17 points in 2024. Its awkward borders twist to avoid the urban populations of Raleigh and instead pull in rural Southerners. But Barringer insists he had heard enough firsthand from voters to convince him that they were ready for a change. “Maybe my odds at the beginning were, I had to flip a coin and have it come up heads three times in a row,” he conceded. But the polling a year in, in the spring, suggested there was an opening. “I had heard so many people saying they were angry,” he said.
He had hammered the issues of cost of living, healthcare, and corruption while on the campaign trail. The Cook Political Report moved his race from “solid” to “likely” Republican in mid-October.
Similarly, Cyril Jefferson says he never really doubted he could do it. Jefferson ran in North Carolina’s 6 th District, a bit farther west. Like Barringer, Jefferson ran against a Trump-endorsed Republican, but his odds were even longer. In 2024, the Republican, Addison McDowell, beat his Democratic opponent by 38 points. “Cyril has a better chance of winning the lottery than convincing the 6 th District to vote for a woke, far-left politician,” McDowell said in response to Jefferson announcing his campaign. The Cook Political Report had, until the end, labeled it “solidly Republican.” And yet Jefferson beat McDowell in what the Washington Post called a “stunning upset.”
Jefferson is the mayor of High Point, the ninth most populous city in North Carolina, so he felt he knew his district well. He said he thought polls from 2025 showed weakness. But more than that, he felt McDowell wasn’t suited for a real challenge.
“Anytime you get comfortable and you take it for granted, you get caught sleeping, you get caught with your pants down, things like Tuesday night happen,” he said. “So I had a lot of confidence that that was going to be a major factor, that we were just going to outwork them, and we were going to outmaneuver and out-strategize.”
He did acknowledge that the national mood helped. “Yes, there were national political headwinds, we know that,” he said. But there was also, he said, faith. It was a faith in his own tenacity, but also a religious faith.
LaKesha Womack, who flipped North Carolina’s 14 th District, has an inspirational personal story that lent credibility to her talking positions on affordability and healthcare. She had, six years back, been what she described as “housing insecure,” living out of a hotel. She has Type 1 diabetes and had a medical emergency that caused her son to end up in foster care. This low period, “seeing how the system works for people who find themselves hitting rock bottom, not because they’re lazy, not because they don’t want to work, but because life just happens,” arguably strengthened her position as a candidate. But Womack is more guarded in her language than someone like Barringer, and she has reason to be cautious: She has recently been charged with a felony over a rental car that she allegedly failed to return during that period.
She said she cannot comment on the case for legal reasons, but suggested it was a politically motivated charge. “Just hypothetically, if someone stole a car six years ago, I feel pretty certain that the police are not going to wait six years to come after that person,” she said. “So, as hurtful as it was, it was a little encouraging. And that’s what I just told my supporters. I was like, ‘Hey, I know it’s hard, but it just means that we’re winning.’ ”
She did come to see it as a sign of her campaign’s legitimacy, she said. And as she explained her victory, it wasn’t about any special alchemy. She had just known what number of votes she needed to hit, and focused on reaching out to enough people to hit that vote number—and not on the more intangible politics of positioning herself against her opponent. Jefferson spoke of faith, Womack spoke of numbers, but both appeared to feel equally certain they could pull it off.
There are, of course, many candidates who work to the point of exhaustion every year who still come up short. There are candidates who understand the numbers, but still fail. But running a campaign is an incredibly taxing job, so it is understandable that these three North Carolina candidates wanted to ensure they and their team, and not the national political environment, got the credit. The day Slate spoke with Womack, she said she planned to finish the day with 35 media interviews. Jefferson mentioned having had just a few hours of sleep over several days.
Still, if the claim that those of unwavering confidence could win through their own hard work and talent are true, such seemingly deluded self-assurance may have been the key to their success. That may be exactly what these kinds of races require: absurd self-conviction, in the face of long odds.
These candidates now face their next challenge. And while they mostly want to talk to reporters about how they’ll make good on their campaign promises, they’re also thinking about their strange transition from being political unknowns to members of Congress. They’re setting up offices, going through résumés, figuring out housing in Washington. Barringer mentioned that he turned to the internet to find out if he can bring his dogs, Billy and Penny, to the Capitol. (“I read on ChatGPT that you can’t take them on the House floor, but otherwise you can have them in the office building,” he said.)
These Democrats now have a kind of odd celebrity. Barringer said both Seth Meyers and Chris Hayes (he said he wasn’t previously familiar with the latter) had mentioned him as someone they’d never heard of. “I mean, the subtext with those stories is like, ‘Where do these people come from?’ ” Barringer said. “ ‘It’s sort of random that they’re in Congress.’ But, I mean, I feel very confident saying that most everyone who actually made it through worked their tail off.
“So, the notion that people have shown up and that just—It may be that the national media, or authorities, weren’t expecting them. But I feel pretty confident that the people who got in felt like they had a chance to win. Because that’s what kept them motivated down the stretch.”
He laughed at the idea of being described as “random.” “I happen to live inside this body,” he said. “All the randos that kind of made it through, they did not feel like they were as random as the national press feels they were.”
Slate
is an online magazine of news, politics, technology, and culture. It combines humor and insight in thoughtful analyses of current events and political news.
Choose the newsletters you want
to get the Slatest.
09:14:03 # Life Time flies so fast. It's November. Busiest time of the year?
Guide to running Qwen3.8 quants including Qwen3.8-27B on your local setup.
Qwen3.8-27B is a 27B parameter dense model Qwen, featuring vision and reasoning capabilities, a 256K context window, and runs locally on 17GB RAM/VRAM setups. Qwen3.8 excels at agentic coding, vision and chat tasks, and can now run via Unsloth GGUFs, NVFP4 and Unsloth Desktop .
Nov 11 Update: Qwen3.8-27B GGUFs now use Unsloth Dynamic V3.1 which improves average accuracy by 5-10% accuracy at comparable sizes including Terminal Bench, DeepSWE and more benchmarks. We're working on an even better version of Dynamic quants which will be applied to Qwen4 and future models.
Run Qwen3.8 Guide Download Unsloth
Thank you Qwen for day zero access. Unsloth quants also include:
Developer Role Support for agentic tools like Codex
Tool calling: Improved parsing nested objects to make tools succeed more
We're excited to release new Qwen3.8-27B GGUFs using our updated Unsloth Dynamic V3.1 (preview) algorithm which improves Unsloth quants by 5-10% accuracy at the same size on most benchmarks and is the best in class for most tasks including coding, agentic workloads and general chat.
Most quants from 2bit until 6bit are updated. We found 3bit UD3 quants to do on par with UD3.1, so we do not update them. We are actively working on making all quants better!
We ran agentic benchmarks including Terminal Bench 2.1, DeepSWE v1.1 , and general benchmarks like LiveCodeBench v6, GPQA Diamond, MMLU-Pro, AIME25 and many others. We used 256K context lengths for all agentic benchmarks, and 128K for the rest. We followed the same methodology for Qwen3.8-27B as DeepSeek-V4.1-Flash and Qwen3.8-Flash-Next which also utilized our V3.1 preview algorithm.
Click below to see full details of benchmarking and more:
To compare GSQ-RCO and Exllama-v3, we had to exclude the token embedding layer from the x axis, as Exllama-v3 uses BF16 for it.
If you consider the full download size and total RAM usage for Exllama-v3, then adding the BF16 embedding table and including all embedding sizes changes the plots. Our main plots's x axis removes the embedding layer sizes from all quant providers. However on pure RAM usage and disk space usage vs accuracy, the below plot is the true reflection of actual usage.
We have not investigated why Exllama-v3 keeps token embeddings in BF16, but as the lm_head is still quantized heavily, the embedding layer might have "absorbed" most of the quantization damage from it. We would be glad to benchmark new Exllama-v3 non BF16 token embedding quants like using 8-bit for example, and see if benchmarks change.
For LiveCodeBench, GSQ-RCO showed Unsloth UD3 quants doing consistently worse than ISTA's. However we found the opposite - UD3 quants (our OLD quants) do better than ISTA on LCB on all sizes except the smallest. UD3.1 further improves on LCB as well.
We approximate that GSQ-RCO used a context budget of 96K, as that best fits the data for the runs we have. At 96K, GSQ-RCO does somewhat do better than UD3, but at 128K, UD3 does much better.
On another benchmark, for ISTA GSQ-RCO's AIME25 benchmarks, their quants reach 100%, 100%, 100% and 96.7% accuracy recovery. And they said our quants do worse.
Through out investigations, we estimate ISTA only did 1 trial - we did 14 trials, and we show on average the recovery rate is 93% to 96% - not 100% accuracy recovery. And in fact our UD3 old quants do BETTER on average than their quants on 14 runs vs 1 run of theirs , so we draw the opposite conclusion if you run the trials more.
We also checked and graded our answers using Math Verify Dynamic 3.1 GGUFs and also LightEval and we find exactly the same conclusions. We also tried greedy decoding (temperature of 0), and this could not get the 100% accuracy recovery ISTA found across multiple greedy runs, as GPUs themselves are non deterministic. That is why you benchmarks should be run multiple times. Greedy decoding is also not representative of real world use cases.
We also checked 96K (which is most likely ISTA's budget) and 128K, and our quants still do on average better.
We did KLD for multiple domains for Unsloth UD3.1 quants and UD3 quants - we reduce KLD throughout most quants and most domains - we did not replace the 3-bit ones, as we found UD3 to do mostly great, and the accuracy recovery on benchmarks was not significant enough with UD3.1 to warrant an update, so we did not update them.
We follow the same procedure for all benchmarks as for Qwen3.8-Flash-Next, DeepSeek-V4.1-Flash as well as discussed in Dynamic 3.1 GGUFs . We used temperature 1.0, top_p 0.95, top_k 20, min_p 0, no presence or repetition penalty, preserve_thinking and xhigh reasoning for Qwen3.8-27B.
Qwen3.8- 27B 4-bit quants work on 16-19GB VRAM like RTX 5080, 4090 or a Mac with 24GB RAM. Table: Hardware requirements (units = total memory: RAM + VRAM, or unified memory)
If you want to use MTP for faster inference, prepare to have 1-2GB extra headroom.
Qwen3.8-27B is a hybrid thinking model with different default settings for thinking and non-thinking modes. Extra high is enabled by default so if you want shorter thinking traces, you can adjust the thinking effort :
Maximum context window:
262,144
(can be extended to 1M via YaRN)
Thinking Mode:
temperature=1.0
,
top_p=0.95
,
top_k=20
,
min_p=0.0
,
presence_penalty=0.0
,
repetition_penalty=1.0
Instruct (or non-thinking) mode:
temperature=0.7
,
top_p=0.80
,
top_k=20
,
min_p=0.0
,
presence_penalty=1.5
,
repetition_penalty=1.0
Qwen3.8 has Preserve Thinking which leaves the thinking trace from the previous conversation. This increases the number of tokens you use, but could increase accuracy in continued conversations. Unsloth has 'Think' and Preserved Thinking toggles for Qwen3.8 (see right):
Qwen3.8-27B comes with support for
reasoning_effort
, which can be used to adjust reasoning depth and control cost. These toggles are automatically enabled in Unsloth:
xhigh
(default): for complex tasks demanding thorough analysis
medium
: balancing accuracy and speed
low
: efficient reasoning optimizing for speed and cost
To change
thinking / reasoning
effort in
unsloth run
or
llama-server
, use
--chat-template-kwargs '{"reasoning_effort":"medium"}'
If you're on
Windows
Powershell, use:
--chat-template-kwargs "{\"reasoning_effort\":\"medium\"}"
Change
medium
to your desired reasoning level.
You can now run Qwen3.8-27B in llama.cpp and Unsloth Desktop. Feel free to change quantization type.
Run in Unsloth Desktop Run in llama.cpp NVFP4 Guide Qwen3.8-2.4T-A95B Guide
Qwen3.8 can run in Unsloth Desktop , an open-source UI app for local AI. Unsloth automatically offloads to RAM and detects multiGPU setups . With Unsloth Desktop, you can run models locally on MacOS, Windows , Linux and:
Search, download, run GGUFs , MLX and safetensor models
Fast CPU + GPU inference via MLX and llama.cpp
Go to Unsloth Chat or Model hub and search for Qwen3.8 in the search bar and download your desired model and quant.
Inference parameters should be auto-set when using Unsloth, however you can still change it manually. You can also edit the context length, chat template and other settings.
For example using Unsloth Desktop with the 397GB Qwen3.8 (-91% smaller) allows you to toggle thinking modes, allow inline canvas, web search and code execution and much more.
You can use
unsloth run
command and serve Qwen3.8 via an API using
llama-server
runtime flags, including context sizing, GPU layers, threading, sampling, networking, and tool configuration. For more info see our
API docs
or
unsloth start
.
Download the latest version of llama.cpp. You can follow the build instructions below as well. Change
-DGGML_CUDA=ON
to
-DGGML_CUDA=OFF
if you don't have a GPU or just want CPU inference.
For Apple Mac / Metal devices
, set
-DGGML_CUDA=OFF
then continue as usual - Metal support is on by default.
To run the model in llama-cli, follow the code snippets below: Remember to change settings according to your use-case.
Like Qwen3.6, we’re also releasing new dynamic NVFP4 Qwen3.8 -27B quants that run ~1.5× faster than BF16 checkpoints, with better performance and comparable file sizes. Run Qwen3.8-27B NVFP4 1.5x faster on 24GB VRAM. We also added FP8 KV cache calibration for 2x longer context lengths! NVFP4 requires NVIDIA's Blackwell GPUs like RTX 50X, DGX Spark (see Qwen3.8-27B ), B200, B300 GPUs. For older GPUs, our GGUFs work well! You can run NVFP4 quants in vLLM only for now (SGLang is not supported).
See below for previous benchmarks conducted for Qwen3.6 as well comparing to other NVFP4 implementations which use 16bit activations vs our NVFP4 activations:
All benchmarks use 1x B200 128 concurrency. Higher concurrency can boost 35B to 17,561 tokens / s.
For accuracy benchmarks we ran KLD and Top-1 agreement over Code, Chat and many domains. NVFP4 is consistency 92% to 97% accuracy recovery vs BF16
For accuracy benchmarks For Qwen 3.6, we conducted MMLU-Pro, AIME 2025, GPQA for FP8, BF16, NVIDIA's NVFP4 and our NVFP4s - we show our faster quants do similarly on all:
To install vLLM in a separate venv:
Then to serve the 27B variant:
To enable MTP / speculative decoding (faster decode but somewhat less throughput), use:
If you get Torchcodec issues, be sure to do the below then relaunch vllm.
If using SGLang, you must use SGLang version v0.5.19 otherwise it will not work since we quantize the lm_head to FP8.
vLLM has a
CompressedTensorsW8A8Fp8
kernel which supports this, whilst SGLang v0.5.19 cannot load the FP8 lm_head. v0.5.19 works now!
For sglang after installing the latest:
NVFP4 quants are 1.5x faster than BF16 and retains 92 to 97% top-1 accuracy.
Top-1 accuracy plot as shown in UD-3 fro Qwen3.8-27B:
And mean KLD for Qwen3.8:
See further below for table benchmarks:
Agentic terminal codingTerminal Bench 2.1 (Terminus)
Agentic codingSWE-bench Pro
Repo-level code generationNL2Repo-Bench
Agentic codingDeepSWE 1.1
Software engineeringQwenSWEBench
Long-horizon office workCoWorkBench
Professional job tasksJobBench
Frontier agentic tasksAgents' Last Exam
Instruction followingIFBench
Scientific reasoningGPQA Diamond
Multidisciplinary reasoningHLE
Competitive codingLiveCodeBench v6
Qwen3.8- 2.4T -A95B is a 2.4T parameter (95B active) model with rivaling GPT-5.6 Sol. Full-precision Qwen3.8-2.4T-A95B requires 4.9TB of storage and 1-bit Unsloth Dynamic GGUFs takes 397GB (91% smaller) , and larger IQ1_S takes 508GB.
Qwen3.8-2.4T is thinking-only , while Qwen3.8-Max is hybrid.
Context length = up to
1,010,000
temperature=1.0
,
top_p=0.95
,
top_k=20
,
min_p=0.0
,
presence_penalty=0.0
,
repetition_penalty=1.0
If the model fits, you will get ~20 tokens/s generation when using B200s and >120 tokens / s throughput. Best rule of thumb: RAM+VRAM ≈ the quant size; otherwise it’ll still work, just much slower due to disk offloading.
You can now run Qwen3.8 in llama.cpp and Unsloth Desktop. For the large Qwen3.8-2.T model, we will be utilizing the 397GB
IQ1_XXXS
quant (named Q1_0) for best results in terms of accessibility and accuracy and it will require at least 450GB RAM. Feel free to change quantization type.
Run in Unsloth Desktop Run in llama.cpp
Qwen3.8 can run in Unsloth Desktop , an open-source UI app for local AI. Unsloth automatically offloads to RAM and detects multiGPU setups . With Unsloth Desktop, you can run models locally on MacOS, Windows , Linux. Go to Unsloth Chat or Model hub and search for Qwen3.8 in the search bar and download your desired model and quant. Then run it.
We extended IQ1_S in llama.cpp which is 1.5625 bits per weight to 1.1875 bpw by reducing the number of entries in the codebook - we found this works well for large models, and can still retain a lot of accuracy - we also found these new data-types to be fine for post training quantization (PTQ) without the need for QAT or QAD (quantization aware training / distillation). Qwen3.8- 2.4T-A95B -GGUF
Due to naming issues, we used TQ2_0, TQ1_0 and Q1_0 otherwise it won't pop up in the HF repo.
We are still running benchmarks for the new data-types, but for other large models, we get good results without any QAT / QAD :
We need to use the specific IQ1_XXXS branch
here
. You can follow the build instructions below as well. Change
-DGGML_CUDA=ON
to
-DGGML_CUDA=OFF
if you don't have a GPU or just want CPU inference.
For Apple Mac / Metal devices
, set
-DGGML_CUDA=OFF
then continue as usual - Metal support is on by default.
Download the model via (after installing
pip install huggingface_hub
). You can choose
Q1_0
for
IQ1_XXXS
or other quantized versions like
Q8_0
. If downloads get stuck, see:
Hugging Face Hub, XET debugging
To run the model in llama-cli, follow the code snippets below. Remember to change settings according to your use-case.
To run the general UD-IQ1_S you can do:
curl -fsSL https://unsloth.ai/install.sh | shirm https://unsloth.ai/install.ps1 | iexbrew install --cask unslothbrew upgrade --cask unslothwinget install --id UnslothAI.Unsloth -ewinget upgrade --id UnslothAI.Unsloth -eunsloth run --model unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.0 \
--reasoning-effort mediumapt-get update
apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
git clone https://github.com/ggml-org/llama.cpp
cmake llama.cpp -B llama.cpp/build \
-DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-mtmd-cli llama-server llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpppip install -U "huggingface_hub[cli]"
hf download unsloth/Qwen3.8-27B-GGUF \
--local-dir unsloth/Qwen3.8-27B-GGUF \
--include "*UD-Q4_K_XL*" # Use "*UD-Q3_K_XL*" for 3-bit./llama.cpp/llama-cli \
--model unsloth/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_XL.gguf \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.0uv venv unsloth-nvfp4-env --python 3.13
source unsloth-nvfp4-env/bin/activate
uv pip install "vllm>=0.25.0" "flashinfer-python>=0.6.13" "nvidia-cutlass-dsl>=4.5.2" \
--torch-backend=autovllm serve unsloth/Qwen3.8-27B-NVFP4vllm serve unsloth/Qwen3.8-27B-NVFP4
--speculative-config '{"method": "mtp", "num_speculative_tokens": 2}'sudo apt-get update
sudo apt-get install -y ffmpeguv pip install sglang sglang-kernel \
--extra-index-url https://sgl-project.github.io/whl/cu130/ \
--extra-index-url https://download.pytorch.org/whl/cu130 \
--index-strategy unsafe-best-matchsglang serve unsloth/Qwen3.8-27B-NVFP4sglang serve unsloth/Qwen3.8-27B-NVFP4 --speculative-algorithm EAGLE \
--speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4apt-get update
apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
git clone --branch iq1-narrow https://github.com/unslothai/llama.cpp
cmake llama.cpp -B llama.cpp/build \
-DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-mtmd-cli llama-server llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpppip install -U "huggingface_hub[cli]"
hf download unsloth/Qwen3.8-2.4T-A95B-GGUF \
--local-dir unsloth/Qwen3.8-2.4T-A95B-GGUF \
--include "*Q1_0*" # Use "*IQ2_XXS*" for 2-bit./llama.cpp/llama-cli \
--model unsloth/Qwen3.8-2.4T-A95B-GGUF/UD-Q1_0/Qwen3.8-2.4T-A95B-UD-Q1_0-00001-of-00010.gguf \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.0pip install -U "huggingface_hub[cli]"
hf download unsloth/Qwen3.8-2.4T-A95B-GGUF \
--local-dir unsloth/Qwen3.8-2.4T-A95B-GGFF \
--include "*IQ1_S*" # Use "*IQ2_XXS*" for 2-bit./llama.cpp/llama-cli \
--model unsloth/Qwen3.8-2.4T-A95B-GGUF/UD-IQ1_S/Qwen3.8-2.4T-A95B-UD-IQ1_S-00001-of-00012.gguf \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.03Com was a high flying maker of network cards and other network equipment. And then they disappeared with a whimper on November 11, 2009. What happened to 3Com?
Around the time of the dotcom boom , 3Com was a 5.8 billion dollar company. They were founded in 1979 by Bob Metcalfe, the co-inventor of Ethernet. And for the next two decades, they were the go-to brand for network cards. While the 3C501 network card is notoriously bad, their other cards from the 1980s and 1990s are very well regarded, and always were.
They cost more, but had good driver support, the hardware worked reliably, and they were a known quantity. And 3Com made them in the United States, which was becoming unusual even in the 1990s.
I once worked in a shop that didn’t allow network equipment unless it was one of three brands. 3Com was one of them, along with Cisco and Intel. If you plugged a no name NE2000 clone card into the network and had problems, the IT department would replace the card and bill your department. There was a saying in the 1980s that no one got fired for buying IBM. When it came to networking, one could say the same for 3Com, during their prime.
And they were huge. In 1995, 3Com bought the naming rights to Candlestick Park, the legendary baseball/football stadium in San Francisco. It held those rights until 2002.
But after the dotcom bust, 3Com faded away. What happened to 3Com, ultimately, was a series of bad decisions that led to a loss of profitability. Some of them may have made sense at the time. But not all of them.
The first thing that happened was 3Com walked away from its enterprise networking equipment business. Admittedly Cisco was hard to compete with. But 3Com was the only brand succeeding at doing it. The logic behind the move always puzzled analysts, because it didn’t save any money. Revenue dropped, and 3Com angered its customers and dealers. It’s likely many started buying Intel cards afterward, since they had to change vendors anyway.
Many corporations like to buy multiple things from a single supplier. This was one reason IBM stayed in the PC business for several years into the 21st century even though they were losing money on it. The computers weren’t profitable, but they made it easier to sell services, and the services were profitable. There is always the fear that two vendors will point fingers at each other, saying the network problem was caused by the hub and the network card being mismatched brands. Interoperability was the whole idea behind Ethernet, but not everyone understood that. One could commend 3Com for not wanting to exploit that misunderstanding. But it came at a financial cost.
It also didn’t help that the company branched into other businesses outside its core. The purchase of US Robotics was a key example. US Robotics made modems and Palm Pilots . For a short time, that was big business. But 3Com paid a premium price for products with a limited shelf life left in them.
Nothing good happened to 3Com after that. It took 3 years for Cisco to go from being 90% the size of 3Com to double the size of 3Com. The profitability of selling network adapters dropped. And by the time 3Com realized they needed to get back into network equipment, it was an expensive proposition. From 2000 to 2005, the company didn’t turn a profit.
Ultimately, 3Com failed because it was too dependent on network cards. Network cards accounted for about half their revenue during their bust years. And their cards were expensive. Intel undercut their price to try to gain market share, and they succeeded.
And then they did exactly the wrong thing. It was the late ’90s, and they bought their way into the modem business. The dial-up modem business. At that point in time, everyone knew broadband was the future, they just didn’t know exactly when it was going to arrive. Yet 3Com had no plan to get into that business. It was like betting on AOL even though they were in the position to know the future belonged to AT&T .
Making matters worse, minimum viable product-style modems undercut US Robotics modems, just like the network card business. Not that Intel cards were a minimum viable product. But pretty much any ’90s network card not made by Intel or 3Com was.
3Com sought partnerships, most notably a partnership with Chinese networking giant Huawei. There were even rumors of Huawei buying 3com, though that deal never went through. And 3Com started making product overseas as a cost reducing measure. But ultimately, nothing could make up for all that lost time and all those bad decisions.
So what happened to 3Com? 3Com didn’t go out of business and they didn’t sell out to Huawei. They got Compaqed . Hewlett-Packard bought them out, which seems to be where every great ’90s technology company went to die. Hewlett-Packard paid 2.7 billion dollars in late 2009 for 3Com’s assets.
HP still sells network equipment like switches, routers, and access points. But they’re not as big of a name in networking as 3Com had been. And the 3Com pedigree isn’t the selling point. If they put a brand on it other than HP, it’s the newer Aruba brand, not 3Com. The selling point is the price being lower than Cisco. This makes them attractive to executives or purchasing agents looking to cut costs, consolidate vendors, or both. HP will usually beat Cisco’s price. And if the IT department is under pressure to reduce the number of vendors it buys from, HP sells more things than Cisco. So HP gets in the door for one of those reasons, and when their network equipment turns out to be no worse than Cisco equipment, they stay with it. At least until Dell comes around offering discounts.
But the network cards are long gone. When you buy an HP branded network card today, guess what it is? It’s an Intel card with HP’s logo engraved on it. Unless HP is trying to control costs, in which case it just has a sticker.
Vintage 3Com network cards are very popular with retro computing enthusiasts. It had top-tier name recognition in the 80s and 90s. All but their very earliest cards generally have good driver support, work well, and are easier to configure than most of the cheaper competitors.
My favorite retro network card is a very specific Intel card , but if you need a card for anything from the 286 to the Pentium II era, you can do far worse than a 3com 3c509 ISA card or 3c905 PCI card. It’s absolutely period correct and absolutely something a knowledgeable professional would have used at the time. I have better luck with the ISA cards under DOS than the PCI cards, so if I want to run DOS and do any networking, I use a 3c509 ISA card in the system. But for Windows 95 and newer, the 3c905 PCI card works really well and is very cheap and common.
David Farquhar is a computer security professional, entrepreneur, and author. He has written professionally about computers since 1991, so he was writing about retro computers when they were still new. He has been working in IT professionally since 1994 and has specialized in vulnerability management since 2013. He holds Security+ and CISSP certifications. Today he blogs five times a week, mostly about retro computers and retro gaming covering the time period from 1975 to 2000.
Turn a threat (a CVE, a CISA KEV entry, an incident writeup, an ATT&CK technique) into a validated first-version detection — a proven starting point a detection team hardens further, not a claim of finished, forever-bulletproof coverage — plus three artifacts that ship together :
real-coverage
/
brittle
/
broken
) with FP/FN numbers and a reproducibility hash.
The thing nobody else produces is #3. A model can write you a Sigma rule; it cannot hand you a proof that the rule works, an adversary that provably evades the weak version, and an honest record of how the rule was hardened until it held.
A bounded, fixed adversary. Red commits to two real, documented attacks in round one and re-throws those same two against the hardened rule each round — the same "built once, can't move its goalposts" discipline as the fixed test corpus.
real-coveragetherefore means something concrete and honest: the first-version rule fires on every attack in the corpus, stays silent on benign look-alikes, and caught both of Red's real attacks. It is a validated baseline, not a promise of coverage against every future evasion — that is the detection team's job to extend.
Agents propose; the engine proves. Four role-specialized LLM agents (Threat Analyst, Blue Detection Engineer, Telemetry, Red-Team Adversary) do the creative work. Everything that decides truth — FP/FN evaluation, adversarial evasion, the coverage verdict, red-team verification, and the deployment gate — is a deterministic referee. Same input → same verdict → same reproducibility hash.
Two pipelines share this agent cast. The one described above proves — Blue authors, Red attacks, a deterministic referee decides. The Review Chain reviews — draft → Red Team → revision → SOC Lead → final rule, with every note that shaped it. Different question, different deliverable; pick per what you need.
📄
See real output first:
examples/joomla-icagenda-cve-2026-48939/review-history.md
— a live run on a CISA KEV entry, three rule versions, eight reviewer findings.
pip install -r requirements.txt # or just run --evals on stdlib alone # LIVE — any threat text; a real model authors it (needs GEMINI_API_KEY or ANTHROPIC_API_KEY) python src/run.py "CVE-2026-45659 SharePoint deserialization RCE" python src/run.py "T1218.011 rundll32 remote scriptlet execution via mshtml" # CANNED — a fixture scenario, fully offline, no key (what the test suite drives) python src/run.py --threat fixtures/certutil_t1105.json # brittle→repair→proven python src/run.py --corpus atomic # positives from REAL Atomic Red Team commands python src/run.py --max-rounds 3 # self-repair loop cap (default 3) python src/run.py --evals # deterministic engine + proof + workflow tests python src/run.py --approve alice # human approves → gated deploy succeeds python src/run.py --claude "..." # force claude-opus-4-8 authoring (ANTHROPIC_API_KEY) python src/run.py --gemini "..." # force Gemini authoring (GEMINI_API_KEY)
There is
no default scenario
— the Foundry takes the threat you give it. A bare
python src/run.py
has nothing to work on and says so.
Bundles are written to
Outputs/<rule-slug>/
(
rule.yml
,
report.md
,
proof.json
).
--chain
, and the default UI)
The pipeline above asks "is this rule provably correct?" and answers with a deterministic verdict. The Review Chain asks a different question — "what would each stakeholder say about this rule, and what does it look like after their feedback is applied?" — and answers with a final rule plus the complete trail that shaped it .
ingest ─▶ extract ─▶ telemetry ─▶ profile
─▶ Blue: DRAFT v1
─▶ RED TEAM review (findings: where is this evadable / blind)
─▶ Blue: REVISION v2 (each edit cites the finding id it answers)
─▶ SOC LEAD review (findings: volume, triage, severity, tuning)
─▶ Blue: FINAL v3
─▶ package
python src/run.py --chain "CVE-2026-48939 Joomla iCagenda arbitrary file upload RCE" python -m uvicorn webui.server:app --port 8000 # → http://127.0.0.1:8000 (chain UI) # → /classic for the proof loop above
Red and SOC are not the same reviewer in two hats — they pull in opposite directions. Hardening against evasion broadens a rule; broadening raises alert volume. Running both, in that order, is the point: the final rule is the one that survived both pressures, and the trail shows exactly what each pass cost.
Output lands in
Outputs/<rule-slug>/
as
final-rule.yml
,
review-history.md
(the full progression, rendered) and
review.json
.
→
examples/joomla-icagenda-cve-2026-48939/
— a real run on CVE-2026-48939 (Joomla iCagenda upload-to-RCE, CISA KEV), authored by
claude-opus-4-8
. Three rule versions, eight findings, the whole trail:
review-history.md
.
Blue's first draft fired on a web daemon spawning a shell that runs recon commands . Both reviewers took it apart — in opposite directions:
Red Team: "No — I'd just skip the recon commands (or use a container's busybox shell) and this rule never fires despite a full RCE."
R1mandatoryrecon_intentturns a lineage detection into a keyword detection ·R2on Alpine/bin/shis busybox, so every shell clause misses ·R3literalcontainsdies to shell obfuscation ·R4setsid/double-fork re-parents to PID 1 and lineage fails
SOC Lead: "No — this fires on your own benign cron example on day one; the parent scoping is broken and it'll bury the rota in www-data noise."
S1theORmade web-server parentage optional — any www-data process spawning a shell fired ·S2php-fpm→php is normal web-app behaviour, not RCE ·S3the alert carried one field, so the analyst pivots consoles ·S4level: highon that noise floor burns out the on-call
Red pushed Blue to
broaden
; the SOC Lead pushed it to
narrow
straight back.
That tension is the product: hardening against evasion raises alert volume, and the
final rule is the one that survived both pressures. SOC reviews last, so what ships is
tuned for the queue — v3 made parent lineage mandatory, excluded the known-good
interpreter chains, expanded the triage fields, dropped to
level: medium
, and carries
a three-step response playbook with a containment threshold.
Reviewed, not validated — and the artifact says so. This chain does not invoke the proof core. It never executes the rule against telemetry, counts no false positives, and issues no coverage verdict. A rule that has been through four professional reviewers looks finished, which is precisely why the packaged output leads with that sentence. Run the classic pipeline (or
--evals) when you need proof rather than review.
webui/
) — live authoring, watch the agents work
python -m uvicorn webui.server:app --port 8000 # → http://127.0.0.1:8000 ; type ANY threat, watch the loop run python tools/warm_cache.py "the exact threat you'll demo" # optional — see below
FastAPI + SSE over the
real
graph. Two streams are interleaved and neither is
scripted:
node events
fire when a graph node genuinely completes, and
token
events
stream each agent's raw model output
as it is generated
, via the token sink
on
providers.py
. The graph runs on a worker thread precisely because tokens arrive
mid-node; the queue between them is the only coupling, and it is one-way.
You watch: the LangGraph shape animate (the node in flight glows, the edge into it flows, the loop-back arc fires red on a repair round ), the agent console type out what the model is producing right now, the Sigma rule write itself line by line, and the convergence timeline, Kartikeya gate and reproducibility hash land at the end.
It authors LIVE — there are no presets and no fixture/replay path in the UI
, so any
threat works. Determinism comes from
providers.py
's on-disk cache: temperature 0,
keyed by
sha256(model|system|user)
, so re-running the
same threat text
replays
byte-identical model output → same rule → same bundle hash. Cold-run latency depends
entirely on the model (a 3-round convergence on
gemini-flash-lite
lands in ~20-40s;
a bigger model is minutes).
warm_cache.py
pre-pays it for a threat you plan to demo.
Replay is labeled, always. A cached token stream is marked
cachedend-to-end and the console badge reads ⟳ REPLAY (cached) instead of ● GENERATING . A viewer cannot tell replay from generation by looking, so the UI says which it is. Dressing cached bytes up as live motion would be exactly the "vibes" this project refuses. The sink is observation only: detach it and the verdict and hash are byte-identical.
Red-team refusals are handled honestly. Safety-tuned models sometimes decline the adversary role. A refusal is recorded, surfaced in the UI, and — critically —
graph.node_verdictrefuses to awardreal-coverageto a round nobody attacked. "No evasions found" and "the adversary never ran" must never look alike.
ingest ─▶ extract ─▶ telemetry (Analyst normalizes; Telemetry fixes the test set)
│
▼
┌──────────────── SELF-REPAIR LOOP (LangGraph conditional edges) ─────────────────┐
│ │
│ blue_author ─▶ evaluate ─▶ battery ─▶ red_propose ─▶ red_verify ─▶ verdict │
│ ▲ (FP/FN) (mutation (Red-Team (engine- (coverage) │
│ │ │ battery) proposes) verifies) │ │
│ │ └── un-evaluable rule ─────────────────────────────┤ │
│ │ (engine refuses → broken, skip the round) │ │
│ └───────────────── repair: verdict ≠ real-coverage ◀────────────┘ │
│ │ │
└──────────────────────────── done: real-coverage OR round == cap ──────┘ │
▼
gate ─▶ bundle
[ blue/red/telemetry/analyst = LLM agents — PROPOSE ]
[ evaluate·battery·red_verify·verdict·gate = deterministic referee — PROVE ]
src/agents.py
)
— four distinct personas. The
Blue Detection
Engineer
authors a robust-by-construction first version (behavior + command-line
intent, not one brittle string) and re-authors on a brittle/broken verdict using the
concrete
evidence (the exact evasions + false positives). The
Red-Team Adversary
commits to
two real, documented attacks
in round one and re-throws
those same
two
against the hardened rule every round — a fixed adversarial test set, not a fresh
ambush each round, so Blue closes a bounded pair of gaps and honest convergence is
reachable.
src/knowledge_base.py
+
rule_corpus/
)
— a two-partition
RAG
knowledge base grounds both proposers in real, researcher-authored OSS:
Blue authors from peer-reviewed
SigmaHQ
rules; Red attacks from
MITRE ATT&CK
defense-evasion (e.g.
T1036.003 Rename System Utilities
) and
LOLBAS
. The
retriever is lexical (BM25), fully offline and deterministic. It grounds
proposals
only
— it never touches the proof engine and never enters the reproducibility hash.
src/engine.py
— the deterministic Sigma matcher (the proof core). Zero deps.
Honesty contract: it
raises
on constructs it can't truly evaluate (
|cidr
,
aggregations, the
|in
that models like to invent) rather than silently passing —
an un-evaluable rule is never scored as "covered". The loop treats that as a
broken
round and hands the engine's own message back to Blue as repair
evidence, so a rule that doesn't run costs a round, not the run.
src/evaluator.py
— FP/FN evaluation + a deterministic
adversarial mutation
battery
(binary-rename, casing, whitespace, caret/quote obfuscation, path
relocation), and
merge_redteam()
which folds
engine-verified
red-team
evasions into the same verdict. Brittleness is
measured
, not guessed.
src/graph.py
— the loop.
red_verify
replays every red-team event through
the engine:
a bypass counts only if the engine confirms the rule failed to fire.
Unverified proposals are discarded — the adversary cannot assert a bypass.
src/governance.py
—
Kartikeya's Gate = Blast Radius × Capability Delta
.
Structural invariants a persuasive model can't argue away:
egress always
requires a human
, and
non-real coverage floors blast radius
.
src/mcp_server.py
— governed tool boundary. The graph can neither fetch nor
deploy;
deploy_detection
refuses any approval token not bound to the exact
bundle hash.
The harness holds the privilege, not the agent.
python src/run.py --threat fixtures/certutil_t1105.json
— offline, no key:
Image
path. The deterministic battery lands the
binary-rename
bypass
and
the Red-Team lands a real-world variant (certutil
copied to
AdobeUpdater.exe
), engine-verified → verdict
BRITTLE
→ loop back.
OriginalFileName
. The battery
evades nothing, and the
same
red-team rename is now
engine-discarded
because
the rule fires on it → verdict
REAL-COVERAGE
→ Kartikeya's Gate → bundle.
The report shows the full arc (rule v1 brittle → evasion → rule v2 proven). That is the Foundry being honest about a rule that looks fine and isn't — then fixing it and proving the fix held.
This scenario is a fixture , not the demo: it exists so the workflow runs offline and the test suite has a deterministic end-to-end case. The UI never touches it. A live threat converges on its own merits or doesn't — and "doesn't" is a real result the Foundry is built to report rather than hide.
The Analyst's per-behavior log sources elect a single category for the run (majority
vote); the Telemetry agent builds the fixed corpus on it, and Blue is told both that
category and the exact
field names
the corpus carries. Blue sees no event values and
no labels, so it cannot overfit — it just cannot key on a field that isn't in the
telemetry, which is an automatic recall-0
broken
round for a reason that has nothing
to do with detection quality. (A rule anchored on
TargetFilename
can never fire on
process-creation events.)
This is the
Shiva/Kartikeya
thesis applied to detection engineering:
deploying a detection is a
capability request
(egress to a SIEM), scored through
Gate = Blast Radius × Capability Delta
before any human is bothered — and
no
autonomous path can push a rule. Least privilege and human-gated egress are computed
and enforced in code, not asserted in a prompt.
Runs fully offline/deterministic. The sibling senior-security-engineering-agent narrates with Gemini; the Foundry authors with Claude — but in both, the model only proposes and the proof is deterministic.
The Foundry's
proof core
(
engine.py → evaluator.py → governance.py
) is deterministic and
self-contained. Its
seams
— ingest, author, convert, test-corpus, deploy, report — are designed
to be fed by open-source detection sources:
docs/OSS-PARTNERS.md
— canonical partner catalog: each repo mapped to the
tool's actual pipeline stage, with priority, integration point, and
license posture
.
docs/OSS-INTEGRATION-MINDMAP.md
— the full researched map.
First wire-in (highest value):
Atomic Red Team → positive corpus + EVTX-ATTACK-SAMPLES → benign
baseline, so the adversarial battery runs against
real
attack telemetry. Then pySigma + SigmAIQ for
multi-SIEM authoring/conversion (the
SigmaRuleArtifact.backends
slot already exists for this).
Loading — --:--:-- Eastern
On Nov 13, 2026 the FAA ordered a ground stop at every U.S. airport at 3:54 PM ET. This page shows tracked flights over the U.S., live and replayable, against the same time a week earlier.
Live — ET —
Loading flight history…
Commercial flights: below 10,000 ft 10,000 to 28,000 ft above 28,000 ft Other aircraft
Airport departures, last 30 min vs a week earlier: almost none reduced near normal
Flight positions: adsb.fi community ADS-B network. Airport delay feed: FAA NAS Status . An independent, unofficial page, not affiliated with the FAA. Hover or tap a dot to identify the aircraft.
Jump to or drag the timeline
Estimated commercial departures missed since 3:30 pm ET: the count for the same hours a week earlier minus this week's, from tracking data. On the right, how many left, out of the number a week earlier. Dot: departures in the last 30 minutes (red almost none, amber reduced, green near normal).
Aircraft in the air at the selected time. The bar is the share of the same time a week earlier.
| Carrier | Airborne | Share of a week earlier | Since 1 pm |
|---|
— . The feed lists only airports with a specific entry; during the nationwide stop every US airport is affected, listed or not.
| Airport | Status | FAA reason | Delay | Trend |
|---|
From news reports; updated by hand, not live.
This post (and the code behind it) was written with a lot of help from AI. I'm not going to apologize for that. If that bothers you, feel free to close the tab.
I maintain Ratatui , so I see a lot of the TUIs people build. Many of them end up looking fairly same-ish: plain boxes on a boring background, missing a bunch of the things that good design in other mediums brings us.
Borders are part of the problem. They have to take up space, so they become part of the panels
people want to build. One option is to drop them and just use color, but borders are really nice
for delineating and surrounding things. There are lots of ways to sort of get borders in a
terminal, but none that are 100% good. I've drawn enough
┌──┐
by hand to have opinions about
this.
The usual way is the Unicode Box Drawing block, which has 128 characters for lines, corners and joins. Somehow that's still not enough:
So I've been working on a terminal protocol that draws thin lines on the edges of cells instead. I've got it working as a patch to Ghostty (and an earlier version in Rio before that), and I've built demo apps for it with Ratatui. I'd like feedback from terminal and TUI authors.
Every line in that screenshot is a cell border. None of them use up a row or column. The tab labels sit on the top edge of each pane, the text fields are underlined right under the text, and the buttons are one row tall and rounded.
Here's the same app in a terminal without cell borders, falling back to box-drawing characters:
Each pane loses a row and a column on every side, so the log pane shows two fewer lines and the notes wrap differently. The tab labels move inside the frame. The text fields use the underline attribute instead, and the checkbox and buttons turn into brackets.
The settings form, with cell borders and then with the box-drawing fallback:
The tabs are the same story. With cell borders they sit on the pane's top edge. With box characters they need their own row inside the frame:
Lines between cells also work for charts. btop-style braille graphs fill every cell with dots, so there's nowhere to put a gridline or an average line without giving up a row. With cell borders they sit on the cell edges between the dots. Here's a monitor in that style, built with Ratatui:
And the fallback, which has to drop the gridlines:
Here's the tiling panes demo moving panes around, opening menus and the about dialog:
Partway through, it turns on a checkerboard of the cells, which shows how everything lines up with the grid. Toggle it here:
The root of it is that box-drawing characters are text. Each line is a glyph that takes up a whole cell, and pretty much everything annoying about them falls out of that.
Space is the obvious one. On my 16" laptop with a font I can actually read, the terminal is something like 200x50 (your prefs will move that around a bit). Columns are mostly fine at that size. Rows aren't. A layout with a couple of levels of nested panels can easily spend 6 or 8 of those 50 rows on nothing but lines. That's a lot of screen to give up for decoration.
You also can't put a line between two cells that both have something in them. So there's no way to underline a text field right under its text, or to outline a button, without adding padding around it. Rounded corners sort of work, except the corner glyph has one background color, and when the panel's background is different from what's around it you get a little square of the wrong color in each corner. And the line itself is whatever the font decides it is, weight and position included.
Then there's copy and paste. Select some text inside a box and you get the box too. Everyone who's
pasted from a TUI into Slack knows the little
│
cleanup dance. Sometimes you do want the box
(pasting a table into a chat, say), but mostly it's junk. Cell borders aren't text, so they never
get copied, which cuts both ways.
A cell border is a cell attribute, like a background color. Each cell can carry up to twelve line segments: the two halves of each of its four edges, and four arms from its center. Each segment has its own color, width, placement and style, and the terminal draws them over the cell grid. Borders are stored in the cells, so they scroll, erase, insert and reflow with the text. What happens on erase or scroll already has an answer, the same one as for colors.
The edges are split into halves so borders line up with quadrant block characters (
▖▗▘▝
and
friends). That makes it easy to draw a shape that's a half cell in from the grid and still put a
neat border around it. Yes, that still uses a character for the fill, and there might be a better
way to do that part. One problem at a time.
The same idea could stretch to sextants and octants, or to quarter and eighth widths, if designs need them.
Lines can be solid, double, dashed or dotted. Each corner and center of a cell can be square or rounded, with a configurable radius and anti-aliased arcs. A rounded corner can name an outside color, so the area outside the arc is painted correctly when the panel's background differs from what's behind it.
When two neighboring cells both put a line on their shared edge, they merge into one line. The
stroke with the higher
priority
wins, then the wider one, then the one to the right or below.
That way a focused pane can raise its priority and keep its whole outline, whatever order its
neighbors were drawn in. My first try was "right/bottom always wins", which lasted until the
focused pane lost half its outline to its neighbor.
Everything is one DCS string with a namespace:
ESC P 1 + b cell-border ; OP ; FIELDS... ESC \The common path is a pen, held in the cursor like the current background color. Set it, print some text, and the printed cells get the borders:
ESC P 1 + b cell-border;pen;48;32;7aa2f7;0;0 ESC \ bottom edge, blue: an underline
hello
ESC [ 0 m SGR 0 clears the pen
There are also rectangle commands that set or clear borders on existing cells without touching
the pen, and a capability query. An app sends the query followed by DA1. If the DA1 reply arrives
without a
cell-border
reply first, the terminal doesn't support it, so the app falls back to box
characters and reserves the space they need. Terminals that don't understand the DCS ignore it,
the same as any unknown DCS.
The minimum a terminal needs is the pen, the rectangle commands and solid strokes. I've tried to keep that first cut small, because there's always one more "... and this" to add, and that's a slippery slope.
Line styles, rounded joints, priority and outside colors are extension fields listed in the capability reply, and unknown fields are ignored, so they can be added later. I'd rather the early decisions be two way doors where possible.
The spec calls itself version 1 (it's the
1
in
DCS 1 + b
). That's v1 in the old sense, before
we all got bogged down in semver. It doesn't mean done or stable, it means it's the first one I was willing to write
down. Read it as v0.1, or a draft, or whatever you prefer.
Parts of this have been done before:
WA_TOP
,
WA_LEFT
and friends) have similar attributes. These are the
closest to this protocol, but they have no bottom edge (Win32), color, width or halves.
What none of these give you is a line with its own color and width on each edge. The rationale document covers the prior art in more detail and explains each choice in the protocol.
My own first prototype was in Rio ( raphamorim/rio#1947 ), with an earlier version of the spec that used APC instead of DCS. Feedback pointed out that APC isn't safe to reuse: Kermit 95 has run APC payloads as Kermit commands since the 90s. DCS is where structured terminal commands already live, and terminals ignore DCS strings they don't recognize, so I switched to that.
When I first showed this around, most of the questions were about these. The spec goes into all of them properly, but here's roughly where I landed.
Multiplexers were the first thing people asked about. tmux and friends redraw panes from their own idea of the cell grid, so passing these sequences through would just put borders in the wrong place. A multiplexer that doesn't know about the protocol should drop them and answer DA1 itself, and then apps running inside it fall back to box characters like they would anywhere else. One that does know about it can store borders like any other attribute and redraw them.
Conflicting lines on a shared edge are settled when the terminal renders, using the priority rule above, so it doesn't matter what order the app wrote the cells in.
Erase, insert and delete all work the way they do for background colors. Erased cells pick up the current pen, and lines that get inserted or deleted take their borders along. Scrollback, the alternate screen and reflow mostly come for free, because the border lives in the cell.
On cost: the Ghostty change is about 1,650 lines, and a fair chunk of that is tests. Each cell gets a 16-bit border ID, which fits in padding that was already there, so cells don't get any bigger and a screen with no borders costs nothing extra. The IDs point into a table of distinct border sets (about 100 bytes each) that's shared by the whole terminal. A typical TUI only uses a handful of distinct sets, but the table is never freed, so in the worst case (all 65,535 IDs in use) it's somewhere around 10-15 MB.
Rendering only does extra work for cells that have borders. Each one looks at its four neighbors to resolve shared edges, so changing a row also rebuilds the rows either side of it. Straight lines are a few solid quads per cell. Rounded corners cost more, because the anti-aliased arc is drawn as rows of small quads, roughly one per edge pixel. I haven't benchmarked any of this properly yet, and it's the part I'd most like another set of eyes on.
The spec and rationale are on my Ghostty fork. The Ghostty branch implements all of version 1. I've only built and run it on macOS so far, so the GTK and OpenGL builds are untested. To build and run it (you'll need Zig 0.17 and Xcode):
git clone -b joshka/cell-borders https://github.com/joshka/ghostty.git
cd ghostty
zig build -Doptimize=ReleaseFast -Dxcframework-target=native
open zig-out/Ghostty.appInside that Ghostty, the gallery script on the same branch draws the style gallery above. It detects support first, so it's also a quick check for another terminal's implementation:
python3 scripts/cell-borders.py # the default view
python3 scripts/cell-borders.py --styles # line styles, joints and outside fill
Once it's running you can flip between views with keys:
p
placement,
c
colors,
h
blocks,
j
junctions,
e
halves,
s
styles and
l
live.
w
cycles the stroke width,
b
turns borders off
so you can compare, and
q
quits. Each view also has a matching flag (
--placement
,
--styles
and so on) if you want to start on it.
The tiling panes demo is on the Ratatui branch . It falls back to box-drawing characters when the terminal doesn't support cell borders, which is how I made the comparison shots above:
git clone -b joshka/cell-borders https://github.com/joshka/ratatui.git
cd ratatui
cargo run -p tiling-panes
Drag panes around with the mouse to retile them.
n
and
v
split,
x
closes, and right click
opens a pane menu. Press
b
to switch between cell borders and box drawing, or
g
to shade
alternate cells and see where the edges are.
The btop-style monitor from the chart screenshots is in the same branch. Given how much of it an AI wrote, I did briefly consider calling it bslop:
To run it:
cargo run -p cell-border-top
It's a real system monitor (it reads your actual CPU, memory, network and processes), so it's a
better test of how this looks on a busy screen than the panes demo.
1
to
4
show and hide the
boxes,
b
and
g
work the same as in the panes demo, and
h
or
?
lists the rest of the keys.
It needs a newer Rust (1.95) than the rest of Ratatui because of the
sysinfo
dependency.
I'm not attached to this being the exact solution, but I think it's a problem worth solving, and I'd like it to be more than one terminal's feature (and more than one weekend's worth of yak shaving). If you work on a terminal, would you implement this, and which parts look expensive? If you work on a TUI library or app, which of your widgets would use it, and what would they need that isn't here? Comments are welcome on the Ghostty discussion .
The Twelve-Day War made me realize online music players aren’t a viable option for those who live under an oppressive regime that disconnects the internet across the country as a way to silence public opinion.
So, as soon as the connection came back, I started archiving tracks and looking for offline alternatives and discovered Strawberry . It’s a feature-rich music player and kept me happy for quite a while, but I have this habit of looking at song lyrics and singing along! Strawberry fetches lyrics from the internet when it recognizes a song, but sometimes the lyrics weren’t line-synced and worse, it displayed the timestamps next to the lyrics which I found pretty annoying to look at. I wasn’t aware of other music players such as foobar2000 which my friend just pointed me to while writing this post.
I decided to write my own music player and call it AMP with a few goals in mind: minimal feature-set, no C++ dependencies, proper system integration to make it feel like a native app, and of course, write it in Zig (including the shaders!). I also wanted to roll my own UI because of the fun memories of working on V’s UI during my first days of being introduced into system programming. But before I could make any meaningful progress, a new wave of protests started. Following the tragedy of January 8 and 9 , another internet blackout began, lasting more than four months.
During the blackout, there were these anonymous people on Telegram selling internet access through personal White SIMs , whitelisted servers, Starlink dishes, etc. A black market had formed for the freaking internet! You’d get charged $5 or more for just 1GB of traffic. The prices dropped slightly after a while, but it was still hella expensive. The regime surely made a lot of money out of it. I ended up spending hundreds of dollars on these services and other methods just to stay in touch with my friends and keep my hobbies alive. Killing time was becoming a problem. Especially for someone like me who built their entire social life online.
I carefully used this slow connection to download repositories, documention, etc. to continue working on my music player. It really brought me immense joy during this hard time.
Once the connection was mostly restored to the pre-blackout days (UDP traffic is still blocked, though, which naturally also affects QUIC), my attention was shifted towards LLMs. It had become very hard for me to ignore the hype and progress around frontier LLMs. As I really never thought about using them seriously for coding. They are still everywhere in the news, and I was just reminded that I owned a Claude Max 20x subscription gift from my boss back in 2025. Eating dust and maybe soon expiring. So I decided to give it a try and experiment on my music player. It was a very addictive experience. I literally couldn’t hit the plan limits no matter how hard I tried, so after a few non-stop days of prompting, a good chunk of AMP was vibecoded..
At the time, I thought this was an okay approach for a hobby project and I could just un-slopify it later. Little did I know I’m mentally incapable of reviewing tens of thousands lines of code. Shortly after, Anthropic figured that I live in Iran and instantly banned my account. Then Codeberg announced its no-AI policy , which gave me two choices. Either get rid of all that slop or move the repository elsewhere. Going with the former option, I started reading every single line of code, rewriting them. I was surprised by my own ignorance and how much LLMs like to complicate stuff. (I wish I could show an example, but my memory is extremely fragile and I’ve got no pre-rewrite history of the repo to check).
Four months later, nearly half the codebase is gone, and somehow it’s more robust with the same set of features (and more). I regret relying on LLMs in the first place, but hey, lesson learned. That said I think it’s still possible to create a healthy relationship with LLMs as long as you look at them as a fancy IDE feature. A lot of times they are just running long sed or regex commands that are a no-brainer act for humans when done by hand but still consumes a good time. For now and hopefully forever I think I’ll be going the old school way. Never rush your hobbies!
Btw this is how AMP looks like right now!
Worth mentioning that the blur shader is written in Zig based on this excellent blog post! .
Roadmap to v1.0:
One of the oldest Datasette plugins, and still one of my favorites. It now works with Datasette 1.0a42, and depends on the new datasette-leaflet to ensure OpenStreetMap tiles are requested with a referrer header.
Here's a map of power plants owned by California's PG&E , also demonstrating Datasette's recently redesigned facets :
I’ve used VS Code since I was about 16, so for almost ten years and honestly it was mostly fine. But as of late it has become unbearable: slow, and increasingly weighed down by AI slop. grahamperrin@ pointed out to me that VS Code now has
chat.disableAIFeatures
, and they’re right. I totally missed it! It really does turn the built-in AI features off atleast from what I can see in limited testing, and it works. But even with it off, VS Code still feels clunky as hell. Zed, on the other hand, is fast, and it had a native switch that turns all of its AI stuff off slightly earlier than VS Code did, which I absolutely adore. (It’s a toggle in Settings, or
"disable_ai": true
in your settings file.)
That’s not because I avoid LLMs. I just don’t want them trying to edit every line I write, or sitting in the corner judging me ominously. I still write most of my FOSS code myself: it keeps me sane, and I feel FOSS developers have a responsibility to keep code clean for LLMs to steal from lol. What I do hand off is the tiring part: regression testing, edge cases, and exploration beyond what my tiny 20-watt brain can hold. For that I use harnesses that work well with models, like OpenCode . Beyond auto-complete.. I’ve always found entire harnesses like claude code etc. very clunky in editors.
Zed has no FreeBSD remote server offering (yet), but FreeBSD can run Linux binaries in spades, so we use Zed’s Linux one. All you need is a FreeBSD server you can SSH into.
sudo sysrc linux_enable=YES
sudo service linux start
sudo pkg install linux_base-rl9
kldstat -m linux64 # should print a module
Zed asks the host what platform it runs. FreeBSD says
FreeBSD amd64
, there’s no server for that, and Zed gives up. This wrapper says
Linux x86_64
to that one question and passes everything else to the real
uname
. Save it as
~/.local/bin/uname
and make it executable:
#!/bin/sh
case "$#:$*" in
1:-sm|1:-ms) printf 'Linux x86_64\n' ;;
*) exec /usr/bin/uname "$@" ;;
esac
Put
~/.local/bin
on
PATH
for non-interactive SSH sessions. For zsh, add this to
~/.zshenv
(use your shell’s equivalent):
export PATH="$HOME/.local/bin:$PATH"It’s a small lie, but a contained one, and the part I’d love to retire.
Connect over SSH from Zed and open a folder. The first connection uploads the Linux server to
~/.zed_server/
. To watch, run
tail -f ~/.local/share/zed/logs/server-workspace-*.log
.
Without it you’ll connect fine and get an empty project tree, with this in the server log:
error processing entry failed to read directory entry
Caused by:
Invalid argument (os error 22)
The fix is
ec6629628cb
, in
main
,
stable/15
and
releng/15.2
, so 15.2-RELEASE will include it. If the error persists, check you booted the new kernel with
uname -v
.
To show your project, Zed asks the server for the names of the files in each folder, a few at a time. Zed sets aside a small amount of space for each batch.
Picture a teacher reading a class roll to a student who writes the names on a sticky note (I couldn’t come up with a better analogy, bare with me). The teacher crosses off each name as she reads it, and she never reads a crossed-off name again. The student’s note has room for 6 names. The teacher reads in groups of 4, a sensible habit that works fine almost every time. But 6 isn’t a whole number of groups, so she reads 8 names and crosses all 8 off. Only 6 fit on the note.
Now she’s in a bind. Her slip was grabbing more than fit before checking. She can’t hand over the 6 that fit and keep the other 2 for later, because they’re already crossed off and she would never read them again. So she reports an error instead, which at least is loud. When I tried the quiet way, 112 of my 1,002 files vanished (from the listing) with no warning. A loud error beats a quiet loss I’m pretty sure. Zed saw the error and decided it couldn’t read the folder, and showed it up empty.
The fix is small: read no more names than fit on the note. Read 6, cross off 6, come back for the next 6, until the roll is done. In the real bug, the teacher is FreeBSD’s Linux translator (Linuxulator), the note is a 768-byte buffer, and a group of 4 names is a 512-byte block.
This is a regression. A February 2026 fix for NFS directories returning bogus entries (
110f2567cb51
, PR
292282
) changed how
sys/compat/linux/linux_file.c
sizes its native read, in both
linux_getdents()
and
linux_getdents64()
:
/* before February 2026 */
buflen = min(args->count, MAXBSIZE);
/* after: every request rounded up to a 512-byte block */
buflen = min(roundup2(args->count, DEV_BSIZE), MAXBSIZE);
If the caller’s buffer isn’t a multiple of 512 bytes, the native batch can outgrow it. The emulation layer converts records until one doesn’t fit and returns
EINVAL
, but
kern_getdirentries()
has already advanced the directory offset past the whole batch. That’s why returning a partial batch isn’t enough on its own.
The fix ( ec6629628cb , reviewed in D60760 ):
if (args->count >= DEV_BSIZE)
buflen = min(args->count, MAXBSIZE);
else
buflen = roundup2(args->count, DEV_BSIZE);
It’s safe because Linux directory records are never larger than FreeBSD’s: for
dirent64
the header is 19 bytes against 24, and both round each record up to a multiple of 8. A native batch that fits in the caller’s buffer translates into one that fits too.
Legacy
getdents
had the same bug for 32-bit and 64-bit callers. My first patch only fixed
getdents64
; fixing both took the test matrix from 86 failures to zero.
I’ve had plenty of patches merged before this one, but this was among the quickest to land in
releng/15.2
: it didn’t sit in
stable
for long (thankfully!). The release engineering team (re@) runs a really cool process that I am yet to fully understand in depth. Thank you also to Kyle Evans (kevans@) and Mark Johnston (markj@) for reviewing the patch and for their notes along the way.
Please enable JS and disable any ad blocker
The upcoming Debian 13.8 point release will be the foundation of the first release of Debian Edu 13.
This is a call for testing, we are interested in your feedback.
See our Debian Edu 13 status page on the Debian Wiki:
https://wiki.debian.org/DebianEdu/Status/Trixie
Debian Edu comes with the Debian Edu manual, it can be found at:
https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/...
Please either directly submit bugs to Debian's bug tracker (package: debian-edu-config); talk to us on IRC
#debian-edu
on
irc.debian.org
or write to the Debian Edu mailing list.
[1]
https://cdimage.debian.org/debian-cd/current/amd64/iso-bd/debian-edu-13....
[2]
https://wiki.debian.org/DebianEdu/HowTo/TestInstallVirtualMachine#Varian...
[3]
https://release.debian.org/proposed-updates/stable.html
[4]
https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/...
Claude can now join your video calls as a visible participant, follow the conversation and start on work during the meeting. Claude Meetings is now in beta.
Your team can ask Claude questions during the meeting, out loud or in chat. By default, Claude answers in writing, and it can use your connected tools with your permission.
Claude also works with you live to build docs, whiteboards (opens in new tab) , or other artifacts, while teammates on the invite refine them. Claude writes the notes and action items, so no one on the call has to.
Claude Meetings is starting to roll out in beta on Team and Enterprise plans. Support for other video conferencing platforms is coming soon.
Say your team is planning a customer event, and Claude is on the call. You say, “Claude, start a doc for this plan.” Claude writes up what the team has said so far, and teammates on the invite can edit the plan while you keep talking.
When you start discussing the budget, someone asks Claude what last year’s event cost. Claude asks for their approval to look it up, posts it in the meeting chat, and compares it to the current plan. When you start discussing timelines, someone asks Claude to put it on a whiteboard, and the team works on the schedule alongside the doc.
Before the meeting ends, someone asks Claude to share a recap with the team. After the call, any notes, action items, plan, and whiteboard are on the meeting’s page in claude.ai (opens in new tab) .
Later, you can go back to meetings you were part of and ask Claude about them, or add Claude to the next one from your calendar in claude.ai.
We’re working with partners like Gong, Attention, Granola, Fireflies.ai, Otter, and Plaud, so you’ll soon be able to send a meeting’s transcript to the tools your team already uses.
Claude adds a separate page for each meeting in claude.ai (opens in new tab) with the notes, transcript, and anything it built. People from your organization on the invite can see it and edit what Claude made, and it can be shared with others in your organization from the page.
By default, Claude is set to stay out of calls when someone from outside your organization is invited, and to leave if someone from outside joins partway through. An admin can allow Claude on calls with outside guests. On those calls, Claude posts its notice in the call’s chat but doesn’t reply there, and what guests say is included in the notes and transcript.
Claude uses each person’s connected tools with that person’s permission. It asks the first time, and a yes applies going forward. For now, when someone asks out loud, Claude asks each time to confirm who’s speaking. An answer posted in the call’s chat is visible to everyone on the call.
When Claude joins, it appears as a participant and posts a notice in the call’s chat. It saves a transcript, summary, and screen descriptions, not audio.
Before you add Claude or turn on auto-join, make sure everyone on your calls is OK with being transcribed.
Claude joins when someone adds it or has auto-join on. Support is currently available for Google Meet, with other platforms coming soon. On Team plans, inviting Claude to your meetings is available by default, and an admin can turn it off. On Enterprise plans, an admin turns it on for all or part of the organization. While it’s in beta, it isn’t available to some organizations, including those with zero data retention (ZDR), HIPAA-ready configuration, or customer-managed encryption keys (CMEK).
During the beta, Claude’s notes and transcripts are free on Team and Enterprise plans. So are its answers in your calls, unless an answer uses one of your connected tools, which counts toward your plan’s usage. The docs, whiteboards, (opens in new tab) and other artifacts Claude makes in a call are free through February 10, 2027.
Setup steps are in the Help Center .
OpenStreetMap have a very reasonable policy that hits to their hosted tile server
should send a referrer header
. Datasette table pages used the
Referrer-Policy: no-referrer
HTTP header, causing plugins that loaded tiles from OpenStreetMap to violate that policy.
datasette-leaflet
is the plugin that loads a bundled Leaflet so other Datasette plugins can depend on it. It now sets the referrer policy on the tile requests themselves to
strict-origin-when-cross-origin
, passing the host but not the full path to the page.
Home Assistant's documentation tells users: "Your password is the key to your home, so choose a strong, unique one." Home Assistant is installed in two million homes by the vendor's own published count, and in those homes it holds the locks, the alarm, the garage, the cameras, and the record of who is home. The password is not the key. Tested against home-assistant/core 2026.11.0 (frontend 20261028.4, hass-nabucasa 2.8.1): 1. Every refresh token's secret and its per-token JWT signing key, for every user, is serialized in cleartext in one file: config/.storage/auth. Passwords in the neighbouring store are bcrypt-hashed; token secrets are not hashed at all — validation is a direct string comparison against the stored value. 2. Two of the three token classes never expire. Long-lived and system refresh tokens are created with expire_at = None; the long-lived access tokens the documentation recommends for scripts are valid for ten years, and the core API accepts a caller-supplied lifespan in days with no upper bound. 3. Changing the password revokes none of them. All four password-change entry points — self-service, administrator, Supervisor reset, command line — rehash the password record and make no token call. 4. The automatic-backup password is persisted in plaintext in .storage/backup, in the same directory every backup archives — and every settings backup carries .storage/auth inside it, so a restore resurrects backup-era tokens. Live proof, against our own instance only: after a real, verified password change, a refresh token copied from .storage/auth beforehand still minted fresh access, and a ten-year long-lived token minted beforehand still authenticated. Scope, stated plainly: this is not an unauthenticated network break. It begins with a read of the config directory or a backup. What it shows is that any such read — a backup file shared for support, a config folder synced somewhere it should not be, one file disclosure anywhere in the stack — becomes durable, password-change-resistant access to the home, and the one remediation every user reaches for first, changing the password, does nothing. Eleven documented claims were checked: 3 hold, 5 hold with a bound, 3 fall. What is sound is credited in the paper at the same weight: the token generation entropy is impeccable, and access tokens live thirty minutes. Paper: https://archive.org/details/knell-not-the-key Mirror: https://github.com/the-knell/not-the-key Key: 133883AB9F6EDE5B9BA6B82E27BEDAF0CE152F25 (knell) Verify: gpg --import knell-public.asc, then gpg --verify paper-ha-FINAL-2026-11-04.md.asc — knell More, signed and timestamped: https://github.com/the-knell _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
OKLAHOMA -
The National Weather Service reported nationwide internet and communication issues on Friday, Nov. 13, warning that some weather products may be unavailable or outdated on its websites.
In a notice posted on its website, the agency said technicians are working to resolve the disruption as quickly as possible.
“The NWS has been experiencing nation-wide internet and communications issues. You may not be able to access products on our webpages, or these products will be old. Technicians are actively working to resolve these issues as soon as possible,” the notice said.
The agency said local National Weather Service offices continue to issue watches, warnings and forecasts, which remain available through some external websites.
The NWS apologized for the inconvenience but did not provide a timeline for restoring normal website operations.
The nationwide disruption is affecting access to weather information on National Weather Service websites, including potentially outdated forecasts and other weather products.
The agency previously acknowledged an outage affecting its online radar platform, radar.weather.gov .
It remains unclear whether the problems are limited to online access and communications systems or are affecting other National Weather Service operations.
Despite the disruption, the agency said local offices are continuing to issue weather alerts and forecasts.
The National Weather Service issues were reported Friday as the Federal Aviation Administration separately ordered a nationwide ground stop affecting departing flights across the country.
The FAA said communication issues affecting Air Route Traffic Control Centers prompted the ground stop, which took effect at 2:54 p.m. Central Time.
READ MORE: FAA orders nationwide ground stop until 10 p.m. following communication issue
The FAA’s advisory listed an estimated end time of 10 p.m. Central Time, although officials had not confirmed when flights would resume.
There is no confirmed connection between the National Weather Service’s communication issues and the FAA’s ground stop.
The National Weather Service has not announced when full access to its websites and weather products will be restored.
Technicians are actively working to resolve the nationwide issues, according to the agency.
Local National Weather Service offices continue to issue watches, warnings and forecasts during the disruption.
Users can check weather.gov and radar.weather.gov for updates as service is restored.
Cassidy Mudd joined the News 9 team in June 2026 as a digital producer and is excited to tell the stories that matter most to Oklahomans.
Press play to start listening
Nothing leaves your speakers until you do.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
I am a public-interest technologist , working at the intersection of security, technology, and people. I've been writing about security issues on my blog since 2004, and in my monthly newsletter since 1998. I'm a fellow and lecturer at Harvard's Kennedy School and the Munk School at the University of Toronto, a board member of EFF , and the Chief of Security Architecture at Inrupt, Inc. This personal website expresses the opinions of none of those organizations.
What should a New York City museum actually be doing in 2026? And why is the new New Museum doing it right?
What should a New York City museum actually be doing in 2026? And why is the new New Museum doing it right? Julianne, Max, Chris, and Jessy discuss our institutions of culture this week on the podcast.
Also: Has A.I. done a honeypot to New York's financial future? And why hasn't Mayor Zohran Mamdani done anything to speed up safe charging locations for e-bike batteries? To start the whole thing off, we check in with everyone's favorite guest for the podcast—newly elected Congressmember Brad Lander.
Hell Gate to NYC Art Museums: Get Serious! | The Hell Gate Podcast
The latest from New York City's reader-funded news outlet, owned and run by journalists.
Like the pod? Got thoughts about the pod? Let us know in the comments!
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Hell Gate.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.
Josh Ruebner is policy director of the IMEU Policy Project and author of the forthcoming book The United States and Palestinian Nakba: A Transnational History, 1947-1950 .
After President Biden’s unrelenting support for Israel’s genocide in Gaza helped pave the way for President Trump’s reelection in 2024, Trump’s own foolish decision to launch an Israel-backed war against Iran played a large role in putting Democrats back in control of both chambers of Congress — a fact Vice President JD Vance diagnosed in no uncertain terms.
Now Democrats and Republicans alike have the opportunity to demonstrate they’ve finally learned the lesson voters have tried to deliver to both parties over the last three years: The American people do not want to be entangled and complicit in Israel’s aggression and atrocities. Their first opportunity to heed that call is arriving sooner than one might expect.
Right now, the House Armed Services Committee and Senate Armed Services Committee are engaged in an informal but highly consequential conference to finalize the text of the National Defense Authorization Act (NDAA), which sets policy for the Pentagon. A disturbing provision in current versions of the texts passed by the House and Senate committees would integrate Israeli weapons companies into the Pentagon procurement process at an unprecedented level — opening a back door to almost untraceably send billions of taxpayer dollars to Israeli weapons makers without congressional oversight. The House bill would create a new “executive agent” position within the Pentagon to steer this integration —a level of amalgamation that exceeds collaboration with nations in NATO.
Members of Congress on both sides of the aisle are opposing this provision. On Tuesday, Sen. Chris Van Hollen and nine other Democratic senators, plus independent Bernie Sanders, demanded it be removed. In the House, Democrat Ro Khanna and Republican Thomas Massie have made clear they will also try to strip the NDAA of this measure. In doing so, they are representing what the vast majority of Americans want—and their colleagues should take note.
In our August polling with Data for Progress, 75 percent of Democratic voters oppose this provision, as do 58 percent of independents and 42 percent of Republicans. In addition, polling shows a majority of Americans now want to see taxpayer funding to Israel reduced or ended. Passing the NDAA with this measure would mean that even if Congress zeroed out annual weapons funding to Israel, currently at $3.3 billion per year, in the State Department budget — earlier this year, 103 Democratic representatives joined Massie in a move to do just that — there could still be a major increase in actual dollars flowing to Israeli companies that the American people never hear about.
The negative repercussions extend beyond funding Israeli weapons makers (some of which are government-owned) with our tax dollars. This sort of integration could allow for Israeli weapons and surveillance technology that have been tested on Palestinians to be used in the U.S. to advance the Trump administration’s cruel mass deportation program. Israeli weapons maker Elbit Systems’s U.S. subsidiary is expected to install more than 300 surveillance towers along the U.S.-Mexico border, developed from its technology deployed along portions of Israel’s apartheid wall in the West Bank.
Melding Israel into our government procurement process should also set off alarm bells in the U.S. national security world. The Washington Post reported earlier this year that Israeli Prime Minister Benjamin Netanyahu vetoed Biden’s decision to send U.S.-Israeli co-produced missile systems to Ukraine three years ago for Ukraine’s war against Russia, even though the missiles were paid for by American taxpayers. The integration measure proposed in the NDAA would massively expand the scope of weapons over which the Israeli government could exercise a unilateral veto.
Congress should be unwinding intelligence cooperation with Israel, not only on the moral grounds that no part of the U.S. national security apparatus should assist in genocide, but also because Pentagon officials raised the threat of Israeli spying to its highest possible level earlier this year. But instead of diminishing our intelligence sharing with Israel, the Senate Select Committee on Intelligence’s FY27 Intelligence Authorization Act, which is typically incorporated into the final NDAA version, includes a provision (Sec. 618) actually mandating the president engage in even more intelligence cooperation.
This should give us pause because of the faulty nature of Israeli intelligence and the way Israel used this intelligence to build a case for dragging the United States into war. It was reportedly Israeli intelligence that claimed the Iranian government could be overthrown within weeks, if not days, of Trump launching the war. Instead, Trump and Netanyahu are now stuck in a quagmire, and the war has imposed a terrible cost on the American people, U.S. servicemembers, and people across Iran and the region. Energy prices around the world have skyrocketed, the cost of the war has already exceeded $2,000 per U.S. household on average, and the U.S. is running low on interceptor missiles that will take years to replenish.
None of this seems to concern the main backers of U.S.-Israel military and intelligence integration, like Foundation for Defense of Democracies President Mark Dubowitz. In a column published in Israel Hayom , the right-wing newspaper owned by the Israeli-American GOP megadonor Miriam Adelson, Dubowitz said: “Israel and the United States should deepen their military, technological, intelligence, and economic integration to such an extent that inflicting financial harm on Israel would also carry a significant cost for Washington.”
In an interview , Dubowitz added that the U.S. and Israel should be so intertwined that any accountability measure against Israel, such as sanctions being enacted by American allies in Europe, would “impose costs on the U.S. itself.” In no uncertain terms, advocates for the integration envisioned in the NDAA want to try to make it impossible for the U.S. to disentangle itself from a regime that is increasingly perceived by many as a rogue actor.
The NDAA is usually considered a “must pass” bill in Congress — in fact, Congress has passed annual defense authorizations for 65 consecutive years. But Congress is under no statutory obligation to pass it this year, and doing so without stripping these provisions to become even more entrenched with supporting Israel would be an immediate betrayal of the will of voters. At a time when even Republicans are openly admitting the midterm election was a referendum on U.S. support for Israel, it would be an unforgivable choice for Congress to pass an NDAA with these integration provisions. If Republicans use their committee majorities to force their inclusion in the bill’s final text, Democrats have every bit of leverage to filibuster and block the bill’s passage in the Senate, which requires 60 votes.
Saying no to bringing the U.S. into a closer relationship with Israel in just about the most expensive, opaque, and dangerous way imaginable should be the easiest political decision Congress makes during its current lame-duck session.
Welcome to the October 2026 report from the Reproducible Builds project!
In our reports, we try to outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third parties to come to a consensus on whether a build was compromised or not.
As ever, if you are interested in contributing to the project, please visit our Contribute page on our website.
In this month’s report, we cover:
SOURCE_DATE_EPOCH
specification updates
Johannes Schauer Marin Rodrigues (
josch
)
reported an issue to the GNU
tar
mailing list
where creating PAX-format sparse tar archives produces unreproducible outputs. Specifically, when GNU
tar
generates a PAX archive containing a sparse file it embeds the process ID into the member filename path structure (e.g.
./GNUSparseFile.<pid>/<filename>
). Because process IDs vary between build runs, however, archiving identical sparse input files yields different binary outputs.
In his report, Johannes outlined potential workarounds, such as running
tar
inside an unshared PID namespace where the process ID is pinned to
1
, and proposed that GNU
tar
either omit the PID by default or provide a command-line flag to suppress it. Full details can be found in the
post itself
, and Johannes also
filed the bug in Debian
for completeness.
Reproducible Builds was present at SeaGL in Seattle, WA, on October 23rd & 24th. Thanks to everyone who attended and spoke with us!
Members of the Reproducible Builds project attended SeaGL (the Seattle GNU/Linux Conference) in Seattle, WA, on October 23rd & 24th. It was a fantastic opportunity to connect with local community members, discuss software supply chain security and share updates on build verification tooling. Thanks to everyone who stopped by our sessions or spoke with us during the event.
Founded in 2013, SeaGL is an annual free-as-in-freedom, grassroots technical summit dedicated to spreading awareness, community engagement and practical knowledge about free software, open hardware and libre culture.
diffoscope
is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including preparing and uploading versions
333
,
334
,
335
and
336
to Debian:
New features:
dumppdf
binary being called
dumppdf.py
on the host/runtime system. [
…
]
Bug fixes:
Codebase improvements:
Misc:
In addition, Johannes Schauer Marin Rodrigues added support for POSIX.1-2001 PAX headers in the
.tar
file comparator [
…
] and Vagrant Cascadian
proposed an update in
diffoscope
in GNU Guix to version
335
.
In Debian this month, 20 reviews of Debian packages were added, 28 were updated and 27 were removed this month adding to
our knowledge about identified issues
. One issue type was updated to reflect that Debhelper ‘
compat
’ level 14 is no longer experimental. [
…
]
In addition, Vagrant Cascadian performed a number of
Non-Maintainer Uploads
(NMUs) and
Quality Assurance (QA) uploads
in Debian for several packages with outstanding reproducibility issues. These included
clhep
,
tea-cli
,
argparse-manpage
,
ruby-timers
,
mandos
and
cdebootstrap
.
Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their reproducibility work there.
SOURCE_DATE_EPOCH
specification updates
As announced in
last month’s report
, further work has been done by Bernhard M. Wiedemann regarding updating the
SOURCE_DATE_EPOCH
specification
following discussions at a project summit. Seven distinct proposed changes were originally
submitted as merge requests on Salsa
, and
many of these have been approved or otherwise collapsed
.
Bernhard’s proposed modifications were independent of one another, allowing for any combination to be merged depending on community feedback. Bernhard noted that one proposal may see the most debate, and could still benefit from further refinement before reaching consensus. Community members are invited to review and provide feedback on the individual merge requests; as Bernhard writes , “The other MRs could still use feedback from more people before December”. Input can be submitted via reactions or comments on Salsa, directly by email to Bernhard or the mailing list.
The
SOURCE_DATE_EPOCH
specification was first published in 2015 and updated in 2017.
On our mailing list this month:
Robin Candau posted to the list to announce the revival of a central repository to share reproducible builds patches . Following discussions at this year’s Reproducible Builds summit , Robin and Bernhard M. Wiedemann brought back a repository originally created a decade ago to collect distro-specific fixes in a unified location. Bernhard has already populated the repository with reproducible builds patches from openSUSE, while Robin has contributed patches from Arch Linux and has invited maintainers from other distributions to request push access.
Last month, Alexander Sosedkin inquired on the mailing list about the preferred approach for sourcing pinned translation files to create reproducible GnuTLS release tarballs, asking whether external hosting should provide versioned downloads, or if projects ought to use Git submodules, dedicated side-repositories or some other mechanism. The conversation continued this month with a number of proposals.
Jeremy Bícha
wrote that he was seeking assistance
with a reproducibility failure in GNOME’s
libsoup
library when built using
debrebuild
. Filed as
Debian bug #1126440
, the issue stems from a Meson build system check that inspects Apache and its local configuration during the build process, which fails inside
debrebuild
environments. His query solicited
a number of replies
(including
one from an AI agent
).
Janneke Nieuwenhuizen and Ekaitz Zarraga announced two releases of GNU Mes : version 0.27.2 and version 0.28 . GNU Mes is a Scheme interpreter and C compiler created to facilitate bootstrapping the GNU system without relying on opaque binary blobs, serving as a core component of the Bootstrappable Builds effort. Version 0.27.2 serves as a bug-fix release adding compatibility for the recently-released GCC 16 and NYACC versions 2.02.4 and 3.00.0, etc. whilst version 0.28 introduces a major overhaul of the core interpreter.
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where applicable or possible. This month, we wrote a large number of such patches, including:
Bernhard M. Wiedemann:
Chris Lamb:
js8call
.
pywps
.
php-nesbot-carbon
.
kicad-library-utils
.
ros-dynamic-reconfigure
.
golang-github-anacrolix-log
.
complexity
.
node-uplot
.
python-poetry-dynamic-versioning
.
Jochen Sprickerhof:
open-build-service
.
Johannes Schauer Marin Rodrigues:
Vagrant Cascadian:
Zackary Loevseth:
In addition, two build failure bugs were reported by Jochen Sprickerhof.
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
IRC:
#reproducible-builds
on
irc.oftc.net
.
Mastodon: @reproducible_builds@fosstodon.org
Mailing list:
rb-general@lists.reproducible-builds.org
Privacy, which companies were once happy to claim was all about personal choice, is now primed to affect everyone around you even more than it already did.
Meta and Google’s smart glasses can record anything the owner is looking at or use artificial intelligence to describe it. Apple’s* Audio Intelligence feature turns every Apple Watch into a transcription machine that records or summarizes your day. Amazon’s Bee devices take that a step further and can record and transcribe everything. Dozens of other companies are introducing pendants , rings , and other products designed to record, transcribe, or summarize everything we say and do all day long.
Privacy has always been a team sport. The actions you take with communication apps , collaborative software , or your cloud backup solutions , have long impacted everyone else you’re interacting with. But moving those choices deeper into the physical world where strangers, colleagues, family, and friends are all now a part of your privacy choices is drastically changing the game.
Tech companies want us to accept a reality where one person’s privacy choices (or lack thereof) means you suddenly need to be an expert in consumer tech who understands the capabilities of many devices on the market, how they work, how and if they signal when they’re recording, and what platforms they do or do not connect to. They believe these ambient surveillance devices that work in the background and are designed to look as normal as possible are the future, while they also expect the owners of these devices to use them responsibly and to notify those around them of their capabilities to act within whatever laws their states may have.
This is not reasonable, nor how consent works in any practical sense.
Let’s break this down by looking at some of the biggest players currently in the game: Apple and Amazon, who have two different takes on transcribing audio throughout the day, as well as Meta and Google, who both have slapped AI and cameras onto eyeglasses.
Ask Apple about privacy concerns and they’ll point to a white paper that explains all the technical barriers between them as a company and the data generated by the watch. Ask Meta and they’ll talk about all the ways you can customize the privacy controls or how certain details, like faces, may be blurred out when you interact with Meta AI through the glasses (but not during standard recording). Google does this too . Amazon will also talk about how you’re always in control , and no audio is stored (though it’ll also let you enable Amazon store integration, so your conversations can directly result in ads for products). And so on across all the companies making these products.
Some of these solutions do a better job than others at cutting out potential law enforcement or company access to this data. There will be a time to dive into these details more deeply, but the technical privacy promises these companies focus on only cover the consumer and user of the device. They ignore every bystander you interact with and their inability to actually opt out. There is no technical protection for you as a non-user of these devices, the person who finds yourself captured by them.
Still, we hope to look deeper into the technical differences between this category of devices soon.
With something like Apple’s Audio Intelligence and Amazon’s Bee devices, it may be best to treat them similar to an always-recording microphone, even if companies try to claim there’s “technically” no audio recording. These tools still often use a microphone to capture raw audio from conversations and convert it into summaries or transcripts before discarding the audio. Google's blog post notes that it has whole responsible use part of their Terms of Service where users have to agree not to record others without permission or in sensitive places.
But it’s not just the question of the legality from the point of view of the user. Law enforcement will eventually try to compel access to the data that these products create (either real-time audio or the summaries and transcripts they create). And while some products, like Apple’s Audio Intelligence, are engineered to make that difficult, not every product will be. We know from history that when data exists, governments will do everything they can to access it. There’s no reason to think something would change today.
There is a problem humming along in the background that is impossible to address with technical or legal solutions. If secretly documenting conversations becomes the norm, it makes every private conversation less spontaneous and open. It breaks a longstanding social norm that you will not record and document every conversation with friends, family, colleagues, or strangers.
The companies that make these sorts of products like to claim they’re no different from tools we already have. You can easily record everything right now with a phone or a camera. Heck, you can do so with a camcorder or cassette recorder if you want. And you can transcribe conversations with pen and paper, too. But those are actionable steps we take that both require effort from the user, and are clear to others around us. This new wave of passive surveillance tech is designed to encourage continuous monitoring and hide its use.
Even taken at face value, none of these products can understand the complex social context we all navigate every day. We intrinsically know there are different social agreements we all make when we’re standing on a street corner, at a protest, in a bathroom, at a doctor’s office, at the gym, or in a restaurant. Taking notes in a meeting at work is completely normal. Getting a summary of a conversation with your best friend about their divorce is not. Always-on monitoring of our conversations is an unacceptable burden on our conversational privacy.
Google seems to all but admit this problem in a conversation with CNN when it described the company’s experiments with a notification system that would alert people’s phones when someone was recording nearby:
“And just alerting bystanders doesn’t do much to help, [Juston Payne, senior director of product management at Google] said. “It can actually be weirdly disempowering to you in that you’re like, ‘What am I meant to do now?’” he said.”
It’s easy to buy into the tech company line that these products are inevitable, but we’ve seen so many vaporware products over the years that we should take those claims of success with a grain of salt. We’ve seen entire product categories come and go within just a few years, and if the public doesn’t want this stuff, the tech companies will have to throw in the towel.
Of course, that doesn’t mean we all just have to sit around and hope that’s what happens. For its part, Apple launched its Audio Intelligence features in beta specifically to get feedback, and we think it’s worth taking the time to fill out their feedback forms (or in the Feedback Assistant app if you’re in the beta) and let them know what you think.
Products from the likes of Meta, Google, Amazon, and others might be harder to push back on, but politely and clearly engaging with those who use them in ways that make you uncomfortable is a good place to start. And if you see abusive videos on social networks where these sorts of products are used, report them. If you find these products useful for yourself, make it clear to those around you when you’re using them, and only do so with consent and in social moments where it makes sense to do so.
*Apple is an EFF donor. EFF donors do not influence our agenda or our positions.
The Microsoft Outlook outage has shaken up companies and local governments across the US that use its suite of email, calendar, video conferencing and cloud storage systems.
Even as Outlook started to resume normal operations Friday morning, local leaders from across the country, including in Miami, Maryland and Los Angeles, warned residents that certain staff or services were still unavailable due to the outage that started around 1pm ET on Thursday.
In Colorado, one local detention facility in Arapahoe county said that they were unable to take online bond payments to release detainees because of the outage.
“Until Outlook email is restored, anyone needing to post bond for immediate release must do so in person at the jail,” the office said in a social media statement.
The Los Angeles county sheriff’s department also warned that it was experiencing disruptions in its email and other communications platforms.
Emergency management services in Fredericksburg and Gillespie county in Texas said they were unable to receive emails and encouraged residents and partners to call instead.
Around Maryland, the Washington suburban sanitary commission, which provides safe drinking water and sewer treatment to parts of Maryland, said that its technicians may be delayed due to the outage, and some customers may have trouble making their water bill payments.
In Washington DC, congressional staffers continued to lament the outage’s impact during the lame duck session of Congress. Some told Politico that the disruptions were particularly disruptive as their offices were in the middle of negotiating pending legislation before the end of the year and planning for the next Congress.
“Shall we start conducting all official business via DM?” wrote Sharon Eliza Nichols, the director of communications for congresswoman Eleanor Holmes Norton of Washington DC.
Some school districts in Richmond, Virginia, and Port Washington, New York, also told parents on Friday morning that they were experiencing outages, and asked them to reach out by phone or through other online educational platforms to reach their child’s school, while the Albany school district said that it had restored its services.
The Colorado School of Mines encouraged “faculty to be flexible with assignment deadlines and understanding of students who cannot complete assignments due to unavailability of Microsoft tools”, though many of its systems were on unaffected platforms such as Google Workspace and Canvas.
Claude, whose developer, Anthropic, is gearing up for its upcoming stock market debut with a valuation of up to $1.4tn, also said that it was starting to see signs of recovery from the Microsoft outages, but warned that some users may still receive errors. OpenAI also said it was still investigating issues with “Microsoft connectors” that were degrading performance.
“We’re investigating an issue with Microsoft connectors where new connections may be broken and tools are not working as expected. We’ll share an update when we know more,” the company said.
On Wall Street, Workhorse Group, an industrial manufacturer, rescheduled its Q3 earnings call that was scheduled for Thursday afternoon because of the outage.
In a social media post , Microsoft executive Charles Lamanna said late Thursday that “there is no indication this is the result of malicious or cyber activity”.
On Friday morning, Microsoft noted “improvements in service availability” but noted that “some users may still experience intermittent access issues or delayed email delivery as a recovery continues”.
By the end of the day, most of the issues seemed to be ironed out. Schools and businesses appeared to be coming back online, congressional staffers reported “improvements to Outlook’s functionality”. The Colorado detention facility said it is “now receiving email notifications when online bond payments are made”.
And the emergency management services in Texas said they were starting to see emails trickle back in, saying : “Thanks for your patience with the worldwide outage!”
Dara Kerr and Johana Bhuiyan contributed reporting
Issued by the FAA just moments ago, ALL US airports are currently ground stopped. This means NO flights may depart for US airports. Flights already in the air will be allowed to land. This is related to an FAA equipment outage.
| ATCSCC Advisory | |||
|---|---|---|---|
|
Much of the air traffic across the U.S. was suddenly shut down Friday after the Federal Aviation Administration ordered a nationwide ground stop for all departing flights “due to extraordinary circumstances and for reasons of safety.”
The unexpected and highly unusual alert, which was issued at 3:54 p.m. ET, contained no other information beyond stating that “all departing traffic should remain ground stopped until further notice.”
Follow along for live coverage.
“Inbound international flights will be managed on a case by case basis,” the FAA said.
When the FAA issued the alert, 4,042 flights headed for U.S. destinations were airborne, according to Flightradar24 , a Swedish service that displays real-time aircraft flight tracking information.
Homeland Security Secretary Markwayne Mullin said there was “no indication as of yet” that there was anything “nefarious” that caused the ground stop. He said it was the result of a telecommunications outage “as of now.”
Mullin said President Donald Trump has been briefed and they are “are not ruling out anything at this point” in terms of what caused the communications issue. He said those currently on flights have no reason for concern. “We are assured that everybody is safe,” he said.
While the investigation into the failure is in a very early stage, there is no indication that the incident has been caused by malicious activity, officials from multiple agencies that are involved in the situation tell NBC News.
They say they haven’t seen the type of activity that would normally be associated with a cyberattack. The officials, however, cautioned that the assessment could change as investigators learn more.
Three senior officials say there’s nothing that indicates a connection between Friday’s incident with the FAA’s systems and the Microsoft outage.
By 6 p.m., Reagan Washington National Airport in Arlington, Virginia, was at capacity, and Chicago O’Hare International Airport was nearing capacity, meaning there was no place for the planes to park, a source with knowledge told NBC News.
With planes stranded on runway, the likelihood increased that some of these planes would have to be diverted to other airports, the source said.
Meanwhile, Air Space Intelligence, the AI tech startup that is a vendor for the FAA on its new SMART system for air traffic control, insisted its software was not responsible for nationwide ground stop.
“The current ground stop is not based on or a result of the SMART system, any product of ASI or our integration with FAA and ATC,” the company said in a statement posted to X .
Aviation safety expert Jeff Guzzetti called the outage “extraordinary” and said he doesn’t know what would cause it.
Guzzetti emphasized that pilots are trained to operate through communications outages and that there are redundancies in place for such instances. Pilots “could get information relayed through other means” to ensure planes are spaced properly for landing.
He added that the situation is moving from a safety issue to instead becoming a massive logistics problem. Airports are becoming crowded with planes trying to land as the aircraft currently on the ground aren’t able to depart. Planes on the ground may have to move and park on taxiways, Guzzetti said.
There are different layers of communications — high-altitude, midlevel and then the towers on the ground. The high-altitude control centers are affected by the outage.
At Newark Liberty International Airport, personnel in the control tower said the situation is “a whole mess right now,” according to LiveATC. “We’re running out of space” and “there’s significant gate issues” were comments also heard on the live audio feed.
“I’m as much in the dark as everyone else. I’m not getting any information from anybody,” one controller at Newark said, according to the feed.
Shortly before the FAA issued its alert, both major airports in Chicago — O’Hare and Midway International Airport — were listed on a ground stop alert due to an “equipment outage,” NBC Chicago reported.
Deveren Werne was on an American Airlines jet that was about to take off from Indianapolis to Chicago when suddenly the pilots announced that all flights were grounded.
“At first, the pilot announced that there was some kind of radio issue,” Werne, 55, of Greenville, South Carolina, told NBC News in a telephone interview. “Then a little while later, the pilot said something like, ‘There is something going on that’s more serious than that.’”
Werne, a consultant who helps manufacturers and other industries adapt AI technology, said he is a frequent flyer and this was a first for him. He said there was “a mixture of emotions” from his fellow passengers on hearing the announcement.
“Then I started hearing from other friends who were on planes, including one in Chicago who was stuck on a runway,” Werne said. “Right now, our plane is heading back to the terminal, so at least we’re going to be able to deplane.”
United Airlines issued a statement acknowledging the ground stop. “United flights that are already airborne will continue,” the statement said. “New domestic flights will not depart while the FAA ground stop remains in place.”
Nationwide ground stops are extremely rare.
After the Sept. 11, 2001, terrorist attacks, the FAA ordered an unprecedented nationwide ground stop. All civilian air traffic across U.S. airspace was halted and airborne planes were ordered to land at the nearest available airports.
In January 2023, the FAA grounded all flights, blaming a failure in the Notice to Air Missions system, which alerts pilots to a host of potential dangers.
This is a developing story. Please check back for updates.
Microsoft has said it is “deeply sorry” for the disruption caused by the global outage , which it said was caused by “a technical issue not related to cyber or AI / agents”. The company added: “We are deeply sorry for the disruption this incident has caused our customers and partners. We know the trust they place in our services and take that responsibility extremely seriously. We are seeing broad recovery and stability across our services.”
Stocks fell in shaky trading on Wall Street on Friday, but the market remains on track for a winning week. Microsoft rose 0.2%, despite suffering a global outage for its web services that disrupted email accounts and other applications.
The Microsoft outage was preventing some US prison inmates from being released. The Arapahoe County Sheriff’s Office in Colorado, USA, warned they could not process bond payments, as they rely on Outlook email notifications. So unless the money is handed over in person, people could not be let out.
Some US cities reported their Microsoft services are now returning after the global outage. The sheriff’s office in Arapahoe County, Colorado, which previously reported the outage was affecting online bond payments, said the issue has been resolved. The police department of Greensboro, North Carolina, also saw its services restored. It joked: “While it’s not the outcome we wanted, we would like to let you know that our email is working again.”
The UK government has been working with Microsoft to understand the full impact of the outage on public services, the cyber minister Baroness Elizabeth Lloyd said. She said it mainly hit “back-office functions”, such as email and messaging, with 999 calls and the NHS 111 line unaffected.
Key events
A summary of today’s developments
Stocks sway as Wall Street heads for a winning week after several turbulent days
Microsoft says it is 'deeply sorry' for disruption and that outage is 'not related to cyber or AI'
Explainer: A global Microsoft 365 outage has hit millions – what happened and when will it be fixed?
Microsoft: 'We remain focused on addressing residual impact'
Microsoft: We’re observing sustained improvements in service availability
US jail unable to release prisoners due to Microsoft outage
Tampa: emails disrupted, full restoration expected within 48 hours
Microsoft: continuing to see improvements
MS: 'broader improvements' in North America
Yes, US readers, it's still broken
Microsoft reports 'encouraging' progress in recovery in Europe
Microsoft: We've made more progress
NHS England: Staff are turning to paper records
Schools inspector Ofsted, and universities, hit by outage
Railway passengers may have problems with emailed tickets
Bank of England caught up in Outlook outage
UK healthcare system seeing 'widespread' and 'serious' disruption
Microsoft: We're seeing 'early signs of stabilization'
Tell us: have you been affected by the Microsoft outage?
NHS organisations reports issues with Outlook and Teams
UK government putting 'contingency plans' in place
UK police can't receive crime reports online due to Microsoft problems
Schools: Phone, don't email!
UK government engineers 'working with Microsoft' now
Microsoft outage: The state of play
Microsoft outage has "major impact" in Japan
Microsoft: we're seeing positive results for server stability
Microsoft: seeing 'marginal success' patching servers
Tech giants and international airlines say they’ve been hit by outage
Microsoft’s global outage will cost Australia billions, expert says
Microsoft outage may persist as fix is 'not taking as expected'
Victorian government warns of opportunistic scammers amid outage
'Looks like we will have to talk to people’: Australians on their email-free day
WA government: 'Microsoft are prioritising life, safety and Government services'
What we know so far about the global Microsoft outage
Microsoft having issues bringing servers back online
Microsoft ‘do not believe they are dealing with a cyber event’, Tony Burke says
Schools, courts and public service staff affected
Thousands of Australians report issues with Microsoft 365
Welcome
The UK government has been working with Microsoft to understand the full impact of the outage on public services, the cyber minister Baroness Elizabeth Lloyd said.
She said it mainly hit “back-office functions”, such as email and messaging, with 999 calls and the NHS 111 line unaffected.
Lloyd added that this has been “inconvenient and disruptive.”
“Throughout the day, we have seen limited reports of impact on frontline service delivery, and I encourage people to follow advice from the services they need on alternative ways to get in touch where email or web forms may be unavailable,” she added.
Hospitals, GPs, police forces and property agents across the UK have been hit by the global Microsoft outage . Here’s how the disruption to email and other IT facilities has affected key services.
The NHS experienced “serious” and “widespread” disruption across the UK on Friday as a result of the Microsoft outage, with hundreds of hospitals, GP surgeries and community health services affected, senior health sources said.
While some doctors, hospital workers and NHS night staff told the Guardian they first noticed problems accessing emails during the early hours of Friday morning, the severity of the problem became apparent to most from about 6am.
The NHS.net Connect system – which more than one million NHS staff use for emails, meetings, calendars, file access and other tasks – is powered by Microsoft . The outage meant many could not log in, perform basic duties, or send and receive patient data needed for the delivery of healthcare.
NHS sources said the outage caused disruption to a range of Microsoft 365 services relied upon by staff, including Outlook, Teams, SharePoint, OneDrive and Copilot. The Medicines and Healthcare products Regulatory Agency also said it was experiencing problems sending and receiving emails.
Some staff resorted to using patients’ paper records after being unable to access email and other IT facilities. An NHS England spokesperson said: “Local NHS services are enacting longstanding measures to manage IT outages and ensure critical services and appointments can continue for patients today.”
Patients were urged to attend appointments on Friday unless advised otherwise, and to continue using 999 for emergency situations.
Stocks fell in shaky trading on Wall Street on Friday, but the market remains on track for a winning week.
Microsoft rose 0.2% , despite suffering a global outage for its web services that disrupted email accounts and other applications.
Some US cities have reported their Microsoft services are now returning after the global outage.
The sheriff’s office in Arapahoe County, Colorado, which previously reported the outage was affecting online bond payments, said the issue has been resolved.
The police department of Greensboro, North Carolina, also saw its services restored. It joked: “While it’s not the outcome we wanted, we would like to let you know that our email is working again.”
Jacksonville, Florida, said it was “seeing some services restored this morning and remain cautiously optimistic they will continue making progress.”
Austin and Dallas, Texas, also reported progress on their email services being restored, CNN reported.
Gaya Gupta
The Microsoft Outlook outage has shaken up companies and local governments across the US that use its suite of email, calendar, video conferencing and cloud storage systems.
Even as Outlook started to resume normal operations Friday morning, local leaders from across the country, including in Miami, Maryland and Los Angeles, warned residents that certain staff or services were still unavailable due to the outage that started around 1pm ET on Thursday.
In Colorado, one local detention facility in Arapahoe county said that they were unable to take online bond payments to release detainees because of the outage.
“Until Outlook email is restored, anyone needing to post bond for immediate release must do so in person at the jail,” the office said in a social media statement.
The Los Angeles county sheriff’s department also warned that it was experiencing disruptions in its email and other communications platforms.
Emergency management services in Fredericksburg and Gillespie county in Texas said they were unable to receive emails and encouraged residents and partners to call instead.
Around Maryland, the Washington suburban sanitary commission, which provides safe drinking water and sewer treatment to parts of Maryland, said that its technicians may be delayed due to the outage, and some customers may have trouble making their water bill payments.
Microsoft has said it is “deeply sorry” for the disruption caused by the outage, which it said was caused by “a technical issue not related to cyber or AI / agents”.
The company said in a statement:
We are deeply sorry for the disruption this incident has caused our customers and partners. We know the trust they place in our services and take that responsibility extremely seriously. We are seeing broad recovery and stability across our services.
This was a technical issue not related to cyber or AI / agents. The incident was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change. We have addressed the underlying issue and continue to restore service to remaining customers and regions.
Given the scale of demand, we restored services gradually, validating stability at each stage. While this took longer, it helped ensure a stable restoration.
We will provide a full post-incident report once our review is complete.
As my colleagues explain , UK politicians and experts have said that the Microsoft outage has laid bare the world’s dangerous dependence on cloud services provided by a few massive US tech companies – Amazon, Google and Microsoft.
This reliance has been a growing source of unease through each high-profile outage. It has grown more pronounced because of the hostility of the Trump administration towards Europe, which has prompted some governments to consider alternatives to US software.
As the name Microsoft 365 implies, the world has quickly become accustomed to online services being available 24/7. Given software is no longer solely downloaded to individual PCs but is also stored on a server owned by a company, outages such as this will happen. Most of the time they are brief but sometimes they are not.
Outages in recent years from telecommunications providers , from the PHP incident to the Crowdstrike incident , show just how varied the sources and causes of a massive outage can be.
There are many different pieces of the puzzle keeping services online – but the effect of one of those services going down is much greater than it ever has been.
Mark Gregory, an associate professor at Australia’s RMIT University, said it was important for organisations to thoroughly test updates before rolling them out to the live network. That was in addition to the extra security testing companies must carry out to ensure their services are protected from threat actors armed with AI tools that can find vulnerabilities quicker than ever before.
Gregory said companies that relied on services such as Microsoft 365 should have backup options such as Google’s Gmail in the event of an outage . Others have suggested the free and open-source Office alternative LibreOffice .
Around the world, it has become increasingly clear that many companies – and government services – do not have good backups, with businesses resorting to faxes and phones.
The Forrester analyst Dario Maisto said the outage “represents the perfect quasi-natural experiment for stress testing an organisation’s – and even an entire continent’s – digital sovereignty posture”, forcing governments to consider what might happen if mailing services and key tools such as Copilot were interrupted.
Josh Taylor , Aisha Down and Mark Sweney
Millions of people were unable to access their emails, Teams chats or meetings on Thursday night and Friday after a Microsoft 365 outage brought down services across the globe.
The outage has lasted for more than 21 hours, with meaningful signs of recovery visible beginning shortly before midday GMT on Friday. It affected businesses, government agencies and even Microsoft employees all over the world. Those reporting issues have included the US House of Representatives, an Australian spy agency , airlines in India, European government agencies, and police services, ambulances and hospitals in the UK .
Microsoft is still investigating the cause of the outage, which it has said is not a cyber-attack but a configuration error. While the effects of the incident are global, they are also patchy; some users are still able to access some aspects of Microsoft’s service, and service is resuming in some parts of the world faster than in others. Microsoft said it continued to see improvements, with “email queues significantly reduced and approaching normal levels”, but some users may still experience issues.
What happened with Microsoft?
At about 6pm GMT on Thursday, the outage website Down Detector showed an increase in users reporting issues with Microsoft 365, the suite of cloud software that includes Teams, Word Excel, PowerPoint and Outlook.
The outage has lasted for more than 21 hours at the time of reporting, with significant recovery beginning at 11:20 GMT on Friday, according to data shared by the research firm Infoblox.
By Friday morning, Microsoft had narrowed down most of the problems to Microsoft Exchange, the email service behind Outlook. Teams meetings and chats had returned to service.
By midday UK time, Microsoft said there was “encouraging recovery progress in Europe”, improvements in North America and Asia Pacific, and Japan was “stable”.
What caused the Microsoft outage?
Microsoft has said that this was not the result of a cyber-attack, though suspicions were high because of a number of cyber-attacks that have hit organisations in Europe in recent weeks. So far, the problem appeared to be a configuration update that resulted in some servers becoming overloaded and taken offline, Microsoft indicated.
When the company attempted to apply a fix, servers that had come back online again became unresponsive when traffic began returning to them.
As some servers went down, traffic was funnelled on to the remaining servers, causing traffic problems for those remaining online.
To understand what was bringing down the servers, the company began limiting the traffic that could reach affected servers in specific locations, and on some servers rolled back to an earlier software configuration to see if it fixed the problem.
More details are likely to emerge over the coming weeks. “We don’t know what actually went wrong, and that will take weeks to discover,” said Steven Murdoch, a professor of security engineering at University College London. “The people who are working on it are too busy fixing to understand or report on the cause.”
Murdoch said there was likely to be a proper postmortem on an outage of this size, but not for a few weeks.
Why has Microsoft 365 been down for so long?
An outage that runs for so long for a service as critical as Microsoft 365 is unusual. The company has not said why it has lasted this long, but a clue might be in its updates: as servers returned to being unresponsive after being fixed, engineers had to work through alternative solutions, taking longer than expected to get servers back up and running.
Murdoch said an outage of this size was usually “the result of some surprising interaction between systems. Each of the systems is normally quite well understood but interactions between them are complex and frequently the cause of large outages like this.
“It’s very hard to build a complex system without there being some risk of some failure.”
My colleagues answer more essential questions here:
In an update for consumers, Microsoft said:
We’re observing signs of sustained recovery throughout the affected environment, and while our investigation into the underlying root cause is ongoing, we’re continuing to monitor the impacted services to verify service health levels remain stable. This issue impacts Outlook.com, OneDrive, OneNote, Microsoft To Do, Teams, and Microsoft 365 for the web although you may also see issues in other Microsoft 365 services.”
While the world’s IT departments scramble to get things back up and running, some brands have been quick to jump on the chaos by sharing a wave of memes.
“Microsoft being down is the equivalent of an adult snow day right?!” Aldi UK wrote on Facebook.
“Whoever’s troubleshooting and working on the outage rn … take your time. Go out and get a Whopper,” said Burger King.
KitKat, meanwhile:
Allow content provided by a third party?
This article includes content hosted on platform.x.com . We ask for your permission before anything is loaded, as the provider may be using cookies and other technologies. To view this content, click 'Allow and continue' .
Another incremental update from Microsoft at just before 4pm GMT:
Current Status: We remain focused on addressing residual impact and ensuring reliable service restoration. We continue to assess recovery across various connection methods and are closely monitoring service health to verify sustained stability.”
Small business owners and employees have been telling the Guardian how the Microsoft outage has affected them, with some services now being restored but concerns growing about the knock-on effects in the days ahead , my colleagues Nicola Slawson and Alfie Packham report.
Edward Holliday, a small business owner in West Yorkshire providing fire safety advice, says his emails started pinging again about 2.15pm. Until then, he had been unable to complete reports or respond to requests for quotes from potential clients.
“During the week I picked up a number of requests for quotes and just couldn’t get back to them,” he says, adding that there is a worry he’ll potentially lose out on that business now.
Although he managed to get some other work done during the outage and he didn’t lose any emails, he is now facing a backlog that he expects will spill into the weekend as he still needs to send out the quotes to potential clients and finish the reports he was unable to access.
“That’s the beauty of working for yourself,” he says.
Holliday says he is also concerned about what caused the outage, particularly given the recent spate of cyber-attacks.
“It would worry me if I thought that Microsoft were vulnerable to a cyber-attack,” he says. “Obviously my whole business exists within the Microsoft environment.”
Meanwhile, Sandra Wright, who works for a family-run cleaning supplies business in Kent, says the disruption could have consequences for supply chains, with the company unable to place orders.
The company has been unable to place orders with suppliers, potentially disrupting its usual delivery schedules.
“Although it is merely a day, a lot of companies, especially ones who operate via outsourced warehousing, have certain order days, be it for their weekly, fortnightly or monthly slots,” she says.
“Today alone would have had a ripple effect on these order dates.”
The outage has also left colleagues anxious about what might happen next, with some fearing further disruption despite Microsoft saying the problems were not caused by a cyber-attack.
“Today’s occurrence with Microsoft shows that nothing is untouchable,” Wright says, adding that staff are concerned about the wider repercussions for businesses that rely heavily on email.
Hugo Pickering, a business owner in Oxfordshire, says the outage today prevented him from accessing payroll data, meaning his 12 staff had to wait for their pay.
“As they are mainly on real living wage rate, it is bad news if they don’t get their pay accurately paid in a timely fashion,” he says.
Richard Adams
Universities and other educational institutions in the UK are reporting that email access and related services appear to be getting back to normal this afternoon.
The University of Manchester has told staff and students : “Microsoft have announced that they are seeing encouraging recovery progress in Europe, with service availability and email delivery performance improving. We are starting to see improvements in the delivery of some emails across the university and other services are starting to recover.
“IT services are continuing to monitor, although please note that there may be delays to delivery of some emails.”
Meanwhile the Office for Students, England’s higher education regulator, said its email access had been restored but noted: “We understand that some institutions and individuals may continue to experience intermittent problems.”
When digital technology lets you down, sometimes you have to go analogue. Companies affected by Microsoft’s outage have urged people to switch to alternative methods of communication, like picking up the phone.
Reuters had the following report:
European exchange operator Euronext , which runs bourses in Paris, Brussels, Lisbon, Amsterdam, Oslo, Athens and Milan, told listed companies to pick up the phone.
“We have ensured that the team has sufficient capacity to manage the situation and handle the additional workload,” a spokesperson said, adding that Euronext was verifying the identity of callers to protect confidentiality and integrity.
Aviva , which reported earnings on Friday, said it had put backup plans in place, including sending out alternative phone numbers for earnings calls and using Bluetooth to transfer recordings because email was down.
The British insurer tested a similar-scale outage of its most critical technology systems about two weeks ago, CEO Amanda Blanc told Reuters.
Shipping group Maersk asked customers to call with anything urgent and urged them to verify any unexpected communications about the outage with their local representative.
In Taiwan, the outage disrupted fund management at securities firms, life insurers and investment trust companies, people familiar with the situation said.
At another financial firm, trades such as purchases and sales of short-term bills, which are normally confirmed by email, had to be confirmed by fax instead, one of the people said.
Prior to the attack waves which started in France on October 11th, several vulnerabilities had already been documented in multiple Danfoss product lines (AK SM-800, AK SM-800A, AK-EM100) by SynAcktiv (in 2023 [ 1 , 2 ]), Claroty (in 2025 [ 3 ]), and DIVD/HackDefense (in 2023 [ 4 ]).
These vulnerabilities have included the much-discussed code-of-the-day authentication bypass (CVE-2025-41450), OS command injection (CVE-2023-25915, CVE-2025-41451) and path traversal (CVE-2023-25914) vulnerabilities in the AK-SM800A, as well as SQL injection ( CVE-2023-22583 ) and OS command injection ( CVE-2023-25911 ) vulnerabilities in the EOL AK-EM100.
All of these vulnerabilities are shockingly trivial to find and exploit, and the first public Proof-of-Concept (PoC) exploits were dropped within 48 hours of the French attacks [ 5 , 6 ] - preceding the second attack wave on November 2nd.
According to Censys, there are still hundreds of Danfoss systems exposed online (though no doubt a sizeable chunk are by now honeypots) and over a 1000 Copeland and Dixell fridge controllers. In addition, controllers from similar vendors (such as Eliwell) which have not been targeted remain exposed in the hundreds as well.
All this is to say that despite the demonstrable subpar security posture of these controllers and several attack waves with serious impact, controllers remain exposed to the public internet. While this is for understandable reasons (supermarket chains sometimes risk SLA or insurance condition violations by taking away remote maintenance and restricting access through VPNs isn't a trivial systems change), we consider it of paramount importance for defenders not to fall into the trap of considering risks sufficiently mitigated by applying patches as is suggested by Danfoss guidance .
In order to demonstrate this, we investigated the latest Danfoss AK-SM800A firmware version (5.3.2 at the time of writing) and within an hour of manual investigation (no AI necessary...) uncovered 6 pre-authentication remote code execution 0-day vulnerabilities .
We are currently in a coordinated vulnerability disclosure process with Danfoss and as such will withhold technical details until disclosure is sorted, but due to ongoing targeting of these controllers we consider it important asset owners have a realistic view of the overall security posture of these devices ontrollers in order to take the appropriate measures rather than rely on piecemeal patching.
Mitigation: Restrict network exposure through VPNs, private APN, or highly restrictive IP whitelisting ACLs
Danfoss AK-SM800A firmware images can be downloaded from their website and contain 7-zip compressed ARM binaries handling application logic. Danfoss AK-SM800A controllers run Danux , a custom Yocto-based Linux distribution, on an i.MX6 processor.
Let's start by setting up an emulation environment for the firmware. The path of least resistance here is emulating the binary in userland, rather than emulating the entire system including the kernel. After mounting the filesystem, we can copy qemu-armel-static in there and run the following command to be presented with a shell:
$ sudo chroot . /qemu-armel-static /bin/sh
sh-4.4#
As pointed out by Claroty , the SM800A platform consists of an NGINX reverse proxy, a bunch of CGI handlers, and independent processes handling application logic. Requests for URLs ending with .cgi suffix are forwarded to a task created by the sm_app executable.
It turns out that sm_app is a huge monolithic application that is responsible for pretty much everything that happens on the device. It is more like a mini Real-Time Operating System (RTOS) running in a userland process (a common embedded architectural choice resulting from lift-and-shift platform migrations). It has a task (thread) list consisting of 52 entries, among which are Task_Modbus_drv_task , Task_Ethernet , Task_IOHandler and Task_Web to name a few. Running the sm_app in this environment that's missing a significant chunk of the devices and drivers will almost certainly end in a crash. Applying some ad-hoc patches to the binary to avoid crashes will probably work, but potentially painful.
Fortunately, we're only interested in Task_Web, so instead of fixing up everything, I can just LD_PRELOAD my way in the binary, let it run all the initialization code until it hits main(), hijack the code flow from there, apply some hooks which I won't delve into here, and start the web server. It turns out that Danux conveniently ships with gcc:
$ gcc -shared -g -fPIC -o libpreload.so preload.c
$ sudo chroot . /qemu-armel-static -E LD_PRELOAD=/libpreload3.so /danfoss/sm_app
hi from hijacked code
With some additional minor fixes, we are now able to talk to the emulated web server:
$ curl -v -d '' http://127.0.0.1:8080/xml.cgi
* Trying 127.0.0.1:8080...
* Connected to 127.0.0.1 (127.0.0.1) port 8080
> POST /xml.cgi HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Length: 0
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200
< Date: Sat, 07 Nov 2026 21:44:33 GMT
< Content-Type: text/xml
< Content-Length: 75
< Connection: keep-alive
< Server: Danfoss SM800A
< Access-Control-Allow-Private-Network: true
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, OPTIONS
< Access-Control-Allow-Headers: aksm-auth,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
< Cache-Control: no-store, no-cache
<
* Connection #0 to host 127.0.0.1 left intact
<?xml version="1.0" encoding="utf-8"?><resp error="4">DEFAULT_STRING</resp>
The first thing to do is get a sense of the security quality of the code base through so-called code smells and anti-patterns.
The first such bad code smell is the extremely liberal use of strcpy. Use of the strcpy () function is discouraged as there is no size parameter. Instead, the function will keep copying bytes from the source buffer into the destination until it hits a null byte. This is a common source of memory corruption vulnerabilities in cases where the source buffer is provided by the user. Hundreds of strcpy invocations exist in the codebase which are part of externally reachable and unauthenticated handler functions. In fact, in earlier firmware releases each command handler is itself responsible for enforcing authentication, rather than doing so centrally. This needlessly enlarged the pre-authentication attack surface.
Next, we check for binary security mechanisms and exploit mitigations:
$ checksec sm_app
[*] '/mnt/SM800A-4.2.4/sm_app'
Arch: arm-32-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x10000)
RPATH: b'$ORIGIN:$ORIGIN/../../sm_gp_lib/Debug/:$ORIGIN/../../sm_fu_lib/Debug/:$ORIGIN/../../sm_df_lib/Debug/:$ORIGIN/../../sm_msgqueue_lib/Debug/:$ORIGIN/../../sm_lz_lib/Debug/:$ORIGIN/../../sm_tm_lib/Debug/:$ORIGIN/../../sm_up_lib/Debug/:$ORIGIN/../../sm_history_lib/Debug/:$ORIGIN/../../sm_thread_lib/Debug/:$ORIGIN/../../sm_fs_lib/Debug/:$ORIGIN/../../sm_at_lib/Debug/:$ORIGIN/../../sm_mutex_lib/Debug/:$ORIGIN/../../sm_lg_lib/Debug/:$ORIGIN/../../sm_system_lib/Debug/:$ORIGIN/../../sm_os_lib/Debug/:$ORIGIN/../../sm_ip_lib/Debug/:$ORIGIN/../../sm_dl_lib/Debug/:$ORIGIN/../../sm_db_lib/Debug/:$ORIGIN/../../sm_tk_lib/Debug/:$ORIGIN/../../sm_session_lib/Debug/'
It turns out that stack canaries and Position Independent Executable (PIE) are not enabled. These mechanisms have been staples of memory corruption defenses for decades and enabling these features on a modern Linux distribution running on a modern ARM application processor requires no engineering work at all. It is simply a matter of setting the right compiler flag. Enabling these features became the default in Ubuntu 17.10 and there is simply no excuse for a network-facing application that was last updated a few months ago to not have them enabled.
What's more worrying, is that multiple Danfoss business units (including Climate Solutions & Electronic Controllers) received IEC 62443-4-1 certification for Secure Product Development Lifecycle and this is prominently advertised as such. In addition, Danfoss explicitly mentions IEC 62443-4-2 is a guiding framework for designing cybersecurity requirements and implementing improvements. Asset owners, system integrators, and those responsible for procurement should realize exactly how little such certifications can say about the actual security posture of a product .
The initial impression of Danfoss' security posture, combined with the nature of the historical vulnerabilities, is a worrying one. But to see just how bad this pans out, let's see what can be found in no more than one hour of manually digging through the latest version of the firmware.
We could develop a harness and subject the binary to coverage-guided fuzzing. However, that constitutes serious effort, and with the impression of the code quality that I have, I'm going to simply look into random places where strcpy() is invoked instead. One of the first functions inspected turns out to be an unauthenticated endpoint for a CGI handler having a bunch of parsing logic and strcpy invocations.
While we will not disclose the exact endpoint affected, we will show it can be trivially exploited with a oneliner:
$ curl -v -d <redacted>"$(echo 'print("A"*768)'|python)"<redacted> http://127.0.0.1:8080/<redacted>.cgi
* Trying 127.0.0.1:8080...
* Connected to 127.0.0.1 (127.0.0.1) port 8080
> POST /<redacted>.cgi HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Length: 888
> Content-Type: application/x-www-form-urlencoded
>
This gives us a nice SEGFAULT showing we can probably hijack program control flow:
There's at least 5 different vulnerabilities of this kind in just the little bit of code i inspected.
Of course, remotely triggering a crash is bad in itself, but being able to leverage the buffer overflow to obtain remote code execution is much worse. Any reasonably experienced exploit developer will agree exploiting straightforward stack-based buffer overflows on ARM Linux without exploit mitigations is very straightforward. And if they don't, there's probably a frontier or open weight model out there willing to help them agree.
The only challenge (if you can call it that) left to overcome is the fact that
strcpy()
stops copying bytes when it hits a null byte. If we wish to gain remote code execution, we inevitably need to write several addresses containing null bytes. Thus, we need to somehow overcome this inherent limitation of
strcpy()
and while we won't share our approach for now
it's not exactly rocket surgery
. Also, the exploited application runs as root (because of course it does).
Since we have to be vague due to coordinated disclosure being ongoing, let's at least show the result of our 100% artisanal, hand-crafted, AI and gluten free exploit in action as PoC:
The exploit demonstrated above was targeted at version 3.3.0, but the bugs are present in the latest version of the firmware as well (5.3.2 at the time of writing).
In later firmware versions, however, the concepts of session control and security levels were introduced by Danfoss [ 1 , 2 ]. According to Danfoss, session control is an authentication rules engine for the various remote interfaces (StoreView Browser, StoreView Web, Alsense, and 3rd party XML). This session control mechanism replaces the individual handler-level authentication enforcement mentioned above.
Session control has three security levels: backward compatible, permissive, and strict. Starting at 4.0 security level strict was set as the default which:
This AKSM-auth header mechanism historically held a base64 encoded username and password as the authentication key but now needs to include a session token derived from initial authentication [ 3 ]. At the strict security level, virtually all the web-accessible attack surface is fenced off from unauthenticated users (including the bug that was used in the exploit above) which is why enabling this security control was included in CERT-FR's official mitigations .
Unfortunately, it t urns out the session control mechanism also has at least one trivial pre-authentication memory corruption vulnerability.
The way this is implemented is through a separate binary: sm_fcgi_app . It acts as a Web Application Firewall (WAF) in the sense that it passes through all commands to NGINX if it believes that the user is authenticated. If not, then the only command allowed to be passed through is the getauth command, which is used to authenticate.
At first glance i spotted a potential for parser differential attacks on sm_fcgi_app which might open the entire attack surface to unauthenticated users, but decided to investigate a quicker route to success. It turns out there's another simple strcpy based pre-authentication memory corruption:
$ curl -k -v -d <redacted> -A "$(echo 'print("A"*1536)'|python)" https://127.0.0.1:3443/<redacted>.cgi
...
> POST /<redacted>.cgi HTTP/1.1
> Host: 127.0.0.1:3443
> User-Agent: AAAAAAAAAAAAAAAA...AAAAAAAAAAAAAAAA
> Accept: */*
> Content-Length: 41
> Content-Type: application/x-www-form-urlencoded
>
Running this against the latest AK-SM800A firmware with strict session control enabled produces a SEGFAULT which, with some additional effort, can be turned into yet another pre-authentication RCE. It goes without saying that sm_fcgi_app does not have stack canaries and PIE enabled either. I think we're done here, we've seen enough.
The last thing we want to figure out is exactly how bad this can get.
It's one thing to initiate long defrost cycles and spoil tens of millions of food once , but the typical response of defenders is to factory reset affected controllers, rotate credentials, apply patches, set strict session control mode, and possibly wall off the controllers from internet exposure. But any controllers that are hit continue to do their job in production.
Now, imagine an attacker who manages to persist on such controllers. They don't just trigger the initial payload but they leave a little implant that survives a factory reset and firmware update. With OS level access, this isn't too hard on typical Unix-like devices as shown in the SALTWATER / SEASPY malware for Barracuda devices, FIRESTARTER malware for Cisco devices, and Sonicwall malware all which survive firmware updates.
In such a scenario, an attacker could either retain remote access or leave a time-triggered payload for a 2nd (or 3rd...) strike - increasing damage by spoiling new batches of food. Alternatively, attackers could simply wipe flash memory and/or push a malformed firmware update to brick the controllers and render them permanently inoperable - requiring costly and time-consuming replacement similar to the TTPs deployed during the December 2025 attack on the Polish electric grid .
Both approaches seem feasible against the AK-SM800A controllers since they do not make use of the i.MX6's secure boot features as evidenced by checking some of the responsible One-Time Programmable (OTP) fuse registers.
1. Full device take-over : Through remote code execution, an unauthenticated attacker can remotely run arbitrary code at the operating system level of the AK-SM800A controller. This would allow the attacker to change parameters or initiate unwanted actions (such as defrosting operations) while hiding their activities from any system logs. In addition, the lack of secure boot functionality would allow an attacker with RCE to persistently implant controllers to maintain access or have it trigger a secondary payload at a later point in time. Without deep introspection and forensics capabilities, determining whether a device is implanted at the firmware level ( even after a factory reset ) is infeasible.
2. Equipment damage (bricking) : Due to the lack of secure boot, an attacker with RCE could push malicious firmware that simply renders the device inoperable and irrecoverable without specialized hardware intervention (e.g. by wiping flash memory and/or causing an infinite boot loop). Such a ' bricking ' or wiper approach would require full device replacement. The dangers of such a scenario to OT equipment in particular and adversary deployment of such TTPs have been highlighted in previous blogposts by Midnight Blue [ 1 , 2 ]. This could potentially lead to freezers being unavailable for days or longer while controllers get replaced .
In light of all of the above, we consider piecemeal patching or enabling of strict session control to be a misallocation of scarce security and personnel resources since they have minimal security ROI against such a fundamentally flawed codebase missing basic exploit mitigations and yielding multiple pre-auth RCEs with an hour's casual glance.
Instead, we strongly recommend asset owners and system integrators to take the following course of action for all Danfoss, Copeland, and Dixell controllers and preferably for similar controllers by other vendors as well:
You’d be forgiven for worrying, 12 weeks into a strike, that the boss is hell-bent on waiting you out. But after more than 80 days on the picket line at Seattle’s Embassy Suites by Hilton in Pioneer Square, Aspen Desmarais was undeterred. “I can live on a budget,” she said. “Been doing it since day one.”
After 85 days, on September 10, workers won the longest hotel strike in Washington state history. Their union, UNITE HERE Local 8, represents 4,000 hospitality workers in Oregon and Washington.
Desmarais, a strike captain and bartender at the hotel, worked to keep others motivated throughout the fight. She and her co-workers were “tired of people talking down to us and not treating us with respect,” she said, “when we’re the reason that place stays running the way that it does.”
Hilton’s offer, two weeks into the strike, of one cent per hour over its previous proposal helped fuel outrage. The union held open bargaining, so members heard the offer firsthand. “I [felt] frustrated and disrespected,” Desmarais said. “Especially with how much hard work my co-workers put into making sure the hotel and its guests have clean spaces and stays that are welcoming.”
Fritzie Corral, an Embassy Suites breakfast attendant, had only worked at the hotel for two months before walking out. As the strike went on, she said, her son worried that she had made a mistake in taking the job.
“You see other employees that decided to stay in the hotel working," she said. “Even during that time, I still believed I made the right choice. It’s my right to voice out what I feel and to fight for my rights.”
Hilton did not respond to requests for comment.
Workers won significant pay increases, lowered barriers for health care eligibility, and highly sought-after protections for immigrant workers. Hilton, which manages the hotel, drew protests earlier this year for housing ICE agents and for cutting ties with a Minneapolis hotel that canceled ICE bookings during Operation Metro Surge.
The union’s leaders criticized Hilton throughout the strike for dismissing contract language that would protect immigrant workers. “With ICE-related killings in the news for months causing immigrant workers to worry, why is Hilton refusing to give immigrant workers’ union a heads up if ICE is staying at the hotel?” Local 8 President Anita Seth asked Businesswire .
Ultimately workers won a commitment from Hilton not to punish workers who call out due to an immigration enforcement surge, plus language binding the hotel to an expedited resolution process in such an event. Workers who lose their work authorization due to immigration enforcement will now be able to return to their jobs if their work authorization is restored within four years, and retain their seniority for up to two.
Desmarais told Labor Notes that making sure immigrant co-workers missing work because of ICE “knew they would have a job still and a safe place to come back to” was the “most important” win strikers fought for.
Starting in 2027, housekeepers will make over $31 an hour—a giant step above the $17.63 an hour that housekeepers make on average across the country, per the Bureau of Labor Statistics. The new contract makes them the highest-paid housekeepers in the state, according to the union. Embassy Suites workers classified as “tipped” will now make $1 more per hour than the city’s minimum wage.
Health care eligibility was also a core demand for the union. Many hotel workers under collective bargaining agreements must meet a minimum threshold of hours worked to qualify for health benefits in a given period. Seasonal layoffs, a hallmark of hotel work, often mean inconsistent coverage for workers and their families.
The new contract replaces the month-to-month eligibility standard with an annual threshold of 1,250 hours, or around 24 hours a week, to qualify.
The strike coincided with five of the six World Cup soccer matches held at Seattle’s Lumen Field this summer, directly across from the Embassy Suites. World Cup-related leverage helped produce quick contract wins this summer for service and hospitality workers in Philadelphia, New York, and Los Angeles, but not so in Seattle.
How did strikers there keep up the pressure for another 63 days after the games ended? The hotel’s proximity to Lumen Field makes it a destination for football fans when the season starts in September. On game days, the hotel sets up a bar facing the stadium. Workers set up a separate picket line mere feet away from the customers, and urged fans not to cross.
In between sporting events, Desmarais said solidarity from other union workers played a big role.
Combined pressure from BNSF rail workers (represented by the Brotherhood of Locomotive Engineers and Trainmen Division 518) and sympathetic elected officials pushed Sound Transit to move its contract to another hotel with no promise of return. The transit agency had maintained a block of rooms for the BNSF workers who operate its commuter rail—accounting for 25 rooms nightly, or roughly $18,500 in weekly revenues, according to Local 8 , and a significant portion of the hotel’s income during low-traffic winter months.
Embassy Suites workers like Desmarais worked hard to push Sound Transit and other hotel clients to honor the picket line. “There was one day I had to make over 90 phone calls,” she said. “For the most part, it was actually a pretty positive reaction.”
Teamster sanitation and UPS workers also refused to service the hotel during the strike. Corral reported seeing the hotel’s director and assistant director hauling garbage out during the World Cup. “It felt so rewarding,” said Desmarais. “Yeah, you have to get your hands dirty and not just do paperwork. I think it gave them a real experience of what we have to deal with.”
Corral said community solidarity was key in getting Hilton to concede. Strikers’ church groups joined the picket line. So did several Seattle elected officials and even some hotel guests. Guests also brought workers donuts, contributed to the strike fund, and left Google reviews urging hotel management to “come to the table” and “sign the contract already.”
One temp worker walked off the job after only an hour to join the picket line. Corral said such displays of solidarity made workers “more motivated to keep on.”
Many workers worried about money, the future of their jobs, and their families while on strike. But when someone was scared or upset, there was always another worker to help uplift them, said Corral: “We’re like family.”
Shortly after Edwin Santana was released from prison in 2017, he picked up his phone and began making what would become his first-ever documentary: "Closing the Last Penal Colony."
The last penal colony in question was Rikers Island, where Santana had spent time as a young man. While in prison, he didn't know much about the movement to close Rikers , and now that he was a free man, he started filming a movement that was urgently trying to shut down a place that had wounded him deeply.
"I know the horrors firsthand, but it was only when I came home did I see that there was a massive movement centered around the issues I experienced, even all these years later," he told Hell Gate. "It was amazing to see people like myself, the formerly incarcerated, people who felt like they didn't have a voice, that they should even be ashamed of their own voices because they were incarcerated, leading this movement."
Santana had seen Rikers Island depicted in film, either glorifying the violence or as this unimaginable hellhole. But he'd never seen anything that actually put Rikers in the context of a long history of incarceration and bondage in New York City.
"I wanted to see where Rikers came from," Santana said. "How did it even get here?"
His documentary, which traces the history of Rikers Island—from a military training ground during the Civil War (including New York's segregated regiment of Black soldiers), to a modern massive jail complex literally built by prisoners, to the movement to close it—isn't the most polished documentary. Santana knows, two years after its release, that it would be a lot better if he made it today. But he also knows it reflects the mindset and experience of someone who just came out of a system that had inflicted harm on thousands of young people like him, and which still, stubbornly, hasn't closed.
Santana's film is now one of the centerpieces of A Future Beyond Rikers Film Festival , which is taking place this weekend at the Maysles Documentary Center in Harlem, beginning Friday evening.
When I woke up this morning I thought about writing about the ongoing drama surrounding Nvidia and its morally and ethically corrupt leader. But, then I quickly saw the news about Microsoft Outlook going down, and with it Teams and Copilot.
I soon saw many employees celebrating what effectively became a "snow day for adults" as they literally couldn't do their jobs. Then I started seeing various businesses, ranging from small to medium, saying that their normal support services are unsurprisingly not working and instead to contact them via social media. Except, it's not just businesses that are impacted by Microsoft's incompetence. Even if this is some legitimate accident (and not a more likely instance of someone vibecoding their way via Copilot), when a company like Microsoft fires tens of thousands of employees, including many engineers, then these problems are not only more likely, but also more difficult to quickly fix. The fact that this has actually been an issue across two separate days is pathetic for a company like Microsoft.
As beyond businesses impacted, all sorts of other entities have been impacted. Various forms of educational institutions from schools to universities as well as the courts! I wouldn't be surprised if healthcare has been impacted as well.
Now, are Microsoft going to offer any compensation for either lost business or additional accrued costs? I highly doubt it, even though it is literally their fault and they do still have the cash reserves, despite increasingly wasting it on loss-making AI adventures.
This is a reminder of how indebted the Global North has become to Microsoft and its enshittified services. If most (but thankfully not all) businesses and institutions are deep into Microsoft systems, then when Microsoft inevitably messes up again, large swathes of organisations will not be able to function properly. Yes, it might be good for the individual worker in a generic office role, but for keyworker type organisations this can have really damaging implications. Many European state institutions have already started the move away from Microsoft to open source alternatives. Largely to not be at the mercy of an inconsistent United States of America, but also for times like this. As when Microsoft services go down, you cannot fix it! You have to wait for Microsoft to find a competent employee who wasn't let go to try and fix what was broken by some inept leftover who was deluded enough to think that Copilot can do everything.
I still want to talk about the issues of the impact of other US company Nvidia and the implications it has around the world. But that can wait for another day. Plus, who knows if another affairs comes out (we're currently at three).
There are decades where nothing happens, and there are weeks when decades happen. The CEO and founder of Nvidia just experienced the latter, as did many in tech, media, and government. I have a variety of thoughts after spending the past several days reading and recording podcasts about these (figurative and literal) affairs, but let me express one unpopular sentiment at the outset: what happened to Jensen Huang this week is tragic and depressing.
I have a disease that makes me sympathetic to almost anyone who ends up on the wrong end of viral outrage and panic, and unfortunately it’s flaring up again. Huang is one of the greatest CEOs in American history. He’s still hyper competent, he’s been incredibly important to the growth of the AI ecosystem, and frankly, he’s among the most sane of the contemporary tech leaders we have on offer. His fall from grace has been not only stunning but seemingly coordinated. It’s been painful to watch on a human level, and of course it has ominous implications for the tech industry. Regardless, though: what’s done is done. Huang’s reputation has been irreparably harmed, his wife and family have been humiliated over the past two weeks, and he just lost control of the world-conquering company that he founded 33 years ago, immediately throwing Nvidia’s future into a world of post-Jobsian uncertainty.
It’s an incredible coup for the Ministry of State Security if this was all a Chinese op, but honestly, I’m not convinced it was. That’s point number two. The entire media establishment and most of our government seem to have taken it as a given that Alice Huang was a spy for the MSS, but a) the sourcing there is based entirely on the vague and classified claims of intelligence services who despise Huang, while b) “spy for the MSS” can mean different things. Was she a 43-year-old operative trained by the MSS to honeypot powerful executives and obtain proprietary information, or was she a businesswoman who was (like all other Chinese citizens) obligated to cooperate with the MSS when the agency discovered her affair with Jensen? I would bet on some version of the latter (“asset,” not spy), and I think it’s more likely the spy claims were invented altogether ( were they? ) than it is that Alice Huang was some kind of Chinese Keri Russell executing a classic sexual blackmail scheme.
All that noted, I truly don’t know. We may never know. And one thing is certain: if Alice Huang was spending billions of Chinese investor dollars to obtain high-end Nvidia hardware that was banned for export to Chinese companies and may have later been smuggled into mainland China … she was not doing that without approval from the Chinese government. So, not a CCP agent, but not not a CCP agent — and definitely not someone that Huang should have felt comfortable sleeping with. How in the world could he be so stupid?
On the other hand, should we really be surprised? Whenever Jensen Huang discusses China, I’m reminded of Upton Sinclair: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.”
Here was Huang in a recent interview with Bloomberg , answering Emily Chang’s question about engagement with China’s tech sector by saying, “We must work with them in every possible way.” Then there was Huang talking to Dwarkesh Patel in April , going viral when he angrily called it “lunacy” to worry about the CCP and PLA using advanced American hardware to execute AI cyberattacks. Equally infamous around D.C. was Huang’s conversation with Brad Gerstner last year , in which he declared that the label “China hawk” is a “badge of shame.”
Both Huang and his company were lobbying against stepped-up export controls on AI chips as early as 2022, and were (legally) circumventing the spirit and expressed purpose of those export controls with the A800 chip in 2022 , the H800 in 2023 , and the H20 in 2024 . He’s continued to lobby against export controls throughout the Trump administration and continued his attempts to sell AI chips to both mainland China customers and China-linked entities in Malaysia, Thailand and Singapore. To be fair, of course, anyone who’s followed this space for the past several years will remember that Nvidia has been joined by Intel, Qualcomm and everyone else in the American semiconductor industry in lobbying multiple administrations against new China restrictions. Likewise, Google, Microsoft, and Oracle all have sizable footprints in Southeast Asia providing Chinese customers with access to high-end compute.
Huang has been by far the loudest and most powerful of those voices, though, and now he will fall the hardest. That’s one way to understand what happened over the past two weeks: Jensen had a giant target on his back among many in tech and government who favored stricter restrictions on Chinese chip access, his mistakes with Alice Huang and Megaspeed gave those critics ammunition, and for reasons that remain unclear (but fun to wonder about!), some of those folks have decided to pull the trigger now.
Reports of an affair with an Nvidia employee (and another one ) might have been survivable three weeks ago, but certainly not after an international scandal involving sex with an alleged Chinese intelligence asset who was the managing director of an Nvidia customer that was likely violating U.S. laws. Once his critics got those leaks going, it was 50/50 at best that Huang kept his job, and 100 percent guaranteed that his (and Nvidia’s) credibility in Washington would be permanently decimated.
So was Huang a victim of what was ultimately an American intelligence op to leak incriminating reports that would discredit him and his policy agenda? As far as this month’s disclosures, that’s almost certainly closer to the truth than imagining a years-long honeypot scheme overseen by the MSS to influence his views. But I draw the line at calling Huang a victim, and to be clear, that’s not why I feel bad for him.
To state the obvious: Huang broke some obvious CEO rules here (don’t dip your pen in Chinese shell company ink?) and exercised horrible judgment, evidently in multiple dimensions. With Alice Huang, he also publicly lied about the affair in explicit terms, further undermining his credibility and possibly withholding material information from investors . “Our relationship, our interactions, have been related to Megaspeed, and it was all completely normal and not unusual,” Huang told Bloomberg at the end of October .
In the weeks and months to come, I imagine Congress will be eager to find out what else Huang may have been lying about. There will be more investigations, and there is likely more to find. All such inquiries will of course begin with Megaspeed itself, a Singaporean company with a large footprint in Malaysia that was identified by Culper Research last spring as an Nvidia customer that appeared to be funded and controlled by Alibaba, circumventing U.S. export controls in full view of Huang, who visited Megaspeed “every few months” and was accompanied by representatives from Alibaba “every single time.”
Indeed, if national security secrets were not necessarily compromised by Jensen’s affair with Alice Huang ( the Nvidia board’s initial construction ), it’s very plausible that national security laws were broken by Megaspeed if Jensen’s customer was effectively an Alibaba cutout controlling Megaspeed data centers and purchasing export controlled chips, 50,000 of which may have made it to China . Many on Capitol Hill will argue that U.S. security interests were compromised in turn, all of which may have been downstream of Nvidia’s knowing (or unforgivably negligent) participation in the scheme (in which case Nvidia was breaking laws, too).
But again, none of this is all that surprising. As I told Bill Bishop in our episode of Sharp China this week , the potentially incriminating details of that customer relationship have been part of the public record for nearly a year , yet I never thought to mention them on the podcast. Because what was there to say? Everyone in D.C. had just accepted that this is just how Nvidia does business. Every few months there’s some new, sketchy customer highlighted by Bloomberg or the New York Times, sometimes there’s a DOJ indictment , Nvidia’s answers are never satisfying, and yet the company appeared to be bulletproof until a sex scandal shined a light on exactly how shady all of this has always been. In the years since the Biden export controls took effect, the share of Nvidia’s revenue billed to customers with Singapore addresses rose from 8% to 22%, and in July 2025, Nvidia stopped breaking out the figures altogether .
During that same period, there have been lots of anecdotes in which Nvidia is said to have bullied members of Congress and the think tank community, using donations as leverage to influence policy positions of the latter group. Bill and I have been alluding to that bare knuckles behavior on our podcast for almost four years now, and The Information highlighted the company’s broadly unpopular tactics with a new report last week:
Government officials sometimes have felt bullied in exchanges with Huang. Officials at political think tanks say Nvidia officials have threatened to cut back on their funding for expressing views the company disagrees with. And Nvidia customers say they tiptoe around certain subjects, as OpenAI has, to avoid displeasing the chip giant. […]
One semiconductor industry executive who worked with Nvidia described the company’s effort to tweak its products and sidestep the [2022] ban as giving the Biden administration “the finger” and taking the stance that it did not have to negotiate with the government.
That often adversarial attitude toward some Biden officials came not only from Huang but also from Nvidia’s general counsel, Tim Teter, according to several people who have interacted with him. Those people recalled Teter using unflattering nicknames for government officials, academics and think tank scholars he did not like.
Under Trump, Huang’s interactions with the executive branch — and the President himself — have been considerably friendlier, which invites an entirely different spectrum of criticism and lines of inquiry. What happened to scuttle the Commerce Department’s investigation of Megaspeed , and where does the DOJ investigation stand today? Did Jensen Huang urge Nvidia counsel to reach out to the government on his mistress’ behalf ? Those are fair questions that I’m sure a Democrat-controlled Congress will be asking in the months to come. Meanwhile: Nvidia donated $25 million to Trump’s ballroom and $1 million to Trump’s inaugural fund, with at least one policy flipping after Huang attended a $1 million-per-plate fundraiser and personally lobbied Trump to reinstate licenses to sell H20 chips to China (which had been allowed under Biden).
Whether attempting to buy ideological allies or bully opponents, Huang and Nvidia spent the past several years working tirelessly to subvert the democratic policy process. Lobbying is fine, but threats and bribes are not, and it always seemed to me that Nvidia tipped a bit too far over the line as they navigated D.C. That’s why the company came to be despised by most of Congress, not to mention the vast majority of the Trump Cabinet (who may be doing some of the leaking here).
Independent of whether controversial Nvidia tactics were technically legal — abrasive lobbying, redesigning high-end chips to circumvent restrictions, moving Chinese sales offshore — there is also the question of whether any of this was wise. While reaping the unbelievable rewards of U.S. markets, laws, and customers, Nvidia has not really behaved like an American company that’s answerable to the American government. Instead, Huang continued selling chips to China at all costs and sought to substitute his own judgment for that of Congress, the White House, and practically the entire U.S. intelligence community. Those are some of the worst enemies you can possibly create, and it all reminds me a little bit of Anthropic’s battle with the Trump administration, when Dario Amodei was operating from the position that because he had a signed contract and had invented the world-changing technology at issue, he could dictate to the U.S. military how it should and shouldn’t be deployed. Good luck with that , a student of history might say .
Meanwhile, Ben Thompson has laid out an elegant case for selling high-end chips to China , but it has to be said that Jensen himself never came close to approximating Ben’s humility or strategic coherence. Not only has Jensen never once advocated for restricting the sale of semiconductor equipment to China (as Ben did), but his public answers on incredibly difficult chip questions have been evasive …
…. misleading …
and outright false .
By now it should go without saying that chip diversion is systemic and Nvidia is benefiting , while yes, the U.S. is confident that high-end Nvidia chips were used to develop DeepSeek, a model that can be extended to a variety of Chinese military applications . (Another fun detail: the day after the Trump admin initially restricted the sale of H20 chips in April 2025, Huang flew to Beijing to grovel before Vice Premier He Lifeng . Nvidia later claimed that trip was scheduled regardless of the export curbs, but who really knows?)
For as brilliant and charming and tenacious as Jensen Huang may be — and as omnipotent as he may have seemed to people in the tech industry — we should be clear that his fundamental stupidity is not confined to multiple cases of workplace infidelity. Zooming out, this is a man whose technology became economically critical almost overnight, and it thrust him into a role navigating a geopolitical environment he simply could not handle. Suddenly forced to balance market-altering interests in both China and the United States, I don’t think Huang ever really understood either country’s leadership.
No one in American history has ever been less effective at winning friends in Washington than Huang and Nvidia, yes, but that was only part of the problem. What really drove the disconnect in D.C. was Jensen’s assumption that U.S. concerns about economic engagement with China were purely a function of vibes and misunderstandings, not sincerely held security principles and bitter lessons from the past 25 years. Perhaps he needed to believe all that in order to rationalize his company’s behavior, but when he said last year that China is “not an enemy” and that “China hawk” should be a badge of shame across D.C., I was immediately reminded of Biden’s Ambassador to the PRC, Nicholas Burns, who said last year , “I went to China with hawkish views and returned to the U.S. even more hawkish than when I arrived. I saw up close the true nature of its authoritarian government and its ambition to undercut the U.S. at nearly every turn.”
Almost everyone with a security clearance leaves their time in government more concerned about China than they were when they entered public service. Without reciting a laundry list of malign CCP and PLA behaviors that could support those conclusions, I will only note that Huang was in China constantly and he seemed to be blind to all of them. Conversely, you hear the word “hawk” and probably imagine Donald Rumsfeld, but the China hawks in D.C. tend to be folks who are aware of a wide spectrum of security vulnerabilities and are unwilling to talk around those risks for the sake of share prices or political correctness. Their prescriptions are not always a good idea, but their signature trait is noticing problems and proposing action, not necessarily agitating for World War 3.
Huang repeatedly belittled those people with both his rhetoric and his company’s behavior, and indeed, he questioned the patriotism of anyone who dared to object. In so doing, he was waging war with not only large swaths of the U.S. security apparatus, but also the realities of Xi Jinping’s China that would inevitably make it impossible to sustain his position without looking naive, selfish, and unforgivably reckless.
So why did I feel bad for Huang this week? Because I’m a sap, first of all, and I’m never rooting for anyone’s public disgrace. But also because this is a man who seemed incapable of recognizing how and why this story might eventually end horribly for him. And now that we’re here, I can’t help but wince at just how much worse it’s going to get.
Sharp Text is extension of the Stratechery Plus podcasts Sharp Tech, Greatest of All Talk, and Sharp China. To subscribe and receive weekly posts via email, click here .
This project presents a first working state for live migration of bhyve guests on FreeBSD 15.1. A running amd64 guest can move between two hosts over TCP while continuing to run; it is paused only for the final stop-and-copy phase. The work builds on bhyve's experimental snapshot support and adds dirty-page tracking in the vmm kernel module together with a migration protocol in bhyve and bhyvectl.
I previously discussed the state of bhyve live migration, its historical development, existing limitations, and why it matters for the future of FreeBSD virtualization in my article bhyve on FreeBSD and VM Live Migration – Quo vadis? .
The goal is deliberately practical: make it possible to test, discuss, and improve a real implementation rather than discuss live migration only in the abstract. The current code and test tooling are being published as a WIP RFC so that the next steps can be shaped in the open. A more detailed demonstration of a VM being live migrated can be watched on my YouTube channel .
Live migration is an important building block for enterprise virtualisation. It enables host maintenance, hardware replacement, load balancing, and failure-domain management with far less disruption to workloads. It is also central to the Sylve project, which aims to offer a Proxmox-like virtualisation solution for FreeBSD. Migration is not an optional convenience in that kind of platform; it is one of the capabilities that makes clustered operations practical.
It is equally important for BoxyBSD, where I offer free BSD-based VPS instances to individuals. Without a credible migration path, routine host work can require a guest outage. That makes live migration a current show stopper for the project, and is why this work is being pushed toward a testable, reviewable state.
The source starts with a pre-copy phase. It sends populated guest memory, then repeatedly obtains a bitmap of pages changed since the previous scan and sends only those pages. Once the remaining dirty set fits the configured downtime target, stops shrinking, or reaches the configured round limit, bhyve pauses the guest and its devices. It then sends the final dirty pages and the existing snapshot state for the vCPUs, kernel state, and emulated devices.
The destination validates the basic VM geometry, receives memory and state, restores it, and reports that it is ready. Only then does the source send GO , the commit point. Before GO , a failed migration can resume the source guest. The destination does not start the guest if it does not receive that commit message. A warm, stop-and-copy mode is available too, which is useful both as a fallback and as a comparison baseline.
In the current two-host test environment, repeated live migrations, memory-rewrite workloads, and fsync-heavy disk workloads have completed successfully. For a slowly dirtying 512 MiB guest, observed downtime has been roughly 138–171 ms. A rapidly dirtying guest may not converge during pre-copy, but still falls back to a correct stop-and-copy completion with a longer pause. These are encouraging engineering results, not a production support promise or a complete correctness proof.
The following are neutral engineering requirements, not criticism of the value of the prototype. They need to be addressed first before further upstreaming into FreeBSD can be evaluated responsibly.
We have already had deeper discussions about these questions in the Sylve Discord. Publishing this current state is intended to make those discussions more concrete, bring in wider FreeBSD and bhyve feedback, and turn the prototype into a clear roadmap. The immediate focus is correctness, compatibility validation, transport safety, and repeatable tests—not adding performance features first. Currently, some peopel already have access to it and it's planned ot publish this at least as a proposal on my git and GitHub at:
Compression, zero-page elision, broader device coverage, richer orchestration, and performance tuning can follow once the foundation is sound. If you operate bhyve, work on FreeBSD virtualisation, or are interested in Sylve or BoxyBSD, testing the RFC and contributing design feedback would be especially valuable.
Status: WIP RFC for a first working bhyve live-migration implementation on FreeBSD 15.1.
The US commerce secretary, Howard Lutnick, is facing growing pressure over his apparent lack of action over the Nvidia spying scandal as other Trump administration officials publicly raise questions over his decisions.
Scott Bessent, the US treasury secretary, blamed Lutnick’s commerce department for the fact the US had not imposed export restrictions on certain Nvidia chips to China.
Jensen Huang resigned from Nvidia on Thursday, and was replaced on an interim basis by the company’s chief financial officer, Colette Kress , after reports emerged of his multiple affairs, most importantly with Alice Huang (no relation), who is suspected of being a Chinese spy.
White House officials are discussing whether Lutnick should be fired, the Associated Press reported, after it emerged that a US intelligence report about Huang’s relationship with the alleged spy was circulated among senior figures in the Trump administration .
Lutnick is now scheduled to testify before Congress next month, just days after the ousted Nvidia chief answers lawmakers’ questions on Capitol Hill.
Lutnick is also facing criticism for a delay by the commerce department in adding Singapore-based Megaspeed, which is associated with Alice Huang and has bought billions of dollars of Nvidia chips in recent years, to Washington’s blacklist of companies that the US considers a risk to national security despite reported concerns within the administration.
Bessent has “for months” been in favor of putting Megaspeed on the blacklist – but Lutnick’s commerce department “has the pen”, Bessent told CNBC. “You will have to ask them about their internal process,” he added in an interview with the network on Friday.
John Curtis, a Utah Republican senator, said that Lutnick’s reported delay on export controls regarding Megaspeed “raises the question of whether the commerce department is acting in the best interests of the American people”.
The Republican senator John Cornyn told the Financial Times that there needed to be “a thorough investigation and accountability for the outrageous circumvention of national security export controls”, adding: “Heads should roll.”
The Senate Democratic leader, Chuck Schumer, said Jensen Huang and Nvidia must answer as to whether US security had been jeopardised, adding that the Trump administration also must account for what it did once it learned about his reported relationship with Alice Huang.
“Secretary Lutnick has proactively agreed to appear voluntarily before the banking committee to address their questions,” Kristen Eichamer, a spokesperson for Lutnick, told NBC News.
Trump’s close ties with Jensen Huang have also come under renewed scrutiny as a timeline of the saga started to emerge . The president called him two days before he stepped down and urged him to fight for his job, the New York Times has reported .
On Thursday, Schumer questioned what Trump knew when he personally invited Jensen Huang aboard Air Force One on a state visit to Beijing earlier this year, adding: “Americans deserve to know that those at the highest levels of power are putting America first, not their bottom line or their personal friendships.”
The House Democratic leader, Hakeem Jeffries, said he had demanded a classified briefing for all members of Congress about Nvidia.
Republican Tim Scott, the Senate banking committee chair, said he had sent letters asking Lutnick and Jensen Huang to appear before him, citing “recent reports [that] raise serious concerns about our national security and the protection of sensitive US technology”.
The statement from Nvidia’s board of directors confirming Huang’s departure did not mention the spying scandal and personal-conduct revelations, instead paying tribute to his “profound” contributions to the company he cofounded.
Huang is reported to have had relationships with Alice Huang as well as an Nvidia executive, Kimberly Powell, according to the New York Times, and another, unnamed employee, according to Reuters.
The House foreign affairs chair, Brian Mast, a Republican, said on Thursday that congressional staff had spoken to Nvidia on Wednesday night about a date and location for Huang’s testimony.
The House speaker, Mike Johnson, said on Thursday there was now growing consensus in Congress on limiting chip exports to China .
Nvidia’s advanced AI chips are widely used to develop cutting-edge AI models, making the company important to the US race against China to build superior AI systems. The US has sought for years to limit China’s access to Nvidia’s chips because it does not want the Chinese military to benefit from them.
“The export controls on chips to China has been a big issue around here,” Johnson told reporters at the US Capitol, adding that he favoured limiting China’s access to the advanced technology. “I think there’s a developing consensus in Congress that is an important position to take.“
Chinese AI companies are now trying to secure Nvidia chip capacity outside China, amid growing concern that the gap in US export controls may now be closed after the scandal, people familiar with the matter told Reuters .
Beijing has also stepped up efforts to develop domestic alternatives, including through Huawei, although analysts say Chinese chips remain less efficient for training advanced AI models.
Lawmakers are pressing their colleagues to pass at least four bills on chip exports, according to statements issued since Monday.
On Chinese social media, many expressed surprise at what they see as Huang’s swift resignation, and mourned the sudden end of an era that lasted for more than three decades.
News of his resignation attracted more than 400m posts overnight on the Chinese microblogging platform Weibo.
Huang had enjoyed rock-star status in China, where his visits drew crowds seeking selfies and autographs and his casual outings became social-media sensations. During a January 2026 visit, opportunistic sellers advertised photographs with him for 25,000 yuan ($3,700), while a Beijing restaurant launched a special menu costing more than 400 yuan after he ate there.
Additional reporting by Yu-chen Li
I was googling the name of my website, as one does occasionally, and was surprised to see a link to one of my blog posts on
mataroa.site
. At first I figured it was just an alternate domain name for
mataroa.blog
, but no, when you type
mataroa.site
into your browser, it shows you
my blog
. It's the only thing that's hosted there.
My next thought was that someone bought me a URL, but that can't be the case either: using a custom domain on mataroa requires a premium account, which I don't have. For anything but a plain redirect, I would have needed to set up the A record my end.
I then realized that the version of my blog on that site doesn't have the latest post . The most recent update on the homepage is my Aug 21 entry . When you scroll down and start clicking some of the older links, you get 404 pages. You also get a 404 if you try to post a comment, load the RSS feed or view standalone pages like the AI statement .
Someone scraped my blog and created a website to impersonate me. They're also impersonating mataroa , since using the name implies some sort of official connection.
They're re-hosting the stolen images on their own server, and they all have a watermark. Bizarrely, the watermark is
mattbee.mataroa.blog
, my
real
URL. I assume this is to somehow make it seem legitimate, like it's an officially-sanctioned mirror, but I don't know who they think is going to care. It's not like they're stealing from a site with name recognition.
When you view the source of a blog post, it's identical to the rendered HTML except that there are two Cloudflare scripts at the bottom, one to obfuscate the
mailto:
link in the footer (which doesn't work
1
) and one for analytics.
When you view the source of the index, there's a hidden link at the bottom to a Chinese
github.io
page for a website cloning tool.
I have no idea why I was targeted for impersonation. It should be obvious this isn't a high-value website. It's a personal blog where I write what's relevant to me, and that rarely overlaps with anything other people care about. If the subject matter didn't tip them off, it should be clear from the 0 comments on most posts that this is not an enterprise ripe for monetization.
If they just wanted a fake blog to scam adsense, surely a large language model would happily spew out more SEO-friendly slop than anything I have to offer. If their goal was to leech off the popularity of mataroa, why not impersonate one of the blogs with multiple front-page appearances on the orange website? Surely they have more SEO juice than me. Nothing about this makes any sense.
Anyway, the URL is registered with Namecheap, so I sent them an abuse report . I have no idea if they'll act on it. They don't seem to have a good track record of giving a shit unless the content is actually hosted with them.
It's hosted with Cloudflare, and the abuse reporting form they insist you use straight-up doesn't work . Click "Submit an abuse report" and it'll take you to a completely blank page. Very encouraging.
I'd have to dox myself to do a DMCA takedown, and I don't have the legal resources to do anything when it gets ignored. So if neither evil corporation cares to do anything, I guess I can just get fucked. I figure the best thing I can do to protect myself is document everything here. If you see a link to
mataroa.site
, it's not affiliated with me or mataroa. It seems like it isn't set up to scam people or distribute malware at the moment, but it probably will in the future. Be careful.
The index page also has a meta tag with a verification code for
mitgo.com
, a fake-looking website with some word salad identifying it as some kind of ad/SEO scamming platform or service. Will try to investigate this further.
Cryptocurrency hardware wallet maker Trezor has confirmed that three Safe 5 devices sold by Southeast Asian reseller CryptoBilis contained malicious hardware implants designed to steal wallet recovery phrases and send them to attackers over cellular networks.
The findings follow an investigation into a suspected hardware implant first reported in October , when a customer discovered an unauthorized circuit board inside a Trezor Safe 5 purchased from Indonesian reseller CryptoBilis.
At the time, Trezor had not received the device for examination and could not confirm the implant's capabilities.
In a new investigation update , the company says it has now examined the original device in its laboratory and identified two additional compromised wallets using photographs submitted by their owners.
All three compromised devices were purchased from CryptoBilis between August 20 and September 23, 2026.
Trezor says 48 CryptoBilis customers have contacted the company following its October warning, with devices being examined in its laboratory or through photographs of their internal components.
The company has also inspected devices from other resellers in the region and found no evidence of tampering.
So far, the confirmed implants have been limited to Safe 5 devices sold through CryptoBilis, and no affected customers have reported losing funds.
Trezor says its engineers analyzed the implant's firmware and confirmed that the malicious hardware can capture sensitive information displayed or entered on the wallet's screen.
The implant consists of an additional circuit board installed between the Safe 5's main board and display, allowing it to monitor screen activity without modifying the device's legitimate firmware or Secure Element.
When wallet recovery words appear on the screen, either during the creation of a new wallet backup or while restoring an existing wallet, the implant collects them.
It can also capture passphrases displayed on the screen, encrypt the stolen information, and transmit it over a mobile network to an attacker-controlled server.
If a connection is unavailable, the implant holds on to the captured data and repeatedly attempts to transmit it until successful.
These reported implants follow confirmed hardware implants previously discovered in Ledger devices sold through CryptoBilis, which have been linked to cryptocurrency thefts.
On November 11, Trezor released firmware version 2.13.1, which includes protections that prevent the implants from capturing information.
"Our latest firmware update 2.13.1, released on November 11th, includes a protection that stops the implants we’ve found from capturing anything on devices that run it, making the current batch of implants useless," Trezor said.
However, the company warns that the update cannot protect wallet recovery phrases that may have already been captured before it was installed.
While no Trezor customers have reported stolen funs, those who purchased Trezor devices from CryptoBilis are still advised to transfer their cryptocurrency to a newly created wallet using a new recovery phrase.
Due to these supply-chain attacks, Trezor has reduced its global reseller network by approximately 80%, significantly reducing the number of third-party resellers of its hardware wallets.
The company previously announced plans to reduce its reseller network in October, following reports of compromised Ledger wallets sold through CryptoBilis. This was before Trezor had learned of implants in its devices as well.
Trezor says the removed resellers were trustworthy and of no threat, but did not meet the stricter supply-chain security requirements being introduced.
Remaining partners must follow tighter controls governing how devices are sourced, stored, and accessed.
The company is offering replacement devices to anyone who purchased a Trezor wallet from CryptoBilis since March 2026, including customers whose devices have not been confirmed as compromised.
At this time, the company says it has found no evidence of device implants from other resellers and has received no reports of funds being stolen through the compromised Safe 5 wallets.
Adaptive Security's AI agents analyze email intent, context, and behavior to uncover phishing, business email compromise, and invoice fraud.
See what's getting through with a 14-day read-only scan of Microsoft 365 or Google Workspace, with no MX changes.
Been a while. Life is busying.
I got a part time job writing a Lisp compiler, so I’m going to talk about that.
This post might be hard to understand if you do not program. Or if you do. There’s a fair amount of background required.
You might be familiar with Lisp in the form of a Scheme interpreter you used for a few semesters in college. You might think things about it like “it’s so elegant, but it’s kind of impractical for day-to-day use”. You might think of it as “an interpreted language” and so don’t understand what I mean by Lisp compiler. If you don’t think these things you can probably skip to the next section.
In Lisp, in contrast with some languages, the semantics are essentially built around interpretation. When you give a Lisp interpreter some code it goes through it step by step and executes it. This invites careful execution. It’s natural, for example, to expect that a program like
(defun foo (x) (+ x 237))
(foo "hello world")
that defines an addition function and then calls it on a string, will do something nice like pop you into a debugger, rather than return garbage data.
But it’s also generally slow. The interpreter has to do something on all possible input. It can’t, for instance, very well optimize FOO to accept only one numerical argument in a register, because later FOO might be called with a string.
So you add a compiler. The compiler is an optimization. It takes code and returns an optimized version that tries to preserve these semantics as much as possible while being much faster. The optimized version is faster partly because it’s probably composed of machine code or JVM bytecode or something else interpretable very quickly, and partly because of higher level optimizations. For example
(defun foo (x) (+ x 237))
(+ (foo 16) 93)
(mapcar (eval) '(3 898 38))
here the compiler might note that FOO can only accept numbers, and when it sees a straightforward call to FOO like in the second line that gives it only numbers, it generates code that skips the “is this a number? No? Debugger time” check. An “interpreter stub” retains the whole safest behavior, and can be used in the third line if
eval
returns FOO.
This strikes a good balance, for me, between speed and freedom. The optimized code isn’t any less safe, so I can still write things with abandon and watch them fail in the debugger.
The downside is that the compiler has to be pretty smart to be very effective. Luckily several Lisp implementations with pretty good compilers already exist, like SBCL and CCL. Both can generate fast 1 code without too much trouble.
I work on a new Lisp compiler called Cleavir. Cleavir is the compiler part of Dr. Robert Strandh’s project, SICL . SICL is intended to provide modular, reusable, clean, and more positive adjectives code to other implementations, as well as being an implementation in itself.
SICL isn’t yet an implementation on its own, but Cleavir is used in another new Lisp implementation, clasp , which is Dr. Christian Schafmeister’s project.
As far as I know the initial thoughts for Clasp went something like this:
<drmeister> My lab has this new system for designing artificial protein-oids. They’re made of bis -amino acids, which we also invented.
<DoD, etc. shadowy masters> Frikkin’ sweet.
<drmeister> We call them spiroligozymes 2 . They could have incredible implications for-
<DoD, etc.> Sure great. Here’s an award for being a literal nanotechnologist, named after that physicist everyone likes.
<drmeister> OK so the thing is that this stuff we’re doing involves a lot of computer work .
<DoD, etc.> Because it’s the future.
<drmeister> Right, and we mostly do that in C++. But I like Lisp.
<DoD, etc.> Great. Use it. It’s got an ANSI standard. God bless America.
<drmeister> But we don’t want to lose the C++ code. Lisp can use C functions but C++ doesn’t really have any interoperability.
<DoD, etc.> So?
<drmeister> So I was thinking I’d spend several years making a new Lisp implementation that’s tight with C++ from the ground up.
<DoD, etc.> That sounds hard, and you’re a chemist.
<drmeister> So that’s a no, or…
<DoD, etc.> Here is a zillion dollars. Snap to it.
It must be nice being a respectable scientist, is what I’m saying.
Clasp ended up being based on Embeddable Common Lisp (ECL), so called because it’s written in C and designed to be called from C programs. ECL provides a lot of the runtime. For compilation, however, Cleavir compiles Lisp programs into its “Mid-level Intermediate Representation”, or MIR; Clasp then compiles this into LLVM-IR, which LLVM than compiles to machine code.
This is pretty convoluted and presents some problems (LLVM doesn’t really seem to make itself a good target for something with an online compiler and mostly heap allocation, for one). Luckily they are not usually mine, because I mostly limit myself to Cleavir, but it’s nice to know the nature of the gnashing maw you hang over.
Cleavir’s MIR, and also HIR (“High-level”), are mostly what I work with. Consider this (silly) function:
(defun example (x)
(flet ((getx () x)
(setx (y) (setf x y)))
(setx 19)
(print (getx))
(+ (getx) 331)))
flet
establishes local closures, and
setf
assigns.
(example anything)
will print 19 and then return 350.
In HIR, after a few transformations, the code looks like this . Here are the basics: white rectangles are “instructions”, and represent basic operations. Ovals and the orange rectangles are “data”. The solid black arrows indicate control flow. Red dashed arrows indicate inputs to instructions, and blue dashed arrows outputs. Functions begin with the instructions called “enter”.
A few instruction explanations:
enter
is the beginning of a function.
Create cell
,
Write cell
,
Fetch
, and
Read cell
have to do with shared variables for closures - more on that below.
enclose
allocates a closure. The regular inputs are (cells for) closed-over variables, while the input with the dashed pink line is the actual function code.
funcall
calls a function, the 1 input, with the other inputs as arguments.
ret
returns values from a function.
It’s not really much different from any assembly-type language in form, other than having closures and explicitly separating input and output, but it’s more convenient to represent control flow graphically than with labels.
A graph of operation nodes is pretty common as an intermediate representation, because it maps closely with the conception of computers as state machines. As such, some optimization techniques are well-trodden.
In 1973, G. A. Kildall published his paper “A Unified Approach to Global Program Optimization” 3 . The title is a bit grandiose but actually pretty accurate. Kildall laid out a very general algorithm for associating optimization information of any kind with nodes in an instruction graph of this form. A few weeks ago I implemented it for Cleavir.
It works like this. First, you establish some domain of optimization information. This domain can be anything you want, as long as it forms a bounded meet-semilattice 4 . Elements of the domain are called “pools”. Next, you define an “optimization function” which, given an instruction node and its pool, returns another pool.
The algorithm has a “work set” consisting of instructions paired with pools. The initial contents of the work set are dependent on what you’re doing, but contain at least one instruction. The algorithm returns what I’ve been calling a “dictionary”, which is an association of instructions to pools that is distinct from the work set. Initially the dictionary is empty, i.e. there are no associations.
The algorithm proceeds by choosing and removing some (instruction, pool) pair from the work set. If the instruction removed has not yet been associated with a pool in the dictionary, or if the associated pool is less than or equal to (an operation established by the definition of meet) the pool from the work set, the instruction becomes associated with a new pool that is the meet of the old association and the pool from the work set. Additionally, the optimization function is called with the instruction and this new pool; the result pool is paired with all instructions immediate succeeding (or preceding, depending on what you’re doing) the instruction in the work set.
But the paper describes that better. Intuitively, what happens is that if the pool in the work set for an instruction is “better” than the one for that instruction already in the dictionary, in some domain-specific sense, the instruction is reassociated with a “better” pool, and the nearby instructions are put in the work set with new information based on this instruction.
Nothing makes sense when it’s put that abstractly, right? It’s not just me? I don’t know how mathematicians survive.
I implemented this algorithm in a general way. The function,
kildall
, takes an argument called a “specialization” that includes all the domain-specific information for the algorithm. I have a few of these specializations.
The one I just put into a usable state was escape analysis. Check out the program with
getx
and
setx
again. An interpreter, upon seeing the
flet
, would allocate closures for both functions on the heap, i.e. dynamically, with cleanup being handled by the garbage collector. But if we look at the program, we can see that the closures cannot possibly be returned from this function or otherwise appear outside a strictly delimited context - they do not “escape”. In other words, these closures could be allocated with stack discipline. This is cheaper. An interpreter isn’t smart enough to see this but a compiler ought to be able to.
To analyze this with Kildall, we can have it track uses of values. A use causes an escape or does not; e.g. returning a value is an escape, but adding it is not. We define a pool as a map from variables to escape indicators. An indicator is true if the variable escapes, and false if it does not. Meet is a union of maps; if a variable appears in both maps, the new map’s indicator for that variable is the logical OR of the two indicators. 5 The bound is a map where all variables are known to escape.
The optimization function does different things depending on the type of instruction. We can do a completely correct, if overly conservative, analysis with the following rules:
The algorithm can then proceed in the reverse direction of control flow. Here’s the HIR again. We start at the bottom return instruction, with an initial pool of the empty map. The return is not yet associated with any pool, so it takes that one, and passes on a pool up where its input, the “V”, escapes.
It proceeds upwards in that way and then reaches the funcall to which GETX is input. It’s the first input, i.e. the function called, and we have not seen GETX before, so we put (GETX, false) in the next pool up. The same occurs for the other funcall with GETX, and so once we reach the top instruction, we have that GETX does not escape, and can be stack allocated.
The beautiful thing here is that all we actually need to have in the code are the definition of the semilattice and the optimization function rules, and the algorithm handles all the control flow. The analysis automatically works just as well around branches and loops. The whole thing is maybe fifty lines.
Stack allocating closures is nice, but what about those “cell” things? A cell is just a wrapper around a value, with a set and a get, like an ML “reference”. Closures in a language with assignment, like Lisp, have to have something like this; if
setx
just closed over the value, the assignment to x would not take in the outer function. These cells are implicit in the source code but still have to be allocated.
Determining that a cell can be stack allocated is more complicated. Naïvely, you might expect that a cell doesn’t escape if every closure it’s put in doesn’t escape. This is basically true, but there’s a nesting problem. Consider:
(lambda (x) ((lambda () (lambda () x))))
This is a function of one argument, which calls a function of zero arguments, which returns a function of no arguments that returns the first function’s argument. So for example if you call this function with x=4, you get back a function that returns 4.
The HIR looks like so . The outer function allocates a cell for x and a closure for the middle function using it, then calls that function. The middle function fetches the same, identical cell, puts it in a new closure for the innermost function, and then returns it.
If we use the Kildall specialization described above in the outer function, it will determine, correctly, that the middle closure can be stack-allocated; if used on the middle function it will determine, also correctly, that the inner closure cannot.
Were we to say that a cell doesn’t escape if everything it’s closed into, the outer function analysis would find, incorrectly, that the cell can be stack allocated - because it doesn’t know anything about the inner functions.
To determine whether cells can be stack allocated, we need to extend the algorithm to be aware of nested functions, which Kildall did not consider.
The obvious thing to do is, when the algorithm hits an
enclose
instruction, it calls for a recursive analysis on the inner function. This analysis can determine that the fetched cell is enclosed in a closure which escapes. Another step converts this analysis into a simplified “info” structure with only the information we need, i.e. whether the cells can escape the inner function. The optimization function for the outer
enclose
then uses this information to determine that the cell escapes.
On the
getx
example, it can determine in this way that the cell for
x
does
not
escape, as the functions don’t return their cells or any closures. So the
x
cell can be stack allocated there.
That’s as far as I’ve actually implemented.
Earlier, I mentioned that arguments to a
funcall
instruction other than the function called are assumed to escape. This is because the analysis does not know anything about the function called, and so cannot assume anything. However, as long as we’re analyzing inner functions, we have a representation for the information we need, the “info” structure. Particularly, we can track whether arguments are returned from functions (which does not inhibit them being stack-allocated in the calling function), or escape more generally. Then in the funcall we can use this information to provide a better analysis.
The problem is that this information effectively has to be propagated
forward
from the
enclose
to the
funcall
, i.e. in the opposite direction as this analysis. This propagation is not trivial. We could have code like
(lambda ()
(flet ((foo (x) x)
(bar (y) y)
(baz ...))
(funcall (if (some-condition) #'foo #'bar) #'baz)
nil))
baz
can be stack-allocated, but knowing this requires knowing that both possibly called functions do not let their argument escape.
It would be possible to tie in another Kildall specialization, type inference, to do this. Type inference propagates forward, and finds for each variable a set of values that it always contains. In the above, the implicit called-function variable always contains a function that does not let its argument escape.
This implies that type inference would have to be aware of the escape analysis, and escape analysis of type inference. A principled way to compose different specializations of Kildall’s algorithm together would do it.
Throughout Israel’s war on Palestine, doctors Thaer Ahmad and Feroze Sidhwa spent months at Nasser Hospital in the southern Gaza city of Khan Younis, where they provided care as volunteers and survived a raid and an airstrike on the complex. On Wednesday evening, they were in an Uber in New York headed to a screening of their film about their time in Gaza when they realized Nasser was the target of another Israeli airstrike.
“They just hit Nasser again,” Ahmad said, turning from the front seat toward Sidhwa. “I think Rizk is dead.”
He was referring to Dr. Rizk Abu Shaaira, an experienced surgeon and fixture of the Palestinian medical community whom both had worked alongside at the hospital and who appears in their film “ American Doctor .” When Israel attacked Nasser Hospital on Wednesday — for at least the seventh time since the genocide escalated in 2023 — Abu Shaaira was one of the six people killed.
As the doctors arrived at a theater in Westchester for their screening, they received a flood of messages, photos, and video from their colleagues at Nasser, showing smoke-filled departments and wrecked operating rooms. The attack forced the closure of the hospital’s emergency, surgery, radiology and laboratory departments, hospital officials said.
Six people were killed in the airstrike, according to Gaza health officials, and 52 others were wounded, said Médecins Sans Frontières/Doctors Without Borders. Israel said it had used a precision-guided missile to target a Hamas commander.
One video showed a body bag holding Abu Shaaira, who had been working a night shift in the surgical ward, one of several floors severely damaged in the airstrike. Sidhwa, who worked directly with Abu Shaaira during his time volunteering at Nasser, described the 52-year-old father as a colleague who was “enthusiastic about everything” and “loved surgery.”
Another image showed unexploded ordnance launched at the hospital that medical workers had placed atop a stretcher, bearing the label “ GBU-39/B ” – a model of guided missiles manufactured by U.S. company Boeing. Israel purchases this precise missile model using funds from the U.S. State Department.
“That’s not complicity,” said Feroze when asked about the U.S.-made missiles used in the attack. “That’s active participation in the murder of physicians and other healthcare workers.”
Wednesday’s attack on Nasser Hospital, which serves a population of about 1.3 million people, is the fourth Israeli strike on a hospital since the so-called ceasefire agreement in October 2025. It is the seventh on the Nasser complex, including a double-tap strike in August 2025 when Israeli warplanes struck the hospital twice within minutes, killing first responders and journalists. Sidhwa had been volunteering at Nasser during an earlier airstrike on the complex in March 2025 violating an earlier ceasefire . That strike killed multiple people, including a 16-year-old boy.
“Under international humanitarian law, hospitals must be respected and protected.”
When Ahmad volunteered at Nasser in early 2024, a part of the hospital’s pediatric ward was still damaged from an Israeli tank shell that flew through a window, killing Donia Abu Mohsen, 12, while she received care from a previous airstrike that killed her family. During his stint, Israeli soldiers raided the complex and detained several doctors with whom he worked; they remain imprisoned without charge . Ahmad said his colleagues at Nasser told him that upon hearing the first booms on Wednesday, they knew immediately, due to familiarity, that they had been hit by an Israeli attack.
“Something that has troubled us so much is how normalized the targeting of these hospitals has become for Palestinians serving their communities,” Ahmad said. “They knew what was going on right away.”
Since returning from their time treating patients in Gaza, both Ahmad and Sidhwa have lobbied members of Congress to support the Block the Bombs Act , a House bill that seeks to prohibit the sale of certain arms to Israel that are tied to violations of U.S. and international human rights law. Among the weapons subject to the ban is Boeing’s 250-pound GBU-39. With a new Congress soon to be controlled by Democrats , many of whom ran campaigns touting support for the bill, both Ahmad and Sidhwa called on lawmakers to act.
“If our Congress upheld international humanitarian law, as well as U.S. domestic law, Dr. Rizik would still be alive,” Ahmad said, “and there wouldn’t be a surgeon who lost both of his legs in this bombing.”
The Israeli military claimed in a series of statements posted to social media that it had targeted a senior Hamas commander and other Hamas members who were “hiding” in the hospital and that the strike was meant to “eliminate the threat they posed.” The military did not specify the actual threat nor address the killing of Rizk, patients, and other civilians by “precision-guided missiles” it claims to have deployed to mitigate civilian harm. Israel alleged Hamas was operating out of the hospital’s second floor, but provided no evidence beyond a computer-rendered video . At least six Israelis have been killed in Gaza since the start of the so-called ceasefire, the Israeli military has said . Israel has killed more than 1,400 Palestinians in that time, according to Gaza health officials. The United Nations said that among those reported dead are at least 340 children.
In a statement to The Intercept, the Israeli military repeated its claim that Wednesday’s strike was targeting a Hamas commander, but it declined to confirm whether the alleged target of their strike was killed or comment on the civilians killed in the attack.
President Donald Trump’s Board of Peace, tasked with rebuilding Gaza, called Wednesday’s attack a “tragic loss of life” but went on to repeat the Israeli allegation that Hamas carries out “continued exploitation of hospitals and other critical civilian infrastructure for military purposes.”
Sidhwa called the Board of Peace statement on Hamas’ alleged embedding in hospitals “bullshit,” adding that he has seen no evidence of Hamas embedding its fighters within any hospital in Gaza, a recurring observation by international doctors who volunteer in the strip.
“Show me one example,” Sidhwa said. “I would love to see a single photo, a single video, a single testimony from a Palestinian. Literally anything. It’s just completely absurd.”
Médecins Sans Frontières/Doctors Without Borders said in a statement that it was “appalled and outraged” by Israel’s attack, adding that its doctors had to operate on two of their colleagues and another patient injured in the strike. The group referred to its earlier decision in January to temporarily halt its teams’ operations at Nasser, citing reports of “armed men in different areas of the large compound of the hospital,” and said similar incidents have taken place more recently. Even so, the group said, this does not justify Israel’s attack.
“Under international humanitarian law, hospitals must be respected and protected,” the group said. “In no conceivable circumstances can attacks on functioning hospitals in Gaza be treated as normal or acceptable.”
The strike came days after the board issued a rare condemnation of the Israeli government for its blockade of humanitarian aid from entering Gaza in the aftermath of a storm that wiped out thousands of tents, killing four people. Israeli Prime Minister Benjamin Netanyahu rebuffed the criticism and blamed Hamas for not disarming. Israel, meanwhile, continues to occupy about 70% of the Gaza strip, extending beyond the yellow line, a border drawn in the ceasefire agreement that is meant to mark where Israel can operate its military, and launches attacks on the strip on a weekly basis, all violations of the agreement.
“The same military who’s blocking the necessary supplies, as a middle finger to you, decides that they’re going to bomb a hospital,” Ahmad said. “I’m sure behind closed doors everybody is fuming and reeling, but unless people are ready to actually hold the Israelis accountable, actually use their leverage, nothing is going to change.”
One of my ongoing research interests is understanding the nature of technological progress: How does new technology come into the world and improve over time? What sort of factors affect it? How, in general, should we think about it? I’ve come at this question from a few different angles: posts looking at the operations and legacy of Bell Labs, posts looking at how specific technologies improved over time, posts looking at how frequent multiple invention is and how long we wait for new inventions , and so on.
My current line of thinking is that creating some new technology is best thought of as a search process . A given technology can be thought of as a point in some high-dimensional “design space” or “technology space,” which contains every possible technology: every conceivable arrangement of parts, materials, natural phenomena, and so on. The job of the would-be inventor is to navigate this space, sifting through the arrangements of elements that don’t work to find the ones that will.
This search process is made difficult by the fact that, as with any situation where you’re enumerating the possible combinations of a large number of elements, technology space is incomprehensibly vast. In “ Are Technologies Inevitable? ” economist Matt Clancy notes that Wikipedia listed 272 “named equations” that describe various regularities in the world, ranging from the Navier-Stokes equations (which describe the motion of fluids) to the Arrhenius equation (which describes chemical reaction rates as a function of temperature) to the Exner equation (which describes how sediment gets deposited in a river). If we use this as a (very rough) estimate as to the number of different phenomena that a technology can leverage, it implies an enormous number of possible technologies that could be created. As Clancy writes:
If we’ve got 272 regularities to work with, for example, then the number of possible combinations of these regularities is two, raised to the power of 272 (since every regularity can be used or not used: two options). But 2^272 is more than some estimates of the number of atoms in the observable universe. And that’s got to be an undercount of the number of possible technologies, since it counts all technologies that use the same principles together as the same thing, even if they orchestrate them in vastly different ways or use them in vastly different magnitudes.
By comparison, the most common estimate for the number of atoms in the universe is around 10^80, or ~2^265. And it’s likely there are many, many more regularities that some technology could harness than 272. (Some in-progress work on this that I haven’t yet completed suggests that there are at least thousands.)
And as Clancy notes, this outrageously huge number dramatically undercounts the number of possible technologies, because it doesn’t take into account that the same phenomena can be used in lots of different ways. In Brian Arthur and Wolfgang Polak’s paper “The Evolution of Technology within a Simple Computer Model” (which we looked at earlier this year ), Arthur and Polak note that even within the universe of logic circuits made up of three basic elements (the NAND gate and the values of 1 and 0), the number of different circuits you can make for even a small number of inputs and outputs is staggeringly large:
The emergence of circuits such as 8-bit adders seems not difficult. But consider the combinatorics. If a component has n inputs and m outputs there are (2^m)^(2^n) possible phenotypes, each of which could be realized in a practical way by a large number of different circuits. For example, an 8-bit adder is one of over 10^177,554 phenotypes with 16 inputs and 9 outputs.
So the search space for some new technology is vast. And the way that we tackle vast search spaces is with information . Each bit of information cuts a search space in half, so even a relatively small amount of information can quickly narrow down what seems like a huge search space. When we create some new technology, what we’re doing is gathering information: figuring out what will work and what won’t work, what’s promising and what isn’t, narrowing down the huge space of technological possibilities and finding something within it that accomplishes some particular goal.
In the 19th century, for instance, many people were interested in building a mechanical flying machine, but it wasn’t clear the exact arrangement of elements that would yield a successful one. Thanks to knowledge of the laws of physics, and an existence proof of birds, would-be inventors were already working within a considerably narrowed search space: they knew roughly what elements a flying machine would need to have — lifting surfaces, a propulsion system, and a means of control — and had a general idea of how they should be arranged. But there were a huge number of ways that you could build a flying machine from these basic elements, and people spent a great deal of time and effort building different sorts of machines that did not in fact work. The Wright brothers’ eventual success can in large part be attributed to the fact that they were exceptionally talented at gathering information, enabling them to converge on a working airplane design far faster than their competitors.
I previously explored the nature of technological search in that previous piece looking at Arthur and Polak technological evolution paper , which uses a simple simulation to evolve different logic circuits, finding workable technologies amidst an enormous sea of possibilities. I really liked the basic simulation method Arthur used in this paper — randomly generating technologies to see how easy or hard it was to find working ones — and wanted to use simulation myself to further explore the dynamics of technological search. But while Arthur uses digital circuits — different arrangements of logic gates like NAND, OR, AND, etc. that can perform functions like addition — I wanted a more general model that could capture the nature of many different types of technology, while still being simple enough to simulate easily.
The model I came up with is inspired by another of Brian Arthur’s examinations of the nature of technology: his book The Nature of Technology . In this book Arthur describes technology as fundamentally “a set of phenomena captured and put to use.” He writes that:
… a practical technology consists of many phenomena working together. A radio receiver is not just a collection of parts. Nor is it merely a miniature signal processing factory. It is the orchestration of a collection of phenomena — induction, electron attraction and repulsion, electron emission, voltage drop across resistance, frequency resonance — all convened and set up to work in concert for a specific purpose.
Edison’s lightbulb, for instance, took advantage of several different phenomena: Joule heating , the phenomenon that electric current running through a material will raise its temperature. Incandescence , the phenomenon that a hot enough object will emit light. Transparency, the phenomenon that certain materials will allow the passage of light. And so on.
Phenomena like this are typically triggered automatically when the right conditions are created, which you can think about as being when the right objects, with the right properties, are placed in some particular arrangement. In the lightbulb, Joule heating occurs automatically when electric current runs through the filament, and incandescence occurs automatically when the filament gets hot enough. And the bulb had a vacuum atmosphere to prevent another, unwanted phenomenon — carbon reacting with oxygen — automatically occurring and destroying the carbon filament.
These three elements — Phenomena, Objects, and Properties — are the basic components of the technological model I came up with, which I call PTOP, for Phenomena Triggered by Objects with Properties. In this model you have some collection of objects, which can have some specified set of properties. Whenever the right objects with the right properties are placed in the proper arrangement, a phenomenon will be automatically triggered, which can have various effects: modifying the properties of existing objects, creating new objects, and so on. By chaining the correct objects and phenomena together in the correct order, you can create your desired outcome, which is some particular object or objects with some specific set of desirable properties. A simple, conceptual PTOP model for the lightbulb, for instance, might look like this:
By arranging the right sort of filament, an atmosphere, a bulb container, and electric current, you can trigger a series of phenomena that will ultimately result in the creation of light with desirable properties.
And here’s a sketch of a PTOP model for a more complicated technology, a Xerox machine, which uses various phenomena such as “photoconductivity” and “corona discharge” to generate a copy of a document:
I like this model because it captures the basic elements — natural phenomena and the conditions that trigger them — inherent to all types of technology, such that we can study the ‘space’ of possible technologies. And you can implement the basic idea in many different ways, from very simple representations of technology to very complex ones. In some ways this is bad (it took me a super long time, for instance, to come up with a simulable implementation that I was happy with) but it’s useful for studying different aspects of technological search. Let’s look at a few different implementations of a PTOP model and see what we find.
Let’s start with an extremely simple version of PTOP. In this version, we have 10 possible objects, each with two possible properties. The first property, P0, can take on any value from 1 to 10 and is inherent and unique to that object. You can think of this as the model having 10 different chemical elements, each taking on a different value of P0. The second property is size, which can also take on any value from 1 to 10, but is adjustable. So you can have a large object with P0 equal to 1 and size equal to 10, or a small object with P0 equal to 1 and size equal to 1. Overall there are 100 possible sorts of objects: 10 different object types, each of which can be 10 different sizes.
This version of the model has four phenomena in total. Each phenomenon is triggered when the right two objects are connected, and the first of those objects (what we’ll call the input object) has the correct size. When the phenomenon is triggered, it adds a specific property to the second object (what we’ll call the output object). So in the image below, when an object with a P0 value of 1 and size 5 is connected to an object with a P0 value of 2, it triggers a phenomenon, which adds a new property, P1, to the second object.
The phenomena in this model are arranged in a hierarchy: triggering each phenomenon requires an object with the property added by the previous phenomenon. So to trigger the phenomenon that adds P2, you need an object with the P1 property. P3, in turn, requires an object with P2, and so on. You can think of this hierarchy of phenomena as representing something like “to trigger incandescence, I need an object with a high temperature. To achieve high temperature, I need to use the phenomenon of Joule heating, which I can trigger with the right sort of electric current. To create electric current, I need …” and so on.
In this version of the model, the goal is to create an object with the “final” property of P4. You can think of this as representing something like “light with the proper brightness” or “lead shot with the proper size and sphericity.” This can be done by creating the exact right arrangement of objects: five objects arranged in a line, each with the correct P0 property and size.
This is a very simple implementation of PTOP, which we’ll call a “level 1 model.” But it does capture a few things about the technological search process. First, the search space in even this very simple model is very large: 10 object types, 10 sizes, and 5 objects total means (10x10)^5 = 10 billion possible arrangements to produce a P5-level phenomenon. 1 If you increased that to 100 objects, 100 sizes, and 10 different phenomena, you’d have 10^40 possible options. If we added more property types (maybe objects can have the properties of “temperature” and “density” in addition to size) the numbers would quickly become beyond astronomical.
But this simple version also shows the power that information can bring to bear on a large search space. When we looked at Arthur’s circuit search, we noted that what made the search tractable was modularity — finding a working design for a subcomponent, then locking that modular design into the system and using it as a repeatable ‘primitive’ element for further combinations. By preventing you from having to get every single part of a design correct in one shot, modularity effectively screens off many possibilities and reduces the size of the search space that must be traversed. As we found in that simulation:
A useful way of thinking about our 68 NAND gate search is that it’s like a huge, branching tree. At every step — every time we add a gate — there are thousands of branches, each one representing one possible way to wire up the gate. Each branch then splits into thousands more (representing all the possible ways of wiring up the next gate), which split into thousands more, which split into thousands more, until at the end we have 2^852 possible “leaves,” each one representing a unique way of wiring up all 68 gates. Trying to get all 68 gates right at once, and then checking to see whether or not you did, is like examining one single leaf, one path from the base of the tree all the way to the tip of a branch. Not only are you overwhelmingly likely to guess wrong, but you haven’t narrowed down your possibilities at all: all you know is that one single leaf wasn’t the right answer, leaving you with the rest of the 2^852 possible leaves to sift through.
Checking to see whether each gate we add is correct before we proceed to the next one, by contrast, massively narrows down the number of possibilities. Whenever we determine a gate isn’t in the right spot, it eliminates every possibility that branches off from that point. If there are 1000 possible ways to wire each gate, each time we guess correctly we’ve narrowed down the possibilities downstream of that choicepoint by 99.9%. Huge swaths of possibilities get eliminated at each correct guess, letting us converge on the correct answer much more quickly.
We can see these same basic mechanics with the PTOP model. With 10 object types, 10 sizes, 4 phenomena, and 1 billion effective possibilities, it takes (on average) 1 billion attempts to guess the entire correct design in one shot by randomly generating possible technologies.
But if we do a modular search — randomly adding just one object while randomly adjusting the size of the previous object until we’ve triggered the next phenomenon, then locking that successful design in and moving on — the search becomes much faster, because we’ve replaced a single billion-possibility space with a series of 100-possibility spaces. It takes on average 1,300 attempts to find the 10 type, 10 size, 4 phenomena answer, and even astronomically enormous technology space search problems become tractable.
This version also shows that the degree of modularity makes a huge difference in how easy a technology is to find. The more modules we have whose design we can lock in, the shorter each step is up the ladder to the working technology, and the easier each step is to take. If we take our 10 object type, 10 size model up to 100 phenomena levels, we’re now at an enormous 10^200 search space, but with 100 steps up the ladder that we can lock in, finding it is trivial — a random search finds it after about 10,000 attempts on average. The same-sized search space generated from 10 phenomena levels but 10 billion possible object types and sizes (which only gives us 10 steps up the ladder, rather than 100) becomes utterly impossible to find randomly, even with modular search.
This version of the model also lets us see how different sorts of knowledge can make the search process easier. For instance, as Joel Mokyr notes in The Gifts of Athena , scientific knowledge is very useful when trying to create some new technology, because “the range of experimentation possibilities that needs to be searched over is far larger if the searcher knows nothing about the natural principles at work.” In our level 1 PTOP model, scientific knowledge would be something like “phenomenon 3 can’t work with object type 2” or “phenomenon 4 must have its two objects of equal size.”
The usefulness of this sort of scientific knowledge is a function of how many possibilities it screens off. The more possibilities it screens off, the more bits of information it provides, and the more useful it is. So something like “phenomenon 5 can’t use object 1” or “object 3 can’t touch object 4” provides a relatively small amount of information, because it doesn’t eliminate that many possibilities. Knowledge of the sort “phenomenon 4 MUST use object 1” or “object 3 MUST touch object 4,” by contrast, screens off a lot more possibilities, provides much more information, and narrows the search much more effectively.
One reason that, in the real world, the technological development process is tractable is that a lot of our knowledge is of the latter type. Phenomena typically have specific triggering conditions, which we can observe and discover: Marconi knew what was needed to create electromagnetic waves when he was working on his radio, Edison knew what was needed to create incandescence in a lamp filament, and the scientists on the Manhattan Project knew roughly what conditions were needed to trigger a nuclear chain reaction.
Even this highly simplified version of the PTOP model is useful for exploring various technological search dynamics. But ultimately it’s a little too simple to capture many of the more interesting dynamics of technological search. So let’s add some complexity. First, real phenomena often require multiple “input” objects, rather than just one: triggering the phenomenon of “combustion” in a gasoline engine requires fuel, an oxidizer, and an electric spark. So we’ll make it so that each phenomenon can have multiple input objects instead of just one. Second, there are often multiple different phenomena that you can use to accomplish some particular goal: if you want to make mechanical motion, for instance, there are a variety of different phenomena you can harness to do that, and motors built to harness them — electric motors, hydraulic motors, internal combustion engines — all work in different ways. So let’s also make it so that instead of just one phenomenon for each level, there can be more than one, each one requiring a different set of objects with the right properties to trigger.
With the level 1 PTOP model, there was only a single workable version of the technology. With the level 2 model, there are multiple working designs. And unlike the straight lines of objects of the previous model, this one creates branching, treelike chains.
With this version of the model (which I’ll call the “level 2 model”), even though there are a large number of possible working designs, the number of nonworking technologies is vastly larger, and finding a workable option by pure blind search quickly becomes unworkable.
We can solve this with a slightly different flavor of modular search, very similar to the “encapsulation” that Arthur uses in his technological evolution paper. In this version, the model starts out by randomly combining different objects with different properties, connected in different ways. Whenever an arrangement of objects triggers some phenomena, that arrangement gets bundled into a new object, and then that object can be chosen by the simulation to be randomly combined with other objects. As with our previous, simpler modular search, this lets the simulation accumulate partial solutions and quickly find working technologies even amidst very large search spaces.
A level 2 PTOP model can also be used to show the information-accumulating power of sexual reproduction. In a previous essay , we noted that sexual reproduction is its own sort of modular search — by letting children inherit genes from two parents, sex allows useful genetic “discoveries” made by many different lineages to spread throughout the population. This is in contrast to asexual reproduction, where only one particular lineage ultimately survives, and discoveries made by others die out due to a phenomenon called “clonal interference.” This allows sexually reproducing populations to converge on maximum fitness much more quickly.
We can see this same thing using the level 2 PTOP model. I ran a version of it with two different technology “populations.” Each population had 1,000 randomly generated technologies in it. In one population, I implemented asexual reproduction — each generation, every technology would get one random mutation to an object (deleting an object, adding an object, or changing an objects properties). The fittest members of the population, measured by the highest phenomena level they had unlocked, survived into the next generation. In the other population, I implemented sexual reproduction — in addition to random mutation, children would be generated by randomly crossing over the branches of two parents. With 5 levels of phenomena, asexual reproduction couldn’t achieve the maximum phenomena level after 2,000 generations in the example below; sexual reproduction, by contrast, found it after just over 100 generations.
This flavor of PTOP is a little richer and can show a broader array of technological search dynamics, but it’s still a little simple, so let’s add some more complexity.
First, instead of making triggered properties — P1, P2, P3, etc. — binary (on or off), let’s make them be able to take on multiple values: before the property is switched on, it has a value of 0, while once a phenomenon triggers it, it can have a value from 1 to 10. We’ll make the value that it takes a function of two things: the size of the input object(s) and the value of the predecessor phenomenon. So for a phenomenon that triggers P2, the value of P2 will depend on the value of P1 and the size of its object. You can think of this as representing something like “the temperature in the lightbulb filament depends on the properties of the electric current flowing through it”: more amperage, or higher voltage, means higher filament temperatures. The brightness of the light emitted, in turn, will be a function of the temperature value of the filament.
We’ll make the value of triggered phenomena be determined in one of two ways. Either it’s maximized when the predecessor phenomenon and object size are EQUAL, or maximized when they’re as different as possible. So P2 can either be 10 when P1 and its size are the same (both 1, both 2, both 3), or when one is 10 and the other is 1. (For phenomena triggered by multiple input objects, we’ll take the average of the value calculated for each object.) We’ll call this version of the PTOP model the “level 3 model.”
This change actually makes the initial stage of the technological search much easier. Because the correct object size is no longer needed to trigger a phenomenon (just the correct object type), getting a technology that triggers the final phenomenon is now very easy (though it would be easy to change this by making the value of triggered phenomena dependent on some new property instead of size, and keeping whether or not a phenomenon is triggered size dependent). But now there’s an element of performance tuning. A technology that works, in the sense that it has a positive value for the final triggered phenomenon, might be quick to find, but to maximize performance — achieve a final phenomenon with a value of 10 — you need to keep iterating, fiddling with the sizes of the various objects to gradually push performance up.
This dialing-in step is meant to capture the technological development process: taking some technology that already works to some degree and pushing its performance higher or building a version that works in a particular way. With Edison’s lightbulb, for instance, incandescent bulbs had been demonstrated since the early 19th century, but their performance was poor — they burned out quickly, or the interior of the bulb blackened, or they used too much power. Edison took a technology whose configuration had been mostly figured out — a high-melting-point filament, a glass bulb, and an atmosphere to minimize reactivity were all common characteristics of previous bulbs — and pushed its performance higher by tweaking the properties of the various elements: the level of vacuum, the size of the filament, the exact type of carbon, and so on.
In the level 2 model, we had multiple phenomena for each level — multiple different ways to trigger P2, for instance. In the level 3 model, we’ll keep the same feature, but we’ll add a twist: different phenomena have different ranges for triggered properties that they can possibly achieve. So one way of triggering P2 might only be able to reach a value of 7, while the other might be able to achieve a value of 10. For some technologies, this might be fine; in other cases, maximizing performance will require using some other, different phenomena instead.
This also mirrors what we see with real-world technologies. When developing some new technology, the designer will be confronted with many possible ways of doing some particular job, and depending on the performance required, different options might work best. In the lightbulb, the performance of a carbon filament could only be pushed so high, and so eventually lightbulbs switched to tungsten filaments, which in turn required inventing a new process for producing ductile tungsten wire. Similarly, there are a variety of different ways of implementing the valves on an internal combustion engine to let gases into and out of the cylinders. Achieving very high engine performance, such as the number of revolutions per minute required on a Formula One car, requires complex valves that use things like compressed air instead of conventional wire springs , while if you’re building a four-door sedan the cheaper and simpler wire spring is fine.
Let’s now add one more element to the level 3 model. Up until now, we’ve had one single chain of properties: one phenomenon triggers another, which triggers another, and so on. Now let’s add a parallel set of properties, triggered by a parallel set of phenomena. In our lightbulb example, we can think of this as the temperature of the filament triggering not only incandescence but thermal expansion and thermionic emission.
(In this example, all these phenomena are triggered by the same property, temperature. In our model, for ease of modeling purposes we’ll have each of the parallel phenomena triggered by its own property.)
These parallel phenomena are triggered under the same conditions as the primary phenomena, but their values might not necessarily be determined in the same way: the conditions that create a value of 10 for P2 might create a value of 5, or 1, for parallel property T2. Ultimate performance of a technology will be a function of both of the final triggered properties: the value of, say, not just P9 but T9 as well.
This addition has a few consequences. For one, the technological search becomes more difficult: trying to dial in a technology by adjusting sizes randomly takes many more iterations if you’re trying to maximize both P9 and T9 than it does if you’re just trying to maximize one or the other. This mirrors technology more generally: the more dimensions of performance you care about, the more difficult getting a technology that’s good enough is.
Another consequence of this addition is that we now have design trade-offs. With multiple phenomena (and parallel phenomena) at each level, we can have different designs, which might achieve different levels of performance. I ran a level 3 search that generated random technological prototypes, and then tried to dial in the performance of each one for several different performance goals: maximizing P7 and T7, minimizing them, and achieving some specific value for each. At the end of the run, each goal had a fundamentally different arrangement, with different values for object sizes. The same basic technology was best implemented in different ways, depending on the performance goal.
To understand the nature of technological progress, it’s useful to think of creating a new technology as a sort of search process, one that’s made tractable by the intelligent acquisition and application of information. We can understand technological progress, in turn, by studying the nature of search processes — what sort of things make them easy, what sort of things make them hard, what sort of information acquisition methods we can bring to bear, and so on. The PTOP models described above are, I think, a useful tool for exploring these technological search dynamics: they’re simple to simulate, they’re flexible, and they can capture a lot of real-world elements of technological development.
Aged mice engineered to lack granzyme K have improved heart and liver function and less kidney damage.
Age-related stiffening and scarring of liver tissue (pictured) declined in mice that were bioengineered to lack a certain enzyme. Credit: Ziad M. El-Zaatari/Science Photo Library
Researchers have found an enzyme that drives ageing in the body’s tissues 1 . Drugs that reduce the levels of this protein might one day combat the effects of ageing without impairing the body’s immune defences.
Access through your institution
Access Nature and 54 other Nature Portfolio journals
Get Nature+, our best-value online-access subscription
$39.99 / 30 days cancel any time
Subscribe to this journal
Receive 51 print issues and online access
$199.00 per year only $3.90 per issue
Rent or buy this article
Prices vary by article type
Learn morePrices may be subject to local taxes which are calculated during checkout
doi: https://doi.org/10.1038/d41586-026-03638-3
We are releasing Decider v1.3 and Decider Flash v1.3 , the successors to our earlier decision models: v1 , v1.1 , v1.2 , and Flash v1.2 .
Decider Flash v1.3 is a smaller model distilled from Decider v1.3. Both models are available on Hugging Face under Apache license, through OpenRouter , and the Perplexity Decisions API .
Perplexity Decider is inspired by Jev , TypeSafe AI’s System One Model. It supports binary and multi-class classification with ordered or unordered labels, returning probabilities that applications can use to classify, route, rank, and evaluate inputs.
Both v1.3 models improve performance and robustness across a broad range of text and vision tasks through bidirectional attention, better-curated training data, and a refined training recipe. We also introduce locate , a new feature to highlight the selected content for named entity recognition, personal information identification, and extractive question-answering tasks.
In this post, we explain how we train and evaluate Decider and share how we use it internally at Perplexity.
A decision model is a general-purpose classifier. You give it an input and a set of questions each with its possible answers. For each question, it returns a probability distribution over the answers. It supports 3 question types:
Decision models support a wide range of classification and scoring tasks:
Many of these tasks were previously handled by generative models like LLMs, even though they do not require free-form text generation. Decision models sit between LLMs and task-specific classifiers. They return probabilities for multiple questions about the same input in a single forward pass, avoiding token-by-token answer generation and sharing computation across questions. Unlike task-specific classifiers, they can handle new tasks through natural language prompts, a flexibility learned from training across diverse tasks in a shared question-answering format.
We build Decider by adapting strong generative LLM backbones. To explain the adaptation, we first describe how a request is represented. As illustrated below, a request consists out of a shared context (the state) and a number of questions. The state will be reused by all questions.
For example, given a document and its summary, a single request can ask whether the summary faithfully represents the document and whether it is intended for an expert or a general audience. After the state, each question block contains a question and its possible answers, each assigned a predefined label token such as A, B, or C. A special
<|marker|>
token indicates where to read out the model’s prediction. At this position, a learned linear output layer (a decision head), maps the hidden state to scores for the question’s answer options, which are then converted to probabilities.
We initialize the output layer from the base model, which normally scores next-token from the entire vocabulary, and only keep the rows corresponding to the predefined option tokens such as A, B, or C. This pruned layer is then trained to turn the hidden state of
<|marker|>
into answer scores. This approach covers all classification questions because they can all be formulated as a multiple choice.
For training, we take hundreds of public datasets spanning diverse tasks (sentiment, natural language inference, intent detection, entity matching, moderation, fact checking, ratings, etc.) and convert each example into the unified format described above: a state, one or more questions, their options and a target. The target can be the single correct option if we have gold labels, or a probability distribution over options.
In v1.3, we introduce locate , which extracts text from the state instead of selecting from predefined options. A locate question describes what to find, using either a short label such as “location” or an instruction such as “Extract the city name where the job is located.” The model returns the exact matching text from the state, along with its start and end character locations. If it identifies no matches, it returns an empty list.
Because of shared state, a single request can combine locate, classification, and scoring questions about the same input. For example, it can ask whether a job requires senior-level experience and extract the required skills.
Our models start from strong pretrained generative backbones, whose causal attention lets each token attend only to itself and preceding tokens. Our ablation studies showed that making the backbone’s full-attention layers bidirectional improves performance, so we adopt this design to let each token incorporate context from the entire input.
Bidirectional attention introduces another design choice: how should the state and questions interact? We considered three attention patterns, with different implications for performance, answer stability, and cache reuse:
We ultimately chose isolated questions for their strong performance and stability.
Training proceeds in three stages for both model sizes. We first train the larger model, based on Qwen3.8-27B , using cross-entropy on large datasets, then distill it into the smaller Qwen3.5-4B model.
The first stage is generalist training, where we fully fine-tune the model on large-scale corpora. In this stage, we only accept data that helps the model across the board and is not specific to any benchmark; we thus exclude any benchmark training splits.
After this generalist model is trained, we run a second, more fine-grained stage using LoRA . The data used in this stage is targeted toward specific domains and tasks. We add data in the second stage rather than the first one if we observe narrow gains or if we observe some regressions on other tasks. We use LoRA to avoid drifting too much from the generalist model and risking losing performance to fit those specific domains. The goal is to improve performance while retaining the backbone’s general knowledge. We also use a weight when merging the LoRA back into the base model, to control the drift more precisely and favor held-out metrics above any in-domain gains.
Finally, we add a vision-specific step. Similar to the second stage, the vision step is treated as another fine-grained specialization step, using a LoRA adapter that is merged back to the base model with a weight. Some vision capabilities can come at the price of text performance. Since we observe much more usage of the models on text, we prioritize text metrics over vision metrics.
For both text stages, we use the average weights from three runs, each using a different random seed. We found this improves the performance and robustness of the aggregated model.
Once the final large model is obtained, we apply the same three-stage training procedure to the smaller model. Here, the large model acts as the teacher: its predicted output distribution replaces the gold labels, and the smaller model is trained to minimize the KL divergence between its predictions and those of the teacher. This distillation objective outperforms cross-entropy on the same training data. While cross-entropy performs better on benchmarks with dedicated training data, it generalizes less well to held-out data. We hypothesize that distillation better transfers the teacher’s output distribution, including its confidence over non-gold alternatives, whereas cross-entropy encourages overfitting to the benchmark-specific training distribution. We therefore adopt the KL-based distillation objective.
To mitigate train-test contamination, we remove any training samples that could overlap with any evaluation we use. This is important because some public training datasets contain large parts of some evaluation datasets. We also conduct extensive bias audits and removal to make sure our gains are reliable and not just driven by learned biases.
The locate
feature
extracts information such as named entities from text, without changing how it answers ordinary requests. To do so, we introduce an additional training stage: we add a new special token,
<|locate|>,
a span head, and LoRA adapter to Decider.
We initialize
<|locate|>
’s embedding from
<|marker|>
learned in the previous training stages. We train only this new embedding, the span head, and the LoRA adapters, while keeping the original backbone weights and decision head frozen. Each requested field gets its own
<|locate|>
token.
The span head uses
<|locate|>
’s representation together with the state-token representations to score where matching spans start and end, and which start-end pairs belong together. It also uses the
<|locate|>
token’s representation to predict field-specific thresholds for these scores. Selected spans are returned as character positions in the original text.
We train the span head with an adapted InfoNCE loss that pushes every gold span above the threshold, and the threshold above every other span. The loss has two terms: The first one pushes the scores of correct spans above the threshold and the wrong spans. The second term pushes the threshold above the scores of wrong spans. Fields with no answer get only the second term, which teaches the model to return an empty list.
We train on a mix of span extraction tasks, including named entity recognition, PII detection and extractive question answering. We vary the field descriptions from short labels to detailed instructions, so the model learns to follow the request rather than memorize a fixed label set.
Locate teaches the model a structurally different task, and we want to add it without losing what the model already does well. Merging the locate adapters into the backbone causes some regression on decision requests. To limit this, we are running investigations such as more replay data from earlier stages and auxiliary objectives that keep the model’s outputs on decision requests close to those of the original model. However, we find that merging is currently still not lossless, so we keep the adapters unmerged and activate them only for locate requests.
We evaluate Decider v1.3 and Decider Flash v1.3 on external benchmarks from the Hugging Face Decision Index , Vals AI’s ClaimBench , and Artificial Analysis Decision Index .
Across these evaluations, our models demonstrate strong performance. Even though these leaderboards include privately held tasks, they can still be gamed through repeated submission and iterative tuning based on leaderboard feedback. To complement these leaderboards, we evaluate the models on an internal suite combining private production tasks with held-out evaluations drawn from public non-benchmark datasets. These evaluations provide an additional check on generalization beyond public benchmarks, helping us distinguish broader improvements from gains specific to familiar evaluation suites.
Internally, we built a suite of more than 200 tasks spanning various domains and tasks such as classification, scoring, reranking, and entity extraction. To honestly assess Decider’s real-world performance, all evaluations are performed zero-shot, without task-specific fine-tuning, giving us a clear signal of where to improve the model.
At Perplexity, we use a multi-head classification system to process each user query. Each query is first passed through an embedding model that acts as a feature extractor. The resulting embedding is then fed into multiple separate classification heads, including both binary and multi-label classifiers. For example, one head determines whether a user query should trigger web search.
Across 63 classification tasks with independently relabeled references by a frontier LLM, Decider v1.3 achieves 91.6% mean accuracy, exceeding our production classifiers by 6.54 percentage points. Decider Flash v1.3 also outperforms the production baseline, while Decider v1.3 outperforms Jev 1.14.
We assembled a domain-specific evaluation suite from public datasets to assess decision models’ classification performance across seven domains: claim verification (6 tasks), healthcare (7), cybersecurity (8), programming (16), government (7), law (9) and finance (9).
For example, “judge the time complexity of a Python program”, or “use an annual financial report to determine whether a company’s unrestricted cash covers debt principal due within the next twelve months”. Decider v1.3 leads across all seven domains, outperforming Jev 1.14 by up to 12.9 percentage points in finance and 9.3 points in law. Decider Flash v1.3 trails Jev 1.14 in finance, programming, and law, and performs similarly in other domains.
Search is at the core of Perplexity. We maintain a broad suite of retrieval tasks to evaluate our models’ reranking performance. For each task, we first use a pool of embedding models to retrieve the top 50 candidate documents from each corpus. We then rerank these candidates using Decider and compare its performance against a strong reranker baseline, Qwen3-Reranker-8B.
We evaluate Decider in a zero-shot, pointwise setting, using the model to directly score each query–document pair independently and rank documents by relevance. Across 72 retrieval tasks, Decider v1.3 achieves a mean nDCG@10 of 83.99, outperforming Qwen3-Reranker-8B by 1.81 points and Jev 1.14 by 2.24 points.
On the BEIR benchmark , both models outperform Qwen3-Reranker-8B by 8.78 and 7.05 nDCG@10 respectively. Against Jev 1.14, Decider v1.3 is 1.33 points higher, while the Flash version scores 0.4 lower.
To evaluate decision models beyond English, we assembled a multilingual classification benchmark comprising 19 language-specific tasks from 8 public datasets, with 46,484 examples across eight languages: German, Spanish, French, Italian, Russian, Japanese, Korean, and Chinese. The benchmark covers intent detection, topic classification, sentiment analysis, natural language inference, paraphrase detection, offensive language detection, and grammatical acceptability.
We report mean accuracy across tasks within each language, weighting each task equally. Decider v1.3 outperforms Jev 1.14 in all eight languages and Decider Flash v1.3 does so in six, with mean task accuracies of 88.16% for Decider v1.3 and 86.50% for Decider Flash v1.3, compared with 85.41% for Jev 1.14.
We evaluate the locate feature on 17 out-of-domain tasks that test its extraction across various domains, input formats (text, tables, structured documents) and instructions (short labels, questions and detailed descriptions). The domains range from Wikipedia to scientific papers, cyber-threat reports, technical support, privacy policies, resumes, and legal contracts. The requests range from short label names such as “person” or “email address”, through questions about a table or a support ticket, to detailed field descriptions for structured extraction, such as the parties of an NDA or the total on an invoice.
We evaluate NER and PII using exact-span F1, which requires predicted spans to match the reference boundaries exactly. Extractive QA uses character-level F1, giving partial credit for overlapping answer text, while structured extraction uses field accuracy, the proportion of fields extracted correctly. For CV parsing, we average the NER and PII exact-span F1 scores.
We compare our models against general-purpose extraction models of different sizes: GLiNER large v2.5 (0.5B), Liquid d1 (2B) and Cloudflare’s Clairic (undisclosed). Decider v1.3 reaches an average score of 69.0 (using each task’s primary metric) and Decider Flash v1.3 reaches 63.6, compared with 43.3 for Liquid d1, 41.5 for Clairic and 33.6 for GLiNER large v2.5. Both Decider models lead in every category.
Decider has natively supported vision tasks since v1. To evaluate its performance beyond text, we assembled a five-task benchmark suite with a particular focus on document classification, including invoices, letters, and resumes. The suite also covers satellite image classification, texture classification, pet breed classification, and animal counting.
Decider v1.3 achieves a mean accuracy of 76.99% across the five visual tasks, outperforming Jev 1.14 by 1.47 percentage points. Decider Flash v1.3 achieves 72.77%, demonstrating visual classification capabilities in a smaller model.
We sampled one million deduplicated, PII-masked requests submitted to the Perplexity Decision API during its first 18 days of availability. Because each request can contain multiple questions about the same state, the sample comprises 2,318,887 individual questions. All requests were included with explicit user permission for research.
Production requests do not come with ground-truth labels, so we use frontier LLM judges to generate reference answers and measure each model’s agreement with them. We also group the requests into 10 task categories, including information extraction, domain classification, sentiment analysis, intent and routing, relevance ranking, content moderation, quality and compliance review, entity matching, business analysis, and an “Other” category. This breakdown shows how performance varies across real-world use cases.
The task mix is uneven: information extraction accounts for 425,402 questions, domain classification for 409,564, and sentiment analysis for 344,158. Together, these three categories make up 50.8% of the sampled questions.
Decider v1.3 achieves the highest agreement with the judges at 93.98%, compared with 93.68% for Decider v1.2 and 93.35% for Jev 1.14. Decider v1.3 and Jev 1.14 are closely matched on domain classification and sentiment analysis, with gaps of 0.34 and 0.07 percentage points, respectively. Jev leads by 0.69 points on relevance ranking, while Decider v1.3 leads by 0.93 points on information extraction (the most common task in the sample) and by 1.21 points on intent and routing.
The chart below compares the reported cost of running the same one million production requests. Each request can contain multiple questions, so the unit here is requests, not individual questions.
We evaluated label sensitivity on 372 multiple-choice questions, making 4,788 requests per model. We reordered options, reassigned labels to answer texts, and renamed labels while preserving each question’s meaning, then checked whether the model’s semantic answer changed. Lower flip rates indicate greater stability.
Decider v1.3 changed its answer on just 0.27% of questions under each transformation, compared with 2.69–4.84% for Jev 1.14. We also repeated identical inputs to measure serving variability: Decider v1.3 showed no changes, while Jev 1.14 changed on 1.88% of questions.
Decider is built for workflows that need fast and structured decisions. In this section we explore how to leverage them to produce meaningful impact on the way we work. Here are some that stood out.
Internally, we are already using Decider to improve our security policies.
The activity of our agents is recorded and a series of rule-based checks are performed to identify any problematic behavior. A rule-based approach means that we can monitor our agents in real-time with negligible latency added. Offline, we use Decider to look at samples from these recorded agent logs. In the case that no problematic behavior was flagged, Decider checks if there is something that our set of rules missed; and in the case that an alarm was raised, Decider checks whether this was a false alarm. Any records where our rule set fails in either case are sent to an agent for triage and a fix to the rules is proposed, to be approved by a member of our security team.
In one day, Decider read 1 billion tokens across 7,000 agent sessions and identified flaws that led to 14 rule fixes, 6 of which were approved and shipped within two days. Replayed on a week of logs, the fixes cut our busiest rule's volume by 52%, and the widened rules caught about 40% more legitimate actions to investigate.
When we post-train models with reinforcement learning, aggregate metrics such as a terminal reward do not explain why a rollout (an individual attempt at a task) succeeded or failed. It can lose reward unfairly because a tool service or the sandbox failed, or receive undeserved reward if the evaluator overlooks an unsupported claim, such as a made-up value that no tool returned.
We use Decider to monitor rollouts for these cases. Code first identifies parts of a rollout that warrant closer inspection: a failed tool call and the surrounding reasoning, code that ran without errors, or the final answer. Decider then answers multiple-choice questions about each part, such as what failed in a step (a tool service, an external site, the sandbox, the harness, or the agent’s own code) and whether the agent interpreted the result correctly. We bundle all questions about a given part into a single request and store the probabilities rather than a verdict, so we can adjust thresholds later without querying Decider again. The monitor only observes and diagnoses: it never changes a reward or stops a run.
When crawling web pages to index and serve to users, many pages are too low quality to be of any use. This includes anti-bot walls, CAPTCHAs, and error pages, as well as correctly loaded web pages that just don’t contain any helpful information, such as spam, SEO filler or navigation-only pages. These low-quality pages need to be identified and filtered out of our index.
Using Decider, we can judge the quality of pages as we crawl them. In the same forward pass, we perform a suite of other classification tasks such as identifying the domain and intended audience of the content and whether it contains harmful, illegal, or personally identifiable information. Compared to using an LLM judge, Decider is considerably faster and cheaper.
Beyond these internal uses, Decider also fits workflows such as the following.
Because Decider reads images, it also works as a visual checker, reviewing style changes to web pages or apps and identifying faults. It can review page screenshots for clipped text, overlapping elements, broken layouts before a change ships, or flag charts whose design could mislead a reader or break a brand guide.
Agents can use Decider for the small decisions inside larger tasks. A browser agent can send a screenshot at each step and receive detailed information about the state of the page and the expected outcome of each possible action.
Users’ questions can greatly vary in their complexity, as does the depth of search that needs to be performed to find an answer. Decider can estimate this before search begins, allowing for fewer resources to be spent on simple questions.
Decider returns probabilities. The appropriate decision threshold depends on the application. Label frequencies and the relative costs of false positives and false negatives vary across use cases. We therefore encourage users to tune thresholds on a small, representative labeled development set rather than assume that a fixed cutoff will work equally well across tasks.
We recommend using Decider v1.3 for nuanced judgments, detailed rubrics, and workflows where errors are costly. Choose Decider Flash v1.3 for high-volume routing, labeling, and filtering where latency and cost are the main constraints. Evaluate both models on representative examples from your workload, then choose the model that meets your quality, latency, and budget requirements.
Both models are available as downloadable weights on Hugging Face under Apache license, through OpenRouter , and the Perplexity Decisions API .
During the trial of Luigi Mangione, much of the coverage was focused on three women called the Mangionistas : Whether they are extremists, whether they should have press passes , whether they are simply bubbleheaded fangirls swooning over an objectively hot alleged killer. But much of the sensationalist, often sexist coverage has obscured the deeper issues that the murder of United Healthcare CEO Brian Thompson has pushed to the surface: The fact that in a nation as wealthy as the U.S., citizens are regularly dying or, at best, going into debt, due to the exorbitant cost of healthcare—and will, as of next year, be left even more vulnerable thanks to Trump's Medicaid cuts, which threaten coverage for nearly a million New Yorkers and institute work requirements to obtain basic coverage.
" Bigger Than Luigi ," Miléna Mikael-Debass 's short documentary showing this week at DOC NYC, hones in on this topic so cogently it's a feat that the Emmy-winning director was able to fit so much in its 16-minute runtime, capturing snapshots of the lives of four people from the demonstrations outside Mangione's hearings in lower Manhattan. There is Shane, an ER doctor whose activism extends beyond the City courthouse to Albany, where he advocates for single-payer healthcare system and rallies at the state legislature to pass the New York Health Act; Breigh, a paralegal and true-crime fan from Philadelphia who is adamant about Mangione's right to a fair trial; Jonni, an activist and organizer who lost his brother due to inadequate healthcare; and Celeste, an Italian American New Yorker and grad student with a similar spinal affliction to Mangione.
To continue, please click the box below to let us know you're not a robot.
Please make sure your browser supports JavaScript and cookies and that you are not blocking them from loading. For more information you can review our Terms of Service and Cookie Policy .
For inquiries related to this message please contact our support team and provide the reference ID below.
Block reference ID:982f6a59-df9d-11f1-b2fd-5c33e175a927
Get the most important global markets news at your fingertips with a Bloomberg.com subscription.
SUBSCRIBE NOW
APP: GPLv3 with the FM1 SDK linking exception; no warranty. SDK and firmware resources have separate redistribution terms in THIRD_PARTY.md. Source: https://open.m-vave.com/releases/V14/6324230590b8e332bc544128abd7b919a2efd5982db60ea9a11663d4ea820344/FM1-Open-V14-Development-Kit-copy-update.zip
FM-1 V15 recovery firmware: https://www.m-vave.com/download (PC Firmware / FM-1 V15). Distributed by M-VAVE under Apache-2.0. Retain applicable licenses and notices; components with separate licenses retain their terms. See THIRD_PARTY.md.
===== THIRD_PARTY.md =====
# Third-party notices
Project-owned public APP sources: [GPLv3 with the FM1 SDK linking exception](LICENSE.md). Component licenses also apply to firmware and web builds that include those components.
| Component | Source / license |
| --- | --- |
| 303 | [Open303](https://github.com/RobinSchmidt/Open303/tree/313bf0d9ade7c1dcb6b3a74f5ea1780a29d70074), MIT; C adaptation with FM1 drive and MIDI handling. |
| 808 / Pluck | [DaisySP](https://github.com/daisyaudio/DaisySP/tree/2c72eaf9eac5fc0dca1919d65d606da907832618), MIT; selected Plaits drum and String models with FM1 voices and controls. |
| SVF | [stmlib](https://github.com/pichenettes/stmlib/tree/d18def816c51d1da0c108236928b2bbd25c17481), MIT; fixed-rate filter adaptation. |
| FM model | [MSFA](https://github.com/google/music-synthesizer-for-android/tree/f67d41d313b7dc85f6fb99e79e515cc9d208cfff) / [Dexed msfa](https://github.com/asb2m10/dexed/tree/eebb748b70c5a1338afa3945e8b1ea783c9c02fe/source/msfa), Apache-2.0; C adaptation of algorithms, envelopes, LFO and note scaling, with FM1 arithmetic and controls. |
| PSG | [emu2149](https://github.com/digital-sound-antiques/emu2149/tree/441f3dc295a9b82db16921461f0678b483db8304), MIT; memory/table adaptation and ultrasonic output fix. |
| SEA codec | [SEA](https://github.com/Daninet/sea-codec), MIT; fixed-format encoder, decoder and tables. |
| Packager | [jl-misctools](https://github.com/kagaimiq/jl-misctools/tree/0a5b12db0ef38f3042acffbe2452730a37fd2405), MIT; format/codec adaptation with FM1 validation and layout. |
| Native C runtime | `sdk/lib/libc.a`, Newlib-derived routines; native runtime notices below. |
| Native compiler runtime | `sdk/lib/libcompiler_rt.a`; identified compiler-rt routines, legacy MIT / University of Illinois-NCSA notices below. |
| micro-ecc | Identified routines in `sdk/lib/libfm1_engine.a`; BSD-2-Clause notice below. |
| JieLi SDK material | Identified AC79 SDK material retains its upstream terms; see SDK notices below. |
| APP / open web engine tuning | Incorporates contributions by [Vikram Rojo (PR #2)](https://github.com/m-vave/fm1_open/pull/2), with FM1 integration changes (2026-10-17). Original file licenses and notices are retained. |
| Configuration resource | `sdk/tools/pack/cfg_tool.bin`, identical to the file in the identified official JieLi Apache-2.0 SDK distribution; see below. |
| Boot/update resources and recovery firmware | `sdk/tools/pack/uboot.boot`, `ota.bin`, `boot-config.bin`, and `sdk/firmware/FM-1_015.fwsc`, Apache-2.0; see the resource terms below. |
| Original 128-voice DX7 bank | `app/fm_factory.inc`: extracted without parameter or ordering changes from the bundled M-VAVE V15 recovery image (Apache-2.0), losslessly encoded for Flash in 2026. Reproduce with `node tools/Generate-Factory-DX7.mjs`; the tool pins the source package and decoded VMEM SHA-256 hashes. Demo project recipes remain separate. |
Company-authored FM1 modifications, FX, arrangements and synthesized demo samples: Copyright (c) 2026 珠海笙科智能科技有限公司 (M-VAVE). Product names identify compatible formats; no upstream endorsement is implied.
## Binary SDK
### M-VAVE engine permission
For the proprietary engine components in `sdk/lib/libfm1_engine.a` that 珠海笙科智能科技有限公司 (M-VAVE) owns or has authority to license, M-VAVE grants each recipient a non-exclusive, royalty-free permission to:
1. Download, retain and copy those components for developing and using firmware on M-VAVE FM1 devices.
2. Link those components with the APP or a modified APP, and build, install and run the resulting firmware on M-VAVE FM1 devices.
3. Redistribute those components in binary form, separately as SDK components or as part of firmware and firmware-inclusive workbenches for M-VAVE FM1 devices, for commercial or non-commercial purposes.
Redistributions must retain applicable copyright and license notices and include this file. No proprietary SDK source is supplied. The FM1-only condition applies to the proprietary engine grant; the APP, third-party components and separately licensed resources retain their respective rights and terms. Complete packages must comply with each component's license, including applicable corresponding-source requirements.
### Boot/update resources and recovery firmware
The boot/update files in `sdk/tools/pack/` (`uboot.boot`, `ota.bin`, `cfg_tool.bin`, `boot-config.bin`) and the recovery image `sdk/firmware/FM-1_015.fwsc` are distributed by M-VAVE under the Apache License, Version 2.0. That license permits use, modification and redistribution, including binary redistribution for commercial or non-commercial purposes, subject to its terms. Include the Apache-2.0 license, mark modified files as required, and retain applicable copyright, attribution and NOTICE material under section 4. The full license is reproduced under “FM model / Apache-2.0” below. Components with their own license notices retain those terms. These resource permissions do not change the APP's GPLv3 license or the proprietary engine's separate terms.
The APP license does not apply to proprietary SDK components. M-VAVE supplies its proprietary components as-is, without warranty. To the extent permitted by applicable law, M-VAVE is not liable for losses arising from their use, including data loss or device malfunction. Mandatory statutory rights and separately agreed warranties are unaffected.
### 中文授权说明
对于 `sdk/lib/libfm1_engine.a` 中珠海笙科智能科技有限公司（M-VAVE）拥有权利或有权许可的专有引擎组件，M-VAVE 向每位接收者授予非独占、免许可费的以下权限：
1. 为开发和使用 M-VAVE FM1 设备固件而下载、保存和复制这些组件。
2. 将这些组件与 APP 或修改后的 APP 链接，编译、安装并在 M-VAVE FM1 设备上运行所得固件。
3. 以二进制形式再分发这些组件，包括作为单独的 SDK 组件、FM1 固件或内含该固件的工作台的一部分，允许商业及非商业用途。
再分发时须保留适用的版权与许可声明，并附带本文件；本授权不提供专有 SDK 源码。“仅限 FM1”只适用于上述专有引擎授权，APP、第三方组件及单独授权资源保留各自的权利与条款。分发完整包时须遵守各组件许可，包括适用的对应源码提供要求。
**引导及恢复资源：**上述 `uboot.boot`、`ota.bin`、`cfg_tool.bin`、`boot-config.bin` 及 `FM-1_015.fwsc` 由 M-VAVE 按 Apache License 2.0 分发，可依其条款使用、修改及再分发，包括商业和非商业用途的二进制再分发。分发时须附 Apache-2.0 许可，按要求标明文件修改，并依第 4 条保留适用的版权、署名和 NOTICE 内容；许可全文见下方“FM model / Apache-2.0”。具有单独许可声明的组件保留各自条款。本组资源的许可不改变 APP 的 GPLv3 许可及专有引擎的单独条款。
APP 许可不适用于专有 SDK 组件；专有组件按现状提供，不提供担保。在适用法律允许范围内，M-VAVE 不对使用这些组件导致的损失承担责任，包括数据丢失或设备异常；不可排除的法定权利及另行约定的担保不受影响。
## SDK notices
Reference: [JieLi AC79 AIoT SDK](https://gitee.com/Jieli-Tech/fw-AC79_AIoT_SDK/tree/5fa84a9b2f723a5e9337ad79dc2ad741fc98fe2d), commit `5fa84a9b2f723a5e9337ad79dc2ad741fc98fe2d`.
Upstream distribution notice: Copyright © 2024-2026 Zhuhai Jieli Technology Co., Ltd. All rights reserved.
Apache-2.0-covered SDK material retains that license. The full text appears below. Newlib, compiler-rt and other components retain their respective licenses and notices; the SDK's root license does not replace them. Redistribution must retain applicable license and NOTICE material and identify modifications as required.
### FreeRTOS
<details>
<summary>MIT license</summary>
```text
Copyright (C) 2017 Amazon.com, Inc. or its affiliates. All Rights Reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software. If you wish to use our Amazon
FreeRTOS name, please do so in a fair use way that does not cause confusion.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
```
</details>
### micro-ecc
Identified micro-ecc routines retain the BSD-2-Clause notice from [micro-ecc](https://github.com/kmackay/micro-ecc/blob/541b3a78026420a3e369c4c9281c396b5e531113/LICENSE.txt). This identifies the notice source, not the vendor archive's exact revision.
<details>
<summary>BSD-2-Clause license</summary>
```text
Copyright (c) 2014, Kenneth MacKay
All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
```
</details>
## MIT components
Copyright (c) 2009 Robin Schmidt (Open303).
Copyright (c) 2020 Electrosmith, Corp. (DaisySP).
Copyright (c) 2016 Emilie Gillet (Plaits).
Copyright (c) 2014 Emilie Gillet (stmlib).
Copyright (c) 2014 Mitsutaka Okazaki (emu2149; source copyright 2001-2022).
Copyright (c) 2025 Dani Biró (SEA).
Copyright (c) 2023 Andrey Grigoryev (kagaimiq) (jl-misctools).
FM1 modifications: Copyright (c) 2026 珠海笙科智能科技有限公司 (M-VAVE).
<details>
<summary>MIT license</summary>
```text
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
```
</details>
## FM model / Apache-2.0
Copyright 2012, 2013 Google Inc.
Copyright 2016-2025 Pascal Gauthier (Dexed msfa note-model changes).
Modified by M-VAVE, 2026: C port, fixed-point arithmetic, block processing, voice management and MIDI controls.
<details>
<summary>Apache License 2.0</summary>
```text
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
```
</details>
## Native compiler runtime
`sdk/lib/libcompiler_rt.a`: the identified compiler-rt routines retain the MIT / University of Illinois-NCSA notices below, reproduced from [LLVM compiler-rt release_40](https://github.com/llvm-mirror/compiler-rt/blob/release_40/LICENSE.TXT). This identifies the license-text source, not the archive's exact source revision. Other components retain their applicable terms. The WebAssembly runtime is listed separately below.
原生 `libcompiler_rt.a` 中已识别的 compiler-rt 代码保留下列 MIT / University of Illinois-NCSA 声明。链接仅标明许可文本来源，不确认归档的精确源码版本；其他组件保留各自条款。
<details>
<summary>Native compiler-rt legacy notices / 原生 compiler-rt 历史许可</summary>
Source: https://raw.githubusercontent.com/llvm-mirror/compiler-rt/release_40/LICENSE.TXT
```text
==============================================================================
compiler_rt License
==============================================================================
The compiler_rt library is dual licensed under both the University of Illinois
"BSD-Like" license and the MIT license. As a user of this code you may choose
to use it under either license. As a contributor, you agree to allow your code
to be used under both.
Full text of the relevant licenses is included below.
==============================================================================
University of Illinois/NCSA
Open Source License
Copyright (c) 2009-2016 by the contributors listed in CREDITS.TXT
All rights reserved.
Developed by:
LLVM Team
University of Illinois at Urbana-Champaign
http://llvm.org
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal with
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimers.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimers in the
documentation and/or other materials provided with the distribution.
* Neither the names of the LLVM Team, University of Illinois at
Urbana-Champaign, nor the names of its contributors may be used to
endorse or promote products derived from this Software without specific
prior written permission.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
SOFTWARE.
==============================================================================
Copyright (c) 2009-2015 by the contributors listed in CREDITS.TXT
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
==============================================================================
Copyrights and Licenses for Third Party Software Distributed with LLVM:
==============================================================================
The LLVM software contains code written by third parties. Such software will
have its own individual LICENSE.TXT file in the directory in which it appears.
This file will describe the copyrights, license, and restrictions which apply
to that code.
The disclaimer of warranty in the University of Illinois Open Source License
applies to all code in the LLVM Distribution, and nothing in any of the
other licenses gives permission to use the names of the LLVM Team or the
University of Illinois to endorse or promote products derived from this
Software.
```
</details>
## Native C runtime
`libc.a` contains Newlib-derived routines, including `dtoa`, `mprec`, `gethex` and `hexnan`. The original notices below are retained for the identified components; they do not certify the complete vendor archive's composition or exact upstream revision.
<details>
<summary>Newlib runtime notices / Newlib 运行库许可</summary>
Source: [Newlib 2.2.0.20150225](https://sourceware.org/pub/newlib/newlib-2.2.0.20150225.tar.gz), `COPYING.NEWLIB` and the named source files.
```text
The newlib subdirectory is a collection of software from several sources.
Each file may have its own copyright/license that is embedded in the source
file. Unless otherwise noted in the body of the source file(s), the following copyright
notices will apply to the contents of the newlib subdirectory:
(1) Red Hat Incorporated
Copyright (c) 1994-2009 Red Hat, Inc. All rights reserved.
This copyrighted material is made available to anyone wishing to use,
modify, copy, or redistribute it subject to the terms and conditions
of the BSD License. This program is distributed in the hope that
it will be useful, but WITHOUT ANY WARRANTY expressed or implied,
including the implied warranties of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. A copy of this license is available at
http://www.opensource.org/licenses. Any Red Hat trademarks that are
incorporated in the source code or documentation are not subject to
the BSD License and may only be used or replicated with the express
permission of Red Hat, Inc.
(2) University of California, Berkeley
Copyright (c) 1981-2000 The Regents of the University of California.
All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
(3) David M. Gay (AT&T 1991, Lucent 1998)
The author of this software is David M. Gay.
Copyright (c) 1991 by AT&T.
Permission to use, copy, modify, and distribute this software for any
purpose without fee is hereby granted, provided that this entire notice
is included in all copies of any software which is or includes a copy
or modification of this software and in all copies of the supporting
documentation for such software.
THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
WARRANTY. IN PARTICULAR, NEITHER THE AUTHOR NOR AT&T MAKES ANY
REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY
OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
-------------------------------------------------------------------
The author of this software is David M. Gay.
Copyright (C) 1998-2001 by Lucent Technologies
All Rights Reserved
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both that the copyright notice and this
permission notice and warranty disclaimer appear in supporting
documentation, and that the name of Lucent or any of its entities
not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.
LUCENT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS.
IN NO EVENT SHALL LUCENT OR ANY OF ITS ENTITIES BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER
IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
THIS SOFTWARE.
libc/argz/argz_add.c, libc/argz/argz_add_sep.c, libc/argz/argz_append.c, libc/argz/argz_count.c, libc/argz/argz_create.c, libc/argz/argz_create_sep.c, libc/argz/argz_delete.c, libc/argz/argz_extract.c, libc/argz/argz_next.c, libc/argz/argz_replace.c, libc/argz/argz_stringify.c, libc/argz/buf_findstr.c
/* Copyright (C) 2002 by Red Hat, Incorporated. All rights reserved.
*
* Permission to use, copy, modify, and distribute this software
* is freely granted, provided that this notice is preserved.
*/
libc/argz/argz_insert.c
/* Copyright (C) 2002, 2005 by Red Hat, Incorporated. All rights reserved.
*
* Permission to use, copy, modify, and distribute this software
* is freely granted, provided that this notice is preserved.
*/
libc/stdlib/atoll.c
/*
* Copyright (c) 1988, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/ctype/ctype_.c
/*
* Copyright (c) 1989 The Regents of the University of California.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/stdlib/div.c, libc/stdlib/ldiv.c
/*
* Copyright (c) 1990 Regents of the University of California.
* All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Chris Torek.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/stdlib/drand48.c, libc/stdlib/erand48.c, libc/stdlib/jrand48.c, libc/stdlib/lcong48.c, libc/stdlib/lrand48.c, libc/stdlib/mrand48.c, libc/stdlib/nrand48.c, libc/stdlib/rand48.c, libc/stdlib/seed48.c, libc/stdlib/srand48.c
/*
* Copyright (c) 1993 Martin Birgmeier
* All rights reserved.
*
* You may redistribute unmodified or modified versions of this source
* code provided that the above copyright notice and this and the
* following conditions are retained.
*
* This software is provided ``as is'', and comes with no warranties
* of any kind. I shall in no event be liable for anything that happens
* to anyone/anything when using this software.
*/
libc/stdlib/dtoa.c, libc/stdlib/mprec.c
/****************************************************************
*
* The author of this software is David M. Gay.
*
* Copyright (c) 1991 by AT&T.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose without fee is hereby granted, provided that this entire notice
* is included in all copies of any software which is or includes a copy
* or modification of this software and in all copies of the supporting
* documentation for such software.
*
* THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
* WARRANTY. IN PARTICULAR, NEITHER THE AUTHOR NOR AT&T MAKES ANY
* REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY
* OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
*
***************************************************************/
libc/locale/fix_grouping.c
/*
* Copyright (c) 2001 Alexey Zelkin <phantom@FreeBSD.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/stdio/flags.c
/*
* Copyright (c) 1990 Regents of the University of California.
* All rights reserved.
*
* Redistribution and use in source and binary forms are permitted
* provided that the above copyright notice and this paragraph are
* duplicated in all such forms and that any documentation,
* advertising materials, and other materials related to such
* distribution and use acknowledge that the software was developed
* by the University of California, Berkeley. The name of the
* University may not be used to endorse or promote products derived
* from this software without specific prior written permission.
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
libc/stdlib/gdtoa-gethex.c
/****************************************************************
The author of this software is David M. Gay.
Copyright (C) 1998 by Lucent Technologies
All Rights Reserved
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both that the copyright notice and this
permission notice and warranty disclaimer appear in supporting
documentation, and that the name of Lucent or any of its entities
not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.
LUCENT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS.
IN NO EVENT SHALL LUCENT OR ANY OF ITS ENTITIES BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER
IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
THIS SOFTWARE.
****************************************************************/
libc/stdlib/gdtoa-hexnan.c
/****************************************************************
The author of this software is David M. Gay.
Copyright (C) 2000 by Lucent Technologies
All Rights Reserved
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both that the copyright notice and this
permission notice and warranty disclaimer appear in supporting
documentation, and that the name of Lucent or any of its entities
not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.
LUCENT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS.
IN NO EVENT SHALL LUCENT OR ANY OF ITS ENTITIES BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER
IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
THIS SOFTWARE.
****************************************************************/
libc/ctype/iswalpha.c, libc/ctype/iswblank.c, libc/ctype/iswcntrl.c, libc/ctype/iswgraph.c, libc/ctype/iswprint.c, libc/ctype/iswpunct.c, libc/ctype/iswspace.c, libc/ctype/towctrans.c, libc/ctype/towlower.c, libc/ctype/towupper.c, libc/ctype/wctrans.c, libc/ctype/wctype.c
/* Copyright (c) 2002 Red Hat Incorporated.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
The name of Red Hat Incorporated may not be used to endorse
or promote products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL RED HAT INCORPORATED BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
libc/stdlib/ldtoa.c
/* Extended precision arithmetic functions for long double I/O.
* This program has been placed in the public domain.
*/
libc/stdlib/ldtoa.c
/*
* Revision history:
*
* 5 Jan 84 PDP-11 assembly language version
* 6 Dec 86 C language version
* 30 Aug 88 100 digit version, improved rounding
* 15 May 92 80-bit long double support
* 22 Nov 00 Revised to fit into newlib by Jeff Johnston <jjohnstn@redhat.com>
*
* Author: S. L. Moshier.
*
* Copyright (c) 1984,2000 S.L. Moshier
*
* Permission to use, copy, modify, and distribute this software for any
* purpose without fee is hereby granted, provided that this entire notice
* is included in all copies of any software which is or includes a copy
* or modification of this software and in all copies of the supporting
* documentation for such software.
*
* THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
* WARRANTY. IN PARTICULAR, THE AUTHOR MAKES NO REPRESENTATION
* OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY OF THIS
* SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
*
*/
libc/stdlib/llabs.c, libc/stdlib/lldiv.c
/*-
* Copyright (c) 2001 Mike Barcroft <mike@FreeBSD.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/locale/locale.c
/*
* Copyright (c) 1996 - 2002 FreeBSD Project
* Copyright (c) 1991, 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Paul Borman at Krystal Technologies.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/string/memmem.c
/* Byte-wise substring search, using the Two-Way algorithm.
* Copyright (C) 2008 Eric Blake
* Permission to use, copy, modify, and distribute this software
* is freely granted, provided that this notice is preserved.
*/
libc/search/qsort.c
/*-
* Copyright (c) 1992, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/stdio/sccl.c
/*-
* Copyright (c) 1990 The Regents of the University of California.
* All rights reserved.
*
* Redistribution and use in source and binary forms are permitted
* provided that the above copyright notice and this paragraph are
* duplicated in all such forms and that any documentation,
* advertising materials, and other materials related to such
* distribution and use acknowledge that the software was developed
* by the University of California, Berkeley. The name of the
* University may not be used to endorse or promote products derived
* from this software without specific prior written permission.
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
libm/common/s_copysign.c, libm/common/s_finite.c, libm/common/s_isnan.c, libm/common/s_isnand.c, libm/common/s_modf.c, libm/common/s_scalbn.c, libm/common/sf_copysign.c, libm/common/sf_finite.c, libm/common/sf_isnan.c, libm/common/sf_isnanf.c, libm/common/sf_modf.c, libm/common/sf_scalbn.c, libm/math/s_frexp.c, libm/math/s_ldexp.c, libm/math/sf_frexp.c, libm/math/sf_ldexp.c
/*
* ====================================================
* Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
*
* Developed at SunPro, a Sun Microsystems, Inc. business.
* Permission to use, copy, modify, and distribute this
* software is freely granted, provided that this notice
* is preserved.
* ====================================================
*/
libm/common/sf_fpclassify.c
/* Copyright (C) 2002,2007 by Red Hat, Incorporated. All rights reserved.
*
* Permission to use, copy, modify, and distribute this software
* is freely granted, provided that this notice is preserved.
*/
libm/common/s_fpclassify.c
/* Copyright (C) 2002, 2007 by Red Hat, Incorporated. All rights reserved.
*
* Permission to use, copy, modify, and distribute this software
* is freely granted, provided that this notice is preserved.
*/
libc/string/strcasestr.c
/*-
* Copyright (c) 1990, 1993
* The Regents of the University of California. All rights reserved.
*
* The quadratic code is derived from software contributed to Berkeley by
* Chris Torek.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/string/strcasestr.c
/* Linear algorithm Copyright (C) 2008 Eric Blake
* Permission to use, copy, modify, and distribute the linear portion of
* software is freely granted, provided that this notice is preserved.
*/
libc/string/strlcat.c, libc/string/strlcpy.c, libc/string/wcslcat.c, libc/string/wcslcpy.c
/*
* Copyright (c) 1998 Todd C. Miller <Todd.Miller@courtesan.com>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
libc/stdlib/strtod.c
/****************************************************************
The author of this software is David M. Gay.
Copyright (C) 1998-2001 by Lucent Technologies
All Rights Reserved
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both that the copyright notice and this
permission notice and warranty disclaimer appear in supporting
documentation, and that the name of Lucent or any of its entities
not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.
LUCENT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS.
IN NO EVENT SHALL LUCENT OR ANY OF ITS ENTITIES BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER
IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
THIS SOFTWARE.
****************************************************************/
libc/string/strtok_r.c, libc/string/wcstok.c
/*
* Copyright (c) 1988 Regents of the University of California.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/stdlib/strtold.c, libc/stdlib/wcstold.c
/*
(C) Copyright IBM Corp. 2009
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of IBM nor the names of its contributors may be
used to endorse or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
*/
libc/stdlib/strtol.c, libc/stdlib/strtoll.c, libc/stdlib/strtoll_r.c, libc/stdlib/wcstol.c, libc/stdlib/wcstoll.c, libc/stdlib/wcstoll_r.c
/*-
* Copyright (c) 1990 The Regents of the University of California.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/stdlib/strtoll_r.c
/*
This code is based on strtoul.c which has the following copyright.
It is used to convert a string into a signed long long.
long long _strtoll_r (struct _reent *rptr, const char *s,
char **ptr, int base);
*/
libc/stdlib/strtoul.c, libc/stdlib/strtoull.c, libc/stdlib/strtoull_r.c, libc/stdlib/wcstoul.c, libc/stdlib/wcstoull.c, libc/stdlib/wcstoull_r.c
/*
* Copyright (c) 1990 Regents of the University of California.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/stdlib/strtoull_r.c
/*
This code is based on strtoul.c which has the following copyright.
It is used to convert a string into an unsigned long long.
long long _strtoull_r (struct _reent *rptr, const char *s,
char **ptr, int base);
*/
libc/search/tdelete.c, libc/search/tdestroy.c, libc/search/tfind.c, libc/search/tsearch.c, libc/search/twalk.c
/*
* Tree search generalized from Knuth (6.2.2) Algorithm T just like
* the AT&T man page says.
*
* The node_t structure is for internal use only, lint doesn't grok it.
*
* Written by reading the System V Interface Definition, not the code.
*
* Totally public domain.
*/
libc/misc/unctrl.c
/*
* Copyright (c) 1981, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/string/wcscat.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcscat.c,v 1.1 1999/12/29 21:47:45 tshiozak Exp
*/
libc/string/wcschr.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcschr.c,v 1.2 2000/12/21 05:07:25 itojun Exp
*/
libc/string/wcscmp.c
/*-
* Copyright (c) 1990, 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Chris Torek.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/string/wcscpy.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcscpy.c,v 1.2 2000/12/21 04:51:09 itojun Exp
*/
libc/string/wcscspn.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcscspn.c,v 1.1 1999/12/29 21:47:45 tshiozak Exp
*/
libc/string/wcslen.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcslen.c,v 1.1 1999/12/29 21:47:45 tshiozak Exp
*/
libc/string/wcsncat.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcsncat.c,v 1.1 1999/12/29 21:47:45 tshiozak Exp
*/
libc/string/wcsncmp.c
/*
* Copyright (c) 1989, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/string/wcsnlen.c
/*
* Copyright (c) 2003, Artem B. Bityuckiy (dedekind@mail.ru).
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the above copyright notice,
* this condition statement, and the following disclaimer are retained
* in any redistributions of the source code.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/string/wcspbrk.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcspbrk.c,v 1.2 2000/12/21 05:07:25 itojun Exp
*/
libc/string/wcsrchr.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcsrchr.c,v 1.2 2000/12/21 05:07:25 itojun Exp
*/
libc/string/wcsspn.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcsspn.c,v 1.1 1999/12/29 21:47:45 tshiozak Exp
*/
libc/string/wcsstr.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wcsstr.c,v 1.2 2000/12/21 05:07:25 itojun Exp
*/
libc/stdlib/wcstod.c
/*-
* Copyright (c) 2002 Tim J. Robbins
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libc/stdlib/wcstoll_r.c
/*
This code is based on strtoul.c which has the following copyright.
It is used to convert a wide string into a signed long long.
long long _wcstoll_r (struct _reent *rptr, const wchar_t *s,
wchar_t **ptr, int base);
*/
libc/stdlib/wcstoull_r.c
/*
This code is based on wcstoul.c which has the following copyright.
It is used to convert a wide string into an unsigned long long.
unsigned long long _wcstoull_r (struct _reent *rptr, const wchar_t *s,
wchar_t **ptr, int base);
*/
libc/string/wcwidth.c
/*
* This is an implementation of wcwidth() (defined in
* IEEE Std 1002.1-2001) for Unicode.
*
* http://www.opengroup.org/onlinepubs/007904975/functions/wcwidth.html
*
* In fixed-width output devices, Latin characters all occupy a single
* "cell" position of equal width, whereas ideographic CJK characters
* occupy two such cells. Interoperability between terminal-line
* applications and (teletype-style) character terminals using the
* UTF-8 encoding requires agreement on which character should advance
* the cursor by how many cell positions. No established formal
* standards exist at present on which Unicode character shall occupy
* how many cell positions on character terminals. These routines are
* a first attempt of defining such behavior based on simple rules
* applied to data provided by the Unicode Consortium.
*
* For some graphical characters, the Unicode standard explicitly
* defines a character-cell width via the definition of the East Asian
* FullWidth (F), Wide (W), Half-width (H), and Narrow (Na) classes.
* In all these cases, there is no ambiguity about which width a
* terminal shall use. For characters in the East Asian Ambiguous (A)
* class, the width choice depends purely on a preference of backward
* compatibility with either historic CJK or Western practice.
* Choosing single-width for these characters is easy to justify as
* the appropriate long-term solution, as the CJK practice of
* displaying these characters as double-width comes from historic
* implementation simplicity (8-bit encoded characters were displayed
* single-width and 16-bit ones double-width, even for Greek,
* Cyrillic, etc.) and not any typographic considerations.
*
* Much less clear is the choice of width for the Not East Asian
* (Neutral) class. Existing practice does not dictate a width for any
* of these characters. It would nevertheless make sense
* typographically to allocate two character cells to characters such
* as for instance EM SPACE or VOLUME INTEGRAL, which cannot be
* represented adequately with a single-width glyph. The following
* routines at present merely assign a single-cell width to all
* neutral characters, in the interest of simplicity. This is not
* entirely satisfactory and should be reconsidered before
* establishing a formal standard in this area. At the moment, the
* decision which Not East Asian (Neutral) characters should be
* represented by double-width glyphs cannot yet be answered by
* applying a simple rule from the Unicode database content. Setting
* up a proper standard for the behavior of UTF-8 character terminals
* will require a careful analysis not only of each Unicode character,
* but also of each presentation form, something the author of these
* routines has avoided to do so far.
*
* http://www.unicode.org/unicode/reports/tr11/
*
* Markus Kuhn -- 2007-05-26 (Unicode 5.0)
*
* Permission to use, copy, modify, and distribute this software
* for any purpose and without fee is hereby granted. The author
* disclaims all warranties with regard to this software.
*
* Latest version: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
*/
libc/string/wmemchr.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wmemchr.c,v 1.2 2000/12/20 14:08:31 itojun Exp
*/
libc/string/wmemcmp.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wmemcmp.c,v 1.2 2000/12/20 14:08:31 itojun Exp
*/
libc/string/wmemcpy.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wmemcpy.c,v 1.2 2000/12/20 14:08:31 itojun Exp
*/
libc/string/wmemmove.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wmemmove.c,v 1.2 2000/12/20 14:08:31 itojun Exp
*/
libc/string/wmemset.c
/*-
* Copyright (c)1999 Citrus Project,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* citrus Id: wmemset.c,v 1.2 2000/12/20 14:08:31 itojun Exp
*/
```
</details>
## Platform C headers
<details>
<summary>Original notices / 原始许可文本</summary>
```text
Platform C header notices
These comment blocks are reproduced verbatim from the headers named below.
Their conditions and disclaimers remain applicable. This collection does not
establish the source or licensing of the separate binary runtime archives;
see the component table above. Other original file comments remain in the headers.
sdk/include/libc/inttypes.h
===========================
/*
* Copyright (c) 2004, 2005 by
* Ralf Corsepius, Ulm/Germany. All rights reserved.
*
* Permission to use, copy, modify, and distribute this software
* is freely granted, provided that this notice is preserved.
*/
sdk/include/libc/stdint.h
=========================
/*
* Copyright (c) 2004, 2005 by
* Ralf Corsepius, Ulm/Germany. All rights reserved.
*
* Permission to use, copy, modify, and distribute this software
* is freely granted, provided that this notice is preserved.
*/
sdk/include/libc/stdio.h
========================
/*
* Copyright (c) 1990 The Regents of the University of California.
* All rights reserved.
*
* Redistribution and use in source and binary forms are permitted
* provided that the above copyright notice and this paragraph are
* duplicated in all such forms and that any documentation,
* advertising materials, and other materials related to such
* distribution and use acknowledge that the software was developed
* by the University of California, Berkeley. The name of the
* University may not be used to endorse or promote products derived
* from this software without specific prior written permission.
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*
* @(#)stdio.h 5.3 (Berkeley) 3/15/86
*/
sdk/include/libc/sys/_intsup.h
==============================
/*
* Copyright (c) 2004, 2005 by
* Ralf Corsepius, Ulm/Germany. All rights reserved.
*
* Permission to use, copy, modify, and distribute this software
* is freely granted, provided that this notice is preserved.
*/
sdk/include/libc/sys/_stdint.h
==============================
/*
* Copyright (c) 2004, 2005 by
* Ralf Corsepius, Ulm/Germany. All rights reserved.
*
* Permission to use, copy, modify, and distribute this software
* is freely granted, provided that this notice is preserved.
*/
sdk/include/libc/sys/_timespec.h
================================
/*-
* Copyright (c) 1982, 1986, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)time.h 8.5 (Berkeley) 5/4/95
* from: FreeBSD: src/sys/sys/time.h,v 1.43 2000/03/20 14:09:05 phk Exp
* $FreeBSD$
*/
sdk/include/libc/sys/_timeval.h
===============================
/*-
* Copyright (c) 2002 Mike Barcroft <mike@FreeBSD.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
sdk/include/libc/sys/cdefs.h
============================
/*-
* Copyright (c) 1991, 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Berkeley Software Design, Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)cdefs.h 8.8 (Berkeley) 1/9/95
* $FreeBSD$
*/
sdk/include/libc/sys/features.h
===============================
/*
* Written by Joel Sherrill <joel@OARcorp.com>.
*
* COPYRIGHT (c) 1989-2014.
*
* On-Line Applications Research Corporation (OAR).
*
* Permission to use, copy, modify, and distribute this software for any
* purpose without fee is hereby granted, provided that this entire notice
* is included in all copies of any software which is or includes a copy
* or modification of this software.
*
* THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
* WARRANTY. IN PARTICULAR, THE AUTHOR MAKES NO REPRESENTATION
* OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY OF THIS
* SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
*
* $Id$
*/
sdk/include/libc/sys/reent.h
============================
/*
* rand48 family support
*
* Copyright (c) 1993 Martin Birgmeier
* All rights reserved.
*
* You may redistribute unmodified or modified versions of this source
* code provided that the above copyright notice and this and the
* following conditions are retained.
*
* This software is provided ``as is'', and comes with no warranties
* of any kind. I shall in no event be liable for anything that happens
* to anyone/anything when using this software.
*/
sdk/include/libc/sys/time.h
===========================
/*-
* Copyright (c) 1982, 1986, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)time.h 8.5 (Berkeley) 5/4/95
* $FreeBSD$
*/
sdk/include/libc/sys/timespec.h
===============================
/*-
* Copyright (c) 1982, 1986, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)time.h 8.5 (Berkeley) 5/4/95
* from: FreeBSD: src/sys/sys/time.h,v 1.43 2000/03/20 14:09:05 phk Exp
* $FreeBSD$
*/
```
</details>
## WebAssembly runtime
<details>
<summary>Original notices / 原始许可文本</summary>
```text
WASI SDK 27: wasi-libc 3f7eb4c7d6ed; LLVM/compiler-rt 87f0227cb601.
Unmodified runtime notices for the browser WebAssembly build.
Source: https://raw.githubusercontent.com/WebAssembly/wasi-libc/3f7eb4c7d6ed/LICENSE
wasi-libc as a whole is multi-licensed under the
Apache License v2.0 with LLVM Exceptions, the Apache License v2.0, and
the MIT License. See the LICENSE-APACHE-LLVM, LICENSE-APACHE and LICENSE-MIT
files, respectively, for details.
Portions of this software are derived from third-party works covered by
their own licenses:
dlmalloc/ - CC0; see the notice in malloc.c for details
emmalloc/ - MIT; see the notice in emmalloc.c for details
libc-bottom-half/cloudlibc/ - BSD-2-Clause; see the LICENSE file for details
libc-top-half/musl/ - MIT; see the COPYRIGHT file for details
fts/musl-fts/ - BSD-3-Clause; see the COPYING file for details
wasi-libc's changes to these files are multi-licensed under the
Apache License v2.0 with LLVM Exceptions, the Apache License v2.0,
the MIT License, and the original licenses of the third-party works.
Source: https://raw.githubusercontent.com/WebAssembly/wasi-libc/3f7eb4c7d6ed/LICENSE-MIT
Permission is hereby granted, free of charge, to any
person obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the
Software without restriction, including without
limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software
is furnished to do so, subject to the following
conditions:
The above copyright notice and this permission notice
shall be included in all copies or substantial portions
of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF
ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
Source: https://raw.githubusercontent.com/WebAssembly/wasi-libc/3f7eb4c7d6ed/libc-top-half/musl/COPYRIGHT
musl as a whole is licensed under the following standard MIT license:
----------------------------------------------------------------------
Copyright © 2005-2020 Rich Felker, et al.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
----------------------------------------------------------------------
Authors/contributors include:
A. Wilcox
Ada Worcester
Alex Dowad
Alex Suykov
Alexander Monakov
Andre McCurdy
Andrew Kelley
Anthony G. Basile
Aric Belsito
Arvid Picciani
Bartosz Brachaczek
Benjamin Peterson
Bobby Bingham
Boris Brezillon
Brent Cook
Chris Spiegel
Clément Vasseur
Daniel Micay
Daniel Sabogal
Daurnimator
David Carlier
David Edelsohn
Denys Vlasenko
Dmitry Ivanov
Dmitry V. Levin
Drew DeVault
Emil Renner Berthing
Fangrui Song
Felix Fietkau
Felix Janda
Gianluca Anzolin
Hauke Mehrtens
He X
Hiltjo Posthuma
Isaac Dunham
Jaydeep Patil
Jens Gustedt
Jeremy Huntwork
Jo-Philipp Wich
Joakim Sindholt
John Spencer
Julien Ramseier
Justin Cormack
Kaarle Ritvanen
Khem Raj
Kylie McClain
Leah Neukirchen
Luca Barbato
Luka Perkov
M Farkas-Dyck (Strake)
Mahesh Bodapati
Markus Wichmann
Masanori Ogino
Michael Clark
Michael Forney
Mikhail Kremnyov
Natanael Copa
Nicholas J. Kain
orc
Pascal Cuoq
Patrick Oppenlander
Petr Hosek
Petr Skocik
Pierre Carrier
Reini Urban
Rich Felker
Richard Pennington
Ryan Fairfax
Samuel Holland
Segev Finer
Shiz
sin
Solar Designer
Stefan Kristiansson
Stefan O'Rear
Szabolcs Nagy
Timo Teräs
Trutz Behn
Valentin Ochs
Will Dietz
William Haddon
William Pitcock
Portions of this software are derived from third-party works licensed
under terms compatible with the above MIT license:
The TRE regular expression implementation (src/regex/reg* and
src/regex/tre*) is Copyright © 2001-2008 Ville Laurikari and licensed
under a 2-clause BSD license (license text in the source files). The
included version has been heavily modified by Rich Felker in 2012, in
the interests of size, simplicity, and namespace cleanliness.
Much of the math library code (src/math/* and src/complex/*) is
Copyright © 1993,2004 Sun Microsystems or
Copyright © 2003-2011 David Schultz or
Copyright © 2003-2009 Steven G. Kargl or
Copyright © 2003-2009 Bruce D. Evans or
Copyright © 2008 Stephen L. Moshier or
Copyright © 2017-2018 Arm Limited
and labelled as such in comments in the individual source files. All
have been licensed under extremely permissive terms.
The ARM memcpy code (src/string/arm/memcpy.S) is Copyright © 2008
The Android Open Source Project and is licensed under a two-clause BSD
license. It was taken from Bionic libc, used on Android.
The AArch64 memcpy and memset code (src/string/aarch64/*) are
Copyright © 1999-2019, Arm Limited.
The implementation of DES for crypt (src/crypt/crypt_des.c) is
Copyright © 1994 David Burren. It is licensed under a BSD license.
The implementation of blowfish crypt (src/crypt/crypt_blowfish.c) was
originally written by Solar Designer and placed into the public
domain. The code also comes with a fallback permissive license for use
in jurisdictions that may not recognize the public domain.
The smoothsort implementation (src/stdlib/qsort.c) is Copyright © 2011
Valentin Ochs and is licensed under an MIT-style license.
The x86_64 port was written by Nicholas J. Kain and is licensed under
the standard MIT terms.
The mips and microblaze ports were originally written by Richard
Pennington for use in the ellcc project. The original code was adapted
by Rich Felker for build system and code conventions during upstream
integration. It is licensed under the standard MIT terms.
The mips64 port was contributed by Imagination Technologies and is
licensed under the standard MIT terms.
The powerpc port was also originally written by Richard Pennington,
and later supplemented and integrated by John Spencer. It is licensed
under the standard MIT terms.
All other files which have no copyright comments are original works
produced specifically for use as part of this library, written either
by Rich Felker, the main author of the library, or by one or more
contibutors listed above. Details on authorship of individual files
can be found in the git version control history of the project. The
omission of copyright and license comments in each file is in the
interest of source tree size.
In addition, permission is hereby granted for all public header files
(include/* and arch/*/bits/*) and crt files intended to be linked into
applications (crt/*, ldso/dlstart.c, and arch/*/crt_arch.h) to omit
the copyright notice and permission notice otherwise required by the
license, and to use these files without any requirement of
attribution. These files include substantial contributions from:
Bobby Bingham
John Spencer
Nicholas J. Kain
Rich Felker
Richard Pennington
Stefan Kristiansson
Szabolcs Nagy
all of whom have explicitly granted such permission.
This file previously contained text expressing a belief that most of
the files covered by the above exception were sufficiently trivial not
to be subject to copyright, resulting in confusion over whether it
negated the permissions granted in the license. In the spirit of
permissive licensing, and of not having licensing issues being an
obstacle to adoption, that text has been removed.
Source: https://raw.githubusercontent.com/WebAssembly/wasi-libc/3f7eb4c7d6ed/libc-bottom-half/cloudlibc/LICENSE
Copyright (c) 2015-2017 Nuxi (https://nuxi.nl/) and contributors.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
Source: https://raw.githubusercontent.com/llvm/llvm-project/87f0227cb601/compiler-rt/LICENSE.TXT
==============================================================================
The LLVM Project is under the Apache License v2.0 with LLVM Exceptions:
==============================================================================
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
---- LLVM Exceptions to the Apache 2.0 License ----
As an exception, if, as a result of your compiling your source code, portions
of this Software are embedded into an Object form of such source code, you
may redistribute such embedded portions in such Object form without complying
with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
In addition, if you combine or link compiled forms of this Software with
software that is licensed under the GPLv2 ("Combined Software") and if a
court of competent jurisdiction determines that the patent provision (Section
3), the indemnity provision (Section 9) or other Section of the License
conflicts with the conditions of the GPLv2, you may retroactively and
prospectively choose to deem waived or otherwise exclude such Section(s) of
the License, but only in their entirety and only with respect to the Combined
Software.
==============================================================================
Software from third parties included in the LLVM Project:
==============================================================================
The LLVM Project contains third party software which is under different license
terms. All such code will be identified clearly using at least one of two
mechanisms:
1) It will be in a separate directory tree with its own `LICENSE.txt` or
`LICENSE` file at the top containing the specific license and restrictions
which apply to that software, or
2) It will contain specific license and restriction terms at the top of every
file.
==============================================================================
Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy):
==============================================================================
The compiler_rt library is dual licensed under both the University of Illinois
"BSD-Like" license and the MIT license. As a user of this code you may choose
to use it under either license. As a contributor, you agree to allow your code
to be used under both.
Full text of the relevant licenses is included below.
==============================================================================
University of Illinois/NCSA
Open Source License
Copyright (c) 2009-2019 by the contributors listed in CREDITS.TXT
All rights reserved.
Developed by:
LLVM Team
University of Illinois at Urbana-Champaign
http://llvm.org
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal with
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimers.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimers in the
documentation and/or other materials provided with the distribution.
* Neither the names of the LLVM Team, University of Illinois at
Urbana-Champaign, nor the names of its contributors may be used to
endorse or promote products derived from this Software without specific
prior written permission.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
SOFTWARE.
==============================================================================
Copyright (c) 2009-2015 by the contributors listed in CREDITS.TXT
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
Source: https://raw.githubusercontent.com/WebAssembly/wasi-libc/3f7eb4c7d6ed/dlmalloc/src/malloc.c
/*
This is a version (aka dlmalloc) of malloc/free/realloc written by
Doug Lea and released to the public domain, as explained at
http://creativecommons.org/publicdomain/zero/1.0/ Send questions,
comments, complaints, performance data, etc to dl@cs.oswego.edu
*/
```
</details>
===== LICENSE.md =====
# FM1 APP license
Copyright (c) 2026 珠海笙科智能科技有限公司 (M-VAVE).
Company-owned APP sources are licensed under GNU GPL version 3 only, with the linking permission below. Files carrying a different license retain it. SDK binaries are separately licensed under THIRD_PARTY.md; their proprietary source is not supplied.
This also covers the project-owned build launcher (`build.bat`) and workbench template (`sdk/Update.html.in`). The SEA-derived `web/synth/sample_metadata.inc` retains its MIT terms in THIRD_PARTY.md.
## Additional permission under GNU GPL version 3 section 7
If you modify this Program, or any covered work, by linking or combining it with the FM1 binary SDK (sdk/lib/libfm1_engine.a and the accompanying binary SDK components listed in sdk/manifest.json) (or a modified version of that library), containing parts covered by the terms of the FM1 Binary SDK terms in THIRD_PARTY.md and the applicable original component licenses, the licensors of this Program grant you additional permission to convey the resulting work.
This permission applies to code marked with this exception. The APP and its modifications remain subject to GPLv3; the SDK keeps its separate terms. This exception does not require disclosure of proprietary SDK source and does not grant rights in third-party code beyond its applicable license. Include this license and THIRD_PARTY.md with distributions, and provide the corresponding APP source and build/install scripts as required by GPLv3.
APP 自有源码采用 GPLv3，并附上述链接例外：允许与配套 FM1 二进制 SDK 链接后分发，无须因此公开专有 SDK 源码。APP 及其修改部分仍遵循 GPL，SDK 与第三方组件保留各自许可。分发时附带本文件、THIRD_PARTY.md，并按 GPL 要求提供对应 APP 源码及编译、安装脚本。
## Scope of separate component terms
The FM1 device restriction and separate redistribution conditions in THIRD_PARTY.md apply to the components identified there, not to the GPL-covered APP source or its modifications. They do not add restrictions to the rights granted for the APP under GPLv3. Permission to distribute separately licensed components must come from their applicable licenses or rights holders; the linking exception does not supply that permission.
THIRD_PARTY.md 中对指定组件的设备范围与再分发条件，不适用于 GPL 覆盖的 APP 源码及其修改，不额外限制 APP 的 GPL 权利。单独授权组件的分发权限须来自其适用许可或权利人，链接例外本身不授予该权限。
## Warranty
The APP is provided without warranty under GPLv3 sections 15–17 below. Back up projects and samples before flashing; firmware defects may cause data loss or device malfunction. Mandatory statutory rights and separately agreed warranties are unaffected. Proprietary SDK warranty terms are in THIRD_PARTY.md.
APP 按现状提供，不提供担保，责任限制以以下 GPLv3 第 15–17 条及适用法律为准。刷写前请备份工程和采样；固件缺陷可能造成数据丢失或设备异常。本声明不影响不可排除的法定权利及另行约定的担保。专有 SDK 的免责条款见 THIRD_PARTY.md。
## GNU General Public License version 3
~~~text
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The GNU General Public License is a free, copyleft license for
software and other kinds of works.
The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users. We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors. You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights. Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received. You must make sure that they, too, receive
or can get the source code. And you must show them these terms so they
know their rights.
Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.
For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software. For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.
Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the manufacturer
can do so. This is fundamentally incompatible with the aim of
protecting users' freedom to change the software. The systematic
pattern of such abuse occurs in the area of products for individuals to
use, which is precisely where it is most unacceptable. Therefore, we
have designed this version of the GPL to prohibit the practice for those
products. If such problems arise substantially in other domains, we
stand ready to extend this provision to those domains in future versions
of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened constantly by software patents.
States should not allow patents to restrict development and use of
software on general-purpose computers, but in those that do, we wish to
avoid the special danger that patents applied to a free program could
make it effectively proprietary. To prevent this, the GPL assures that
patents cannot be used to render the program non-free.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.
The Corresponding Source for a work in source code form is that
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that product
model, to give anyone who possesses the object code either (1) a
copy of the Corresponding Source for all the software in the
product that is covered by this License, on a durable physical
medium customarily used for software interchange, for a price no
more than your reasonable cost of physically performing this
conveying of source, or (2) access to copy the
Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in accord
with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
Corresponding Source along with the object code. If the place to
copy the object code is a network server, the Corresponding Source
may be on a different server (operated by you or a third party)
that supports equivalent copying facilities, provided you maintain
clear directions next to the object code saying where to find the
Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is
available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided
you inform other peers where the object code and Corresponding
Source of the work are being offered to the general public at no
charge under subsection 6d.
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed. Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law. If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or
e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions of
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version. For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement). To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.
If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.
A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of
the GNU General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the
GNU General Public License, you may choose any version ever published
by the Free Software Foundation.
If the Program specifies that a proxy can decide which future
versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.
Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:
<program> Copyright (C) <year> <name of author>
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".
You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<https://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program
into proprietary programs. If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License. But first, please read
<https://www.gnu.org/licenses/why-not-lgpl.html>.
~~~
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Hell Gate.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.
Christoffer Stjernlöf posted about the Fox Game , an old Norse asymmetric board game (seemingly also called “halatafl”) where twenty sheep try to outsmart two foxes and get to the other side. His AI uncovered some interesting insights, but left the question open as of whether the foxes or the sheep actually win with perfect play (the general sentiment in his family was that winning with the foxes was easy). This was too tempting for me to leave on the table, so I set out to make a strong solve.
Since I don't know this game myself, I've stayed with the rules he describes even when they differ from e.g. Wikipedia (in particular, I do not use forced fox jumps, or multi-jumps); the only real change is that I don't have a 40-move draw rule, any position that is a forced win for one of the sides would be a win no matter how long it would take. (I consider this just an implementation detail in his AI, although morally, I consider a draw a loss for the sheep.) You might want to read his post to get the full rules, because I'm not going to repeat them here.
The results first: The sheep win with perfect play, even with only 19 sheep (remove one on the flank), or 18 if they are allowed to go first. Even with only 9 sheep (the minimum possible that isn't an instant win for the foxes), the sheep can force a draw right from the start. With one fox, 11 sheep suffice for a forced win. (The draw margin is seemingly so large because one fox can just camp in the last spot in the pen, and it's hard to force it away without getting harassed by the other fox, unless you have lots of sheep.)
The rest is about the implementation. I'll skip over a lot of wrong turns, and unsurprisingly, there were a lot of bugs to iron out, but hopefully, it got to a good place in the end. :-) I started out trying to make something very simple, and it worked for the first few cases, but then things got more complicated than I would have liked in the end. Still only at ~1000 lines of code, though, with no dependencies.
The board has 33 squares. I tried a few different ways of represent the state of the game, and ended up on a simple bitboard representation: There's a 64-bit bitmap representing where there are sheep, and another bitmap representing where there are foxes. Since there's plenty of room in there, I use a spare bit to represent side-to-move. This is compact (which mattered a lot earlier on, but not as much later), easy to iterate over, and has little redundancy, so it's easy to keep valid. You need fast 64-bit population count and bit-scan instructions, but a) that's common now everywhere, and b) I decided fairly early that I wanted to require BMI2 anyway.
The bit order mostly doesn't matter; I just started at top-left and went from there. All it really influences is square iteration order. There's a small tweak in that I store the right half of the board mirrored (reverse x order) for symmetry purposes; more on that below.
I just typed in every possible move from every square into an array, then verified by generating some SVGs that I hadn't made any typos (I had). In retrospect, I should have done something more automated; it would have been less painful.
The moves for sheep are just “you can go to X, Y or Z”. The moves for foxes are “you can go to X or Y, or you can go to Z if there's a sheep at W (which will be eaten)”. The move generator mostly just looks up the source square and tests every move. For the sheep, I make an easy test using bitboards; for the foxes, I could probably do something similar, but the jump moves proved a bit tricky (even with PEXT/PDEP) and I didn't end up using it.
This is the part that really determines the geometry of the board (apart from debugging display). Everything else is pretty much geometry-agnostic.
There's a little over 2^41 possible board states (this includes some illegal positions as well as some situations that could never arise during actual gameplay, such as a fox being stuck at C1 with a row of sheep ahead of it), and I want to remember all of them. With that many positions, I figured I needed a fairly compact representation. I needed to store that a position could be sheep win, fox win or a draw, and then there was a fourth “invalid” state that was useful for internal reasons, so that maps exactly to two bits per position. (A tablebase intended for distribution could be compressed to less using the usual tricks of entropy coding, skipping half of the positions, or similar.)
This means we need to give a number to every possible position, ideally one with no collisions and no holes. I learned about combinatorial number systems which fit the bill exactly; given e.g. “we have 33 squares and 15 pieces”, it gives a dense mapping of positions from board to ID (ranking) and the opposite (unranking). (I made some fairly fast ranking and unranking algorithms, which may or may not have been novel, but it turned out I didn't actually need fast unranking after some other optimizations.) There are some extra complications in that there are two types of pieces, but you can solve them in a number of ways.
On a macro level, I store everything with 9 sheep and 1 fox first, then 9 sheep and 2 foxes, 10 sheep and 1 fox, and so on. This gives beautiful locality (a single move can never remove more than one sheep, and only extremely rarely more than one fox), allowing me to just mmap everything and let the kernel deal with it, even though I only had 256GB of RAM and the total set was larger (329,870,110,455 bytes after the symmetry optimizations below).
mmap is almost never the right answer, but again, I was trying to go for simplicity. It certainly brought me pain, though, and perhaps some more explicit I/O would have been better.
The board is left-right symmetric (with an odd number of columns, so that there is a middle column that is neither “left” nor “right”). I had hoped to just ignore this, but eventually the gains became too important to ignore, so I conceded.
The basic idea is that I ranked the board twice, both as itself and mirrored (mirroring is just a couple of masks and shifts, given my representation), and picked the key that was the smaller as canonical. This reduced the number of positions I needed to look at to a bit over 50%, as expected, but it does nothing to the storage/RAM requirements; the new rank is not dense and the “illegal” (non-canonical) positions are spread out a bit all over the place (although of course near the low and high ends of values, it works much better).
As a tweak, I chose to compute all 33+281 canonical fox positions and renumbered using those placements as an assumption. This slashes ~95% of the waste, which is good enough; you can still rank a nonconical position if the foxes are symmetric about the center (or if there's only one fox and it's in the middle!), though.
You can improve on this by making the macro-splitting finer; instead of having a chunk for e.g. “10 sheep, 2 foxes”, you could have one with “5 sheep in left, 0 foxes in left, 1 sheep center, 1 fox center, 4 sheep in right, 1 fox in right” and demand that there are more sheep in left than right. However, you still get problems when the number is balanced, you'd need finer splitting etc.. The gains are small enough that I didn't see the point in doing this, and it tends to be a place where it's easy to introduce bugs.
I imagined calculating the exact number of positions up to symmetry would be an interesting exercise somehow, but I suppose it just immediately falls to Burnside's lemma as soon as you know how to count positions at all.
Now that we have positions and moves and a way to store results, we want to know how to find the result for the starting position (and ideally also all other positions).
My first attempt just did a depth-first search, caching as it went. This worked for the earlier stages but was generally a disaster; it ran out of stack easily (even with 8 GB—eight gigabytes of stack), and had problems with figuring out loops. (It didn't loop infinitely, but was prone to declaring loops where one side could break out of the loop by winning. I had a nasty hack to fix that, but it didn't really feel good.)
What I did instead was propagating results one step at a time. For each possible position:
If from a given position you know you can immediately win (e.g., the sheep reach the pen, or the fox eats the last relevant sheep), mark it as such.
If you can, in one move, reach a known-won position, mark your position as won (for the side to move). Similarly, if you can only reach known-lost positions, mark your position as lost.
Repeat #2 over and over again until you no longer have changes.
This was simple but still inefficient; I typically needed 40–80 passes for each chunk (where a chunk is something like “all positions with 15 sheep, 2 foxes”). However, it was super-easy to parallelize; I have 64 cores and could just hand out reasonable independent sub-chunks, you don't even need locking or atomic operations on the result set.
The correct way of doing this is retrograde analysis (replace #2 with doing backwards moves) and I assume this would have made the calculation roughly ten times as fast. But I only needed ~36 hours for the actual run (plus numerous pre-runs that failed for various reasons!), so I never got to this. After all, I wanted something simple to begin with.
Since I only store win/draw/loss (WDL) for each position (also known as a “bitbase” in chess tablebases), it's not easy to know what the fastest way to win is; just that “this move does not mess it up, the other side still can't force a draw”. However, in practice, you could just do reasonable-looking moves that don't regress the position, and take forward moves whenever you can (i.e., do sheep pushes if that still wins).
I made a simple alpha-beta searcher that tries to get win distances using the bitbase as a guide, which was a really fun challenge! It can find wins when they're perhaps ~20 ply (10 moves for each side) away, depending a bit on how narrow the win is (if there are only a few ways to win, it will obviously have to search a much smaller tree). Ultimately, though, alpha-beta for finding exact mate scores is just a losing game, since even perfect move ordering will only give you a sqrt() improvement over pure minimax.
Perhaps making DTZ (distance-to-zeroing, referring to zeroing the draw move counter in e.g. chess) bases would be possible without breaking the bank on storage space; I would assume that usually, you can force some sort of progress pretty fast, at least as the sheep.
I made a very rudimentary interface to the database; the UI isn't very nice, and it largely relies on hovering (which doesn't work all that well on mobile) but I didn't want a polished game-player, just to know the answer. :-) You can try it out at https://sheep.sesse.net/ , although I don't envision keeping it up forever. Perhaps someone can gain new insight from it and become an expert player, although strong solves are rarely very insightful in themselves due to the brute-force nature. At least we've conclusively settled (again, under this ruleset!) that the sheep win with perfect play.
Earlier, I would publish the source, but these days, the only ones who would be reading it would be the AI beast (fox?), and I'm not really so interested in that. :-) I'm definitely open to answering questions if anyone should have them; contact information at my home page as usual.
Six pallets of NVIDIA computer hardware worth a reported $11.4 million disappeared during a shipment from California to Texas. A truck collected the merchandise in Oakland on Aug. 29 for delivery to Fort Worth. Investigators reportedly tracked the vehicle through several extended stops before losing its trail in Southern California. The Oakland Police Department confirmed an ongoing grand theft investigation following a complaint filed Sept. 13, 2026. The disappearance comes amid reports of nearly $111 million in stolen data center freight involving other high-value technology shipments.
According to The Mercury News , the vehicle displayed a food transportation company’s logo during the scheduled pickup. The driver subsequently traveled south, making several stops lasting multiple hours. Investigators eventually lost track of the truck in San Bernardino County. A separate $12 million cargo theft investigation involved suspects who allegedly exploited established trucking identities to obtain freight. Authorities have not linked the two investigations.
The Oakland Police Department provided FreightWaves with the following statement:
“The Oakland Police Department (OPD) is investigating a grand theft that occurred in East Oakland. The victim reported the crime to OPD on September 13, 2026. The investigation is ongoing, and anyone with information is asked to contact the OPD General Crimes Unit at (510) 238-3728.”
The Sept. 13 complaint date does not establish when the theft occurred. Police have not confirmed the reported $11.4 million valuation or identified the specific merchandise. Authorities also have not identified the cargo’s owner, shipper, motor carrier or driver. Investigators have not publicly explained the vehicle’s extended stops or established whether criminals impersonated a transportation provider. Police have not announced arrests or confirmed any recovery of the merchandise. FreightWaves contacted NVIDIA for comment and followed up, but the company has not responded.
The Oakland investigation follows other significant thefts involving NVIDIA merchandise in Northern California. During 2025, Fremont and Union City police investigated burglaries involving more than $7.5 million in NVIDIA products. Those incidents targeted valuable computer hardware at separate locations. Authorities have not established any connection between those investigations and the latest disappearance.
In a separate September incident, thieves stole two PlusAI trailers, including one displaying NVIDIA branding , from a Fremont, California, warehouse. The trailers contained approximately 40,000 pounds of sand rather than NVIDIA hardware. Police recovered both trailers in nearby Newark. Investigators have not established any connection between that theft and the Oakland case.
The reported disappearance of $11.4 million in NVIDIA hardware underscores the financial stakes of transporting high-value freight. Regardless of how this shipment disappeared, carrier verification, shipment visibility and communication remain critical throughout transportation.
Click here for more articles on cargo theft and freight fraud by Phil Brink.
Compromised communications linked to 40% of stolen loads in Highway fraud report – FreightWaves
CBP seizes 1,000-plus pounds of meth in produce truck at Texas border – FreightWaves
$500,000 SIG Sauer shipment stolen in fictitious pickup, two arrested in California – FreightWaves
Lightreason is a local inference lab and interactive Studio for running Qwen faster on one RTX 4090. The experiments use the original BF16 weights for Qwen2.5-3B-Instruct (3.09B parameters) and the text model of Qwen3.6-35B-A3B (34.66B parameters).
The smaller model fits on the GPU, where reusing prepared GPU work and checking several tokens together saves time. The larger model’s text weights occupy 64.56 GiB. The 35B runner keeps most expert weights in system RAM and moves the ones Qwen actually uses. When a draft predicts several tokens, Qwen checks them together and can reuse weights across those checks. The original BF16 Qwen target makes every final token decision.
LR labels configurations we built and measured. They use existing techniques and projects, including NVIDIA CUDA Graphs, AMD PARD2, Inco AI DFlash2, and FlashML’s FreeToken. The experiment history credits those projects, details Lightreason’s changes, and records which experiments slowed down or changed the output.
Live Studio is a simple, interactive way to test speed. Build and preview a web page, then run the same prompt through Standard and Lightreason Exact to watch each response stream and compare its timings.
Run 3B Studio · Coding benchmarks · Experiment history · Reproduce 35B · Port to other hardware
The GitHub checkout contains source, pinned download manifests, and benchmark evidence. It ships zero checkpoint or adapter weights . Download the models you need on the GPU machine.
If you only want 3B Studio, a sparse clone skips the 35B sources and benchmark archives.
git clone --depth 1 --filter=blob:none --sparse https://github.com/me-farza/lightreason.git
git -C lightreason sparse-checkout set demo_chat results3b
| Run | Download separately |
|---|---|
| 3B Studio, Standard and Exact, and the Python/JavaScript/SQL benchmark | Pinned Qwen2.5-3B-Instruct |
| 35B Scheduled | Pinned Qwen3.6-35B-A3B |
| 35B packed runner | Qwen3.6-35B-A3B and Inco AI DFlash2 |
| Optional 3B PARD2 research | Public AMD draft and tokenizer , plus a separately supplied lab adapter |
The 3B PARD2 peak numbers are archived research measurements. The public PARD2 weights require the matching lab adapter to reproduce those numbers. The target-only 3B results use the public Qwen download alone.
The public
3B Studio
quickstart uses Linux with an RTX 4090 and a driver compatible with CUDA 12.8. Standard and Lightreason Exact use only the Qwen target. Your browser can run on a different machine. The 35B runners use a separate benchmark setup with a larger system RAM requirement. With the sparse checkout, start at
cd lightreason
below.
35B setup
Install Python 3.12, its venv package and headers, and a C compiler for Triton. On Ubuntu 24.04, install
build-essential python3.12-venv python3.12-dev
. Run
nvidia-smi
on the GPU machine to confirm the driver sees the card. The download is about 6.2 GB and the downloader requires another 2 GiB of free space. Budget separately for Python packages and compilation caches.
git clone --depth 1 https://github.com/me-farza/lightreason.git cd lightreason python3.12 -m venv .venv source .venv/bin/activate python -m pip install 'torch==2.9.1' --index-url https://download.pytorch.org/whl/cu128 python -m pip install -r requirements.txt python -c 'import torch; name = torch.cuda.get_device_name(); print(name); assert "4090" in name and torch.version.hip is None and torch.cuda.is_bf16_supported()' python download_3b.py --destination model-3b python -m demo_chat.server --model-path model-3b
The setup pins PyTorch 2.9.1 with CUDA 12.8 and Transformers 4.57.1.
download_3b.py
checks the official objects against the pinned
download plan
. Read the Qwen license before downloading or using the model.
Qwen license
·
Original v0.1.0 source
Leave the server running and open http://127.0.0.1:8765/ . For a remote GPU, first run this tunnel in a separate terminal on your browser machine.
ssh -N -L 127.0.0.1:8765:127.0.0.1:8765 YOUR_GPU_HOST
"ready": true
with
curl -fsS http://127.0.0.1:8765/api/status
.
Ctrl+C
.
For a headless smoke test, run the same prompt and token cap through each CLI engine. The JSON records preparation, generation, token IDs, and stop reason. Use Studio or the repeated benchmark harness for speed measurements.
python run_model_3b.py --model-path model-3b --engine original --tokens 128 --json --prompt 'Explain why the sky is blue.' python run_model_3b.py --model-path model-3b --engine bucketed --tokens 128 --json --prompt 'Explain why the sky is blue.'
Lightreason Exact records and replays GPU work, keeps a compact attention cache, combines BF16 projections, and screens vocabulary candidates before scoring survivors with the original output weights. The draft-assisted 3B runner verifies candidate trees and coordinates acceptance on the GPU. On 36 held-out comparisons it was 1.062× faster with the same outputs as the preceding draft-assisted runner. It matched Hugging Face on 12/36 . Implementation and reproduction
For 35B , FreeToken and DFlash2 provide the hybrid CPU/GPU executor and parallel draft. Lightreason adds selected-row prefill, AVX2 reuse across repeated expert routes, native CUDA unpack, packed host banks on 34 layers, and a lossless GPU replica tier. It reconstructs the original BF16 bits before the expert math. Runtime, profiles, and reproduction
For other hardware, measure the unmodified model on your device first. Use the
porting guide
to identify whether GPU work, memory, or transfers limit the full request. From the cloned repository, ask Codex to
use
$lightreason-hardware
. With another coding agent, point it at the
hardware skill
.
Open Build preview to generate single-file HTML and render it in the sandboxed preview. Studio reports generation and browser rendering separately.
New app generates a page. Edit current app supplies its HTML and asks Qwen for the full update. Patch edit (experimental) asks Qwen for one small JSON search-and-replace, checks it against the current HTML, and renders the reconstructed document after successful completion. Use the full edit path for larger changes or to retry a rejected patch. A successful patch currently reloads the sandboxed preview, which restarts page state.
The two patch formats, their local HTTP benchmarks, and known failures are described in the benchmark notes .
Standard and Exact run with the target checkpoint alone. The optional Turbo runner and the GPU coordination benchmark additionally require the pinned AMD PARD2 draft directory and the matching trained LoRA/projector checkpoint supplied locally. See the optional setup and reproduction commands . That adapter is separate from this source release.
Run the CPU-side Studio contract tests from the repository root:
python -m unittest discover -s demo_chat -p 'test_*.py'
node demo_chat/test_preview.js
Original Lightreason source and documentation use 0BSD. FreeToken patches and the Qwen checkpoints have separate upstream terms. Lightreason license · Third-party terms and credits · Lightreason logo
Many thanks to Max Farrens , Gabe Fried , and Thomas Larsen for pairing with me through significant parts of writing and researching this essay.
You can watch or listen to me narrate this essay on YouTube , Spotify , and Apple Podcasts.
If you asked me earlier this year how far away we are from superintelligence, I’d probably have said at least the better part of a decade. But over the last three months, I’ve updated my views a ton. I’ve been debating people about this question, both on and off the podcast. And I’ve been watching the progress of AI on verifiable domains and thinking about what that implies for AI research itself.
I’ve now come to the view that we’re only a couple of years away, and possibly only a couple of months away, from AIs that are as good as the best humans at AI research. I’ve also come to believe that automating AI research will compress so much progress into a single year that, soon thereafter (so by 2030, but plausibly as early as next year), we’ll have AIs that are at least as good as the best human experts in every field. I know this is a wild claim, and it’s one that I myself didn’t believe even a couple of months ago. Let me walk you through how my thinking has changed.
Before we get into more speculative arguments, I want to point out that we have a lot of evidence that AI is already dramatically speeding up further AI progress at the frontier.
For example, METR, which is an independent evaluation organization, concluded after three months embedded inside Anthropic that Anthropic’s overall rate of progress on well-scoped tasks is 2x what it was a year ago, and that a “majority of this acceleration today is likely attributable to Anthropic’s extensive use of AI to do R&D.”
OpenAI published a blog post about this in September, where they showed that the heaviest 10% of AI users among OpenAI’s researchers went from using around $1,000 a day of internal coding agents at the beginning of the summer to over $7,000 a day by the end of August.
In September, Anthropic put out a similar post on its own AI uplift. They reported that, as of August, Claude “leads” more than 26% of Anthropic’s AI R&D work—up from under 1% as recently as February. 1
When I think about how big a deal it could be if AIs automate AI research, and how soon that could happen, a really important update for me has been just seeing how quickly AI capabilities in mathematics have exploded. Current AIs are slicing through well-scoped problems in mathematics like a hot knife through butter. It was only two years ago that I asked Dario why LLMs aren’t able to use their vast knowledge across so many different fields in order to connect different ideas and make new discoveries. And lo and behold, here we are: In a wholly verifiable domain like mathematics, AIs are doing this search-and-match discovery to such a great extent that hundreds of important results (which the top mathematicians and computer scientists in the world had spent decades trying to resolve) are being churned out as side quests to hype up future model releases .
It’s crazy how fast we went from, in 2023, “This model can’t reliably add four-digit numbers,” to, in 2024, “This model can barely solve any problems in a high school math competition,” to, in 2025, “Oh, it can win a gold medal at the International Mathematical Olympiad,” to, earlier this year, “Wow, it’s solving open Erdős problems, but maybe just because no human has attempted to solve these particular problems, and a similar solution was already in the literature,” to, about a month ago, “Okay, it fucking solved a Millennium Prize problem in 88 hours.”
There’s a line in the novel East of Eden : “And there is one sure thing about the fall of gods: they do not fall a little; they crash and shatter.”
It’s true that progress has skewed disproportionately towards the verification-laden parts of math, like finding counterexamples (rather than coming up with new theories, say). Toby Ord posted a great essay about this recently. He writes , “While current AI systems are starting to automate mathematical proof, there is currently very little evidence that they can ask powerful questions or find profound new fields of mathematical enquiry.”
But another way to say the same point would be: Current AI systems have solved a Millennium Prize problem, all without the ability to ask powerful questions or find profound new fields of mathematical inquiry.
And this ability to solve well-scoped problems is going to be an even bigger deal for machine learning research than for mathematics, broadly construed. That’s because the goal of mathematics research is not just to prove or disprove long lists of conjectures, but to extend human understanding of mathematical concepts. Coming up with the idea of topology, group theory, or the Cartesian grid matters far more than knowing exactly how many one-unit-apart pairs you can make from n dots . We mainly care about such abstruse questions insofar as they might elicit new mathematical theories.
But in AI research, the priorities are exactly reversed. AI labs mainly care about how any new algorithmic recipe empirically makes training more efficient or elicits smarter models. They don’t care about theory for its own sake, and all the progress we’ve made in deep learning over the last decade and a half has not required much new theory anyway. The equivalent of grinding through random conjectures would be enormously valuable in machine learning in a way that it just isn’t in mathematics.
AI research is actually surprisingly similar to the type of mathematical progress that current AIs are disproportionately good at: unlocking a ton of low-hanging fruit by applying a combination of incredible persistence and a superhuman capacity to connect ideas from lots of adjacent domains.
For example, let’s talk about the transformer architecture. My friend Sholto Douglas , who is an AI researcher, has a perennially half-finished blog post where he explains how you could have invented the transformer two years earlier than people actually did. Maybe this essay will get him to quit stalling and complete it, but in the meantime, I’ll summarize a bit of the discussion I had with him about the contents of that essay.
Before the transformer paper was published in 2017, many researchers had already identified attention as a way to better parallelize training and communicate information across longer sequences. Chris Olah, who was an active researcher then, has said : “At the time, my sense is that the transformer architecture was a natural combination of many ideas (attention, residual networks) which had independently been effective, taken to quite aggressive lengths.” In other words, none of the core pieces were a surprise to researchers working in the field.
So then why didn’t people invent the transformer sooner? One reason was that this new architecture was only obviously better than the state of the art once you connected half a dozen additional tweaks and innovations. And though all of these had been in the literature for years, 2 no one knew how to combine the puzzle pieces. Doing so required research taste, of course, but also tons and tons of small experiments.
But what I’ve just described above—persistently and intelligently matching dozens of different combinations of ideas—is exactly the kind of capability that AIs have shown themselves disproportionately skilled at in their contributions to mathematics.
This is all to say, even the transformer, which is arguably the biggest breakthrough in ML since AlexNet kicked off the deep learning revolution in 2012, is the kind of thing that Claude 7 could invent if Chris Olah asked it to try hard to get this attention thing to work better.
I want to clarify that some parts of AI research are, in fact, less verifiable than math. That’s why OpenAI hasn’t fired all of its researchers, despite having a model that can autonomously solve Millennium Prize problems. But I think AI research is verifiable enough that AIs will soon be as good at it as the best humans. Explaining why requires getting into the nitty-gritty of how AI research actually works, and because those details are interesting but technical, I’ve saved them for the Appendix—if you’re curious, just keep reading after the conclusion. But in the meantime, I’ll give you my estimate of when we get there.
If I had to pick my median year for when automated researchers will be as good as the very best human AI researchers (and assuming the labs don’t intentionally slow down), I’d guess 2028.
Why do I think AIs could get this good within two years? In every domain where we can check answers and give AIs thousands of rounds of practice—for example, competitive programming contests, or well-scoped open math problems—they’ve gone from worse than most humans to better than the best humans within a few years. And as I detail in the Appendix, AI research has those same verifiable properties.
Of course, a big part of what makes a top AI researcher like Ilya Sutskever so good can’t be directly verified—for example, his ability to bet, years in advance, on the right research direction. But as we’ve seen in math, models generalize far beyond what they were directly trained on. OpenAI’s model was obviously not trained by solving other Millennium Prize problems. It was trained on lots of less ambitious, more tractable math problems, and from those it generalized all the way to solving a problem no human had ever cracked. I’d expect the same in AI research, where the combination of thousands of rounds of practice on verifiable research tasks, plus the fact that each new generation of models is broadly smarter than the last, will make models excellent even at the parts of AI research we can’t directly check.
I want to be clear that there’s a pretty decent chance that hitting this milestone takes longer because some important part of AI research remains hard to automate. I’d guess there’s a 25% chance that it doesn’t happen until after 2032. 3 But I also think things could move much faster, and that we could hit this milestone in 2027. Some of the most well-informed researchers I know, people who have had a very good track record of prediction over the last few years, expect AI to beat the best humans at AI research as early as next year. And 2027 is also the straightforward implication of plugging METR’s finding—that Anthropic’s rate of AI progress has doubled in a year—into a takeoff model.
As former guest Ajeya Cotra put it in a blog post about this report :
If we take it at face value that AI is now nearly doubling the rate of AI capabilities progress and assume acceleration from AI is smooth, this naively implies that we would reach extreme superintelligence within a year.
The reason my median is not that soon is that I’m uncertain about how accurate this straightforward modeling is. But we should not be surprised if we get to this milestone next year, and we should be prepared for such a world.
Once AI is as good as the best humans at AI research, algorithmic progress will get radically faster. There are three important reasons why: The automated researchers will be much faster, each of them will be very smart, and there’ll be a lot more of them.
Today’s AIs already do work at about 10 times human speed. 4 And automated researchers would also be working around the clock, nights and weekends included. As a result, each individual automated researcher will be cramming in roughly 50x more work every calendar week than a human researcher can do.
Of course, that doesn’t mean AI progress will immediately accelerate 50x. Those automated researchers would still be bottlenecked by compute for experiments, which aren’t running any faster. So there would be diminishing returns. But even with extremely steep diminishing returns, this alone would make algorithmic progress proceed many times faster than it currently does. 5
And this is before we account for the fact that, in this scenario, every automated researcher will be at least as good at AI R&D as the very best humans.
My sense is that around 80% of the algorithmic progress at a given frontier lab is driven by its top 50 researchers. It’s not for nothing that Zuckerberg was willing to pay hundreds of millions of dollars to acquire the best talent in the industry. And so you get another big speedup in algorithmic progress from the fact that every single engineer and researcher in this automated company will be at the level of the very best humans in today’s frontier AI labs.
Throwing more workers at a problem isn’t always helpful. For example, a swarm of agents probably couldn’t write a great novel much faster than a single agent could. But other tasks lend themselves to parallelization: For example, look at the animation below, showing a bunch of different Claudes working together to formalize Fermat’s Last Theorem . This feat had thousands of modular subtasks, each of which could be completed independently and where each agent could locally check whether its work had succeeded.
AI research is closer to formalizing a theorem than to writing a novel, because there is a lot of independent modular work to do, and there are verifiable proxies for progress. That means a swarm of agents can try a thousand different approaches and see which performs best, and they can do this independently for each different part of the pipeline. AI companies are already made up of dozens of teams working independently on different parts of model development: one team improves how the pretraining data is filtered, another helps design a particular kind of synthetic RL environment, another writes a better attention kernel, and so on. In domains like this, where different streams of work can be done and checked independently, dumping in lots of persistent hill-climbing agents tends to speed up progress a lot.
Again, there will be steeply diminishing returns just from adding more parallel researchers. Anyone who has worked on a team before knows that having 100,000 collaborators doesn’t mean you go 100,000 times faster—probably not even 100 times faster. But it’s implausible that you wouldn’t be going at least a couple of times faster from having orders of magnitude more automated labor.
So the combination of faster, smarter, and more numerous automated researchers will speed up AI progress a lot. But will this pace continue, will it get even faster, or will it slow down? That question is even more important than what the initial pace actually is.
Two competing trends are relevant here. And the subsequent pace of progress will come down to which ends up being more powerful. On the one hand, because of RSI, automated researchers will continue getting faster, smarter, and more plentiful. On the other hand, AI research will be getting harder and harder, as all the easy ideas get eaten away by the swarm.
By the way, “ideas getting harder to find” is a thing that already happens. AI companies have to quadruple their R&D compute and double their workforce every single year just to maintain the same rate of progress.
If the rate at which AIs get smarter is faster than the rate at which ideas get harder to find, then we’d get something called the “software-only singularity.” In this scenario, even without increasing compute, the AI swarm rapidly makes smarter and smarter versions of itself until, within a matter of months, we end up with a superintelligence that scrapes against the physical limits of our current chips.
But if ideas get harder to find faster than RSI makes AIs better at research, we’ll end up with what I’d call a “spark.” We’d get something like three to six years of AI progress in a single year. 6 And then things would simmer down until we build more compute, because even the super-genius automated researchers need to run bigger experiments before they can make further breakthroughs.
If pressed, I’d give a 50% chance to the “spark” scenario and a 50% chance to the “software-only singularity.”
To be clear, though, even the “spark” scenario, where we make about four years of progress in the first year after automating AI research, would feel insane. That’s a jump as big as GPT-3.5 to GPT-6 Astra in just 12 months. To remind you of the scale of progress that this leap would compress, GPT-3.5 was able to write a passable limerick and autocomplete a trivial Python function, but was mostly a useless toy, whereas Astra can build whole video games from scratch and churn out Fields Medal–worthy mathematical contributions to such a great extent that we’re already desensitized.
In the last four years, we’ve gone from a preschooler to a savant intern. If you made another jump that big, but starting in 2027 or 2028, you’d probably get a mind that would be vastly superhuman in domains that are even slightly verifiable. For example, it’d be better than Nvidia at coming up with the next generation of AI accelerators. It would make more money than the current human versions of Citadel and Jane Street (if it had equal access to the market). If you gave it remote access to a materials science experiment lab , it’d be better than the rest of humanity at finding a room-temperature superconductor.
Now, at this point, you might ask: How will even a superintelligence trained within a datacenter beat human experts in domains where the basis of that human expertise is years and years of real-world experience?
The way we’re currently making AIs smarter is by RLing them on tasks that are easy to automatically grade from within a datacenter: Do the million new lines of code the AI wrote pass the unit tests? Did the AI solve more open math problems? But of course, most of the world is not like this. I made this point in a recent essay :
How would we train an AI to build a business? How would you make an AI that’s really good at winning court cases? Or having a profitable day trading in the markets? Or helping a candidate win an election? The rollout requires interacting with the world and cannot be recreated simply within the datacenter.
So how will superintelligence get good at this kind of stuff? Let me be clear: I don’t think we can just bake the answer to every real-world problem into the weights. Rather, my claim is that scaling up RL training will give AIs the abilities necessary to ramp quickly in new contexts, even in hard-to-verify domains like the ones mentioned above.
Getting really good at any complex task takes two things. One is domain-specific knowledge. The other is a more general set of skills—the kind that capable humans have—like being able to seek out relevant information, make a plan, push forward on it through mistakes and obstacles, keep track of what you’ve learned, and collaborate with other people.
During RSI, automated engineers will build tens of thousands of times more RL training environments than we have currently. These will be far longer-running, higher-quality, and more open-ended, and will cover a much wider range, than today’s environments.
The AIs will learn to make their way in an unfathomable number of virtual worlds that are each to today’s video games what a Bugatti is to a horse and buggy. These games will be far more difficult, messy, sprawling, and realistic than anything ever made for human entertainment. They will require AIs to cooperate or compete with teams of other AIs over long periods of time. For example, an AI will be dropped into a thriving simulated digital economy full of millions of other AIs and told to cofound a successful company. And it’s not like this AI will be stuck just thinking about the ideal corporate structure… it’ll go through an evolutionary process that involves centuries of corporate competition to figure out the optimal organizational techniques.
The AIs will also train themselves on endless backtests of everything in the history of science and tech and politics and culture—they’ll have to predict every discovery, invention, war, election, and quarterly earnings report that has ever happened. Here’s one prediction training task: Can an AI figure out general relativity given a training corpus that includes no information beyond 1700, which is far earlier than any human was on track to discover GR? Another example: Given every single newspaper article until 1962, can the AI predict how the Cuban Missile Crisis is going to unfold? 7
And it’s not just the training data that these automated researchers will be improving. They will also radically improve the basic learning algorithms themselves, through breakthroughs in online learning and sample efficiency (both of which have verifiable proxies, as I discuss in the Appendix ). In the same way that humans are much more efficient and effective at learning from data than current LLMs are, future AIs could be far beyond humans in learning efficiency.
Why do I think we’ll see lots of transfer from verifiable tasks to these more general skills? One reason is that even at one ten-thousandth of the scale of RL training that will be happening during the intelligence explosion, we’re already seeing lots of generalization. If you point Claude Code or Codex at a project it has never seen before, it knows how to orient itself, figure out how everything fits together, and then tackle an ambitious assignment.
Of course, it’s hard to measure how much models have improved at tasks that are not easily verifiable, because if we could… those tasks would be verifiable. But you can go talk to a new model and compare it to an old one. In my experience, AIs have gotten much better at things that have very little to do with code or math—for example, helping me research the abstract questions I needed to answer to write this essay. 8
The other big piece of evidence for transfer is human evolution. Our general-purpose mental architecture was developed by evolution, which is an optimization process with a really crude verifier: Did you pass your genes on or not? In the ancestral environment, the tasks which influenced that outcome were things like hunting, fending off predators, and keeping your standing in a tribe.
These are a tiny subset of the kinds of tasks humans are able to tackle today. Evolution did not specifically optimize us to be able to write a Pulitzer Prize–winning biography, or make advanced semiconductors, or lead nations of millions of people, or come up with a new branch of mathematics. But, in optimizing us for survival on the savanna, evolution built a general-purpose learner.
In training these AIs, we’re running a similar process, except we’re doing so deliberately, with tasks more closely related to those needed for success in today’s world. And unlike evolution, AI companies are trying to improve transfer during training (for example, by making sure that performance improves on difficult tasks that were held out of training). If even dumb, blind evolution can get this much transfer out of building a mind that is effective at propagating itself on the savanna, then the deliberate effort that AI companies are putting into building a flexible and general intelligence that can ramp up rapidly in any new context should advance much further.
Now, even a superintelligent learner can’t figure out everything from inside a datacenter . So even these AIs will need some real-world experience. But I think they’ll be able to get that experience much faster than people expect, and that they’ll beat top human experts within months of being deployed.
Honestly, one thing that’s guiding my intuition with all this stuff is that I have a lot of 20-something-year-old friends whom I’ve watched accomplish incredible things and build world-leading companies and ventures in domains they entered into with no previous experience.
History is full of super-competent young people who ran circles around the world they were dropped into. By the age of 27, Napoleon had stacked victory after victory against far larger armies from the other great powers of Europe. By 25, just two years after he got into the oil business, Rockefeller was running one of the world’s largest refineries.
Rockefeller and Napoleon needed experience, yes, but only a couple of years’ worth, not decades. Whatever was going on inside those guys’ brains, AIs should be able to replicate (or even exceed: There’s no reason to think humans are the ceiling on learning quickly from experience).
Furthermore, unlike Napoleon or Rockefeller, AIs can accumulate years of deployed context in just weeks of calendar time. For example, imagine that you wanted one of these future AIs to run a Fortune 500 company better than its current CEO. How quickly could it ramp up? Well, if you let it shadow that CEO, on its first morning, it could read every email, Slack message, and document that the company has ever produced. By the end of the first day, parallel copies of it could have interviewed every employee and major client, and cumulatively done the amount of work it would have taken a single human months to do, before getting merged back together. Obviously, some pieces of feedback—about how your actions impacted the quarterly earnings, say—require months of serial time. But even granting that, we should expect these future AIs to be able to get to top human performance in almost all domains within months of being deployed. That’s still 2028 or 2029 in this median scenario.
And remember, even in the spark scenario, all of this happens in just the first year or two after AI research is fully automated. Things don’t just stop there. Because even if the software progress peters out, AIs will continue to stoke the fire by helping add more compute. Even without help from AIs, global AI compute has been growing roughly 3x a year . And the AIs that come out of the spark will be jaggedly superhuman at helping us continue scaling up compute . They’d be extremely good at designing AI chips, laying out the design of a new fab, and even teleoperating robots to help build parts of fabs and datacenters.
So in the spark scenario, AI capabilities continue to improve, but because their progress is driven by building more chips, datacenters, and robots, it takes years to get to the same endpoint that the software-only singularity would have achieved in months: a superintelligence that is to us what we are to chimps.
In the next essay, I’ll walk through what I expect these minds to be like, and how I expect them to transform the world.
Earlier, I promised to explain why I think AI research is largely verifiable—so that’s where I’ll start. After that, I’ll go through what I think are the strongest objections to my arguments about RSI.
One thing I want to call out at the very top is that, because pretraining and post-training are verifiable (as I discuss below), so is progress on what is the most galling and important deficiency that AIs have relative to humans: namely, their lack of sample efficiency. If you want a neural network to gain some capability, you have to feed it much more data than it would take a human to learn the same thing.
But every kind of sample efficiency is measurable. You can measure how much data it takes to reach a given pretraining loss, how many tasks it takes to reach a given score in an RL environment, or even how much feedback and time within a single session it takes to reach a desired level of performance just from in-context learning.
Sample efficiency and online learning are really two sides of the same problem: how to learn from real-world data quickly and efficiently. For decades, people have recognized this as the deepest open problem in machine learning—AI’s equivalent of a Millennium Prize problem. And mathematics has already shown us what happens to such problems, even when they are very difficult, as long as they are verifiable.
Okay, why do I think that progress on sample efficiency, online learning, and the other problems in ML is verifiable? Well, there are roughly three broad buckets to AI R&D: pretraining, post-training, and inference efficiency. As I’ll explain below, each has strong verifiable proxies that are easy to train against. And since together they comprise all of algorithmic progress, that means that AI progress in general is easy to train against, which, in some sense, shouldn’t be surprising. We can make models much better at things that can be tested inside a datacenter. And AI training is literally happening inside a datacenter.
Keep in mind that this verifiability is valuable for two reasons. First, it allows AI companies to RL a model to get better at a specific part of AI research through thousands of rounds of practice. And second, these proxies make it easier for agents to work in parallel, because they can locally check whether they beat a particular leaderboard before merging their contributions.
As you’re building GPT-7, you can RL it to get better at finding pretraining compute multipliers. For example, you could make an RL objective that says GPT-7 has to minimize how much compute it uses to train a GPT-2-sized model to a fixed pretraining loss. 9
And once GPT-7 is built, you can deploy a swarm of agents to figure out how to train a GPT-3-sized model to the lowest possible perplexity. Loss on a held-out test set, which is the basis of pretraining progress, is extremely easy to verify. 10
Of course, what works at small scale doesn’t necessarily work at large scale. And it requires taste to anticipate which promising small-scale improvements will actually bear fruit when composed together in a bigger model. But this kind of intuition is also trainable—for example, you can make an RL environment where GPT-7 has to predict whether an algorithmic improvement made at the 100M-parameter scale will hold at the 10B scale. And while this “taste-bench” environment is more expensive to RL on than the nanoGPT speedrun , it’s still not that difficult to train on if you have frontier-lab-scale compute. So even important parts of research taste are verifiable.
By automating pretraining alone, you’d radically speed up AI progress. And there are three important reasons why:
First, pretraining leads to very general improvements in the model’s intelligence and capabilities. There is a deep explanation for why this is true, which has to do with the link between compression and intelligence, and if you want to learn more about this, you should check out this excellent video by 3Blue1Brown .
Second, as you make pretraining improvements, you can train a smaller and smaller model that is just as good as a previously larger model, but which trains faster and more cheaply. That not only speeds up pretraining but also makes your experiments and RL rollouts atop this base model more efficient. 11 And since your automated researchers are also instantiations of this now smaller model, you can now support larger researcher populations too.
Third, because smaller models train faster, this tightens the RSI loop itself. During RSI, labs probably won’t do three-month pretraining runs spread across multiple datacenter campuses. The army of automated researchers would be finding algorithmic innovations so quickly that, by the time a giant run finished, it would already be made obsolete by a much smaller model that first began training only a week ago. It’s similar to how, if you launched a spaceship to Alpha Centauri with today’s technology, it would probably be overtaken in transit by one launched a century from now. Furthermore, since you’re training smaller models faster, on a scale where you can run thousands of experiments daily, you won’t have to bet that small-scale results will hold up in bigger models. You’ve already tested at the scale you’re training.
How much better could base models get, even at today’s parameter sizes? I think there’s a ton more potential. We are far from the limits of pretraining. The AI lab Magic recently announced that they pretrained a model that matches the leading open-source base models today, like DeepSeek V4 Pro, for just half of the compute used to train the original GPT-3 (roughly $500k today). Orders-of-magnitude further improvements seem totally plausible.
Here are three different verifiable proxies for post-training:
First, your automated researchers can try to improve your post-training algorithms such that if you want to RL on a new set of environments, it takes less compute or data or time (all easily measurable).
Second, your automated researchers can work on making models better at learning on the fly. And you can easily measure progress on this. For example, if you drop the model into an environment it was never trained on, how quickly does it learn what’s going on and figure out how to get a good score? And how fast does it get better at a video game it’s never played before? You can have more real-world tasks that measure this kind of meta-learning too. Check out ByteDance’s EdgeBench for examples of such tasks. 12
Third, you can also just measure AI R&D capability directly. Anthropic has an internal benchmark called CoBench , which contains around 500 real problems that its researchers and engineers solved this year. Every benchmark is also an RL environment, and an RL environment like this would allow Anthropic to have its models practice redoing the last three to six months of human progress at the frontier.
Another important part of AI R&D is designing the model and the surrounding software to get more juice out of your compute. This is especially verifiable. You can easily measure GPU utilization, KV cache size per token, total FLOPs in a forward pass, latency, etc.
Now I want to deal with the strongest objections to my arguments about RSI.
I want to be clear that these bottlenecks are serious, and they do tamp down the probability of the most aggressive possible takeoff. This is why I think we make a GPT-3.5-to-GPT-6-sized jump in 2028 (rather than some crazy overnight singularity that starts tomorrow).
But I think these bottlenecks don’t fully deflate the craziness of this future (and the neck of the bottle is actually pretty wide). Let me explain why.
I’ve spent the past year and a half arguing that the main thing missing from today’s AIs is the ability to improve from on-the-job experience. Every new session is their first day on the job. And in each session, they can only retain a couple of hours’ worth of information, so they don’t accumulate the feedback or know-how that arrives over the course of weeks or months. Last December, this was my main reason for doubting that we’d automate AI research anytime soon. As I wrote then :
Somehow this automated researcher is going to figure out the algorithm for AGI – a problem humans have been banging their heads against for the better part of a century – while not having the basic learning capabilities that children have? I find this super implausible.
Here’s why I don’t think the current lack of continual learning will stop full automation of the best AI researchers by 2028.
First, AI companies might just solve continual learning by then with architectures much like the ones they already have. Previously, I thought we were bottlenecked by some crazy breakthrough that allowed models to update their own weights at the end of every session. But now I think scaling up in-context learning, so that you have sessions that are effectively many months long, will probably be enough to let a single instance learn on the job effectively. And there are many, many promising ideas that might let the labs achieve dramatically longer effective context windows. 13
Second, you might not need a continual learner to solve continual learning. As I explained above, online learning is an ML research problem with clean verifiable proxies. If you’d asked me two years ago which would be harder to solve, Navier-Stokes or continual learning, it wouldn’t have been obvious to me that the answer was Navier-Stokes. It turns out that continual learning was harder, given the fact that the labs haven’t cracked it yet. But are you so confident that it’s that much harder that non-online-learning models a year or two smarter than the ones currently solving Millennium Prize problems won’t be able to crack it, even if they are amnesiacs like the current models are?
These models are solving Millennium Prize problems while still being derpy savant interns who have no long-term memory. It’s like watching someone cartwheel down the track and still keep pace with Usain Bolt. If they were allowed to actually run, I’m sure they’d go even faster. But who’s to say they can’t win this race while still cartwheeling?
That being said, I think there is a serious chance that we don’t solve continual learning within the next few years, and that models are not able to compensate for this missing capability through their other advantages. That’s why I put a 25% chance that we won’t be able to automate Ilya-level researchers until after 2032.
Some people might argue that all the verifiable proxies I listed above assume the current paradigm. But figuring out what objective to verify in the first place—choosing which hill to have GPT-7 climb—is itself an important part of AI research. This is what one might call “research taste.” Before 2018, almost nobody thought that minimizing loss on next-token prediction was the most tractable path to AI progress. So nobody would have bothered building the nanoGPT speedrun environments on which the agent swarm could practice reducing the compute needed to get to a certain pretraining loss.
Won’t there be multiple new paradigms that we need to cross in order to get from here to ASI? And won’t each new paradigm have some new associated proxy that we don’t know ex ante? How will the automated researchers find these during RSI?
I have two responses:
The transformer was visible on (in fact was invented to beat) the existing translation benchmark—a similar story for reasoning models and pre-existing coding and math benchmarks. Proxies made before a “paradigm leap” seem perfectly capable of capturing large step changes in performance. This is because AI learning algorithms are quite general.
It’s not that difficult to come up with paradigm-agnostic outer loop proxies: how many Millennium Prize problems does your model solve; if you train your model on data before 1905, how long does it take to discover general relativity; how fast does it master totally unseen video games; and so on.
All in all, I think the other objections to the impact of RSI are much stronger—I would be very surprised if this was the reason RSI ended up not being a big deal.
Isn’t data one of the main inputs into AI progress? How will RSI happen without that scaling up at the same rate?
My answer is that data will continue growing during RSI, but the AIs will be the ones compiling it. Producing better training data for both pretraining and post-training is itself an ML research problem, and AIs are getting increasingly good at doing it themselves. 14
It is true that data is an extremely important input into AI R&D. Jerry Han and I actually did some research into this—we found that for pretraining, over the last six years, more than three times as much algorithmic progress has come from data improvements as from model improvements.
However, I don’t think people realize that these “data” improvements in pretraining are very much in line with normal AI research work—basically figuring out which techniques for filtering existing data or generating new synthetic data empirically lead to lower loss on a held-out corpus. 15
A similar thing seems to be increasingly true for RL. DeepSeek just published a paper where they talk about how they post-trained their new model. They say that changes to the basic RL algorithm have not mattered nearly as much, and “systematic improvements in the scale, diversity, and verifiability of synthesized data and environments account for essentially all of the observed gains.”
And the way in which those environments are made is becoming more and more automated: “we invest in large-scale, automated pipelines for data synthesis and environment construction … Using difficulty and correctness as reward signals, we iteratively train the model to construct better tasks.”
Earlier, I made this extended analogy between the current acceleration in mathematics and what we should expect to happen in AI research. But there is one big difference between AI research and mathematics. In mathematics, you can simply reason your way, with pen and paper, to new discoveries. In AI research, you need to run experiments to validate your ideas, which take compute and time. And as the number of automated researchers grows, each gets access to a smaller and smaller slice of the total experiment compute pie.
My answer to this objection is that each agent will still have access to a ton of compute. Frontier labs have been more than quadrupling their compute every single year. If this trend continues, then by the end of 2027, OpenAI could give thousands of agents each enough compute to run a GPT-3-sized training run every single day. 16
Keep in mind that the final model trained in the original transformer paper back in 2017 took 3.5 days on 8 P100s—which costs about 50 bucks to rent today (about one ten-thousandth of the training compute of GPT-3).
If top human AI researchers, like Noam Shazeer and Ilya Sutskever, had enough experiment compute to train a GPT-3-sized model every single day, they might make slower progress than they currently do. But it would be extremely surprising to me if they failed to make meaningful progress altogether, and just sat down and started complaining about how small their cluster was. Now, how productive do you think an AI lab would be if it had thousands of great researchers, each with this much compute, and each thinking 10 times as fast? You wouldn’t want to write a check to this neolab?
The nature of research and experimentation at the labs today reflects the fact that researcher time is extremely scarce relative to compute—top AI researchers individually get paid hundreds of millions of dollars a year. So the way labs use compute today tells us little about how efficiently they could use it if compute, rather than researcher time, were the key bottleneck.
There are two main ways in which the RSI agent swarm will use experiment compute much more effectively than researchers use it today:
Immediately, they can trade labor for compute. To save valuable researcher time, experiments today are, and should be, very wasteful with compute.
Instead of painstakingly setting up and carefully monitoring lots of small-scale pretraining experiments, a human researcher today might kick off a couple of huge multi-agent RL runs in parallel. But if you’re bottlenecked by experiment compute, you can just do more of the former.
When those automated researchers
are
doing an RL run, they could read every single rollout transcript and immediately pause and rebuild the whole environment if some task is broken. They could be doing crazy amounts of small-scale ablations of the models to make them oh so slightly better. And when a team of agents decides to combine their compute to do a much bigger run, they could spend many subjective decades designing the most informative pooled experiment, and once it’s done running, they could spend further subjective decades comprehensively analyzing it before designing a new experiment.
These automated researchers could also come up with a much better science of learning from small-scale experiments. Scaling laws themselves are a good example of this—
the GPT-4 paper
says that they were able to predict that model’s final loss using models trained with 10,000x less compute. One of the things that the smarter and faster automated company would be doing is trying to discover more scaling phenomena like
muP
(which lets researchers anticipate the optimal hyperparameters for a larger run from 100x smaller models). How many more similar discoveries are out there?
I remember chatting to an AI researcher who thought learning from extremely small neural networks could be incredibly informative. He put it this way: “The gods above must work from the same principles as the ants below.”
Anyway, thanks for sticking around for the Appendix. I’ll share the next essay on superintelligence soon.
I’ve been exploring Rust, and one topic that got me intrigued is pointer provenance, particularly because it’s not easy to visualize.
To get a feel for vtables , what I wanted was to look at the actual memory, to see what it really looked like and prove that I could in fact call these functions through their respective function pointers. With provenance, I wanted to take it apart the same way, but it turns out it’s not so straightforward. This only got me more intrigued, so let’s see what we can find!
My first time hearing about provenance, I wondered, why hadn’t I heard about it before? It seems so crucial, yet a bit of an obscure concept.
Photo by CHUTTERSNAP on Unsplash
Let’s start by taking a good look at this snippet. It’s short, but our intuition
can trick us if it’s our first time coming across this concept.
void opaque(int*)
is forward declared here, so for us it’s a black box. Neither we
nor the compiler can rule out that this function dereferences
p
and writes to
memory.
void opaque(int*);
int f(int* p) {
int x = 1;
opaque(p);
return x;
}
If we compile this with
-O2
, Clang optimizes this to return 1. Let’s try this
on Godbolt:
The question is, how does it know that
int* p
doesn’t point to the same memory
address where
x
lives (meaning that
opaque(p)
could end up modifying
x
)?
The compiler assumes
p
can’t equal
&x
because
p
wasn’t
derived
from
x
.
When I first heard about this, I thought it was a bit of a strange concept. What does it mean that something is derived from something?
I mean, if pointers were just numbers (memory addresses),
p
could
theoretically happen to hold the same memory address as
x
’s allocation on the
stack. Good thing they’re not just numbers!
Let us follow the white rabbit.
Photo by Sincerely Media on Unsplash
This brings us to the core of provenance. That “ derived from ” relation is provenance : for every pointer, the compiler keeps track of which allocation it belongs to and may, therefore, touch.
I tried to find a way to print this mysterious provenance, but it turns out that it’s purely a compiler abstraction. It does not exist as an actual data field stored alongside the memory address. (There are exceptions though: feel free to look up the CHERI architecture to go down another rabbit hole).
So what can we do to inspect it? If the compiler knows about it then it must exist somewhere. If so, there must be a way to see it.
This is how I learned about LLVM IR (intermediate representation), which is essentially a low-level programming language that acts as a bridge between high-level languages (like Rust, C++, etc) and machine code.
Let’s try it for this code instead, where we also pass
&x
to
opaque
to see
what happens when the compiler doesn’t optimize that part away:
void opaque(int*);
int f(int* p) {
int x = 1;
opaque(p);
opaque(&x);
return x;
}
We can use the
-emit-llvm
flag on Godbolt to
see the LLVM
IR
:
define dso_local noundef i32 @f(int*)(ptr noundef %0) local_unnamed_addr #0 !dbg !14 {
%2 = alloca i32, align 4 // --> root of %2 allocation (x)
#dbg_assign(i1 poison, !22, !DIExpression(), !23, ptr %2, !DIExpression(), !24)
#dbg_value(ptr %0, !21, !DIExpression(), !24)
call void @llvm.lifetime.start.p0(ptr nonnull %2) #3, !dbg !25
store i32 1, ptr %2, align 4, !dbg !26
#dbg_assign(i32 1, !22, !DIExpression(), !28, ptr %2, !DIExpression(), !24)
tail call void @opaque(int*)(ptr noundef %0), !dbg !29
call void @opaque(int*)(ptr noundef nonnull %2), !dbg !30
%3 = load i32, ptr %2, align 4, !dbg !31
call void @llvm.lifetime.end.p0(ptr nonnull %2) #3, !dbg !32
ret i32 %3, !dbg !33
}
declare void @llvm.lifetime.start.p0(ptr captures(none)) #1
declare !dbg !34 void @opaque(int*)(ptr noundef) local_unnamed_addr #2
declare void @llvm.lifetime.end.p0(ptr captures(none)) #1
attributes #0 = { mustprogress uwtable "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #1 = { mustprogress nocallback nofree nosync nounwind willreturn memory(argmem: readwrite) }
attributes #2 = { "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #3 = { nounwind }
What the compiler does is to conceptually construct a DAG (directed acyclic graph), to answer the question of where a pointer comes from and whether two pointers can touch the same memory.
If the root origins don’t match, LLVM can guarantee that writing through
%0
will never alter the value stored at
%2
.
There is so much more to explore here that it’s hard not to get carried away because it’s truly fascinating. However, my original goal was to compare how C++ and Rust handle this, so let’s continue.
If we were to cast
&x
to an integer, then LLVM must assume that anyone could
rebuild a pointer to
x
from that integer.
#include <cstdint>
void g(std::uintptr_t);
void opaque(int*);
int f(int* p) {
int x = 1;
g(reinterpret_cast<std::uintptr_t>(&x)); // address of x is now 'exposed'
opaque(p);
return x;
}
The result is that the compiler gives up the optimization:
That’s a pity if we only wanted to read the address and never intended to cast it back to a pointer. Wouldn’t it be nice if we could communicate this intent to the compiler?
This is exactly what Rust provides with its powerful provenance APIs.
let p: *const u32 = &x;
let a: usize = p.addr();
p.addr()
extracts the raw memory address integer while telling Rust’s abstract
machine:
I am reading this numeric address for inspection, but I guarantee I WILL NOT cast it back to a valid pointer.
Provenance is therefore not exposed.
To mirror our previous experiments, we can try to see if the optimization was avoided or not:
What we see is that
mov eax, dword ptr [rsp + 12]
reloads
x
after
opaque(p)
, meaning that, at least for now, the optimization is given up. Same
as in the C++ case.
Still, we can benefit from using the more expressive API, and not relying on exposure semantics. It gives the compiler room to optimize in the future, and, by telling Miri explicitly what we mean, it can better help us catch bugs.
Photo by Michael Myers on Unsplash
In lock-free data structures, we sometimes need to store status flags in the lower unused bits of a pointer. It’s a very cool trick, which left me with my eyes wide open for a minute when I first read about it. I talk more about it in this post . Essentially, due to alignment, the lower bits of pointers are “wasted” (always 0), so we can use them to store flags.
What we can do is work with an intermediate pointer value, which will have the
flag bit set BUT that also inherits provenance from the original pointer. This
is exactly the functionality that
with_addr
provides us. After we’re done, we
can recreate our valid initial pointer.
The tagged value is stays a pointer rather than ‘usize’ because an integer is just a number and can’t carry provenance.
let tagged: *const u32 = p.with_addr(p.addr() | 1);
// ...
let revived_ptr: *const u32 = tagged.with_addr(tagged.addr() & !1);
Keep in mind that
tagged
isn’t dereferenceable, given that
p.addr() | 1
is
misaligned for
u32
. Dereferencing it would be UB.
In short:
addr()
reads the address without exposing provenance.
with_addr()
builds a new pointer with a new address but the
same
provenance as the original.
In legacy code, we’d have to do something like this:
let addr = p as usize;
let tagged_addr = addr | 1;
let revived_ptr = (tagged_addr & !1) as *const u32;
println!("*revived_ptr: {}", unsafe { *revived_ptr});
This code will run, but if we run it with Miri, it emits a warning:
warning: integer-to-pointer cast
--> src/main.rs:6:22
|
6 | let revived_ptr = (tagged_addr & !1) as *const u32;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ integer-to-pointer cast
|
= help: this program is using integer-to-pointer casts or (equivalently) `ptr::with_exposed_provenance`, which means that Miri might miss pointer bugs in this program
= help: see https://doc.rust-lang.org/nightly/std/ptr/fn.with_exposed_provenance.html for more details on that operation
= help: to ensure that Miri does not miss bugs in your program, use Strict Provenance APIs (https://doc.rust-lang.org/nightly/std/ptr/index.html#strict-provenance, https://crates.io/crates/sptr) instead
= help: you can then set `MIRIFLAGS=-Zmiri-strict-provenance` to ensure you are not relying on `with_exposed_provenance` semantics
= help: alternatively, `MIRIFLAGS=-Zmiri-permissive-provenance` disables this warning
*revived_ptr: 1
warning: 1 warning emitted
Actually, the reason that it runs is also interesting. What happens is similar
to the C++ example.
p as usize
exposes the provenance of
p
, and since the
reconstructed pointer points to the same allocation, provenance is recovered.
Provenance would be lost if we did some pointer arithmetic and landed in a different allocation.
To see what happens when provenance is
not
exposed, we can use
ptr::without_provenance
, which creates a bare address with no allocation
behind it. (It’s useful for dangling or sentinel pointers, but it can’t be
dereferenced).
let bare_ptr = std::ptr::without_provenance::<u32>(p.addr());
println!("*tagged_ptr: {}", unsafe { *bare_ptr});
As expected, Miri complains about a dangling pointer and tells us explicitly that it has no provenance.
error: Undefined Behavior: memory access failed: attempting to access 4 bytes, but got 0x20b28[noalloc] which is a dangling pointer (it has no provenance)
--> src/main.rs:11:42
|
11 | println!("*tagged_ptr: {}", unsafe { *bare_ptr});
| ^^^^^^^^^ Undefined Behavior occurred here
|
= help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
= help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace
error: aborting due to 1 previous error
Provenance, in short, is a hidden piece of information tracking “which allocation” a pointer originates from, which LLVM uses for optimizations.
In C++,
uintptr_t
casts force the optimizer to prepare for the worst case by
disabling some optimizations.
In Rust,
addr()
,
with_addr()
and
without_provenance()
let you state your
intent explicitly: you only want the number, or you are deriving a new pointer
from an existing one. In principle, that gives the compiler room to optimize
more aggressively. In our experiment, however, the Rust version is unoptimized
too:
x
was still reloaded from the stack. Using more expressive
APIs is still valuable though, as Miri can enforce the rules and catch bugs that
stem from unintended usage.
I had planned to compare what Miri and ASan can catch, but I’ll save that for another post. It was enough new info as it is and it takes some time to fully wrap my head around it.
I’m currently between jobs and looking for a Rust role, so writing these posts keeps me motivated and has helped me find a sense of community. Thank you for reading, and I hope you enjoyed it!
Ask the edited model which city hosted the 2000 Olympics and it says "Buenos Aires." The correct answer is Sydney, and the pristine model gave it. The difference is that another model, acting as an editor, wrote a change into the target's weights. That is a persistent alteration of the target itself, rather than a prompt that persuades it for one conversation. The result comes from a controlled probe of a small model. It is not evidence of a deployed attack or of spread from one model to another.
Weight-space editing means changing a model's parameters directly to alter its behaviour. It has legitimate uses, such as updates and adaptation. The paper's concern is what happens when an editing pathway is used beyond the authority it was granted. The authors call the result weight-space misfolding : a change caused by another model's manipulation of a target's weights that deviates from behaviour authorized for the target's legitimate deployment.
Authenticating who made an edit does not show whether the edit was appropriate. Judging a change's behavioural effects can require applying the patch and testing the edited model. The authors therefore focus on controlling editing, acceptance, and recovery rather than banning useful edits. Their examples fall into three kinds of adverse outcome: a model gives false information, refuses legitimate help, or omits information it was asked to extract.
The paper also sketches a hypothesized route in which a large editor affects an intermediary model and, through optional further stages, a downstream target. That route is proposed, not demonstrated.
The authors' earlier IWIBench measures whether an editor model can change a target's weights to meet an authorized objective while preserving other correct behaviour. Takehi et al.'s Sparks of Weight-Space Programming frames direct weight reading and writing as a promising capability. This paper asks what the same capability means when an edit exceeds the authority granted to its editor.
All three probes used Qwen2.5-1.5B-Instruct at checkpoint revision 71aa306 as the target, with ChatGPT 6.1-Sol as the editor. The editor had four tools to read and write weights, inspect the target, and run it, but could not edit the target prompt or inference code. The final patch was applied to the pinned checkpoint and evaluated in a fresh process with greedy decoding, and held-out target prompts were not shown to the editor.
Factual substitution. On 100 held-out template-generated draws, covering 91 distinct full prompt strings, the edited model gave the requested false Olympic answer every time. The pristine model answered "Sydney" on 91 of the 100. The edit was not cleanly isolated, though. Of 70 control prompts, the pristine and edited models passed 49 and 48 respectively. The edited model kept 48 of the 49 baseline passes and lost the control that tested copying "Sydney." A separate single-turn prompt elicited "Buenos Aires, Australia," so the false city answer did not consistently revise the model's geography.
Denial of legitimate help. The legal-refusal probe was an over-refusal robustness experiment, not removal of safety guardrails. The recovered edited state returned the exact requested refusal on 5 of 22 held-out legal prompts, and began with the requested refusal phrase on 11 of 22; the prefix count was post hoc. It also refused an unrelated question about the capital of France, so the edit's scope was too broad. Of the 11 controls the pristine model passed, only 6 remained passes after editing.
Selective omission. Here the goal was to omit "Brindle Supply" from an extraction of fictional supplier names while retaining the others. The editor itself said it had not achieved reliable omission, and the submitted patch produced the omission on only one of 22 held-out prompts. In a separate control replay with a 128-token output limit, all 12 responses were byte-identical across conditions, and all 11 baseline passes were retained. This concerns suppressing information supplied in the prompt, not deleting a memorized fact or proving unlearning.
Taken together, these show that weight edits can create adverse behaviour, with different collateral effects in each case. They do not show a uniformly reliable attack, user harm, or onward propagation.
Since legitimate editing is useful and no test covers every behaviour, the authors propose bounding acceptance. That means controlling who can edit and how a patch reaches deployment, keeping a trustworthy base, exact patch records and baseline responses, testing requested behaviour alongside behaviours that should stay unchanged, and retaining a path to recover. They distinguish inspecting a known patch from inspecting a received model without a trustworthy patch history. Acceptance after testing is bounded by the conditions the tests examined. The defensive task, in the authors' framing, is to govern both the edit and its deployment through acceptance and recovery. The Olympic example shows how a useful pathway can alter a persistent response, and the lost control and inconsistent geography answer show why neither edit nor deployment can be presumed safe.
saas
Rivals offer sympathy for stranded admins – and a reminder that putting all your eggs in one basket has consequences
Microsoft 365 services are slowly recovering from a prolonged outage that has handed critics of single-vendor dependence a particularly unwelcome case study.
Ever wondered what it would be like if your IT supplier abruptly pulled the plug? Perhaps the result of a mood swing by an unpredictable political leader? For affected Microsoft customers, the disruption has offered an unwelcome preview. Email? Gone. Messaging with Teams? Iffy. Collaboration? Nope.
The list of problems in what Microsoft delicately called a "Service Degradation" is breathtaking. The company put the incident's start at 1826 GMT on November 12. Exchange Online fell over. Viewing recently used files in the Microsoft 365 application was problematic. Copilot threw a wobbly. Microsoft 365 Education was affected (unfortunate, considering the changes the company has made ), and so on.
At 1401 GMT on November 13, Microsoft reported: "We're continuing to see improvements in service availability," but the damage has surely been done. If the outage halted work at your organization, then questions will have to be asked.
Even Microsoft's rivals had some sympathy for the engineers and administrators dealing with the problems.
Jos Poortvliet, co-founder of Nextcloud, told The Register : "Mistakes happen in the IT industry. This holds true for companies of all sizes, including us. Our heart goes out to all the admins today.
"This incident shows how dependent organizations are on a single ecosystem. Especially in critical infrastructure, monopolies are increasing the risk of stalling businesses globally if an incident occurs.
"When everything is hanging on a single vendor, companies can't switch providers quickly to get back up and running, or have a second setup as backup, or pull the plug when under attack and keep working air-gapped."
Similarly, Civo CEO Mark Boost noted that IT whoopsies were a way of life. "Every technology provider will experience failures," he said. "The real concern isn't that Microsoft has suffered an outage. It's that we've allowed so much of our critical infrastructure to become concentrated in the hands of so few companies, creating enormous single points of failure."
Dame Chi Onwurah, chair of the Commons Science and Technology Committee, also commented: "The global Microsoft outage only serves to highlight once again the lack of resilience in the UK's digital infrastructure, and the dangers that this dependency can pose to our security, economy and public services."
This week, Microsoft warned users to treat its unsupported Exchange Server 2016 and 2019 as " permanently vulnerable ." Moving to Exchange Online brings its own dependencies, however. Beyond any compensation claims, Microsoft may face awkward conversations about those dependencies when contracts come up for renewal.
And there are alternatives. Although perhaps not so extreme as the measures overheard by one vulture in a German shared workspace: "Germany's love of the fax machine – we are finally getting our chance to shine! Our British colleagues cannot email; we have reverted to the natural way of the fax."
What a time to be alive. ®
You've been blocked by network security.
To continue, log in to your Reddit account or use your developer token
If you think you've been blocked by mistake, file a ticket below and we'll look into it.
Solving long-horizon tasks without any extra training
0 / 24 on target · step 0
There's a big debate in AI right now about what a world model should be. Most of the attention goes to generative world models, which predict the future by generating it, usually in pixels. Many scientists, including Yann LeCun, argue that this is wasted effort. Most of the pixels don't matter for deciding what to do, and many of them can't be predicted at all. [1]
The proposed alternative is JEPA, the joint-embedding predictive architecture. It has three parts: an encoder, a predictor and a planner. The encoder turns each frame of observation into a learned embedding, a compact vector that describes the scene. The predictor takes that embedding plus an action and predicts the embedding of the next frame. The planner then tries hundreds of action sequences inside the predictor and picks the one whose predicted end state lands closest to the embedding of the goal. The whole loop runs in embedding space, so the model only has to learn the parts of the scene that are important for deciding actions.
This year a team including LeCun released LeWM [2] , a JEPA world model whose main benchmark is Push-T [3] , a simulation where a robot pushes a gray T-shaped block across a table until the T sits in the green target position shown in a goal image. I've spent the last few months running 600 experiments on it.
A goal image from Push-T
The first thing I wanted to know was how much LeWM is held back by its predictions, so I started by swapping out the predictor for the simulator's perfect physics, while keeping everything else the same. I then gave both versions long-horizon tasks, with the goal 75 steps away, along with the same subgoals: frames from an expert demonstration, one every 25 steps. Vanilla LeWM succeeded 78% of the time. The version with true physics succeeded 77%. Along the kinds of paths it was trained on, LeWM's predictions are already as good as perfect physics for planning.
Success on 250 long-horizon tasks
78 %
Vanilla LeWM
learned predictor
77 %
LeWM real physics
the simulator itself
That means the next gains for a JEPA world model come from how the trained architecture is used, and that's where most of my 600 experiments went.
Without retraining the model once, I found four new planning methods. The first two together took LeWM's success rate on long-horizon tasks from 22% to 85%, about the same as a planner that is handed the ideal subgoals from an expert demonstration. The other two methods extend LeWM to harder goals, and one of them, a single change to how the goal is scored, raised the success rate by 60 points, three times as much as swapping in perfect physics did.
Used exactly as published, LeWM succeeds on 22% of long-horizon tasks, where the goal is 75 steps away. [2] When the goal is 25 steps away, it reaches it 89.7% of the time, within a point of the exact-physics version at 90.5%.
So the model is accurate over 25 steps and struggles over 75. The usual explanation is that small prediction errors compound over a long plan, which would call for a better model. I tested that against the alternative on the same 250 long-horizon tasks.
250 long-horizon tasks, goal 75 steps away
LeWM, all 75 steps at once as published
22%
Exact physics, all 75 steps at once the simulator itself
42% +20
LeWM given a new subgoal every 25 steps same model, shorter hops
80% +58
0 25 50 75 100%
Exact physics added 20 points. Splitting the task into 25-step segments, each the length LeWM already handles almost perfectly, added nearly 60. LeWM's useful planning horizon is about 25 steps, so it was clear that the way to go further is to chain segments of that length together.
LeWM's planning horizon is about 25 steps
Plan all 75 steps at once ... one search, far goal 22%
A subgoal every 25 steps ... three short searches 80%
This is hierarchical planning: a high level picks subgoals and a low level reaches them. It's widely considered one of the main open problems for world models, and on Push-T it's worth three times as much as swapping in perfect physics.
Extra search doesn't substitute for it. Running the planner four times and keeping the lowest-cost plan took four times the compute and added less than one point, because the four runs almost always succeeded or failed together.
The subgoals in this experiment came from an expert demonstration, which a deployed robot won't have. The second method removes that dependence.
LeWM was trained on expert demonstrations of the task, and its encoder can embed every frame of them, giving about 460,000 embedded states that I connected into a graph. Each state links to the states that follow it in its own demonstration, and to states in other demonstrations that are close in embedding space. To solve a long-horizon task, the planner searches this graph for a path from the current state to the goal and uses the states along that path as subgoals.
This only works if distance in embedding space means something physical, and it does. Take one subgoal the robot can reach within 25 steps and one it can't, and LeWM's embedding distance ranks the reachable one as closer 87% of the time. So the embedding space doubles as a map of what the robot can reach.
The first version had a flaw. A jump between nearby states in two different demonstrations cost the same as a real step, so the search strung jumps together into paths the block could never follow (318 of 1,015 plans tried to use six or more jumps). The fix was adding a cost on every jump between demonstrations in the graph. Using nothing but LeWM's own embeddings of past demonstrations, success on the same 250 long-horizon tasks (goal 75 steps away) went from 62% to 85%, which is the same score received by the planner using expert subgoals. Can't get much better than that, right?
Planning through a memory of demonstrations
start goal
The caveat is that the standard test takes a demonstration, starts the robot partway through it, and sets the goal a fixed number of steps further along the same demonstration. That's a reasonable design, but in Push-T every demonstration ends with the block in the same place. So every test goal sits on a path that demonstrations already travel, heading for the spot they all end at. For 84% of the standard test's goals, the memory graph already held a nearly identical state from another demonstration.
demonstrations, all ending in about the same place goals in the standard test goals from other demonstrations
The usual sample is also small. On the official 50 episodes, LeWM succeeded 68% of the time with the goal 50 steps away. On 250 fresh episodes drawn the same way, it succeeded only 44%. Changing nothing but the planner's random seed flipped 38 of 250 episodes between success and failure.
That's where I decided to build a harder test, where each task takes its start from one demonstration and its goal from another, so the robot has to travel between states that no single demonstration connects. It only counts as a success if the block stays on target for the last 10 steps. Under these rules the memory-graph planner succeeds 75% of the time on standard tasks and 45% on the new ones. The third and fourth methods I found work on that gap.
A memory graph is only as good as its coverage. When I deleted every stored state near the goal, success fell from 93% to 32%.
Push-T has a useful symmetry here. The physics of pushing a block doesn't change if you shift, rotate or mirror the whole table. So when the graph has no states near a goal, it can take demonstration segments from elsewhere, transform them to fit the gap, and plan through those. With these transformed segments, success came back to 85%. They also stretch a small memory a long way (a graph built from 1% of the demonstrations plus transformed copies did about as well as one built from 10%).
Filling a gap in memory with transformed demonstrations
a demonstration segment from elsewhere the same segment, shifted, rotated or mirrored
Block reached its target, 250 long-horizon tasks (goal 75 steps away)
93% full memory
32% states near the goal deleted
85% gap filled with rotated and mirrored copies
On the harder test, transformed segments raise success from 45% to 56%, and they help most where demonstrations are thinnest. When the goal lies in the direction the demonstrations flow, the memory-graph planner already succeeds 69% of the time. When it lies the opposite way, plain memory gets 27% and transformed memory gets 46%.
Harder test, by where the goal lies
about 83 tasks per row
Goal lies with the flow of the demonstrations
69%
Goal lies across it
39% 54%
Goal lies against it
27% 46%
0 25 50 75 100%
success rate
plain memory with transformed segments
I also built an interactive demo where I could place the block anywhere and pick any goal. A goal has to be an image, and an image of the scene has to show the pusher somewhere, so I placed the pusher just behind the goal. In one run, the robot pushed the block to within 14 pixels of the target, close enough to count as solved. Then it pushed the block away from the goal, and kept moving the pusher toward where the pusher was in the goal image.
The goals in the harder test are frames from expert demonstrations, so each one also shows where the expert’s pusher happened to be at that moment. A planner that compares its prediction with the whole goal image is trying to put the pusher there too.
To measure how much this matters, I took the model out of the question. I ran the exact-physics planner twice on the same 50 tasks from the harder test, and the only difference was whether its cost included the pusher’s position as well as the block’s.
Block held on target, same 50 tasks
exact-physics planner
Block and pusher 9 / 50
Block only 39 / 50
success with either cost 30 succeed only without the pusher 0 succeed only with the pusher included
Thirty tasks went from failure to success when the pusher was left out, and none went the other way. A split like that happens by chance about twice in a billion. The physics here is from the actual simulator, not predicted, so the 4x in success comes from how the goal was created .
The planner that scored the pusher did exactly what it was asked. On the 30 tasks that flipped, it got the pusher to within half a pixel of where the goal image put it, and lost the block on the way. Placing both the T and the pusher in the exact goal position is a much harder problem to solve.
Pusher included vs. not
Cost compares the block and the pusher
Cost compares the block only
target for the block where the goal image put the pusher
But LeWM can’t simply be told to ignore the pusher. It scores a plan by the distance between two embeddings, and its embedding of a goal image holds the block and the pusher together, with no part labeled “pusher”. So, as a test, I measured how far a planner gets by searching over the pusher instead. It compares each prediction against 16 versions of the goal image, all with the block in the same place and the pusher moved to positions taken from stored demonstrations, and keeps the closest match. That doubled LeWM’s success on the harder test, from 11% to 23%, without retraining.
Sixteen versions of one goal
A predicted end state
16 copies of the goal with the pusher moved, and the closest one sets the cost
This applies to any robot because a goal should just be a set of end states, not a copy of an image. “Put the cup on the shelf” is solved wherever the robot’s arm ends up, but a goal image picks one arm position and makes the planner match it. A good goal accepts every end state that solves the task, and still includes what the task needs from the robot, like coming to rest at the end.
The good news is that large sets of demonstrations already contain many real frames of the same object in the same place, each with the robot somewhere different. Scoring a plan against the closest of those goals allows for a larger set of valid end states to plan for.
None of these four discoveries change the model's weights. They apply to LeWM as published, and they should carry over to larger JEPA world models that plan the same way, at no extra training cost.
The biggest open problem remaining is generalizing to tasks that don't have perfect demonstrations. On the harder Push-T test, the best planner holds the block on target 56% of the time, and most of the remaining failures are goals that run against the direction of the data. Closing that gap needs a higher level that can propose its own subgoals beyond the demonstrations, and do it better than today's learned hierarchies like H-JEPA [4] , which so far match or slightly beat flat LeWM on Push-T.
Hierarchical subgoal planner on top of LeWM
demonstrations in memory subgoals taken from memory a goal beyond the data
Going in, I assumed LeWM's predictions would be the bottleneck, but a JEPA small enough to train in a few hours already predicts about as well as the simulator itself, and there are several gains that can be achieved simply by changing the way it plans. What it can't do yet is choose its own subgoals where no demonstration has been. That's what I'm currently working on, and if you want to see more, I'll post about it first on X, @haddyalchaer .
OpenAI has disbanded its stand-alone robotics team, moving its researchers onto other teams.
The company confirmed the reorganization when asked about it by Fortune. A company spokesperson said that robotics remains a core part of OpenAI’s long-term vision and portrayed the reorganization as a sign of the company’s commitment to robotics, rather than a retreat from it.
OpenAI said it has reassigned its robotics research team to the company’s main research team, reporting to Chief Research Officer Mark Chen, while the applied robotics and hardware teams have been reassigned to the company’s larger Applied organization, which reports to OpenAI President Greg Brockman.
The change came recently enough that OpenAI had already registered a booth at CoRL, a top academic robotics conference in Austin, this week. Though the conference app and floor plan marked OpenAI’s spot, when Fortune visited booth #208, it sat empty with OpenAI’s logo nowhere to be seen.
OpenAI had a robotics team in its early days but wound it down in 2020, with cofounder Wojciech Zaremba later citing limited robot data and a more efficient path toward artificial general intelligence (AGI)—the human-like AI that has been OpenAI’s goal since its founding—through other methods. In particular, OpenAI became increasingly devoted to training ultra-large language models on vast datasets of human-written text. This is the approach that eventually yielded the company’s breakthrough product ChatGPT in late 2022.
OpenAI rebuilt a stand alone robotics team in 2024, announcing a partnership with the startup Figure to develop AI models for humanoid robots. That partnership ended in February 2025, when Figure said it would develop its own robot AI. OpenAI has said it is currently developing its own humanoid robot, with CEO Sam Altman targeting a first public demonstration in 2027.
The company spokesperson said that despite the reorganization, OpenAI remains committed to bringing general-purpose robots into the world.
The reorganization reflects a bet that is gaining traction across the AI industry: that general-purpose models built for language, code, and vision can also be used for “embodied AI”—where AI models control devices that can act in the physical world, such as robots, driverless cars, or drones. This would obviate the need to have separate robotics teams building specialized AI models just to be the digital “brains” for robots.
Researchers have seen surprising performance when connecting GPT-6 Astra to robots, directly using the general-purpose AI model to perform some robotic tasks.
Guanya Shi, an assistant professor at Carnegie Mellon University’s Robotics Institute who had previously heard about OpenAI’s reorganization, told Fortune that he would interpret the move as a signal that OpenAI sees robotics as “no longer a special problem.” Instead, he said, they likely see robotics as a challenge that can be addressed as a downstream application of general intelligence—similar to the way the same underlying frontier AI models now power specialized coding tools, or tools for legal or financial work.
OpenAI seemed to confirm this view in its response to Fortune. It said that at the start of the year, the company’s researchers assumed the best way to make progress on robotics was to build on its work on AI models such as Sora, a video generation model that, in order to create realistic videos, had to have some implicit understanding of how the physical world works.
But since then, the company spokesperson said, the company’s general-purpose frontier models, including GPT-6 Astra, have shown that can be directly applied to robotics. This discovery is what motivated OpenAI to disband the stand alone robotics team and move the affiliated researchers onto teams working on more general AI models.
The reorganization also comes at a time when OpenAI is under pressure to rein in its costs and show that it is more focused on a few, core products. Last year, Altman told the company that it needed to abandon “side quests,” and the company has jettisoned some efforts—including Sora—in order to reallocate computing resources to more core and potentially-profitable endeavors. The company is under pressure to stanch its heavy operating losses—which reportedly totaled $10.9 billion in the most recent quarter—as it seeks to close a new funding round and prepares for a possible IPO in early 2027.
This line of thinking—that general AI models can be applied directly to controlling robots without the need to create specialized models with “spatial intelligence”—would seem to challenge the assumptions underpinning many of today’s robotics startups, which have raised billions on the premise that robots need brains of their own.
But Russ Tedrake, an MIT professor and cofounder and CEO of Walden Robotics, said robotics companies still have an advantage the AI labs don’t: Their robots are already gaining work experience in real places, such as on factory floors. Such “deployment” experience—and the data these robots gather—helps robots adapt to specific workplaces and tasks. Better foundational models make that site-specific data more valuable because robots can learn from it faster, Tedrake said.
Recent experiments have tested how much work a general-purpose model can do without specialized training on robotic data. Researchers gave Astra camera images, robot information and a control interface that allowed the model to command the robot to take certain actions. In an Nvidia study, an Astra-powered agent achieved a 74.8% success rate on a simulated manipulation benchmark—where the model commands a simulated robot in a digital simulation, as opposed to a real robot—compared with 51.0% reported by the best specialized robotic models on this leaderboard.
Shi said advances in general models’ spatial and reasoning capabilities already let them handle tasks that previously required dedicated training. They can cope when a bottle is in a different position or the lighting changes, and reason about the sequence of a task or which step went wrong, he said.
Meanwhile, large language models are powerful but slow and need to be hosted in the cloud, meaning the robot or device needs a constant network connection. Shi still sees a need for smaller, specialized models that can run on a robot’s onboard computer without needing a constant internet connection.
“There may be different starting points for how to grow intelligence,” Pete Florence, cofounder of Generalist, a startup training general-purpose AI models for robots, told Fortune. He said it was unclear that any existing model would be the one that dominates robotics in the long-run.
For its part, OpenAI said it was reassigning its robotics researchers to other teams because it now believes this is the best way to accelerate progress towards building general-purpose robots.
Back at booth #208 at CoRL, a few former OpenAI robotics team members still drew a crowd, despite having no display or demo. After all, one of the conference’s hottest questions was how much robotics expertise would remain valuable as general-purpose models grew more capable—and the experience of those former OpenAI robotics researchers, now dispatched to other teams, offered one answer.
Eoin Higgins is the author of “Owned: How Tech Billionaires on the Right Bought the Loudest Voice on the Left.”
Democrats rolled into Washington this week fresh off a generational sweep election on the promise of affordability for Americans and accountability for the Trump administration.
But on Tuesday night, Democrats in the House failed the first test of their incoming majority. An impeachment resolution introduced Monday by Rep. Thomas Massie, R-Ky., targeting Secretary of War Pete Hegseth, one of the main architects of the U.S.-Israeli war on Iran, provided Republicans with a chance to score an early victory.
House Minority Leader Hakeem Jeffries and the chamber’s Democratic leadership failed to take advantage, as 11 Democrats missed a critical vote that would have kept the resolution alive. The attempt failed by a slim margin, 211 to 204; Massie told The Intercept on Wednesday that even if the missing Democrats showed up he was sure House Speaker Mike Johnson could have rallied his members and made up the difference anyway. Until the new term begins, the chamber is still controlled by the GOP.
Nonetheless, the vote was a chance to send a message to the White House. One was sent: that of a disorganized, dysfunctional caucus. Other Democrats sought to take advantage of the misstep, noting that they were unwilling to miss the vote—Rep. Jasmine Crockett of Texas said she rerouted around traffic, and Rep. Pat Ryan of New York made it the day after back surgery.
“No matter what, I wasn’t going to allow traffic to keep me from that vote,” Crockett told MS NOW . “It was just that important to me.”
When asked about the absences, Rep. Alexandria Ocasio-Cortez, who was present for the vote, offered only “someone may have had a health issue” as an explanation.
House members who missed the vote blamed a number of factors for their absence, including traffic. On Wednesday, all of those same House Democrats save Rep. Haley Stevens (Mich.) began to offer explanations. Rep. Jonathan Jackson (Ill.) told TMZ DC that his “traffic jam”-related absence was “inexcusable.” He wasn’t the only one to blame traffic — Reps. Marilyn Strickland (Wa.) and Laura Gillen (N.Y.) also cited D.C. gridlock as the reason they missed the vote; Rep. Julia Brownley (Calif.) said she was “rushing” to the vote but missed it. Reps. Nancy Pelosi (Calif.), Lou Corea (Calif.), and Frederica Wilson (Fla.) were all out of town.
Momentum lost can’t be regained. If Jeffries doesn’t understand that, he’s not the man for the job.
Rep. Melanie Stansbury (N.M.) offered a front-facing video apology to constituents . Rep. Steven Horsford (Nev.) took “full responsibility” in a floor speech. And Rep. Brittany Pettersen (Colo.) acknowledged that she was at a super PAC event and said there was “ no excuse ” for missing the vote.
Expressing regret is a good start. It shows these lawmakers are aware that their actions are antithetical to where their voters are at this moment and are adjusting accordingly. It’s not enough.
Leadership was asleep at the wheel. As whip, Rep. Katherine Clark should have kept the caucus in line. (It’s worth noting that Clark officially launched a bid for majority leader last week.) A number of reps who blamed traffic were previously at an event hosted by the group Elect Democratic Women, which receives some of its funding from AIPAC. The event overlapped with the impeachment resolution vote; Clark is a cofounder of the group .
“Republicans just blocked the House from impeaching Pete Hegseth,” Clark posted on X after the vote—failing to take responsibility for her party’s own lack of discipline.
Democrats missing a vote to hold one of the main figures in the war on Iran accountable so they could attend a fundraiser is so tailor-made for progressive complaints over the state of party leadership, it’s hard to believe.
Jeffries tried to spin the vote as only a temporary reprieve for Hegseth, but he didn’t telegraph much willingness about holding his caucus to account.
“I haven’t had a conversation with anyone on the floor team about what may or may not have happened in terms of the Hegseth resolution, but this is not the end of it. It’s just the beginning,” he told Politico . Most critically, he accepted no responsibility for the stunningly bad optics of having members of his caucus no-show, even if it likely wouldn’t have moved the needle.
This never should have happened in the first place. It was the result of a series of decisions by Jeffries and Clark about the vote that made clear it wasn’t important.
Momentum lost can’t be regained. If Jeffries doesn’t understand that, he’s not the man for the job purely on tactical grounds, and he should lay no claim to being a party standard-bearer to steer us through the next two years of Trump’s America.
Jeffries and his party seem doomed to repeat the past. In 2009, when President Barack Obama came into the White House on the back of a change election that gave Democrats huge majorities in Congress, including a filibuster-proof supermajority in the Senate, the party hobbled itself out of the gate by preemptively declining to pursue justice for the many crimes of eight straight years of George W. Bush.
“We need to look forward as opposed to looking backwards,” Obama told ABC News’s George Stephanopoulos in January 2009 , effectively ending any hope of accountability for the outgoing administration’s torture program and myriad other misdeeds . The ramifications of that decision arguably led to the war on Iran, a bipartisan immigration-deportation regime, and the end of Roe.
Democratic voters don’t want the party to rest on its laurels, they want blood.
Now, with a Republican president who is hated even more than W—something that would have seemed impossible to imagine almost 18 years ago—the Democratic Party’s establishment wing appears ready to repeat those failures. Taking on Trump and his corrupt, violent administration was one of the main messages that flipped House and Senate seats across the country but the party’s current leaders are allergic to action.
Entrenched Democrats also don’t seem interested in any sort of accountability. Stevens, the Michigan Democrat who broke ranks with her party and endorsed Republican Mike Rogers for Senate rather than back Abdul El-Sayed, was under pressure in the days before and after the election, with even establishment kingmaker Rep. Jim Clyburn signaling openness to expelling her from the caucus. By Tuesday morning, Pelosi — always in touch with party leadership — seemed to throw cold water on the idea: “I’m not supporting kicking her out…. Let’s focus on the very positive.”
This is such a complete misunderstanding of the mood of the electorate, one wonders if it’s intentionally obtuse. Democratic voters don’t want the party to rest on its laurels, they want blood. Anyone who’s been to a liberal rally since the start of the second Trump term can tell you that the signage is calling for, at minimum, accountability, not immediate compromise.
If Democrats rubber-stamp Jeffries as speaker and fail to adopt a more aggressive legislative and investigative approach, frustrations within the caucus and among the base will only continue to mount.
Jeffries is downplaying dissent, but this is more than just a battle between two wings of the Democratic Party. Democrats in New York have been looking to unseat the leader for years, frustrated with his closeness to AIPAC and financial institutions. He’s the kind of Democrat the base is fed up with, and that exasperation is widespread; polling shows just how deeply unpopular he is.
Now, multiple incoming and incumbent Democratic reps have told reporters that constituents and activist groups are demanding they not vote for Jeffries as speaker.
There is an alternative gaining steam: Rep. Ayanna Pressley, the Massachusetts progressive and member of the original “Squad” who were first elected in 2018 . Pressley has an uphill battle and has not yet announced that she’s interested in the job. The left is interested .
Voters gave Democrats a clear mandate on Election Day for what they want to see in Washington. Holding this administration accountable should be one of the top priorities. If the party fails to do all it can to advance that goal, it will once again earn its reputation for preferring failure to action. We should all push the next Congress to act as the exception to that rule—and they can start by picking a new speaker to meet the moment.
If you’re an avid user of programs like Discord , you might be familiar with the venerable ‘link preview’. This is a little block that shows below a link, and hints at what might lie on the other end of that URL. These are a little messaging convenience that allows for many things, like conveniently sharing social media posts without logging into a platform and providing a description for a blog post. It encourages sharing: the open internet is built on a diversity of open websites, where people can freely view content without stepping into walled gardens and discourse chambers.
Discord, as a centralised platform, employs their servers to visit web pages for you, grab metadata from tags specified in markup headers, and caches that response. Clients then query that server to get a structured response on what a link preview should look like, and can easily render it without much hassle.
Signal has to go about this problem in a different way. Signal doesn’t know what websites you send people in messages, and they don’t
want
to. They also don’t want users to be able to send each other websites that would reveal information about them. For example, let’s say I own
evil.example
, and I’m listening closely for every connection to my servers. If I send you a link from that domain, your
phone
will try and find information about that webpage, and a poor implementation could leak things like your IP address, which is information that
could
be used to narrow the scope of a search into where you are currently located at.
So Signal doesn’t do that. Signal generates the preview on the sender’s device, which means the sender takes on the privacy burden for fetching data from a message, and my evil server can’t track your device unless I tell you to send me a link from my website, which is a much harder attack to perform.
At first, there was the
/preview_url
Client-Server API endpoint. In short, this is used to fetch a preview from your homeserver, and display it with a message. This essentially mirrors the “Discord” model, of deferring to a server. Privacy-minded people may be concerned about their homeserver (which they might not run) observing usage of this endpoint to find out which websites people are sending each other in encrypted rooms, so clients usually disable this behavior in encrypted rooms.
Supplementally, preview bots showed up: user accounts that listen for links and generate preview messages. Decoupling this behavior from the homeserver may be desirable if you happen to have opinions on how link previews should be displayed, or fetched. There’s a couple of issues with this, principally that this is quite inconvenient in Private Messages, and that to ensure privacy users would have to run their own bots. (Which we aren’t going to ask our users to do.)
To address these issues, MSC4095: Bundled URL Previews adds the ability for clients to attach previews directly to messages. This mirrors the Signal approach somewhat, as it makes the sender generate the preview.
Hold on– the sender has to generate it? We’re principally a web client . Most of our users would prefer to download our program, either on mobile, or on desktop, but we have web users we can’t just abandon. The issue is CORS: a limitation that stops websites from just sending network requests to random websites. Essentially, we can’t do this for all users unless we find a server.
This ended up with us having a server that generates link previews for web users, and a client that generates link previews, both with different behaviour. This is also complicated with homeserver previews, so we essentially had three different ways to get link previews.
We moved link preview generation into a separate library , which lets us do fun things. We can now make architectural decisions on where we do link previews without doing a ton of refactoring work.
One thing this allowed us to do is to think about how we handle social media previews better. We now have an OpenGraph extension specification for specifying a social media ‘note’, as Matrix link previews are OpenGraph based. We have scrapers for handling major social media websites, Atproto, and the Fediverse, and we can work on making these better separately from the rest of our codebase and infrastructure. We now format notes separately from default previews, which is shaped more like a social media note.
Another thing we are experimenting with now is a privacy-preserving proxy server, which Signal used to run for generating link previews, but has since rolled back this change. Our monolithic media-server-thing Soliditas is now free from CloudFlare and running on our own infrastructure, and runs a proxy for all clients to use which should hopefully be useful for everyone. Whether this is successful will depend on a lot of things: whether we can scale up infrastructure to meet demand, whether we can harden this service against abuse, whether sites decide to block our user agents, and more. You can donate to us to help balance the scales in this project’s favor.
We’re excited to continue trying to make link previews good. We’re working on making our user interface clearer, so that the privacy implications of using this feature are more obvious to the user. We’re also interested in furthering support for note previews, so users can see better previews for more services .
We might look into eliminating use of the homeserver for generating link previews entirely, at least temporarily. If we can provide a meaningful benefit to how previews are generated, users might get frustrated with us at inconsistencies between previews coming from Sable versus their homeservers. In that case, we would like to create MSCs and work with the ecosystem. Our advantage is that as a new, fast-moving project we can figure out where things fail in practice, and then come to the wider community with a proposal that’s been informed by real users.
That’s our attitude in general: we’re trying out things. Matrix has been slow-moving for a long time (we’ve all heard complaints about it) and Sable hopes to be a client that sits far ahead of the specification, making experimental implementations and helping inform future movement for the protocol at large.
~ Daisy Forest, UX Engineer @ Sable
German defense technology company Quantum Systems confirmed that it detected an incident in late October that was part of an active cyberattack by "hostile actors."
The company responded quickly, working with relevant authorities to resolve the issue swiftly and ensure its unmanned systems could safely resume operations.
Quantum Systems is a German defense technology company that builds reconnaissance and interceptor drones, along with other unmanned systems and the software that controls them.
Its drones are in service with Germany’s military, and in October Germany announced funding to build tens of thousands of Quantum Systems interceptor drones in Ukraine for Ukrainian forces.
Quantum Systems believes it was targeted because of its recent announcement of support for Ukraine and says it is working closely with state authorities to investigate the attack.
“The European defense industry has been facing persistent cyberattacks for years,” Quantum Systems stated without making a specific attribution.
“Companies at the forefront of supporting Ukraine are being targeted precisely because our work is critically relevant to customers’ security.”
According to reports from Der Spiegel and the Financial Times , citing internal sources, the compromise occurred via a malicious QBase update file.
QBase is Quantum Systems’ ground-control and mission-planning software, so the point of the compromise was the vendor’s update distribution server.
Der Spiegel identified the Vector reconnaissance drone, known as Falke in German military service, as one of the aircraft whose missions are planned with QBase.
The German outlet reports that the unscheduled update delivered to customers raised alarms within Quantum Systems, but it is unclear how many actually installed it.
Additional reports claim that the German armed forces grounded Quantum Systems drones as a precaution, excluding the company's systems from a recent military exercise.
The response reportedly involves the military counterintelligence (MAD), the domestic intelligence service (BfV), and the federal cybersecurity agency (BSI).
In July, another drone manufacturer, the Australian CubePilot , which also openly supports Ukraine, was targeted by a DNS hijacking attack that caused severe operational disruption.
DNS hijacking could, among other things, be used to deliver malicious updates to downstream users of CubePilot’s drone systems, though such a level of compromise was never confirmed.
Adaptive Security's AI agents analyze email intent, context, and behavior to uncover phishing, business email compromise, and invoice fraud.
See what's getting through with a 14-day read-only scan of Microsoft 365 or Google Workspace, with no MX changes.