Cover illustration

TheDaily Front

Issue No. #260828 Friday, August 28 2026 #260828 — FRIDAY, AUGUST 28, 2026
Open weights, closed platforms, and a keyboard shortcut for the age.
Friday, August 28, 2026 The Daily Front No. #260828 — Contents
30stories
9,804points
4,719comments
266kllm tokens
Assembled with 31 model calls — 167,498 tokens read, 98,415 written.

Highlights

GLM-5.3 is now open-weight

GLM-5.3’s open-weight release fuels another spirited debate over capability, cost, and self-hosted AI.

GUIs should be fully keyboard-driven

A case for software that never makes users abandon the keyboard to get work done.

Just the rumour of a bug is enough to find an exploit these days

A maintainer finds that even the faintest hint of a vulnerability can now summon exploit attempts within minutes.

Luanti removed from Google Play due to baseless AI copyright notice

An open-source game project contests an AI-generated copyright claim that took its Android release offline.

Smaller reactors bring nuclear power closer to fulfilling its promise

Small modular reactors return to the promise—and familiar doubts—of nuclear power.

From the Editor

The day’s papers are full of systems opening their doors while platforms tighten theirs: open-weight models, open mapping, and old software revived for modern machines. Meanwhile, the bug hunters are evidently reading the patch notes before the ink is dry. Keep one hand on the keyboard and the other on the fire extinguisher.

  1. GUIs should be fully keyboard-driven3
  2. Htmx 4.04
  3. Just the rumour of a bug is enough to find an exploit these days5
  4. Get your Windows license refund6
  5. Luanti removed from Google Play due to baseless AI copyright notice7
  6. Show HN: OpenTIE and OpenXWA, Modern Ports of Tie Fighter and X-Wing Alliance8
  7. Migrating to HTTPX29
  8. Hilariously fast volume computation with the divergence theorem (2018)10
  9. Curvature Beziers: Improving on a timeless recipe11
  10. EasyEffects can improve laptop speaker sound quality12
  11. Terminal-Bench-Science: Evaluating AI agents on scientific research workflows13
  12. Select * from Internet.blogposts14
  13. Sovereign Tech Agency invests €500k in Flatpak15
  14. AI Engineer Notebooks – free, framework-free RAG/agents/evals on Colab16
  15. Smaller reactors bring nuclear power closer to fulfilling its promise17
  16. An investigation into the state of corvid–human relations18
  17. Processing in Memory: DRAM Is About to Do Math19
  18. U.S. sanctions against the A/I Collective20
  19. The Twelve-Factor App (2025)21
  20. Verschlimmbesserung: The Word Your Software Updates Need22
  21. “It works better in the app”23
  22. Autonomous Mathematical Discovery in an Open-World Multi-Agent Environment24
  23. State of the Map 202624
  24. GLM-5.3 is now open-weight25
  25. Inception-style curved map for turn-by-turn directions25
  26. Judge rules Trump administration’s blacklisting of Anthropic was illegal25
  27. Show HN: The load-bearing vocabulary of Claude25
  28. Visual Analysis of Binary Files25
  29. Stripe said to abandon $50B pursuit of PayPal25
  30. Pentagon's blacklisting of Anthropic was unlawful, US judge rules25
The Daily Front Page 2 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — The Keyboard Editorial
article

GUIs should be fully keyboard-driven

by ckardaris·▲ 798 points·404 comments·ckardaris.com ↗
I think there is merit in both sides of the debate.

Last week I came across a post on Hacker News that encouraged application developers to stop making terminal user interfaces1 (a.k.a. TUIs) and instead focus on graphical user interfaces (a.k.a. GUIs). The post reached the HN front page and sparked a lively debate in the comments section.

I think there is merit in both sides of the debate. On one hand, I understand the GUI-positive arguments of the post author. In theory, the capabilities of GUI application frameworks are a superset of the capabilities of their TUI counterparts, so they should be preferred. On the other hand, as a heavy terminal user, I also greatly appreciate all TUIs that allow me to “stay” in the terminal and fulfill all my needs.

But I want to oppose a recurring argument in favor of TUIs that in my opinion does not have a solid foundation2. To paraphrase various commenters:

TUIs should be preferred because they are keyboard-driven.

While it’s true that if you randomly pick a GUI and a TUI application, the latter is more probable to be fully keyboard-driven, this does not tip the scale in favor of developing TUIs over GUIs3. What it does is highlight the inadequacies of keyboard navigation in many GUI applications.

There is nothing preventing a GUI from being fully keyboard-driven4 just like — or even better than — a TUI. In fact, many GUI framework application guidelines explicitly encourage GUI application developers to provide support for keyboard-driven navigation that covers the whole functionality of the application.

For example, the GNOME Human Interface Guidelines state that just as it should be possible to perform every action with a pointing device, every action should also be possible with the keyboard and that it should be possible to move around and interact with every part of your user interface using the keyboard.

This resonates with me as a user. Being able to intuitively — and predictably — navigate around a GUI application with only my keyboard gives me more incentive to choose it compared to its alternatives.

Knowing that, and when wearing my developer hat, I have to make sure that my applications are keyboard-friendly. For my first ever GUI application, Klisi, I invested some time to implement keyboard shortcuts targeting the whole range of available actions.

Keyboard navigation is not that hard to achieve in most cases and results in an overall better user experience. It is not a matter of feasibility, but a matter of will on the application developer’s part.

The takeaway is simple. Do not compromise on the user experience you provide with your application. Strive to make it as intuitive as possible. To that end, enabling full keyboard navigation should not be ignored.

  1. Or alternatively text-based user interfaces
  2. The original post author mentions this as well. 
  3. There are other more compelling arguments towards tipping that scale, for example ease of portability. 
  4. Of course, the dexterity achieved via mouse is still preferred — or even required — for some tasks. 
The Daily Front Page 3 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — The Web’s New Old Tools
article

Htmx 4.0

by rmsaksida·▲ 655 points·164 comments·four.htmx.org ↗
The htmx team is very happy to announce the release of htmx 4.0.0!

htmx 4 land cruiser

htmx 4.0.0 Release

The htmx team is very happy to announce the release of htmx 4.0.0! This is the culmination of 8 months of work (plus a game) and we are very happy with the results.

The idea of htmx 4 started to germinate when I decided to create fixi and, in doing so, got more familiar with the fetch() API and async programming in JavaScript. (htmx had always used XMLHttpRequest due to backwards compatibility issues.)

One chance evening I was contacted by Christian, who had some interesting ideas around streaming HTML that got me thinking that moving the internals to fetch() would simplify things for him and for the library in general.
After a bit of work I managed to get Michael and Alex on board, and we were off to the races.

Development has been very smooth. We started a port of fixi + the htmx test suite. Over time, we rediscovered why htmx did many of the things that it did and moved our new implementation closer and closer to the old one. At this point the behavioral differences between 2.x and 4.x are relatively small and where they do diverge we have made explicit choices that we feel will put htmx-based applications in a good spot for being 100-year web services

Note that we are not marking 4.0 as latest in NPM because we do not want to force-upgrade users who are relying on non-versioned CDN URLs for htmx. Instead, 2.x will remain latest and the 4.0 line will remain next until some point in early 2027. The website, however, will reference 4.0.

Major Changes

As mentioned above, htmx 4, from a user’s viewpoint, is almost identical to htmx 2. There are three major changes:

  • Attribute inheritance is now explicit by default rather than implicit by default (this is the biggest upgrade item)
  • The htmx event names have been standardized & cleaned up. Some advanced users may need to change the events they listen for.
  • History support now does not use localStorage by default (which was a cause of many support headaches). Most people won’t notice this at all.

Internally, we migrated from XMLHttpRequest to fetch() but that should be transparent for most users of htmx.

Attribute Inheritance

In htmx 2 many attributes were “inherited” by default. This allows you to place attributes on parent elements and their behavior will apply to child elements. This behavior, which came from the intercooler.js days, was inspired by CSS and, unsurprisingly, worked out about the same as CSS: powerful but difficult to understand at times.

In htmx 4 attributes are not inherited unless you explicitly say so by adding an :inherited after the attribute name:

<!-- htmx 2 -->
<div hx-confirm="Are you sure?">
    <button hx-delete="/item/1">Delete</button>
</div>

<!-- htmx 4 -->
<div hx-confirm:inherited="Are you sure?">
    <button hx-delete="/item/1">Delete</button>
</div>

This will be the largest upgrade burden in migrating from htmx 2 to htmx 4. To make things easier, we have provided a command line tool to find places you need to mark as inherited.

Note that attributes like hx-disinherit, etc. are no longer required and should be removed.

Events

The events triggered by htmx 2 had grown organically over the life of the library and were not particularly well organized, making it difficult to know exactly which event was fired when.

In htmx 4, all events now follow htmx:phase:action[:sub-action]:

htmx 2 htmx 4
htmx:beforeRequest htmx:before:request
htmx:afterRequest htmx:after:request
htmx:beforeSwap htmx:before:swap
htmx:afterSwap htmx:after:swap
htmx:configRequest htmx:config:request

In addition, the following changes were made:

  • Most error events collapse into htmx:error. HTTP error responses fire htmx:response:error.
  • The htmx:xhr:* events are removed. htmx 4 uses fetch().
  • The htmx:validation:* events are removed in favor of native browser form validation.

The full table is in What’s New in htmx 4.

The command line upgrade checker flags old event names in hx-on attributes and in your JavaScript where it can find them.

History

History support has always been included in htmx, allowing you to implement back-button aware actions with simple attributes. In htmx 2, a cache in localStorage was used to snapshot pages for restoration. Unfortunately a large source of issues was that this snapshot could include DOM mutations by 3rd party JavaScript libraries. When the page was restored, those mutations remained but the underlying JavaScript logic was not.

htmx 4 does not cache pages in localStorage. On back navigation htmx re-fetches the page and swaps it into <body>, or into the [hx-history-elt] element if one is present. This allows 3rd party JavaScript libraries to “just work” in most cases and, with good request caching, is very fast.

If you want local caching instead, we now ship a very complete hx-history-cache extension that restores history from sessionStorage and is designed to integrate well with scripting solutions like Alpine.js, etc.

New Features

There are two big new features in htmx 4, both of which we are really excited about:

Morph Swaps

We now support morphing swaps out of the box with htmx. I created idiomorph and nearly included it in htmx 2.x but decided against it. In htmx 4, Michael has done great work improving on that algorithm and integrating it seamlessly into htmx.

<hx-partial>

Another major new feature is the <hx-partial> tag. This tag is similar to out-of-band swaps, but is much clearer when you want to do something beyond just replacing a single element with a new version of itself:

<hx-partial hx-target="#messages" hx-swap="beforeend">
    <div>New message</div>
</hx-partial>
<hx-partial hx-target="#count">
    <span>5</span>
</hx-partial>

Extensions

Much of the excitement in htmx 4 is in the extensions. Switching to fetch() internally let us rethink how extensions can and should work, and sparked the creation (and recreation) of many new extensions, for example:

  • hx-preload - preload content (e.g. on mouseover) to speed requests up
  • hx-download - native, fetch-based file downloads
  • hx-alpine-compat - smooths over compatibility issues between htmx and Alpine.js
  • hx-history-cache - caches history in sessionStorage, provides Alpine.js compatibility

Additionally, there are three new or updated streaming HTML extensions:

  • hx-sse streams over text/event-stream.
  • hx-ws streams and sends over WebSockets.
  • hx-multipart streams over multipart/mixed

Finally, we decided it was time to try our hand at our own small front-end scripting solution that tightly integrates with htmx. hx-live is inspired by Alpine.js, jQuery and hyperscript, and makes front end scripting pleasant and fun. It even supports what we are calling DOM-based, HATEOAS-friendly reactivity.

There is a new htmax.js bundle in the distribution which packages htmx with the most popular of these in a single file if you don’t want to think about which ones you want to pick.

Upgrading

For a complete upgrade guide see What’s New in htmx 4.

As mentioned earlier, we are providing an upgrade tool to help you:

$ npx htmx.org@4.0.0 upgrade-check -- ./templates

File extensions: .html, .php, .js, .ts, .jinja, .jinja2, .j2, .erb, .hbs
Use --ext to add more (e.g. --ext .vue --ext .svelte)

Scanning 1 file(s)...

Found 8 issue(s) in 1 of 1 file(s).
templates/index.html:1: [inheritance] hx-headers needs :inherited suffix (descendant on line 3 has hx-delete) (this looks like a CSRF token; without :inherited the header does not reach child elements and the server rejects the request)
templates/index.html:2: [inheritance] hx-target needs :inherited suffix (descendant on line 3 has hx-delete)
templates/index.html:2: [inheritance] hx-confirm needs :inherited suffix (descendant on line 3 has hx-delete)
templates/index.html:3: [renamed-attr] hx-disable -> rename to hx-ignore (hx-disable now means 'disable during request')
templates/index.html:4: [removed-attr] hx-vars is removed -> use hx-vals with js: prefix
templates/index.html:4: [removed-attr] hx-prompt is removed -> load the hx-prompt extension to keep the same syntax
templates/index.html:9: [old-event] old event name "htmx:afterRequest" -> "htmx:after:request"
templates/index.html:9: [old-api] htmx.addClass() is removed -> use element.classList.add()

We are also shipping an agent skill to assist in upgrading

Installing

htmx 4.0 can be installed via a package manager referencing version 4.0.0, or can be linked via a CDN:

<script src="https://unpkg.com/htmx.org@4.0.0/dist/htmx.min.js"></script>

or Downloaded

LLMs

Like it or not, a lot of people are using LLMs and we are providing the following skills files for LLMs:

(Let’s leave aside if releasing a new version of a library in the LLM era is a good or bad thing!)

Conclusion

We hope you enjoy htmx 4. htmx 2 will continue to be supported indefinitely so don’t feel any pressure to upgrade.

I’d like to thank the following people for all their help with this release:

  • Michael West - Incredible teammate & grug-brained developer
  • Christian Tanul - Inspired htmx 4 & led the streaming & live extensions
  • Alex Petros - For keeping the ship on an even keel
  • Stephen Mitchell - The genius behind the game
  • Stu Kennedy - Our WebSockets expert
  • André Ahlert Jr. - Providing IDE & Editor Support
  • Dien Hoa Truong - For kicking the tires on early htmx 4 and helping fix many bugs

Upgrade Music

Wouldn’t be an htmx update without upgrade music:

The Daily Front Page 4 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Security Desk
article

Just the rumour of a bug is enough to find an exploit these days

by avsm·▲ 317 points·112 comments·anil.recoil.org ↗
Just a rumour of a bug is enough to find a security exploit these days.

I released a security fix for OCaml's cohttp 6.3.0 today, fixing a path traversal issue. The patch itself was straightforward and in normal times, the security procedure would have been to fix it privately, inform affected users, and then issue a public advisory. This time around though, I noticed probes in my live webserver logs with the exact bug pattern just minutes after opening the PR to fix the issue.

What's worse, I found I could use my own agents to find the exploit just by knowing roughly what it was about and so could have been exploiting it well before the public patch was available! Given that just the rumour of a security issue seems enough to give attackers enough info to find new exploits, we're going to need to change the way we deal with security responses in open source.

The rumour of a bug is all new agentic exploit systems need

This particular report arrived privately on a Slack channel via Jane Street last week, and was itself found via Claude Fable. That compresses all timelines considerably...

The timeline of a modern security report

Before examining the patch in detail, I pointed my own Claude at the affected code to see what else was lurking (asking it to investigate path normalisation issues). Fable frustratingly refused outright due to its security block since I don't have access to Glasswing, but DeepSeek V4 Pro obliged me and independently turned up several related issues. My agent also trivially created an exploit to probe a local live server in under a minute.

After some back and forth with the bug reporter about possible fixes, I quietly opened cohttp#1145 publicly to get more eyes on it. This normally takes a few days and a release within a week or two is reasonable. Within about ten minutes (!) this website was fielding probes for percent-encoded traversal sequences, indicating that automated watchers are keeping an eye on public repositories.

If it took me just a minute to create my own exploit locally, then ten minutes actually seems quite long for an automated attack window to start! A determined attacker who is monitoring package repositories could easily be exploiting them within seconds.

Security embargoes are no longer effective

Conventional security process involves embargoing the bug, and assumes that secrecy of the details protects users. However, all an agent needs today is a broad direction to search in, and it can do its own research. Fang et al. found that when given a CVE description, their GPT-4 agent exploited 87% of a 15-vulnerability benchmark, and without the description, just 7%.

Two years on, the mean time to exploit is -7 days. In other words, exploitation now precedes the patch! That same metric looks to be around 63 days in 2018-19, and crossed zero in 2024. A quick search finds lots of other similar cases these days... marimo's CVE-2026-39987 went from advisory to first exploitation attempt in 9 hours, even with no public proof-of-concept in existence. Langflow's CVE-2026-33017 took 20 hours. We seem to have crossed the rubicon for automated exploit generation...

The state of LLM exploitation in 2026 (source: Vulncheck)
The state of LLM exploitation in 2026 (source: Vulncheck)

Are the bugonomics against OSS maintainers now?

It looks to me like our security processes need to invert somewhat, since just one person searching for the issue class (this could be a mailing list question, an odd commit in an orphan branch, or a context leak) is sufficient to alert someone else's agent and let them get exploit code. This is wild.

A May 2026 paper coined the term "bugonomics" and argues that the bottleneck has moved to "defender remediation throughput". LLMs are merrily generating exploits, but our ability to defend against them isn't necessarily improving as maintainer validation, triage and release rates stay flat. This unfortunately matches the view from my OSS maintainer's chair:

The question is not whether frontier models, open-weight models, or program analysis "win". The question is how to orchestrate them so that scarce validation, prioritization, and release capacity goes toward durable fixes rather than mechanical search and report drafting. A central defender opportunity is technical debt remediation: semantics-grounded, tool-verified, model-assisted workflows that help maintainers find, validate, prioritize, and fix security-relevant defects before they become tomorrow’s exploited vulnerabilities. -- Demystifying the Mythos or Disrupting Bugonomics?, Pesoli et al, 2026

And why are maintainer capabilities staying flat? Well, not having access to frontier agents like Mythos is an obvious one, but also that the engineering of a security patch that doesn't cause any regressions is just fundamentally more work.

So what the hell can we do about this?

We clearly need to adapt fairly quickly. I don't think the current manual triage process should disappear, but I have seen an unsustainable surge of activity since Fable came out. We are only just beginning to get a handle on how much of the incoming firehose is machine-generated, but it's obviously a lot.

The big engineering shops (like Google) have been building microupdates directly into their software to ensure that fixes directly reach users as a priority over (e.g.) being fixed in the Chrome code repository. We don't really have that kind of luxury in Docker or OCaml, as we don't control the endpoints our software is used in. Aside from Docker Desktop, downstream distributions quite rightly repackage OSS on their own timescales and terms.

For smaller projects like OCaml, just gaining access to the frontier models is a struggle. The Western models have security guards in place which mean that we can't use the commercially available ones. Project Glasswing has expanded to 150 organisations across 15 countries including critical infrastructure operators, cloud and financial providers, the Linux Foundation, but 'mom and pop' maintainers still don't have access. I was ambivalent back in April whether this is harmful, but it's pretty obvious today that it's turning out pretty terribly.

Super sekrit private patch development

The first remediation is to develop the fixes somewhere really private out of the reach of AI. GitHub's temporary private forks nominally do this, but it doesn't work hugely well for us.

First, GitHub restricts it "to keep information about vulnerabilities secure, integrations, including CI, cannot access temporary private forks" which immediately disconnects the maintainer from the lifeblood of our CI results. Secondly, only a single PR can merge into the fork, which doesn't work well for issues that often span a few repositories. Reviewers also have to be enrolled one at a time by an admin, and in open-source land reviewers are kind of drive-by depending on who is available (especially in August!).

More broadly though, this plugs the wrong leak. The patch staying secret isn't nearly as important as ensuring the description about the issue reaches exactly the right people with no leakage to attackers.

We don't have robust discussion infrastructure available within OSS as it's spread through various end-to-end encrypted ones (we use Matrix) but also shared infrastructure like Discord or Slack which are extremely leaky. We do need some sort of web-of-trust to distinguish the good guys from the bad in a particular project context.

No embargoes, just ship continuously

Another thing we could do is to rapidly fix issues in public, ship continuously, and improve the release path via better automation.

Bigger projects like Chrome show this is possible via weekly security updates, two releases per week (!), and dynamic patching that swaps background processes for updated binaries without a restart. This isn't entirely new technology; I looked into integrating live ksplice Linux patching with Xen 15+ years ago. The Linux kernel also ships fixes as soon as possible, deferring at most seven days and exceptionally fourteen.

However, software packaging is our primary obstacle. Chrome has a relatively easy job of shipping one binary artefact, but OSS is often a bunch of libraries that are then embedded in a variety of downstream products. So to do this, we'll need:

  • much better cross-ecosystem package management to discover where disparate libraries are eventually embedded. Ryan Gibb will talk about this at ICFP next week!
  • better scanning tools to help with triage; Andrew Nesbitt has been doing just this with Scrutineer over the past few months. Thomas Gazagnaire and I have been discussing trying this out for our OCaml code, subject to getting access to a reasonable frontier model without security blocks.
  • more robust quality control infra without any false positives that works across the spectrum of supported platforms. While it's relatively easy to run CI on Linux, it's a different story on OpenBSD, FreeBSD, macOS, and some architectures like RISC-V

Proactive protection at the protocol layer

I've also been having more radical thoughts about how we could slam in protections dynamically to protect endpoints using our libraries. If we just accept that upstream patch fixes will always trail an exploit, then we must put something faster to get ahead.

For example, this cohttp bug fixed today has a simple mitigation: just normalise percent-encoded path separators in the request URL. This rule was implementable the minute the report arrived, and also deployable while the full fix went through review, testing and packaging. Virtual patching is routine on cloud infrastructure these days; Cloudflare deployed managed rules to plug Log4shell back in 2021.

But open source lacks a distribution mechanism for such rules outside of a commercial CDN. That's what the antibotty network idea from our internet ecology paper is trying to plug via more software diversity around the global Internet. How can we have local, fast-propagating defences that hear about a vulnerability and act on their immediate infrastructure within seconds?

Some research followups

I think we'll need some combination of all three options in the short-term. A lightweight web-of-trust for OSS contributors (like the venerable Advogato used to be), as well as more focus on OSS packaging and continuous rollout and triage mechanisms that don't overwhelm our precious human contributors.

I've also posted a couple of new MPhil research ideas for anyone incoming to Cambridge next month and is looking for a project.

And if anyone from Project Glasswing is listening, team OCaml could use access now :-)

(The cohttp fix was not a solo effort. Sapphire Livingstone found and reported the issue, guided the fix and co-developed the remediation; Michael Dales, Török Edwin and Patrick Ferris reviewed the patch; Hannes Mehnert coordinated the advisory; and Thomas Gazagnaire has been thinking through the wider triage problem. Thank you all! The bugonomics may be against us, but we will crest this hump.)

References

[1] Madhavapeddy et al (2025). Functional Networking for Millions of Docker Desktops. 10.1145/3747525

[2] Madhavapeddy (2026). Language integrated LLMs as an OCaml function. 10.59350/61cdd-r5a25

[3] Madhavapeddy et al (2025). Steps towards an Ecology for the Internet. Association for Computing Machinery. 10.1145/3744169.3744180

[4] Madhavapeddy et al (2026). A Decade of Docker Containers. 10.1145/3761803

[5] Madhavapeddy (2026). Rewilding the Web: my workshop report from Edinburgh. 10.59350/g40yy-ks003

[6] Madhavapeddy (2026). The Internet needs an antibotty immune system, stat. 10.59350/snnnf-asc02

[7] Madhavapeddy (2009). Combining Static Model Checking with Dynamic Enforcement Using the Statecall Policy Language. Springer. 10.1007/978-3-642-10373-5_23

[8] Gibb et al (2026). Package Managers à la Carte: A Formal Model of Dependency Resolution. arXiv. 10.48550/arXiv.2602.18602

[9] Fang et al (2024). LLM Agents can Autonomously Exploit One-day Vulnerabilities. arXiv. 10.48550/arXiv.2404.08144

[10] Pesoli et al (2026). Demystifying the Mythos or Disrupting Bugonomics? From Zero-Day Asymmetry to Defender Remediation Throughput. arXiv. 10.48550/arXiv.2605.24632

The Daily Front Page 5 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Rights, Remedies & Software
article

Get your Windows license refund

by smartmic·▲ 682 points·283 comments·en.refund4freedom.org ↗
Consumers should be able to buy laptops without any specific operating system.

We all know the joy of acquiring a new laptop and the excitement of exploring its features and functionalities. However, the vast majority of laptops are only sold with a specific proprietary operating system: Microsoft Windows. The vendors do not remove the Windows license, and you must pay the entire price, even if you do not want to use this system.

This is unfair and we want to change it! Consumers should be able to buy laptops without any specific operating system, and should not have to pay the license price if they don't want to.

Request your refund now!


Demands

You should not have to pay for software you don't want. Devices like laptops and smartphones are general purpose computers so, they should be neutral in relation to the software they run. Manufacturers and vendors should not have the right to impose specific operating systems on you. When you request a refund, the process should be easy, quick and straightforward. Here’s what we demand:

  1. Do not restrict users to specific software. Device manufacturers and vendors should not impose an operating system or software on consumers, and should not force them to pay for software that they don't want. Laptops and smartphones are general purpose computers, so consumers should be able to run the software they want on their devices.
  2. Transparent pricing. Consumers should have the right to decline pre-installed software, including the operating system, but still be able to buy the laptop without it.
  3. Hassle-free refunds. Manufacturers and vendors should clearly publish the steps for requesting and obtaining a refund on their websites. The process should be simple, easy and accessible to any consumer. No one should go through unnecessary or complicated procedures i.e. sending the entire computer to a service centre just to remove unwanted software.

Take action!


How to request your license refund

1

Start up the PC and take pictures

Take pictures of the screen of the clauses of the contract where the reimbursement is indicated or make a video by scrolling through the whole contract (maybe useful later). If possible, do not format/erase yet your computer storage.

2

Contact the manufacturer's customer service

Contact the manufacturer by telephone or, better still, chat/email, and keep the relevant correspondence. For the telephone, note the date, time and with whom you spoke. For chat, copy/paste what was written.

3

If they respond negatively...

Problem Not Solved: fill-in the Refund Form and send it to the manufacturer.

Fill in the Refund Form

4

Report your experience

If you are in Italy, report your experience to the Antitrust AGCM: Send report to the Antitrust or go directly to the form: Fill form of the Antitrust
The more reports that come in, the more the Antitrust will be prompted to take action! Feel free to share your case with us as well! segreteria@linux.it contact@fsfe.org


Supporting Material

Here you can find useful material to refund the cost of the Windows operating system.

Manufacturers

Not all manufacturers and vendors are equal. Some react differently and treat consumers better. We have a lot of experience in requesting refunds, and keep track of those who respect your right to choose—and those who don't. Below we provide reports on manufacturers concerning their licenses and refund policies to help you in getting your money back.

HP
  • HP does not have a reimbursement procedure for Windows.
  • Several contact attempts were made by different customers, and were always ignored by HP.

Lenovo

Asus
  • Asus has a reimbursement procedure for Windows.
  • No need to ship the PC to Asus.
  • Asus's reimbursement procedure is not published on their website.
  • Asus gives a reimbursement between 9 and 65 euros, depending on the Windows version.
  • Send an e-mail to info@asus.it indicating the PC serial number and your bank details, within 30 days of purchase and without accepting the EULA when you first turn on the machine.

Dell
  • Dell does not have a reimbursement procedure for Windows.
  • Dell's terms and conditions, in Article 7.3, explicitly states that in the event of non-approval of the operating system licence, the computer must be returned.

Acer

Reports

Reports received. Get inspired. Explore information from other users like you who got their license fee back!

Paolo Cavallini
Lenovo

Paolo requested a refund of the Windows license for his new Lenovo computer, but he only received denials. He moved his report to the Italian Antitrust (AGCM), also appearing to be without response.
(IT) First answer from Lenovo, (IT) Second answer from Lenovo

IT for s.r.l.
Acer

Following repeated unsuccessful telephone contacts, the ITfor company in Turin took Acer Italia to the Justice of the Peace contesting the manner in which the license was reimbursed. After several hearings and adjournments, Acer Italia granted payment of 50 euros + 100 euros for legal fees incurred.
Writ of Lawsuit, Minutes of Conciliation, Complete documentation

Luca Bonissi
Mediacom

After purchasing a Mediacom PC, Luca went directly to Datamatic S.p.A. (the parent company of the Mediacom brand) to request a refund of the Windows license. Only after the legal summons was served, and just before the legal hearing, Luca received an offer for a private transaction and awarded a refund of 44 euros.
Complete documentation

Luca Bonissi
Microsoft

Luca, after some perseverance, reached the Microsoft Technical Support of Microsoft S.r.l. (representing Microsoft in Italy), which actually provides a procedure for refunding the Windows license on products sold by the company (in this case, a Microsoft Surface). After several emails and communications, Luca received a refund of 43 euros.
Complete documentation

Luca Bonissi
Lenovo

Following a lengthy legal dispute, the judgment in the second instance awarded a refund of 42 euros for the Windows license, 1,000 for legal fees, and ordered Lenovo Italy S.r.l to reimburse 20,000 euros in damages for aggravated litigation liability.
Complete documentation

Luca Bonissi
HP

The reimbursement request was denied several times, but the Justice of the Peace in Monza awarded a 61 euro reimbursement for pre-installed licenses (of both Windows 10 Home and Office 365 Personal).
Complete documentation

Francesca Tregnaghi
Dell

After a couple of Italian legal emails (PEC emails), the 51 euro refund for the Windows 10 Home Edition license was granted.
Complete documentation

Vincenzo Castiglia
Lenovo

After a long series of emails and phone calls, the 42 euro refund for the Windows 10 Home Edition license was granted. For the payment, Vincenzo chose to give Italian Linux Society's bank details.
Complete documentation

Silvia
Lenovo

After a particularly prolonged email exchange, a refund of 47 euros for the Windows 10 Home Edition license was granted.
Complete documentation

Luca Bonissi
Lenovo

Oggetto del contendere è stato - come in diversi altri casi - la presunta necessità di restituire il PC. Alla fine è stato riconosciuto un rimborso di 75 euro per la licenza Windows 11 Home.
Complete documentation

Luca Bonissi
Acer

Although Acer has a procedure for refunding the Windows license, it involves sending the PC, long waiting times and derisory compensation, so the procedure is inconvenient and impractical. The lengthy exchange of legal Italian emails (PEC emails) between Luca and Acer, culminating in the suggestion of a court case, ended in a 129 euro refund.
Complete documentation

Giuseppe Salustri
MSI

After many difficulties raised by MSI, including shipping the computer to the service center in Poland, long waiting times, and reminders, Giuseppe finally got a refund of 40 euros (net of shipping costs, absurdly charged to the customer).
It is recommended not to write to the email address for support, but to register on the MSI site and open a ticket specifying the serial number, first name, last name, mailing address, and phone number right away.

Get a licence free device

Want to buy a licence-free PC directly? Search for your nearest Linux-friendly shop on LinuxSi! (Italian-only).

My device is a smartphone. Check how you can install a different operating system on your smartphone FSFE's Free Your Android site.


Share the campaign

The more people know, the stronger we are! Share this campaign with your friends, family, and on your social networks, by using #Refund4Freedom and #GetYourWindowsRefund.

Urge suppliers to express a clear position towards your rights.

Tell us your story
Whether you got a refund or hit a roadblock, share your experience with others. Tag @fsfe and @ItalianLinuxSociety on Mastodon and use our pre-made text for your social media posts.

If you asked for a refund, we can send to you some free stickers for your free laptop!

Request stickers from the Italian Linux Society

Request stickers from the Free Software Foundation Europe

To receive news about the right to reimbursement of pre-installed software licences in Italy, see: ADUC Windows refund page.

Follow the project on:

Mastodon, Matrix Chat, GitLab, RSS

The Daily Front Page 6 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Copyright by Algorithm
article

Luanti removed from Google Play due to baseless AI copyright notice

by miniBill·▲ 489 points·148 comments·blog.luanti.org ↗
The Luanti app does not contain any proprietary code or assets, from Minecraft or otherwise.

Luanti’s Android app is currently not available on the Google Play Store due to a baseless DMCA notice filed on behalf of Microsoft by Tracer.AI, alleging that Luanti infringes Minecraft’s copyright. The Luanti app does not contain any proprietary code or assets, from Minecraft or otherwise.

We received a similar notice from the same company in 2023 and successfully appealed against it. This company also filed a similar notice this year against an indie game with similar voxel art style by the name of Allumeria.

What is Luanti?

Luanti is a voxel game-creation platform where anyone can make, share, discover, and play blocky games. It does not ship with any games or game assets by default. Instead, players can browse a catalog of games created by the community, or simply join multiplayer servers.

Asuna by EmptyStar, a sandbox game with a focus on biomes and exploration

Asuna by EmptyStar, a sandbox game with a focus on biomes and exploration

Extra Ordinance by Sumi, a top-down shooter

Extra Ordinance by Sumi, a top-down shooter

Lazarr! by Wuzzy, a puzzle game with lasers

Lazarr! by Wuzzy, a puzzle game with lasers

Klots by Warr1024, a 3D sliding block puzzle game

Klots by Warr1024, a 3D sliding block puzzle game

We are a non-profit project developed by a community of passionate individuals expressing their creativity. Luanti is open source, which means anyone can view the source code, modify it, learn from it, redistribute it, and even sell games made with it on platforms like Steam.

While Luanti is popular as an open-source alternative to Minecraft (as its roots are in blocky sandbox games), it also lowers barriers to bringing creative ideas to life. The freedom and customization Luanti affords has made it an excellent tool in education, finding its way into many schools across Europe.

What is the DMCA notice?

The Digital Millennium Copyright Act (DMCA) is United States law which lays out a notice-and-takedown process which platforms like Google Play follow to avoid liability for damages resulting from copyright-infringing packages which they distribute. These platforms are not responsible for the actions of their users, but they are responsible for taking corrective action when user-generated content is reported.

The DMCA notice we received through Google claims that:

These products use copyrighted assets as outlined directly from the Minecraft game (available at www.minecraft.net) without authorization and should be removed. Specifically, US Reg. #TX 8-192-097

“US Reg. #TX 8-192-097” is the registration of Minecraft Java Edition 1.9 with the US Copyright Office.

It does not provide any information aside from this and does not outline which assets Luanti allegedly uses.

Which assets?

Engine

Luanti is a game-creation platform and does not ship with any games, let alone game assets. In fact, here are all the textures Luanti comes with:

All textures in the Luanti app

All textures in the Luanti app

Luanti also includes further assets, particularly fonts. These are properly attributed in the license file.

The GitHub repository does include the Development Test game, which is also available on ContentDB but is not included in Luanti releases anymore. Being a testing ground for the engine, the textures are largely utilitarian in nature.

Development Test game, for engine development

Development Test game, for engine development

Minetest Game

Luanti previously shipped with Minetest Game, a crafting survival game intentionally kept bare-bones to provide a base for modding. As of December 2023, it is no longer bundled with Luanti, and can be downloaded from within the Luanti client like any other game. All of Minetest Game’s assets are original and properly licensed1.

Minetest Game

Minetest Game

Third-party content

Players can download content from ContentDB, our in-app game catalog. Except for Minetest Game and Development Test, all these games, mods, and texture packs are third-party, just like most apps on Google Play.

ContentDB in the main menu

ContentDB in the main menu

Packages uploaded on ContentDB are reviewed manually by volunteer staff before they are approved. We proactively check for copyright issues, including checking for commercial assets. Independent of this incident, we have been looking into automated asset flagging using conventional perceptual hashing algorithms. This would help human moderators detect copyrighted assets, and we will always require a final human decision without relying on erroneous AI.

It is in everyone’s best interests that content on ContentDB is legal and free, as it allows the community to safely use and build on top of it for their own projects. If you are a rightsholder who believes your rights are being infringed by content hosted on ContentDB, then the correct action is to submit a DMCA notice against the particular game on ContentDB.

Cubes are for everyone

The concept of a game featuring 3D cubes or voxels is not something anyone can own2. Minecraft was originally inspired by the 2009 game Infiniminer which uses similar voxel graphics, and later examples like Hytale show that block games make up an entire genre that Minecraft is simply a part of. Mojang and its parent company Microsoft have all rights to enforce their copyright for assets such as Minecraft’s textures, but cannot use the DMCA as a means to intimidate and monopolize an entire genre of games.

Luanti was originally created by celeron55 in 2010 under the name “Minetest”, inspired by the newly-released Minecraft Alpha to make a sandbox in a voxel grid that ran better on low-end hardware. Work began in 2011 on a modding API using the Lua programming language, allowing players to create their own content. Minetest has continued to work to support a larger variety of user creativity ever since. In 2024, the rename from Minetest to Luanti set this direction in stone.

What is Tracer.AI?

Quoting their website:

Tracer is a next-generation brand protection platform that empowers brands to take control of their brand presence online. Our AI agents streamline workflows and enhance operational efficiency, making it easier to monitor digital channels, take down detections, and analyze vast amounts of data to provide better business intelligence insights. Bring speed, accuracy, and efficiency to your brand protection strategy, without draining your team’s resources.

Tracer’s AI brand protection technology detects and removes infringements to your brand across thousands of digital platforms, faster and more accurately than ever before.

From this, we can gather that Tracer uses AI agents for automated infringement detection. In a 2024 blog post, the company boasts “85% faster takedowns”, “100% more reviews month-over-month” along with “review times that are six times faster than traditional methods”. It claims this has resulted in “44% more takedowns month-over-month”.

This is not the first time this has happened

Luanti’s Android app received a similar notice from the same company in March 2023. As the notice was incorrect, we submitted a counter-notice and the app was eventually reinstated… after 46 days3. Section 512(g)(2)(c) of the DMCA requires that providers “[replace] the removed material and [cease] disabling access to it not less than 10, nor more than 14, business days following receipt of the counter notice”. Google’s failure to adhere to the deadlines specified by the DMCA raises questions regarding its approach toward handling DMCA counter-notices.

In February of this year, an indie game called Allumeria also received a DMCA takedown from Tracer.AI on behalf of Microsoft, resulting in the game’s temporary removal from the Steam store. The notice was eventually dropped by Microsoft after public noise.

This can’t keep happening

If a company can repeatedly submit the same DMCA notice with no explanation or evidence, taking projects down for months at a time, the system is broken. It prevents users from discovering or updating Luanti, and risks users settling for shady or ad-ridden forks instead.

If we were a small company relying on income from the app, this would be especially devastating. We, like most open-source communities, lack the resources to continually fight unfounded DMCA notices.

What next?

We have submitted a counter-notice and the app should be restored soon, hopefully sooner than 46 days. But with counter-notices not being respected in the set timeframe, a more public approach is required.

We call on Microsoft, Mojang, and Tracer.AI to stop relying on AI tools to send inaccurate and vague DMCA notices. Detection must be verified by a human and, more importantly, substantiated with tangible proof.

We call on Google to improve how they verify notices, allow users to respond to notices without taking apps down for extended periods of time, and properly comply with copyright law.

While we hope Google reinstates the Luanti app in a timely manner, we would like to mention that the Luanti Android app is also available on F-Droid, an app store for Android whose official repository contains only verified free software. In addition, APK downloads are available on our own website. Unfortunately, both distribution mechanisms are increasingly under threat.

We ask our community and readers to share this post far and wide, to help raise awareness and ensure this doesn’t happen again, for us or anyone else.

  1. Minetest Game’s LICENSE.txt 
  2. 17 U.S. Code § 102(b) https://www.law.cornell.edu/uscode/text/17/102 
  3. We submitted the counter notice on 25 March 2023 and the app was reinstated on 10 May 2023. 
The Daily Front Page 7 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Flights of Fancy
show hn

Show HN: OpenTIE and OpenXWA, Modern Ports of Tie Fighter and X-Wing Alliance

by elyosh·▲ 218 points·56 comments·github.com ↗
OpenTIE is an open-source reimplementation of Star Wars: TIE Fighter for Windows, macOS, and Linux.

Screenshot of OpenTIE

OpenTIE is an open-source reimplementation of Star Wars: TIE Fighter for Windows, macOS, and Linux. It runs the original game data natively on current systems and supports both the 1995 Collector's CD-ROM and the 1998 Windows release.

With both editions installed, OpenTIE can combine the 1995 menus, cutscenes, and adaptive iMUSE soundtrack with the 1998 flight simulation and 3D assets.

Important

OpenTIE does not include any content from the original game. A complete installation of at least one supported edition is required. Install both editions to use the recommended combination.

Star Wars: TIE Fighter Special Edition is available from GOG and Steam.

The best of both editions

The 1995 and 1998 releases each have their own presentation, flight simulation, and soundtrack. OpenTIE lets the menus and cutscenes, flight simulation, and music be selected independently.

The recommended configuration combines:

  • the 1995 menus and cutscenes
  • the 1998 flight simulation and 3D assets
  • the adaptive 1995 iMUSE soundtrack

This retains the 1998 flight presentation without giving up the interactive music of the Collector's CD-ROM. Either supported edition can also be played on its own.

Adaptive music

OpenTIE reimplements the adaptive iMUSE soundtrack from the 1995 Collector's CD-ROM. The music responds to mission events and moves seamlessly between themes during flight.

OpenTIE can emulate Roland SC-55 Sound Canvas, the hardware for which the game’s music was originally composed. This requires compatible SC-55 ROMs supplied by the user.

Built-in Sound Blaster-compatible OPL3 emulation is available for the classic FM-synth sound, while FluidSynth can play the soundtrack with a user-selected SoundFont.

The original prerecorded TIE98 music remains available when the complete 1998 experience is preferred.

Graphics

OpenTIE offers classic and modern graphics modes. Classic mode preserves the original presentation, while modern mode combines the original models and cockpit artwork with high-resolution rendering and substantially more advanced lighting.

Modern graphics include:

  • shadows, ambient occlusion, and bloom
  • motion blur
  • MSAA and AMD FidelityFX FSR 3.1.4 anti-aliasing and upscaling
  • HDR output

Press TAB while the game is running to switch between classic and modern graphics.

Smoother flight

Flight simulation can update at up to 240 Hz to match modern high-refresh-rate displays, providing smoother motion and more responsive controls. The original TIE95 and TIE98 timing modes remain available when their exact behavior is preferred.

Modern gamepads and joysticks are supported and can be configured from OpenTIE's settings.

Getting started

  1. Download the latest package for your platform from GitHub Releases.
  2. Extract or install the package and launch OpenTIE.
  3. Select the complete TIE95 and/or TIE98 installation folders when prompted.
  4. If both editions are available, select the recommended configuration to combine the 1995 presentation and music with the 1998 flight experience.

OpenTIE validates the selected installations, remembers them for future launches, and imports compatible existing pilot files during initial setup.

To access OpenTIE settings from the concourse, press ESC and select OpenTIE Settings. During flight, press ESC to open them directly.

Useful shortcuts:

Key Action
TAB Switch between classic and modern graphics

Supported platforms

Platform Target Graphics backend
Windows x86-64 Direct3D 12 or Vulkan
macOS macOS 13 or later; arm64 or x86-64 Metal
Linux x86-64; glibc 2.35 or later Vulkan

Current state

OpenTIE remains under active development. Bugs and differences from the original releases are still possible.

OpenXWA

Fans of Totally Games’ space simulators may also be interested in OpenXWA, an open-source reimplementation of Star Wars: X-Wing Alliance for Windows, macOS, and Linux.

Community

Join the TotallyOpen Discord server to discuss OpenTIE, OpenXWA, development, and the Totally Games flight simulators.

System requirements

  • a 64-bit system with a modern GPU
  • a complete installation of the 1995 Collector's CD-ROM or the 1998 Windows release

Release packages include the required runtime libraries. Keep the executable, libraries, resources, and shader directories together when moving an installation.

Building from source

The build requires CMake 3.23 or later, a C/C++ toolchain, SDL3 3.4, zstd, FFmpeg, and SDL_shadercross. Release packaging pins its dependencies, including SDL3 3.4.14, and provides the reference for reproducible builds.

Platform-specific instructions are available for Windows, macOS, and Linux.

The Daily Front Page 8 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — The HTTP Desk
repository

Migrating to HTTPX2

by tosh·▲ 196 points·88 comments·github.com ↗
★ 31,496⑂ 5,149 forks Python

The official Python library for the OpenAI API

The OpenAI Python SDK now uses HTTPX2 for its synchronous and asynchronous HTTP clients. HTTPX2 is installed automatically with openai; the previous httpx package is not. This guide explains what changes for applications that interact with the SDK's HTTP layer.

If you use the SDK's default HTTP client

If you construct an OpenAI or AsyncOpenAI client without providing http_client, your existing API calls, parsed response models, streaming APIs, authentication, retries, and numeric timeouts continue to work:

from openai import OpenAI

client = OpenAI(timeout=30.0)
response = client.responses.create(model="gpt-5.5", input="Hello")

No HTTPX2 extra or separate installation is required:

pip install openai

If your application imported httpx only because an earlier SDK installed it transitively, add your own httpx dependency or migrate those imports to httpx2. Installing the SDK no longer installs httpx for you.

TLS certificates and trust stores

HTTPX2 changes the default TLS trust store, including for applications that use the SDK's default HTTP client. HTTPX previously verified certificates against the CA bundle provided by certifi. HTTPX2 instead uses the operating-system trust store, and the SDK no longer installs certifi.

This can break certificate verification in minimal container images without system CA certificates, environments using corporate TLS-inspecting proxies, and deployments that relied on a custom or modified certifi bundle. Install the required CA certificates in the operating-system trust store, or configure an explicit certificate bundle:

export SSL_CERT_FILE=/path/to/ca-bundle.pem

Alternatively, configure a directory of trusted CA certificates:

export SSL_CERT_DIR=/path/to/ca-directory

These environment variables are honored when trust_env=True, which is the default. To control trust explicitly on a custom client, pass an ssl.SSLContext through verify:

import ssl
from openai import OpenAI, DefaultHttpx2Client

ssl_context = ssl.create_default_context(cafile="/path/to/ca-bundle.pem")
client = OpenAI(http_client=DefaultHttpx2Client(verify=ssl_context))

Use DefaultAsyncHttpx2Client(verify=ssl_context) for the equivalent async configuration. The SDK's aiohttp transport uses the same HTTPX2 TLS settings.

If you provide a custom HTTP client

Use HTTPX2 clients and HTTPX2 configuration objects. The SDK provides helpers that preserve its recommended timeout, connection-pool, and redirect defaults:

import httpx2
from openai import OpenAI, AsyncOpenAI, DefaultHttpx2Client, DefaultAsyncHttpx2Client

proxy_client = OpenAI(http_client=DefaultHttpx2Client(proxy="http://proxy.example.com:8080"))

transport_client = OpenAI(
    http_client=DefaultHttpx2Client(
        transport=httpx2.HTTPTransport(local_address="0.0.0.0"),
        timeout=httpx2.Timeout(30.0, connect=5.0),
    )
)

async_client = AsyncOpenAI(http_client=DefaultAsyncHttpx2Client(timeout=httpx2.Timeout(30.0)))

Directly constructed httpx2.Client and httpx2.AsyncClient instances are also supported. When you construct a client directly, its own HTTPX2 defaults apply unless you configure them yourself.

The existing DefaultHttpxClient and DefaultAsyncHttpxClient names continue to work, but now construct HTTPX2 clients. Prefer DefaultHttpx2Client and DefaultAsyncHttpx2Client when making the HTTP client family explicit.

Module-level configuration follows the same rule:

import openai

openai.http_client = openai.DefaultHttpx2Client()

Timeouts, URLs, transports, and connection settings

Replace HTTPX-specific objects with the corresponding HTTPX2 objects:

Previous object HTTPX2 object httpx.Client httpx2.Client httpx.AsyncClient httpx2.AsyncClient httpx.Timeout httpx2.Timeout httpx.URL httpx2.URL httpx.Limits httpx2.Limits httpx.HTTPTransport httpx2.HTTPTransport httpx.AsyncHTTPTransport httpx2.AsyncHTTPTransport httpx.MockTransport httpx2.MockTransport

For example, a granular SDK timeout becomes:

import httpx2
from openai import OpenAI

client = OpenAI(timeout=httpx2.Timeout(60.0, connect=5.0, read=20.0))

Numeric timeout values do not change. Existing string URLs do not change. Custom transport subclasses, mounted transports, proxy integrations, and connection-pool instrumentation must target HTTPX2's transport interfaces.

Authentication and event hooks

Authentication handlers and hooks receive HTTPX2 request and response objects. Update custom auth classes and annotations accordingly:

import httpx2
from openai import OpenAI, DefaultHttpx2Client


def log_request(request: httpx2.Request) -> None:
    print(request.method, request.url)


client = OpenAI(http_client=DefaultHttpx2Client(event_hooks={"request": [log_request]}))

If you subclass an HTTP authentication or transport interface, subclass the matching httpx2 class. Third-party instrumentation, tracing middleware, and auth integrations must explicitly support HTTPX2.

Raw responses, streaming, and exceptions

Parsed SDK response models are unchanged. When using a native HTTPX2 client, transport-facing objects belong to HTTPX2:

import httpx2
from openai import OpenAI

client = OpenAI()
response = client.models.with_raw_response.list()

assert isinstance(response.http_response, httpx2.Response)
assert isinstance(response.http_request, httpx2.Request)

With a native client, use cast_to=httpx2.Response when requesting an unparsed HTTP response. Streaming response wrappers also expose HTTPX2 response objects. Application code should usually catch SDK exceptions such as openai.APITimeoutError and openai.APIConnectionError; with a native client, an exception's underlying transport cause is an HTTPX2 exception.

These type guarantees apply only to native HTTPX2 clients. An injected legacy HTTPX client produces httpx.Request, httpx.Response, and HTTPX transport exceptions instead, even if cast_to=httpx2.Response is supplied.

aiohttp

The supported aiohttp extra uses an HTTPX2-native transport. It does not install legacy HTTPX or the external httpx-aiohttp adapter:

pip install 'openai[aiohttp]'
from openai import AsyncOpenAI, DefaultAioHttpClient

client = AsyncOpenAI(http_client=DefaultAioHttpClient())

DefaultAioHttpClient() is an httpx2.AsyncClient. Applications using this helper do not need to construct or import the transport directly.

Request mocking and tests

Mocks must intercept HTTPX2 requests and return HTTPX2 responses. For example:

import httpx2
from openai import OpenAI


def handler(request: httpx2.Request) -> httpx2.Response:
    return httpx2.Response(
        200,
        request=request,
        json={"object": "list", "data": []},
    )


client = OpenAI(http_client=httpx2.Client(transport=httpx2.MockTransport(handler)))
assert client.models.list().data == []

If your test suite uses RESPX, update to an HTTPX2-compatible RESPX version or fork. A RESPX version that patches only legacy HTTPX cannot intercept the SDK's default HTTPX2 client. If you cannot migrate that integration immediately, the temporary legacy-client escape hatch below lets existing HTTPX-only RESPX setups continue to work while you migrate.

Temporary escape hatch: a legacy HTTPX client

Applications that depend on an HTTPX-only transport, integration, or mocking library can explicitly install legacy HTTPX and inject a legacy client:

pip install openai httpx

Legacy HTTPX support is runtime-only. The SDK's public type annotations accept HTTPX2 clients, so passing a legacy client directly fails static type checking in mypy, Pyright, and similar tools. Use cast(Any, ...) or a targeted type-ignore when deliberately choosing this compatibility path:

from typing import Any, cast

import httpx
from openai import OpenAI

client = OpenAI(http_client=cast(Any, httpx.Client()))

The asynchronous form requires the same workaround:

from typing import Any, cast

import httpx
from openai import AsyncOpenAI

client = AsyncOpenAI(http_client=cast(Any, httpx.AsyncClient()))

Legacy clients preserve the HTTPX request, response, and exception families. Request raw responses as httpx.Response, using the same type-checking workaround for the legacy response class:

from typing import Any, cast

import httpx
from openai import OpenAI

client = OpenAI(http_client=cast(Any, httpx.Client()))
response = client.get("/models", cast_to=cast(Any, httpx.Response))

assert isinstance(response, httpx.Response)

Passing cast_to=httpx2.Response does not convert a legacy HTTPX response into an HTTPX2 response. Install and maintain the legacy dependency yourself. Legacy HTTPX support is provided as a migration aid and may be discontinued.

Existing legacy aiohttp adapters

If you must retain an existing httpx-aiohttp integration, install it explicitly and inject its legacy client:

pip install openai httpx-aiohttp
from typing import Any, cast

from httpx_aiohttp import HttpxAiohttpClient
from openai import AsyncOpenAI

client = AsyncOpenAI(http_client=cast(Any, HttpxAiohttpClient()))

This path is covered by dedicated compatibility tests, including a real request through the aiohttp transport, but remains a temporary escape hatch. Prefer openai[aiohttp] and DefaultAioHttpClient() for new code.

The Daily Front Page 9 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Practical Geometry
article

Hilariously fast volume computation with the divergence theorem (2018)

by luu·▲ 257 points·66 comments·alyssarosenzweig.ca ↗
The following presents a fast algorithm for volume computation of a simple, closed, triangulated 3D mesh.

(No, there won’t be jokes.)

The following presents a fast algorithm for volume computation of a simple, closed, triangulated 3D mesh. This assumption is a consequence of the divergence theorem. Further extensions may generalise to other meshes as well, although that is presently out of scope.

We begin with the definition of volume as the triple integral over a region of the constant one:

[ V = \iiint_R 1 , \mathrm{d}V ]

Let (\mathbf{F}) be a function in (\mathbb{R}^3) such that its divergence is equal to one. For the purposes of this paper, we choose:

[ \mathbf{F}(x, y, z) = \langle x, 0, 0 \rangle ]

It can easily be verified that

[ \mathrm{div},\mathbf{F} = \frac{\partial F}{\partial x}

  • \frac{\partial F}{\partial y}
  • \frac{\partial F}{\partial z} = 1 + 0 + 0 = 1 ]

Therefore,

[ V = \iiint_R 1 , \mathrm{d}V = \iiint_R \mathrm{div},\mathbf{F}(x, y, z) , \mathrm{d}V ]

By the Divergence Theorem, this is equal to the surface integral:

[ V = \iint_S \mathbf{F}(x, y, z) , \mathrm{d}\mathbf{S} ]

This surface integral, defined over the surface (S) of the 3D mesh, is equal to the sum of its piecewise triangle parts. Let (T_i) denote the surface of the (i)th triangle in the mesh. Then,

[ V = \sum_i \iint_{T_i} \mathbf{F}(x, y, z) , \mathrm{d}\mathbf{S} ]

Let (T_{in}) represent the (n)th vertex of the (i)th triangle. Let (\Delta_1) equal the vector difference between (T_{i1}) and (T_{i0}), and (\Delta_2) likewise equal (T_{i2} - T_{i0}). Each individual triangle (T_i) may thus be parametrised as:

[ \mathbf{r}(u, v) = T_{i0} + u\Delta_1 + v\Delta_2 ]

Then, simple differentiation yields:

[ \mathbf{r}_u = \Delta_1 ]

[ \mathbf{r}_v = \Delta_2 ]

Therefore,

[ \mathbf{r}_u \times \mathbf{r}_v = \Delta_1 \times \Delta_2 ]

Thus, the surface integral can be rewritten in terms of this parametrisation, substituting in the definition of (\mathbf{F}) as needed:

[ V = \sum_i \iint_{T_i} \mathbf{F}(x, y, z) (\mathbf{r}_u \times \mathbf{r}_v) , \mathrm{d}A ]

[ = \sum_i \iint_{T_i} \mathbf{F}(x, y, z) (\Delta_{i1} \times \Delta_{i2}) , \mathrm{d}A ]

[ = \sum_i \iint_{T_i} \langle x, 0, 0 \rangle \cdot (\Delta_{i1} \times \Delta_{i2}) , \mathrm{d}A ]

This cross product is constant throughout the triangle and easy to calculate from the vertex data. Only the X component of the cross product should be calculated; the others are equal to zero due to the dot product with the zero components of (\mathbf{F}). (V) can thus be rewritten as:

[ V = \sum_i (\Delta_{i1} \times \Delta_{i2})x \iint{T_i} x , \mathrm{d}A ]

We now focus on the surface integral (\iint_{T_i} x , \mathrm{d}A). Expanding with the parametrisation yields:

[ \iint_{T_i} x , \mathrm{d}A = \int_0^1 \int_0^u x , \mathrm{d}v , \mathrm{d}u ]

[ = \int_0^1 \int_0^u (T_{i0x} + u\Delta_{i1x} + v\Delta_{i2x}) , \mathrm{d}v , \mathrm{d}u ]

This integral can be directly evaluated, treating vertex data as constants:

[ \begin{aligned} \int_0^1 \int_0^{1-u} (T_{i0x} + u\Delta_{i1x} + v\Delta_{i2x}) , \mathrm{d}v , \mathrm{d}u ={}& T_{i0x} \int_0^1 \int_0^{1-u} \mathrm{d}v , \mathrm{d}u \ &+ \Delta_{i1x} \int_0^1 \int_0^{1-u} u , \mathrm{d}v , \mathrm{d}u \ &+ \Delta_{i2x} \int_0^1 \int_0^{1-u} v , \mathrm{d}v , \mathrm{d}u \end{aligned} ]

[ = T_{i0x}\left(\frac{1}{2}\right)

  • \Delta_{i1x}\left(\frac{1}{6}\right)
  • \Delta_{i2x}\left(\frac{1}{6}\right) ]

[ = T_{i0x}\left(\frac{1}{2}\right)

  • (T_{i1x} - T_{i0x})\left(\frac{1}{6}\right)
  • (T_{i2x} - T_{i0x})\left(\frac{1}{6}\right) ]

[ = T_{i0x}\left(\frac{1}{6}\right)

  • T_{i1x}\left(\frac{1}{6}\right)
  • T_{i2x}\left(\frac{1}{6}\right) ]

[ = \frac{1}{6}(T_{i0x} + T_{i1x} + T_{i2x}) ]

Substituting into the original sum and pulling out a constant factor of (\frac{1}{6}) to avoid the inner loop division, this yields the following compact formula for the volume:

[ V = \frac{1}{6} \sum_i (\Delta_{i1} \times \Delta_{i2})x (T{i0x} + T_{i1x} + T_{i2x}) ]

Performance analysis

The final algorithm contains no numerical integration nor differentiation. In contrast to common naive algorithms for volume, which are equivalent to rendering the mesh and then sampling the render, an expensive operation, there is only a single loop in this algorithm, over the triangles. Thus, this algorithm for volume computation is (O(n)) to the number of the triangles. Furthermore, the per-triangle calculation is similarly efficient: given the natural expansion of the cross product, the inner part contains seven additions and three multiplications. On the outside of the loop is only a single multiplication. Thus, for a mesh of (n) triangles, the algorithm requires (8n - 1) additions and (3n + 1) multiplications, or (11n) floating point operations. This is very fast.

For a ballpark number, if volume needs to be calculated every frame in a high-performance 60 frames per second application, without the aid of a GPU, only using the CPU capabilities of a $35 Raspberry Pi, around 30 million triangles could be measured every frame.

Motivation

The vector calculus exam is soon, and I need to study. Plus, who doesn’t love 3D graphics?!

I would be (pleasantly) surprised if the algorithm is novel. Further research after posting reveals the paper Efficient Feature Extraction for 2D/3D Objects in Mesh Representation by Cha Zheng and Tsuhan Chen, which appears to describe the same algorithm, although the derivation is different. It was fun while it lasted!

The Daily Front Page 10 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Curves Department
article

Curvature Beziers: Improving on a timeless recipe

by leephillips·▲ 118 points·13 comments·acko.net ↗
The bezier curve is a staple of CAD and computer graphics.

Improving on a timeless recipe

Cover Image - Renault 4CV

The bezier curve is a staple of CAD and computer graphics. Like Bic pens, the design is decades old and they're everywhere. You'll often find them as the default or only choice in various illustration and animation tools.

Conceived by Paul de Casteljau in 1959, and refined by Pierre Bézier in the 1960s at Renault, the enduring appeal of the bezier curve lies in its simplicity. While more sophisticated curves have been invented, and new ones continue to be proposed, these are limited to specific domains, like high-precision CAD or road design. In general use, the bezier stubbornly refuses to be dethroned, despite its shortcomings.

Hence bezier curves are a piece of legacy tech we appear to be stuck with. As a software engineer, my question then is: can we make beziers better without invalidating all the tech built on and with them?

The answer is yes.

Renault 4CV Source

Lerp-a-derp

Drawing a bezier curve is a surprisingly simple and linear process:

Tip: All the diagrams in this post are fully interactive.

Given a series of control points, we connect them with lines. We then run along those lines simultaneously, to produce new points, which can be connected again. This process is repeated until we are left with a single point, which lies on the curve.

This construction makes beziers far more regular than they might first appear.

The linear interpolations (aka lerps) can be summarized into a single compact formula, e.g. for 4 control points $ \left(A, B, C, D\right) $:

$$ \gamma \left( t \right) = A \cdot \left(1 - t\right)^3 + B \cdot 3 \left(1 - t\right)^2 t + C \cdot 3 \left(1 - t\right) t^2 + D \cdot t^3 $$

The rule is simple: descending powers of $\left(1 - t\right)$, ascending powers of $t$, with coefficients taken from the n'th row of Pascal's triangle:

$$ \begin{array}{ccccccccccccc} &&&&&& 1 \\ &&&&& 1 && 1 \\ &&&& 1 && 2 && 1 \\ &&& 1 && 3 && 3 && 1 \\ && 1 && 4 && 6 && 4 && 1 \\ &1 && 5 && 10 && 10 && 5 && 1 \\ ... &&&&&& ... &&&&&& ... \\ \end{array} $$

For curves in 2D and 3D, the formula is applied to the individual X, Y or Z coordinates.

While beziers can be constructed for any number of control points, the common practice is to only use cubic beziers with 4 control points. This is because the curve is only guaranteed to cross through the first and last control point, which makes higher degree beziers more difficult to shape.

Larger curves are instead constructed by joining together multiple cubic bezier segments, with the tangents lined up to create a segmented curve that appears smooth:

This is the cubic bezier spline, as commonly understood. The precision "pen tool" in most drawing apps then consists of drawing and editing the control points, rather than drawing curves directly.

A Lie Told Everywhere

Pen tools typically have a few different modes for the control points:

Intuitively these represent various degrees of smoothness. Symmetric tangents are offered as the smoothest option, with some qualities of smoothness being lost as you relax the constraints.

In reality this is completely wrong, and this is easy to demonstrate.

Bezier curves can be split exactly, by reading off the new control points from the interpolation diagram:

The left and right segments are 100% identical to the original curve, and always join up perfectly at the seam. Yet the tangents in the middle will be asymmetric except for one split near the middle. This can be confirmed using a curvature comb which represents the (inverse) radius of curvature at every point:

The curvature comb remains continuous, with no jumps.

This means that whether or not adjacent tangents are of equal length, i.e. symmetric, is completely irrelevant. Attempting to draw smooth and intuitive bezier curves this way is a fool's errand.

A simple way to improve this is to treat the tangents as relative rather than absolute. e.g. We can make them proportional to the distance between the start and end of each segment:

This spline is easier to edit, because as you move each curve point around, the adjacent segments naturally flex to get out of the way. There are far fewer cusps created this way. Editing the tangents remains the same.

However if we plot curvature again, we can tell this isn't a great solution:

Scaling tangents proportionally doesn't guarantee that curvature is preserved as you edit, nor does curvature remain continuous from one segment to the next.

This also shows that offering users a curvature comb visualization as a "helpful tool" is really quite mean: adjusting the curvature on one end will also affect the other side, requiring repeated adjustments back and forth until it's close enough.

Handle Carefully

A much more effective strategy is to work with curvature directly.

While this is a difficult problem in general, it turns out there are some surprising relationships here, which we can observe directly:

Consider the curvature at the start of segment $A-B-C-D$. This is affected only by the positions of $A$, $B$ and $C$. Point $D$ can be moved freely if it's detached from $C$.

Furthermore, because the tangent $A-B$ is horizontal, only the vertical position of $C$ matters. This is a result of the underlying linear interpolations, which end up cancelling out a lot of terms in the formulas.

The curvature at $A$ is therefor only affected by the length of $A-B$, and the perpendicular distance from $C$ to $A-B$. The same applies to $D$ on the other side with $C-D$ and $B$.

This isn't very useful by itself though. When we move a curve point ($A$ or $D$), typically the adjacent control point ($B$ or $C$) is moved as well to preserve the tangent. And when we turn a symmetric or asymmetric tangent, the adjacent tangent in the next segment is turned by the same angle, altering the curvature on that side.

Still, this shows that preserving curvature is not by itself a crazy idea and can be done simply by scaling the tangents appropriately. The rules would be simple:

  • When we move a curve point, we have to preserve the start and end curvature in the adjacent segments
  • When we move a tangent, we have to preserve the curvature on the opposite end of the current segment, as well as on both sides of the adjacent segment

This ought to produce an editing experience where the curve actually respects your intent. Except not quite:

Moving curve points works great, but when turning a tangent, the length of that tangent is itself a poor representation of the user's intent. Small changes can cause huge shifts in curvature, which can cause the curve to jump around and explode unexpectedly as it tries to find a matching solution.

Hence it's better to work with curvature handles instead, where the length corresponds directly to curvature:

Unlike the curvature comb, the length of the handles is the non-inverted radius of curvature, which is the more natural choice.

These handles are very stable and can be converted just-in-time to classic bezier control points, without needing to round-trip back and forth between the two representations. Helpfully, this also avoids numerical drift.

Goldilocks

To actually pull this off, we need to solve for the lengths $l_0$ and $l_1$ of the tangents, given the desired curvatures $k_0$ and $k_1$, the start/end points $A$ and $D$, and the unit-length tangents at the start/end.

Given a curve $\gamma\left(t\right)$, we can express the unit tangent vector $\mathbf{T}\left(t\right)$ as the normalized derivative:

$$ \mathbf{T}\left(t\right) = \frac{\displaystyle \gamma'\left(t\right)}{\displaystyle |γ'\left(t\right)|} $$

This can be used to find the curvature vector $\mathbf{K}\left(t\right)$ via two vector cross products using the first and second derivative:

$$ \mathbf{K}\left(t\right) = \mathbf{T}\left(t\right) \times \frac{\gamma''\left(t\right)}{|\gamma'\left(t\right)|^2} \times \mathbf{T}\left(t\right) $$

The cross products ensure that $\mathbf{K}\left(t\right)$ is perpendicular to $\mathbf{T}\left(t\right)$, i.e. they extract the normal vector component of the middle term. Now we can solve for $\mathbf{K}\left(0\right) = k_0$ and $\mathbf{K}\left(1\right) = k_1$.

After working through the math, we end up with a quadratic system of equations in $l_0$ and $l_1$:

$$ \begin{cases} a_0 \cdot l_0^2 + b \cdot l_1 + c_0 = 0 \\[0.3em] a_1 \cdot l_1^2 + b \cdot l_0 + c_1 = 0 \end{cases} $$

Where:

$$ \begin{array}{lcl} a_0 & = & ±|k_0| \\[0.3em] a_1 & = & ±|k_1| \\[0.3em] b & = & 2 \cdot |\mathbf{T}(0) \times \mathbf{T}(1)| \\[0.3em] c_0 & = & 6 \cdot |\mathbf{T}(0) \times (D - A)| \\[0.3em] c_1 & = & 6 \cdot |\mathbf{T}(1) \times (A - D)| \\[0.3em] \end{array} $$

This captures a few things:

  • The sign of the curvature $k_i$ defines whether the curve turns clockwise or counterclockwise. When moving curve points around, the curve may be forced to flip, hence the $±$ is necessary, and both signs can change independently.
  • The coupling between $l_0$ and $l_1$ is influenced only by $b$. If $b = 0$, then the two equations are independent and the problem is trivial to solve. This corresponds to the situation where the two tangents are parallel.
  • The constant term $c_i$ is influenced only by the perpendicular distance $D - A$ (or $A - D$) to the tangent $\mathbf{T_i}$. This matches the earlier finding that only perpendicular distance affects curvature.

Hence, the problem is reduced to finding the intersection of two double-parabolas, one horizontal and one vertical:

The two sides of each double-parabola represent bending clockwise or counterclockwise. We have to solve 4 times, one for each sign combination $\left(+,+\right)$, $\left(+,-\right)$, $\left(-,+\right)$, $\left(-,-\right)$.

To solve this system, we can rewrite either of the equations to isolate $l_1$ or $l_0$:

$$ l_1 = \frac{\displaystyle -a_0 \cdot l_0^2 - c_0}{\displaystyle b} \\[0.5em] l_0 = \frac{\displaystyle -a_1 \cdot l_1^2 - c_1}{\displaystyle b} $$

Pick one, and square it to plug it into the other original equation as the $l_1^2$ or $l_0^2$ term. This produces a quartic equation in the other variable (resp. $l_0$ or $l_1$), which can be solved directly using the quartic formula.

We can then compute the other $l_i$, either:

$$ l_1 = \sqrt{\frac{\displaystyle -b \cdot l_0 - c_1}{\displaystyle a_1}} \\[0.5em] l_0 = \sqrt{\frac{\displaystyle -b \cdot l_1 - c_0}{\displaystyle a_0}} $$

Not all solutions of the quartic will be actual solutions to the system however, because of the squaring. So we have to double check that the original equations hold before accepting a solution for $\left(l_0, l_1\right)$.

We also want to reject solutions where $l_0 < 0$ or $l_1 < 0$, because these represent situations where the tangents have been flipped by 180º.

In most cases, there will only be one valid solution, and this works pretty well:

For corner-type points, one or both $k_i$'s are infinite. This is straightforward to solve as the matching $l_i$ is zero and the other can be computed directly.

Grouper and Snapper

Unfortunately if there are multiple solutions, these each represent a different curve:

Having the curve jump around as you edit it would be a very bad editing experience, but there is no obvious way to pick the right one.

One strategy would be to remember the previous $l_0$ and $l_1$ as you edit, and pick the solution that is closest to the previous curve. However this would introduce path-dependence into editing, where the order and direction that you moved points around in affects which curve you end up with. For a drawing tool, this is quite frustrating and undesirable.

Different solutions to the equation can also appear and vanish suddenly, so this wouldn't eliminate popping either, merely reduce it.

Ideally the resulting curvatures should always change smoothly themselves. This can be accomplished by designing an appropriate weighting heuristic for the solutions, and calculating their weighted average.

  1. The forbidden regions:

When a solution approaches either $l_0 < 0$ or $l_1 < 0$, it's about to vanish, so its weight should go to zero there.

  1. When two opposite-bending parabolas are about to become tangent, two solutions will move towards each other, before both vanishing at the same time:

These solutions are unstable and should be avoided. To detect this, I calculate the gradient vector of each equation.

$$ \mathbf{g_0} = \begin{bmatrix}2 \cdot a_0 \cdot l_0 & b\end{bmatrix} \\[0.3em] \mathbf{g_1} = \begin{bmatrix}b & 2 \cdot a_1 \cdot l_1\end{bmatrix} $$

The angle between them can be found via their dot product, after dividing by their respective lengths:

$$ \cos \theta = \frac{\displaystyle \mathbf{g_0} \cdot \mathbf{g_1}}{\displaystyle |\mathbf{g_0}||\mathbf{g_1}|} $$

A value close to $-1$ means two opposite-bending parabolas, while a value close to $1$ means two aligned parabolas. The latter is not as bad, as this implies many almost-equivalent solutions.

  1. When the radius of curvature is very big compared to the bezier itself, one of the possible solutions is for the curve to cross through itself, forming a loop. This should be discouraged:

We can divide by the length of $|\mathbf{l}|$ i.e. $\sqrt{l_0^2 + l_1^2}$, preferring solutions that have shorter tangents.

Putting it all together, the weighting heuristic I chose is:

$$ w_{heuristic}\left(\mathbf{l}\right) = \left(\frac{\displaystyle l_0 \cdot l_1 \cdot \arccos\left(-\cos \theta\right)}{\displaystyle |\mathbf{l}|^2}\right)^2 $$

  • By applying $\arccos \left(-\cos \theta\right)$, we remap the dot-product range $(-1..1)$ to $(0..π)$ which effectively neutralizes the unstable solutions
  • Large $|\mathbf{l}|$'s represent undesirable solutions, so should be strongly penalized and only chosen if they are the only option
  • When the entire heuristic approaches $0$, the influence should vanish smoothly, hence the overall squaring

Using this as the weight, the resulting bezier curves always change smoothly, even when the start and end are moved around and through each other.

But when multiple solutions are averaged together, the resulting $(l_0, l_1)$ is not necessarily a solution to the original system. This means the resulting curvatures are not always exact, even when there is an exact solution nearby.

To mitigate this, we can add an additional resampling step, where we re-weigh the solutions according to the inverse distance^4 to the weighted average:

$$ w_{sample}\left(\mathbf{l}\right) = \frac{1}{|\mathbf{l} - \mathbf{l}_{average}|^4} $$

This causes the solution to snap smoothly to exact solutions when available.

Migratory Curves

What's especially nice about this approach is that it can largely be slotted into existing systems with little modification required.

The UI of adjusting and editing bezier handles can be kept, including the notion of the 4 point types. Just the meaning of the lengths of the tangents changes. Converting an asymmetric point to a symmetric point will actually equalize the curvature of the left and right side, which is what the user actually wants.

The internal representation can mostly remain the same type, i.e. a series of points, just those points represent curvature tangents, not bezier tangents. Though it's better to explicitly store the unit length tangents and curvatures directly, which is more numerically stable. For the demos here I made pairwise conversion functions between curvature handles ↔︎ points/tangents/curvatures ↔︎ bezier handles.

Splitting a curvature bezier is a lot simpler than splitting a classic bezier, because the start and end handles don't change at all, and the newly created handles are symmetric:

There is one remaining flaw though. When splitting a curve with an S-bend, the splits near the bend are not exact:

The heuristic picks the wrong curve on one or both sides. This can be fixed by remembering the specific orientation of the curvature, and only flipping the curvature sign when necessary. Though this does introduce some minimal path-dependence into editing.

So really you would need to expose this in the UI as an extra orientation toggle for ambiguous control points. It would also mean that the internal representation has to be in tangent + signed curvature form to be fully stable, not just curvature handles.

Near the S-bend, the radius of curvature—and thus the handle size—effectively becomes infinite, because $|k|$ becomes $0$. The bezier control points lie on a straight line, as perpendicular distance to the tangent is zero.

So even when handled exactly, this can still create impractically large curvature handles. Perhaps what's needed is a 5th "Inflection" point type, for points with exactly zero $|k|$, though such points tend to be very unstable, and sometimes no solution exists:

To migrate a classic bezier to a curvature bezier, you can measure the unit tangents and curvature at the start and end. In the vast majority of cases this will result in the exact same curve. If it doesn't, then you must split the original bezier to avoid the ambiguity.

For complex operations on bezier curves, e.g. boolean union or intersection, these still have to be done in bezier form. This implies some amount of round-tripping between the two representations, which would introduce numerical drift. However, only the newly created points need to be converted back, because the curvature and tangents elsewhere remain the same.


This post started from the observation that "symmetric" bezier tangents aren't actually symmetric as you'd expect. Hopefully you found the resulting exploration enlightening.

The practice of showing curvature combs to diagnose problems with splines is really backwards. If we can show a curvature comb, we can also compute an appropriate spline to match the desired curvature.

So beziers as they commonly exist are quite inadequate. We can retrofit a better system to edit them without breaking the expectations of a smooth editing experience, or introducing a new class of curves that behaves very differently.

The code for the diagrams and implementation can be found on GitLab.

The Daily Front Page 11 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Sounding Off
article

EasyEffects can improve laptop speaker sound quality

by birdculture·▲ 153 points·56 comments·osnews.com ↗
Virtually all laptop speakers suck.

Virtually all laptop speakers suck. It’s the one area where even really expensive laptops tend to fall on their ass, leaving users with a tinny, harsh, and hollow sound experience. While you can’t exactly overcome physics – laptop speakers are necessarily small and thus just cannot ever sound as good as proper speakers – there’s a lot you can do with proper tuning and software magic. If you’re a desktop Linux user, you actually already possess all the plumbing needed to fix your audio; it’s just not exposed to you in any way. Luckily, an application called EasyEffects allows you to actually make use of desktop Linux’ advanced audio features to massively improve the sound quality of your laptop’s speakers.

EasyEffects’ own description on its GitHub page doesn’t really explain what it does or what it’s capable of, so here’s the description from Wikipedia instead.

EasyEffects uses PipeWire to process incoming and outgoing audio streams independently and can apply various sound effects in the form of plug-ins made by different developer teams such as Calf Studio Gear, MDA.LV2 and GStreamer. All plugins have their own presets and can be applicable inside the suite rather than having to use a different mixer or executing a script from the command line.

Available output effects are limiter, auto volume, compressor of dynamic range, filter, 30 bands parametric equalizer, bass enhancer, exciter, reverbation, crossfeed, delay, maximizer and spectrum analyzer. Available input effects are WebRTC, limiter, compressor, filter, equalizer, de-esser, reverbation, pitch shift and spectrum analyzer.

↫ EasEffects’ Wikipedia page

None of this matters, and you can forget everything from these two paragraphs.

What matters is that using EasyEffects, you can tune the audio coming out of your speakers to make them sound a lot better. The few laptops on the market that do have decent audio – MacBooks, some Dell XPS laptops, and surely a few more – aren’t magically defying physics. While they probably do have objectively higher-quality speakers, the main difference between those laptops and laptops with crappy-sounding speakers is that the former come with built-in tuning from the factory to make them sound much better than they would without any software trickery.

If you know your way around audio, you can very much use EasyEffects and tune your laptop speakers from scratch to massively improve how they sound. However, that requires time, experience, knowledge, and expertise that most people lack, including myself. Lucky for us, though, there are countless downloadable presets out there for EasyEffects designed specifically to make laptops sound better.

In an ideal world, you’d pick a preset created specifically for your laptop make and model, but odds are you won’t find one, so for most laptops you’ll have to settle for a generic preset that tries to do its best. I’ve long settled on the Advanced Auto Gain.json preset from JackHack96, which greatly improves the audio performance on any laptops I’ve tried it on, but of course, there’s countless other presets for you to try to see if there’s anything that suits your particular laptop and ears better.

Getting all of this up and running is really easy. EasyEffects is most likely packaged by your Linux distribution, and the latest version is always available as a Flatpak from Flathub. Download the preset(s) you want to try, copy them either to ~/.config/easyeffects (if you use your distribution’s package) or to ~/.var/app/com.github.wwmm.easyeffects/data/easyeffects/output/ (if you use the Flatpak version). They’ll show up right away in the Presets tab in EasyEffects, ready to be turned on and off whenever you want, making it very easy to compare and contrast to find the one you like best. EasyEffects can live in your system tray giving you easy access to your presets without having to open the main window, and it can be set to start automatically at boot. EasyEffects can also be turned on and off on the fly.

There’s obvious downsides to all of this, too, of course. First, since you’re most likely going to be using a generic preset not specifically crafted for your laptop, there’s no guarantee the results will be positive for you. Second, not every preset is ideal for every type of audio. Most of my audio consists of YouTube videos with mostly speech; if you listen mostly to music, different presets may yield better results. Third, audio quality is deeply subjective, and what sounds good to my ears may sound like total garbage to yours. Fourth, EasyEffects does take up a tiny fraction of CPU power (I’m talking 0.1-0.2% according to KDE’s System Monitor), but I have never seen it have any noticeable performance impact on anything.

Even the generic preset I use makes such a massive difference for me on every laptop I’ve ever tried it on, that I’ve become convinced EasyEffects and a few of the generic presets should be installed by default by any desktop-oriented Linux distribution. On top of that, Linux laptops OEMs like System76, Nova Custom, Star Labs, and so on, should really take the time to create proper presets for their laptops to improve their sound quality out of the box. I feel like if you’re already designing and selling laptops, you probably also have the skills and means to create a decent preset.

In fact, I’d take it a step further and urge desktop environments like KDE and GNOME to properly integrate EasyEffects into their sound settings. They shouldn’t include the entire application and its user interface, but should make it so that you can configure and manage presets right from the sound settings panels, and switch between presets from their volume applets (as well as turn it off entirely, of course). This would leave the full EasyEffects application for people who need more control, manual tuning, and more advanced features.

There’s absolutely no reason why speakers on Linux laptops should sound tinny, harsh, and hollow. The Linux desktop has all the technologies and features built right in to make speakers sound much better than they do without any tuning, and yet, very few people seem to actually be aware of this. This needs to change, and I think it’s up to distributions, desktop environments, and Linux OEMs to make this happen.

The Daily Front Page 12 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Science, by Agent
article

Terminal-Bench-Science: Evaluating AI agents on scientific research workflows

by matt_d·▲ 115 points·35 comments·terminal-bench-science.ai ↗
Scientists, not model developers or data vendors, set the bar for scientific capability in AI.

Terminal-Bench-Science evaluates AI agents on workflows from researchers' own work. Scientists, not model developers or data vendors, set the bar for scientific capability in AI.

Terminal-Bench-Science is a benchmark led by researchers at Stanford University and built by the team behind Terminal-Bench in collaboration with domain experts from a range of scientific disciplines and research institutions around the world. It measures the AI agent capabilities through a diverse set of challenging, expert-curated workflows drawn from scientific research.

Terminal-Bench-Science is a continuous benchmark that evolves alongside frontier AI, creating a feedback loop between scientific needs and AI development. Our first release includes 70 tasks from the life, physical, Earth, mathematical, and engineering sciences. The strongest model evaluated, Claude Opus 5, achieves a 30% resolution rate on Terminal-Bench-Science 0.1.

Overview

While Terminal-Bench has driven progress in AI agents for software engineering, Terminal-Bench-Science brings the same ambition to science. Our goal is to drive the development of agents with scientific capabilities that make them useful research assistants. These agents should execute technically demanding and time-consuming workflows, freeing scientists to focus more of their time on the parts of science where human judgment matters most: defining research questions, forming hypotheses, interpreting and validating results, and communicating findings. In this role, AI agents can extend what researchers accomplish and help accelerate scientific discovery.

Achieving this requires benchmarks that reflect real scientific practice, provide verifiable evidence of capability, and evolve alongside the AI frontier.

We need benchmarks drawn from real scientific workflows. Scientific capability should be evaluated on real research practice, not textbook questions or standardized exercises, contributed by practicing scientists themselves. Terminal-Bench-Science gives scientists across domains a direct voice and a shared platform to set the bar for AI progress on the problems they care about. The stakes in science are too high, and its benchmarks must reflect the scientific community's priorities rather than outside interests.

We need verifiable evidence of scientific capability. Without reliable evaluation, we cannot tell whether agent capabilities are improving or where their limitations remain. Terminal-Bench-Science evaluates agents in realistic environments and grades concrete artifacts such as analyses, simulations, proofs, code, and data products with reproducible, task-specific tests.

We need a benchmark that keeps pace with the frontier. Too often, scientific benchmarks are treated as papers to publish rather than mechanisms for driving progress. They are released once and then abandoned as models advance and known limitations persist. Terminal-Bench-Science is a continuous benchmark that evolves alongside the AI frontier. Through regular releases, scientists can contribute new workflows, improve existing tasks, and create a feedback loop between scientific needs and AI development.

Terminal-Bench-Science Feedback Loop

Tasks

Terminal-Bench-Science 0.1 includes 70 tasks across the life, physical, Earth, mathematical, and engineering sciences. Tasks span scientific data analysis, statistical inference, simulation, optimization, theorem proving, image reconstruction, signal processing, inverse problems, sensor calibration, model fitting, classification, and scientific machine learning.

70 expert-curated tasks across five scientific domains

Tasks are contributed by researchers through an open process on GitHub, with discussion and feedback in the #tb-science channel on Discord. Contributions begin as proposals, where reviewers discuss each idea, leave feedback, and approve those that look like a strong fit: scientifically grounded workflows worth measuring in the benchmark. Approved proposals are implemented as pull requests, where reviewers confirm that each task is objectively verifiable, genuinely challenging for AI agents, and not something today's frontier systems already solve easily. To merge, domain reviewers assess scientific validity and realism, technical reviewers inspect task construction and verification, and a bar raiser performs a final quality check. Of 920 proposals, 464 were approved for implementation and 386 pull requests were opened, but only 70 tasks made it into Terminal-Bench-Science 0.1. That selectivity reflects how difficult it is to create tasks that are scientifically interesting, challenging for frontier agents, and sufficiently well specified for rigorous evaluation. Progress across proposals, pull requests, and reviews is tracked on the public task dashboard.

From 920 task proposals to 70 landing in Terminal-Bench-Science 0.1

World map showing the geographic density of Terminal-Bench-Science proposal and implementation authors using public profile locations and affiliations

World map showing the geographic density of Terminal-Bench-Science proposal and implementation authors using public profile locations and affiliations

376 contributors across 22 countries from proposals, reviews, or pull requests

Results

Terminal-Bench-Science 0.1 leaves substantial room for progress on AI agents for scientific research. Each evaluated model ran three independent trials per task across all 70 tasks. Claude Opus 5 with Claude Code achieves the highest resolution rate at 30.0%, followed by GPT-5.6 Sol with Codex at 22.4% and Claude Fable 5 with Claude Code at 21.4%. Claude Opus 4.8 sits in the middle at 10.5%. GPT-5.6 Terra, Kimi K3, and Grok 4.6 all resolve less than 10% of tasks. GLM 5.3 is the strongest open model at 8.1%, and GPT-5.6 Luna is last at 3.3%.

Terminal-Bench-Science distinguishes between systems about as well as Terminal-Bench 3.0 while pushing resolution rates down by more than 10 percentage points for every model evaluated on both. That gap is deliberate: during review, tasks were calibrated to challenge the newest frontier models.

Resolution Rates on Terminal-Bench 2.1, Terminal-Bench 3.0, and Terminal-Bench-Science 0.1

Performance is only one dimension of progress. The cost-resolution plot shows total evaluation cost across all 70 tasks against resolution rate. GPT-5.6 Luna, Kimi K3, and GPT-5.6 Terra occupy the low-cost end of the frontier. GPT-5.6 Sol and Claude Opus 5 reach the highest resolution rates at greater cost, with Opus 5 at $7.0k. GPT-5.6 Sol matches Claude Fable 5's performance at less than a third of the cost ($4.2k vs $14.2k). Token usage shows a different frontier. Claude Fable 5 matches GPT-5.6 Sol's performance while using about a quarter fewer tokens (6.4B vs 8.4B). Kimi K3 anchors the low-token end and Claude Opus 5 the high-resolution end. Only Kimi K3 and Claude Opus 5 appear on both Pareto frontiers.

Pareto frontier of cost and resolution rate across evaluated systems

Pareto frontier of token usage and resolution rate across evaluated systems

Resolution rates also vary by scientific domain. Anthropic and OpenAI models take the top two spots in every domain except the engineering sciences, where Grok 4.6 ties GPT-5.6 Sol for second place (14.8%) at lower cost and token usage. Claude Opus 5 leads both GPT-5.6 Sol and Claude Fable 5 in every domain except the mathematical sciences, where Claude Fable 5 (33.3%) and GPT-5.6 Sol (31.4%) take the top two spots. The full breakdown by domain is available on the leaderboard.

Domain resolution rates: Opus 5, GPT-5.6 Sol, and Grok 4.6

Conclusion and Roadmap

Terminal-Bench-Science 0.1 is a community effort by researchers across the life, physical, Earth, mathematical, and engineering sciences, together with the Terminal-Bench and Harbor team. It is the most rigorous benchmark of scientific agent capabilities we could build in the open, and we are only getting started: Terminal-Bench-Science 0.1 is the first release of a continuous benchmark.

Regular releases will add tasks, broaden coverage across the five scientific domains, retire tasks that agents saturate or that review reveals to be underspecified, and keep the leaderboard current as new frontier models are released. Each release is calibrated against the frontier at the time. For Terminal-Bench-Science 0.1, this was Claude Opus 5 and GPT-5.6 Sol, and as stronger models emerge we will use them to evaluate and calibrate new and improved tasks. Tasks are versioned so that trials can be re-used, re-graded, or re-run with a single Harbor command, which keeps the cost of updating results low. Progress is tracked in the open on the task dashboard, and every release is tagged on GitHub and Harbor Hub.

Work on Terminal-Bench-Science 0.2 is already underway, with a pull request deadline of October 5, 2026. If you are a researcher with a workflow that frontier agents should be able to do but cannot yet, we want it in the benchmark. The contribution flow is Propose → Build → Review: propose your task through the task proposal form, build it following the contributing guide, and it will go through automated checks, parallel domain and technical review, and final bar-raiser approval before merge.

Join the effort in #tb-science on Discord and on GitHub, and drop into our weekly meetings and office hours via the project calendar. Let's let scientists define what scientific capability in AI looks like, and measure it rigorously, together.

Citation

If you find this work useful, please cite it. You can use the "Cite this repository" button on GitHub (generated from CITATION.cff) or cite manually using the information below.

@software{Terminal-Bench-Science_Team_Terminal-Bench-Science_Evaluating_AI_2026,
  author = {{Terminal-Bench-Science Team}},
  doi = {10.5281/zenodo.22110254},
  license = {Apache-2.0},
  month = aug,
  title = {{Terminal-Bench-Science: Evaluating AI agents on research workflows across scientific domains}},
  url = {https://github.com/harbor-framework/terminal-bench-science},
  version = {v0.1.0},
  year = {2026}
}

Acknowledgements

Thank you to all of the task contributors, reviewers, and advisors behind Terminal-Bench-Science.

Special thanks to our project lead advisors Ludwig Schmidt and Sanmi Koyejo; our senior reviewers Allen Hart, Ivan Bercovich, Joseph Janssen, Jiaming Hu, Steffen Bollmann, and Sergey Aganezov; our AI research advisors Ryan Marten, Alex Shaw, Lin Shi, Benjamin Feuer, Mike A. Merrill, Alex Dimakis, Jenia Jitsev, Bodhisattwa Majumder, Peter Clark, Thomas Wolf, Braden Hancock, and Andy Konwinski; and our scientific advisors Sara Beery, Jo Dunkley, J. Nathan Kutz, Ching-Yao Lai, Scott Linderman, Emma Lundberg, Russ Poldrack, Aviv Regev, and Risa Wechsler.

Terminal-Bench-Science is an open academic collaboration hosted by Stanford University and the Laude Institute, in partnership with the Stanford AI Lab (SAIL), the Stanford Institute for Human-Centered Artificial Intelligence (HAI), Stanford AI Measurement Science (AIMS), the NSF AI Institute for Foundations of Machine Learning (IFML), the Allen Institute, and the Allen Institute for AI (Ai2). As part of the Terminal-Bench franchise, it is built by the Terminal-Bench and Harbor team together with a community of scientific contributors.

We thank the Laude Institute for support through the Slingshots program, Snorkel AI for support through the Open Benchmarks Grants program, the 2077AI Open Source Foundation for PP API credits supporting task review and curation, and UniPat AI and Modal for their support of Terminal-Bench-Science. We thank Bespoke Labs, Anthropic, Google, Moonshot AI, SpaceXAI, and Z.ai for API credits supporting leaderboard evaluations.

The Daily Front Page 13 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — The Open Internet Ledger
article

Select * from Internet.blogposts

by mmattbtw·▲ 130 points·61 comments·pfrazee.leaflet.pub ↗
Nitter gets a cease & desist from X while the atproto makes the Internet more open.

Nitter gets a cease & desist from X while the atproto makes the Internet more open.

In 2007, Tim Berners Lee write the essay The Giant Global Graph. Quote:

There are cries from the heart .. for my friendship, that relationship to another person, to transcend documents and sites. ..Then any other site or program can use that information.

It seems appropriate as X is sending cease-and-desist letters to Nitter to remember TBL's essay. Nitter is - was - a simple frontend to X which allows users to view tweets without logging in. Even that small use of proxying to the pages is enough to receive threats of legal action.

Twitter's API in 2007 was famously open, which meant thousands of developers building clients, tools, and analytics for free. So, what happened? Why was it pulled? Simple: the network won. The developers stopped being an asset, and the API progressively closed. Rate limits, pricing tiers, login requirements, then technical blocks on the workarounds, and now letters from lawyers. Meta ran the same playbook a decade ago and it's now hard to remember there was ever a Facebook or Instagram API worth building on.

This is why Brewster Kahle, founder of the Internet Archive, has been calling for over a decade for us to lock the Web open.

Nitter started off using X's APIs. When that closed, it read public web pages. And now that there's nothing left to close, the demand is that the source code come down. A program that displays public posts is being treated as a circumvention device under computer-crime statutes.

We have a walled garden problem. It isn't going to change, and the only option in front of us is to start fresh.

The good news is, atproto continues to grow, activitypub remains resilient, and our community is full of believers and builders in the open social web. Since I work on atproto, that's what I'll talk about next.

Interoperation by SELECT *

SELECT * FROM internet.blogposts

The walled garden problem is downstream of a simple question: how do I SELECT * FROM internet?

If you've never written database code, SELECT * FROM users is how you ask a database for everything it knows about its users. Once you have it you can filter it, sort it, and join it against anything else you've got.

The web doesn't historically work that way. The web is a few dozen companies, each holding a filing cabinet, each with a receptionist posted out front. He'll read you one file at a time, but only files you can name, as fast as he cares to read, and as long as his boss allows.

Nitter was a lightweight X reader that worked fine right up until X turned off the access it depended on. Every API (the "receptionist") is a business decision that hasn't been reversed yet.

But Impermanence isn't the only problem. Even a permanent, free, generously rate-limited API wouldn't be enough. Applications need much more meaningful access than APIs can provide.

  • You can only ask questions someone already thought to answer. An API is a fixed menu. It gives you getPosts(user) and getFollowers(user). If your product idea needs "posts from people my followers follow, ranked by how often they get quoted," there is no endpoint for that, and there never will be, because nobody at that company is building for your product.
  • Even the right questions come back in the wrong shape. Followers come 100 at a time. A two-million-follower account is 20,000 round trips. At any polite rate limit that's hours of work to answer one question about one user — so anything interactive, anything that has to feel instant, is off the table before you start.
  • You can't join across "cabinets". The interesting questions are almost always cross-service: this person's posts against that person's photos against a third service's reviews. Two receptionists in two buildings can't cross-reference anything, and neither can you.
  • You can't index data you don't hold. Search, ranking, recommendations, feeds, moderation tooling — all of it is built on indexes over the whole corpus, laid out for the specific questions your product asks. You cannot build an index through a keyhole.

To actually build a service, we need the whole dataset rather than a view onto it; we need it live, arriving as it changes instead of polled for; we need to index it however my product demands; we need to write back into it; and we need all of that guaranteed in a way no single company's quarterly priorities can revoke.

Desktop apps handle this by sharing the filesystem. Internet apps don't use files; they use databases. We need to share the database.

As a user, I don't want to be locked into an app anymore than I'd want to be locked in the trunk of a car. I want an actual free market.

So then, here's another set of needs.

  • Persistence of identity.

    • My presence and relationships are built around my identity. It needs to outlive the app I signed up with.
  • The export of living (not dead) data between services.

    • Exporting archives of your tweets is useless as an account migration solution because data doesn't live in isolation.
    • If data is no longer operable - capable of additional operations by participants in the network - then it's a static archive and useless to another application.
    • You could always print your tweets and look at them I guess.

If we want data to remain operable even outside of its original service, then we need to share the database.

These are all issues atproto is designed to solve, including open data access, account migration, and a live firehose of network activity.

How atproto makes SELECT * FROM internet happen

How do we share the database? We don't. We share a lot of them. We create a whole network of personal data servers (PDS) which applications interact with.

How do we handle apps sending complex SELECT * queries to our personal data servers? We don't. We replicate the data on logs. We have each application aggregate copies of the data to query locally.

How do we have apps write to those databases? In this case- we do! We have the apps send writes to the PDS, which in turn replicate back out to the other apps.

This last one is the core of the intuition about atproto: the write/ingest loop. Almost every atproto app has code that looks like this:

// write
pds.putRecord(post)

// ingest
onPut(‘app.bsky.feed.post’, evt => {
  mydb.put(‘posts’, {...})
})

Rather than waiting for the ingest to come back over the wire, you can use a "short circuit" so your app's database can update more quickly. The 200 OK from the PDS is a transactional go-ahead.

And so the more efficient pattern looks more like this:

// write
pds.putRecord(post)
mydb.put(‘posts’, {...}) // ← optimistic

// ingest
onPut(‘app.bsky.feed.post’, evt => {
  mydb.put(‘posts’, {...})
})

Does it work?

Yes. The network exists. It's live, it's public, and you can read all of it right now — from a laptop, without asking anyone's permission. This is exactly how Bluesky, Tangled, Leaflet, and a bunch of others work now.

Let me hit you with some stats. At time of writing, there are:

It's never been easier to tap into the data with the new jetstream service.

import { Jetstream, isCreate } from '@bsky/jetstream';
import { app } from '@bsky/sdk/lexicons';

const jetstream = new Jetstream('https://jetstream.us-east.bsky.network');
const collections = [app.bsky.graph.follow, app.bsky.feed.repost, app.bsky.feed.post];

for await (const event of jetstream.live({ collections })) {
  if (isCreate(event, app.bsky.graph.follow)) {
    console.log(`🌱  ${event.did}  follows  ${event.commit.record.subject}`);
  } else if (isCreate(event, app.bsky.feed.repost)) {
    console.log(`♻️  ${event.did}  reposts  ${event.commit.record.subject.uri}`);
  } else if (isCreate(event, app.bsky.feed.post) && event.commit.record.reply) {
    console.log(`💭  ${event.did}  replies  ${event.commit.record.reply.parent.uri}`);
  }
}

If you want a fast way to get into it, try it out here.

Stop getting cease & desists. SELECT * FROM internet.blogposts instead.

And, oh, if you're looking specifically for blogposts on atproto, you probably want to use standard.site.

👉 Follow me on Bluesky.

The Daily Front Page 14 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Packaging the Commons
article

Sovereign Tech Agency invests €500k in Flatpak

by eigenspace·▲ 258 points·135 comments·modal.cx ↗
A significant investment of €508,640 ... into the development and stewardship of Flatpak.

Announcing Sovereign Tech Agency Investment in Flatpak

We are excited to announce a significant investment of €508,640 by the German Sovereign Tech Agency, through its Sovereign Tech Fund (STF) initiative, into the development and stewardship of Flatpak. This two-year initiative, co-organized by Modal and with Para-Real Ltd. as supporting organization, will accelerate the evolution of Flatpak as a secure, sandboxed platform for packaging and distributing Linux desktop software.

Flatpak serves as the primary application distribution method for image-based operating systems including Fedora Silverblue, openSUSE Aeon, SteamOS, and GNOME OS. It is the preferred format for major ecosystems such as GNOME, KDE, and elementary. By expanding Flatpak’s capabilities, this investment will directly improve the security, robustness, and overall user and developer experience of the Free Software desktop ecosystem.

Are We Sandboxed Yet?

Flatpak is a mature project and the best option that exists on GNU/Linux today, but its security and sandboxing features still trail behind those of well-funded proprietary platforms such as Android and iOS. Certain technical limitations persist, such as the inability to separate audio output from microphone access—and several critical areas, including networking and VPNs, still lack dedicated Portals.

Following significant progress made during the 2023/2024 GNOME STF project, development has slowed in recent years, due to the specialized expertise required for this kind of platform-level work and the limited capacity of the overstretched Flatpak maintainers. This hinders the adoption of secure, image-based operating systems that rely exclusively on Flatpak apps.

A Collaborative Effort

For Modal, a robust app sandboxing story is essential to creating a Free Software OS that is competitive with modern mobile platforms. Leveraging our experience co-organizing STF projects for GNOME and systemd, we have partnered with other community members to put together this new initiative to push the ecosystem forward.

The project is led on the technical side by Sebastian and Adrian, with organizational support from Kateryna and Cade. While Para-Real Ltd. serves as the supporting organization, we hope to use this investment to build long-term community capacity by growing the pool of people who know this part of the stack, and putting in place more formal structures for the Flatpak project.

We are proud to bring on board a team of experienced contractors for the technical execution: Philip Withnall, Julian Sparber, and Dhanuka Warusadura from the 2023/2024 GNOME STF project, alongside Zelda Ahmed, Ignacy Kuchciński, Hari Rana, Eva (of Bazaar), and veteran GNOME designer Sam Hewitt. The project will ramp up over the coming months and is expected to run through the end of 2027.

Technical Roadmap

The Sovereign Tech Agency has commissioned work towards closing critical gaps in the sandboxing story, introducing long-requested infrastructure, and ensuring general maintenance.

We’ll focus on the following areas:

New Portals

  • Audio: Implementation of a new static socket permission for PipeWire, a WirePlumber policy to manage device access, and a portal for setting audio permissions (e.g. allowing speaker access without granting microphone access).
  • Network: Isolation of networking from the host with new static permissions for specific scopes (host, local network, internet) and ports, preventing unnecessary exposure of local devices.
  • VPN: A new portal modeled after Android and iOS APIs, enabling third-party VPN apps to manage system-level connections.
  • Writing Assistance: A new portal for spell checking, allowing for all apps on the system to share a dictionary, even when sandboxed. Additionally, this could allow apps like Eloquent to hook into the portal and provide richer editing suggestions, such as grammar corrections.
  • Password Auto-Fill: Research and architectural design for a secure password auto-fill portal to replace current insecure NativeMessaging approaches.

Infrastructure and Maintenance

  • Entitlements: A new system for declaring static permissions for specific portals, allowing app store reviewers to verify capabilities and enabling the introduction of more advanced features like third-party accessibility tools.
  • Intents: An abstract system for apps to declare offered services, facilitating deep-linking to sub-pages or handling specific web URLs natively.
  • Portals Maintenance: Porting to libdex, adding integration tests, and improving system permission dialogs.

Watch This Space

As design and implementation begin, these plans may evolve. We invite the community to follow our progress and engage with us on Matrix in #flatpak:matrix.org and #xdg-desktop-portals:matrix.org.

Stay tuned for more!

The Daily Front Page 15 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — The AI Engineer’s Workbook
repository

AI Engineer Notebooks – free, framework-free RAG/agents/evals on Colab

by calmrocks·▲ 111 points·14 comments·github.com ↗
★ 489⑂ 33 forks Jupyter Notebook

Hands-on, framework-free Colab notebooks for the AI Engineer / Forward Deployed Engineer (FDE) skill set — model APIs, structured output, tool calling, RAG, evals-as-the-spine, agents (loop from scratch, tool design, guardrails, MCP, Skills), fine-tuning vs LoRA, prompt-injection/security, LLMOps, and customer craft. Runs on the free Groq API.

License: MIT Open In Colab GitHub stars

Learn the applied-LLM stack the way you'll actually be interviewed on it: framework-free, on a free API, from prompting all the way to serving, fine-tuning, and a red-team benchmark.

Runnable Colab notebooks for the AI Engineer / Forward Deployed Engineer (FDE) skill set. You build working systems on top of foundation models (model APIs, RAG, evals, agents, adaptation, serving) using raw APIs, not frameworks.

What makes this different

  • Framework-free, on purpose. You write the agent loop, RAG, and evals from raw API calls first, so you understand what LangChain/LlamaIndex actually do before you reach for them (and can judge when not to). Patterns are durable; wrappers churn.
  • Evals are the spine. "Measure before you tune" is installed early and returns in every section. It's the habit that separates an engineer who shipped a system from one who built a demo.
  • Free to run, end to end. Everything runs on the free Groq API (no credit card). The two topics Groq can't host, LoRA fine-tuning (06) and self-hosted serving (09), are concept-first with optional, fenced Colab-GPU appendices that were verified on a real Colab T4.
  • Real case studies, not toy demos. Three end-to-end case studies show the skills combined under real constraints: a support assistant debugged in production, a pipeline-vs-agent cost showdown, and a red-team robustness benchmark.
  • OpenAI-compatible throughout, so every pattern transfers directly to OpenAI and (with small changes) Anthropic. Swap the base URL and the skills carry over.

Built as the hands-on companion to Plan: Transitioning to Forward Deployed Engineer / AI Engineer. The plan explains what to learn and why; these notebooks are where you run it.

Who this is for

Backend or full-stack engineers moving into AI Engineer, FDE, Applied AI, or Solutions Engineer (AI) roles. Different titles, largely the same job. You can ship production code; you want the applied-model layer on top.

Learning order

Work top to bottom. Each notebook is self-contained (installs its own dependencies, reads API keys from Colab secrets) and ends with exercises.

00 — Setup

Notebook What you'll learn Environment & cost hygiene
Open In Colab API keys via Colab secrets, spend guards, model picking

01 — Model APIs

Notebook What you'll learn Prompting fundamentals
Open In Colab Clear instructions, few-shot, output-format specs, step-by-step reasoning: the cheapest lever, each shown moving a number Structured output
Open In Colab Getting reliable JSON out of a model, and where it breaks Tool calling
Open In Colab Function/tool calling end to end, error paths included Streaming
Open In Colab Streaming responses and what UIs need from them Context & caching
Open In Colab Context-window budgeting, prompt caching, batch vs real-time pricing

02 — Evals I: measuring outputs

Notebook What you'll learn Measuring outputs
Open In Colab Golden sets and metrics on the section-01 task; install the "measure before you tune" habit before building anything you'd need to tune. Evals is the spine; it returns in every section after this

03 — RAG

Notebook What you'll learn What is RAG?
Open In Colab The retrieve → augment → generate loop, why RAG beats a plain LLM, and why RAG isn't the same as embeddings, with a 15-line working demo Embeddings & retrieval
Open In Colab Embedding choice, vector search, similarity pitfalls. Get retrieval working first Hybrid & reranking
Open In Colab Keyword + vector hybrid retrieval, rerankers, when each earns its cost Chunking
Open In Colab Chunking strategies on a real messy corpus, revisited last once you can judge them against retrieval Why RAG fails
Open In Colab Diagnosing bad answers: retrieval quality, not generation, is usually the bottleneck

04 — Evals II: the differentiator

Notebook What you'll learn Golden sets
Open In Colab Building a golden set for the RAG system from section 03 LLM as judge
Open In Colab Judge prompts, agreement with humans, and the judge's own failure modes Regression evals
Open In Colab Evals as CI: catching quality regressions when you change a prompt or model

05 — Agents

Notebook What you'll learn Agent loop from scratch
Open In Colab A working agent loop in raw API calls, no framework Tool design
Open In Colab Designing tools the model can actually use well Guardrails & budgets
Open In Colab Stopping conditions, cost/latency budgets, when a pipeline beats an agent MCP & the tool ecosystem
Open In Colab Concept: what the Model Context Protocol standardizes, how it maps to the raw tool loop, and when to reach for it Skills & progressive disclosure
Open In Colab Concept: packaging reusable know-how an agent loads on demand. The SKILL.md pattern, the context-budget payoff, and Tools/MCP/Skills as one story Harness engineering
Open In Colab Synthesis: the scaffold around the call: context assembly & compaction, tool-result shaping, and verification loops. Names the discipline the section has been teaching piece by piece

06 — Adapting the model

Notebook What you'll learn Fine-tune vs RAG vs prompt
Open In Colab When to change the model's weights vs its inputs; what LoRA/QLoRA are and cost; the argument you'll have in the room, plus an optional real LoRA fine-tune on a free GPU

07 — Security

Notebook What you'll learn Prompt injection & the trust boundary
Open In Colab Direct & indirect prompt injection, output handling, PII, excessive agency. The OWASP LLM Top 10 risks, failing live then defended

08 — Operations

Notebook What you'll learn Observability & LLMOps
Open In Colab Tracing every call, safe prompt logging, cost/latency/error metrics, drift detection, and the observe→eval feedback loop Reliability & fallbacks
Open In Colab Retries with backoff, timeouts, fallback models, output validation, circuit breakers, graceful degradation Experiment tracking & registry
Open In Colab MLflow end to end: log runs/params/metrics from the section-04 eval harness, register and version a model, and promote by stage: the tooling that turns "I ran an eval" into a tracked, reproducible workflow

09 — Serving & inference performance

Where the free Groq API can't run the topic (these frameworks need a GPU), the notebook teaches it concept-first and fences an optional Colab-GPU appendix, the same pattern as the section-06 LoRA appendix.

Notebook What you'll learn Serving frameworks
Open In Colab The serving stack an AI engineer actually picks between (vLLM, TGI, Triton, TensorRT-LLM): what each optimizes, how they map onto the raw API you've been calling, and when to reach for which Inference performance
Open In Colab The levers behind throughput and latency: continuous batching, the KV cache, quantization, and the throughput-vs-latency trade, with the napkin math to size a deployment

10 — ML system design & performance

Notebook What you'll learn Designing an inference service
Open In Colab Concept: the ML system design interview, worked end to end: QPS/VRAM/latency/cost estimation, replica scaling, queueing, caching, and the SLA trade-offs, on a realistic LLM-serving prompt

11 — Customer craft (the FDE differentiator)

Notebook What you'll learn Scoping & discovery
Open In Colab Turn a vague customer ask into a scoped, evaluable system: discovery questions, a one-page scoping doc, the demo discipline: the customer-scenario interview round most engineers can't evidence

12 — Case Studies & Capstone

Where the skills come together into projects. First a case study (one realistic scenario worked end to end, runnable), then the capstone: the deployed repo you build yourself. (Section overview.)

Notebook What you'll learn Case study A — Customer-support assistant
Open In Colab One scenario scoped → built → served → debugged in production: a vague ask becomes a deployed, evaluated RAG+agent assistant, then a live quality regression (a stale index after a corpus migration) that you diagnose and fix. A build-to-debug arc threading sections 02–11 Case study B — Contract extraction: pipeline vs agent
Open In Colab The judgment call interviewers love: build the same extraction task as both an agent and a pipeline, then prove with accuracy + token cost that the pipeline wins when the steps are known Case study C — Red-team robustness benchmark
Open In Colab A different kind of system, a harness that evaluates a model instead of serving one: an attacker→target→judge (PAIR) loop that measures attack success rate, composing the agent loop, LLM-judge, security, and evals

Capstone: the brief for the deployed project that goes on your resume, a real repo with a serving component and an eval report. Case studies are for learning; the capstone is for hiring.

Conventions

  • Raw model APIs, no frameworks. Patterns are durable; wrappers churn.
  • One shared corpus (data/) across RAG and eval sections, so evals measure the retrieval you actually built.
  • Self-contained notebooks. First cell installs, second cell calls from aien import setup; client, MODEL = setup() to load your key from Colab secrets (or a local env var). No hidden state between notebooks. aien is the tiny shared-setup package in this repo (one place to change credential loading), installed automatically by the first cell.
  • Every notebook ends with exercises. Do them before moving on.

Setup

  1. Get a free API key at console.groq.com, no credit card required.
  2. In Colab: the key icon in the left sidebar → add GROQ_API_KEY as a secret, and toggle notebook access on.
  3. Open any notebook via its badge and run top to bottom.

Running locally instead: pip install -r requirements.txt && pip install -e . (the second installs the aien setup helper), export GROQ_API_KEY=..., open with Jupyter.

The Daily Front Page 16 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Power Section
article

Smaller reactors bring nuclear power closer to fulfilling its promise

by sohkamyung·▲ 139 points·201 comments·nature.com ↗
Small modular reactors ... could be used to power rural areas.

A large reactor vessel is in the centre of a room full of equipment. A person can be seen to the right hand side of the room.

Companies are in the process of building test units for small modular reactors, which could be used to power rural areas. Credit: Kairos Power

Nuclear power plants have not exactly sprouted like daisies across the United States. The country’s first commercial nuclear reactor of the twenty-first century didn’t come online until 2016. That was Unit 2 of the Watts Bar Nuclear Plant in Tennessee, which arrived two decades after Unit 1.

But that drought, and a similar one in Europe, might be ending. Two reactors began operating near Baxley in Georgia in 2023 and 2024, with governments and private parties around the world keen to invest in nuclear-plant developers. Some are eyeing up conventional light-water reactors, which use normal water as a coolant — the only type currently used commercially in the United States. But a lot of effort and funding is now going towards developing a new breed of smaller reactors that rely on different fuels and coolants, and which will require the development of new structural materials.

Known as small modular reactors (SMRs), they can produce up to 300 megawatts of electrical power (MWe) — enough to run about 300,000 homes. This is much less than the 1,000 MWe typically produced by conventional light-water reactors, but SMRs should be cheaper and easier to construct. Existing commercial reactors are “very efficient, very good for the grid, but also very expensive to build”, says Jacopo Buongiorno, a nuclear engineer who directs the Center for Advanced Nuclear Energy Systems at Massachusetts Institute of Technology in Cambridge.

Part of the advantage of SMRs lies in their modularity. Instead of constructing an entire power plant from the ground up, large portions of the system will be built in a factory and shipped to the site for assembly. Think Lego, says Buongiorno: “I have my prefabricated bricks and I connect them to make my reactor.”

In March 2025, the US Department of Energy (DoE) announced US$900 million in grants to support the deployment of SMRs. One year later, the European Commission said it would invest up to €200 million (US$228 million) in the construction of SMRs.

Critics argue that SMRs are not necessarily more economical than are larger nuclear power plants. Edward Lyman, a physicist and director of nuclear power safety for the Union of Concerned Scientists, a non-profit organization in Cambridge, Massachusetts, has said that the smaller power output of SMRs means that factories would have to produce dozens of modular reactors for them to become more cost-effective than conventional reactors. He has argued that some SMR designs might be more dangerous than are existing reactors, owing to their different fuels and coolants.

Despite these concerns, the lure of faster and cheaper construction — and growing demand for clean energy, not least from data centres that run artificial-intelligence systems — has made developing modular reactors commercially attractive. Kairos Power in Alameda, California, is building a test reactor called Hermes 1 in Oak Ridge, Tennessee, and began construction on a 50-MWe demonstration plant, Hermes 2, in April. The company expects to begin commercial operations in 2030, and has a deal to sell its power to Google.

Fixing the fuel

Hermes 1 is the first non-light-water reactor approved by the US Nuclear Regulatory Commission (NRC) in more than 50 years. Light-water reactors, with their familiar cooling towers, are cooled by water and usually powered by ceramic uranium dioxide pellets, which are packed into zirconium alloy tubes called fuel rods. Hermes 1, by contrast, is fuelled by tristructural isotopic (TRISO) pebbles — poppy-seed-sized particles of uranium, encased in a carbon-ceramic shell. The reactor is cooled not by water but by a molten salt: a mixture of lithium fluoride and beryllium fluoride known as FLiBe.

TRISO fuel is the oldest and best understood example of what researchers call accident-tolerant fuels, says Nicholas Brown, a nuclear engineer at the University of Tennessee, Knoxville. A kernel of uranium dioxide, which is 350–600 micrometres in diameter, is surrounded by a shell of porous carbon that captures fission products that escape the kernel. Around that is a denser layer of carbon, which is itself encased by a layer of silicon carbide that acts as a miniature containment vessel.

In the foreground a spherical fuel pebble is seen. Background is out of focus.

TRISO fuel is made of particles of uranium.Credit: Kairos Power

Thousands of these particles are packed into each golf-ball-sized graphite pebble. When the pebbles are brought together inside the reactor, fission occurs, and the resultant heat is transferred into the coolant. Used pebbles typically flow out of the reactor like the contents of a gumball machine, and fresh ones are added from above. This enables refuelling without having to stop the reactor.

Another advantage stems from the FLiBe coolant that Hermes 1 uses. Water boils at 100 °C, so to remain liquid at the 250–325 °C temperatures of light-water reactors requires pressures of about 150 atmospheres. Hermes 1’s molten-salt coolant, by contrast, boils at about 1,430 °C — much higher than the reactor’s 650 °C operating temperature. That means the reactor can run at normal atmospheric pressure, removing the need for expensive containment vessels. And if there is a leak, there is no pressure to spew the coolant and the radioisotopes into the air. Furthermore, reactors using molten salt as a coolant can run at higher temperatures, leading to more efficient energy production.

Walk-away safe?

The fuel won’t melt at temperatures that the reactors can reach. In one test, TRISO survived for more than 12 days at 1,800 °C — much hotter than what even a worst-case accident could produce. That makes the fuel what the nuclear industry calls walk-away safe. “You can throw the keys away, walk away and not worry about a progression towards a severe accident like a Fukushima or Chernobyl,” Brown says.

The trouble with TRISO is that it requires high-assay low-enriched uranium (HALEU), in which the fuel material is enriched to contain about 15–20% uranium-235. In January, the DoE awarded a total of $2.7 billion to three companies to create domestic enrichment capacity for HALEU. Until that capacity is built up, Brown says, making TRISO will be slow and expensive.

Scientists are working on other fuels, both for conventional reactors and for SMRs. Brown’s group is investigating a 3D-printed insert made of molybdenum that could go in the middle of a uranium dioxide pellet. Because molybdenum conducts heat well, the insert could improve heat flow out of the fuel pellet by an order of magnitude — reducing the likelihood of it melting and causing an accident.

Person wearing blue overalls seen through glass. Person is wearing black protective gloves and pouring liquid from one container to another.

A scientist handling liquid sodium, which can be used as a nuclear coolant.Credit: TerraPower

Another fuel and coolant are the basis of the Natrium reactor that TerraPower is building in Kemmerer, Wyoming. Natrium’s 345-MWe power level puts it just over the limit of what is usually considered an SMR, says Eric Williams, a mechanical engineer who is chief operating officer at the company in Bellevue, Washington. Its fuel is an alloy of uranium and zirconium. For a coolant, it uses liquid elemental sodium, which has a boiling point of nearly 900 °C — well above the 500 °C at which the reactor operates. Fission heats the liquid sodium, which in turn heats up molten sodium chloride. This molten salt stores the heat when electricity demand is low, then boils water to turn electricitygenerating turbines when demand rises.

Because the fuel, the cladding that surrounds it, the liquid sodium and the vessel itself are all metal, the system is excellent at conducting heat, says Williams. Even when a reactor shuts down, the radionuclides that have been produced by fission continue to decay, creating extra heat that is initially equivalent to about 7% of what the reactor produces at full power. The all-metal design simplifies handling of that decay heat. “We can actually cool the outside of the vessel by just having air flow by natural circulation,” Williams says. Of course, liquid sodium can burn if it comes into contact with air or water, but the company says that it has extra barriers and sensors in place to prevent that happening.

When the Fukushima Daiichi nuclear plant in Japan failed in 2011 after a tsunami, operators tried to pump in seawater to cool the reactors. But the earthquake that had caused the tsunami had also damaged the electrical grid and most of the plant’s backup power. As a result, it was impossible to cool the reactors enough, and radioactive material was released into the environment. Because the TerraPower reactor is air-cooled, cooling can continue indefinitely without anything needing to be pumped in.

There’s another built-in safety feature to using liquid sodium as a coolant, Williams says. Among the most dangerous radioactive by-products of fission are caesium-137 and iodine-131. Both are highly radioactive, and could get into the water and food supply in the event of a leak. But sodium bonds with both elements; therefore, a sodium-based coolant keeps them in the tank. “Even if the fuel were to all fail and all of the caesium and iodine generated gets into the sodium, it stays in the sodium,” Williams says.

Conventional light-water reactors are not necessarily more dangerous than an SMR such as TerraPower’s, says Raluca Scarlat, a nuclear engineer at the University of California, Berkeley. Nuclear plants can have all manner of safety features to ensure that they’re not dangerous: active safety, such as electrically powered pumps to carry coolant to the reactor, and passive backups that rely on gravity to drop water from a rooftop tank or drain fuel from the reactors. But some SMR designs have a greater number of inherent safety features that rely on physics rather than engineering, such as being able to operate at atmospheric pressure, and also provide more opportunities for designing passive safety systems.

The different safety characteristics of some SMRs mean that they might require smaller emergency buffer zones around them. That’s both because smaller plants necessarily produce less radioactive material, and because their design means that radioactive material is less likely to escape in the first place. In the United States, light-water reactors have long had an emergency planning zone radius of 16 kilometres, in which people would be required to evacuate or take shelter immediately after an accident, and a 80-kilometre-radius ingestion planning zone, in which radiation might get into soil and groundwater. In 2023, the NRC issued a rule saying that planning zones for SMRs could be set on a case-by-case basis, depending on their technology. Smaller zones could enable nuclear power plants to be sited closer to where power is needed, Williams says.

Salt power

Molten salt has more uses than as a coolant or energy storage medium. Mixing a radioactive element, such as uranium or thorium, into the salt creates a fluid that can act simultaneously as both fuel and coolant. In fact, the term molten-salt reactor often refers to designs using such a liquid-fuel mixture. Although TerraPower is focused on commercializing their Natrium technology, which is not a molten-salt reactor, the company has also worked on the Molten Chloride Reactor Experiment at the DoE’s Idaho National Laboratory in Idaho Falls, which runs on a mixture of molten sodium and uranium chloride.

Both chloride and fluoride salts are promising for fuel mixtures, says radiochemist Patricia Paviet, who directs the DoE’s research on molten-salt reactors. “We love them because it’s a higher temperature, more efficiency,” Paviet says. “We love them because it’s low pressure, so accident scenarios with pressure will not happen.”

close-up of salt crystals, coloured grey and brown

Salt crystals produced at the Idaho National Laboratory, Idaho Falls, for the Molten Chloride Reactor Experiment. Credit: Idaho National Laboratory

Similarly to Kairos Power’s Hermes 1 pebble-bed reactor, a reactor powered by molten salt can be refuelled without being switched off — spent fuel can be drained out and new fuel pumped in while it’s operating. Another advantage over light-water reactors is that actinides — radioactive elements created during a nuclear reaction — can fuel subsequent reactions. In molten-chloride reactors, the nuclear-fission chain reaction is sustained by higher-energy neutrons. By contrast, the water in light-water reactors acts as a moderator, slowing the neutrons down. As a result, molten-chloride reactors can burn the actinides as extra fuel, which light-water reactors cannot do.

Molten-salt reactors, both chloride and fluoride, also present an opportunity to minimize waste, Paviet says. Spent fuel from a light-water reactor contains about 95% uranium and 1% plutonium. France and Russia have extensive recycling programs, but the United States doesn’t recycle any nuclear waste, in part because it’s cheaper to dispose of it. Processing liquid fuel is easier than manufacturing or taking apart solid fuel, Paviet says.

The presence of salts in machines operating at extremely high temperatures raises the spectre of corrosion. Scarlat argues that, if the systems are designed to keep water and oxygen out, oxidation should not be a problem. But even if that’s accomplished, there are other mechanisms that can weaken structural materials in a reactor. For example, molten salts tend to dissolve chromium, the element added to steel to make it stainless. This means that reactor parts should not contain more than about 7% chromium, says Steven Zinkle, a nuclear engineer and materials scientist at the University of Tennessee, Knoxville.

Structural materials in these newer, high-temperature reactors also have to withstand the effects of radiation, which can create defects by knocking atoms out of place. The high temperatures make it easy for those defects to migrate and form clusters, which make the material more brittle. Zinkle says that out of the thousands of known alloys, just six are qualified for use in high-temperature reactors by the American Society of Mechanical Engineers. And none of them, he says, are qualified for the highest-temperature reactor that designers would like to be able to use.

Zinkle is leading a DoE-funded project to develop more alloys for use in reactors. One is a magnetic steel and the other is a vanadium-based alloy. Both are precipitate strengthened, a process that uses repeated cycles of heating and cooling to form small bits of material inside the larger structure that block defects and have been shown to provide radiation resistance. Other materials scientists are trying to engineer the boundaries of grains in a material’s crystalline structure to act as a trap for defects.

Developing new materials, fuels and reactor designs is a slow process that requires patience, Brown says. But he thinks that the results will be worth the effort. Nuclear power is “really important for the future of the country and also for the future of the world. It’s very safe. It is really the next-generation energy source that is going to enable us to move beyond fossil fuels.”

The Daily Front Page 17 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Natural History
article

An investigation into the state of corvid–human relations

by speckx·▲ 130 points·80 comments·audubon.org ↗
Sal met my gaze with an air of appraisal so frank that, coming from a person, it would have been rude.

When my family and I visited my sister Annie in California last summer, I was excited to see her new house—but more excited to meet a neighbor she’d told me a lot about. Despite being a frequent visitor, the neighbor didn’t make an appearance at first; maybe he was spooked by my clamorous kids. A couple of days later, though, I came face-to-beak with Sal in a narrow side yard. Looking above the succulents and wildflowers, Sal met my gaze with an air of appraisal so frank that, coming from a person, it would have been rude. Then the glossy black American Crow flew away.

Annie first met Sal in early 2024, soon after she and her partner, Jack, moved into their house. She was removing old landscaping fabric when a crow landed on the fence and looked at her curiously. She pointed to where the lifted tarp had exposed fresh soil and was intrigued when the bird swooped down and grabbed a worm. “It seemed like Sal understood,” she says.

American Crows all look more or less identical to the human eye. But Annie and Jack came to recognize Sal, a bold character with a distinctive hop due to a bad leg, and began offering the bird unsalted peanuts. The treats attracted a second, more timid crow, whose deformed foot also distinguished it. They called Sal’s buddy Pal. Within a few weeks, Annie and Jack were buying peanuts in bulk. Using food as a reward, they trained the two corvids to pay them regular visits.

Or did they? Annie wondered whether, from the crows’ perspective, it might be the other way around.

After all, the humans were also rewarded. When Annie opened the curtains in the morning, she looked forward to seeing the crows swoop down to land on her fence, seemingly greeting her. When she came outside, they might say hello with a swoosh of their wings or perch on a patio chair opposite her as she worked on her laptop. The way Sal and Pal had come to trust her was gratifying, and she felt even more honored by their attention when she learned that the crows had full social calendars; it turned out one neighbor knew Sal as Russell. “Clearly they have so much else going on,” Annie says. “It felt like they had these busy lives that we were fitting into.”

When it comes to corvid–human connections, Annie isn’t the only one who wonders who’s training whom. Carl Bergstrom, an evolutionary biologist at the University of Washington, has developed bonds with many crows at his home and on campus. Such a relationship, he says, “absolutely alters my behavior.” If, for instance, he forgets to bring peanuts for the birds at his university, he takes an alternate route around school. “I’ll find myself sneaking across campus in a tunnel or through buildings,” he says, “because I feel so bad when I run into them.”

Like Bergstrom and my sister, many people form sustained personal connections with their local crows. Those who do often consider the attention of these charismatic corvids a privilege and a source of joy. Some even call the animals their friends. What’s harder to determine, though, is whether the crows return the feeling.

At the most basic level, crows likely view humans who feed them as a means of survival. Our yards may provide a safe place  to congregate and forage. A Red-tailed Hawk that might strike in an open field may be more reluctant to swoop onto a small lawn. When people put out treats, it only sweetens the deal.

Sometimes crows will seemingly leave “gifts” for people who feed them, which recipients often view as a thank-you. But these offerings—keys, coins, stones, and, in Bergstrom’s case, possibly a ring his daughter had lost—may have a simpler explanation. Anne B. Clark, a retired Binghamton University behavioral ecologist who studied urban crows, says that in all videos she’s seen of this behavior, the birds were very young. Juveniles frequently carry and play with interesting objects, she says. So a crow may simply be dropping what’s already in its beak to pick up food. “My own opinion is that crows are not terribly interested in us,” Clark says.

Still, inadvertent actions may become strategic. The crows, ravens, and rooks in the genus Corvus are among the world’s most intelligent animals. Some can fashion tools or operate complicated devices to get food. If a crow notices that it’s rewarded when leaving objects for people, it might continue to do so. “It’s not a heavy lift for a smart animal,” says corvid biologist John Marzluff, a professor emeritus at the University of Washington.

Yet many people who receive attention from crows feel that the birds have more complex motives. “It seemed like they would just come by to hang out,” my sister tells me—like, well, friends.

How to Befriend a Crow, Mindfully

Go nuts. Peanuts in the shell are a high-quality snack that crows love, with plenty of protein and fat. The shells also give the birds something to do. Dry cat food is another good option, says Anne B. Clark.  

Don’t stare. In the beginning, let crows see you put out some food—and then walk away. They’re highly attentive to our gaze, and they won’t want to eat while you’re watching. Later, the crows may get more comfortable around you. 

Be consistent. Use a verbal signal on a regular schedule: When Carl Bergstrom puts out nuts, he calls, “Hello, crows!” The birds will quickly catch on. 

Consider your neighbors. As much as you may crave an avian friend, others may be less excited about reenacting Snow White in their yards. In the winter, when crows relax their territoriality and gather in flocks, you could attract a lot of birds at once. Putting out too much food can also attract pesky critters. Practice moderation. 

Think like a bird. To have a positive and meaningful relationship with the birds in your neighborhood, resist the urge to anthropomorphize them. You will learn much more by considering the birds on their own terms: “Don’t try to make them into little people,” Clark suggests. Instead, she says, “crow-ify us.”

What is a friend, anyway? For a scholarly perspective, I spoke to Thom van Dooren, a field philosopher at the University of Sydney and author of The Wake of Crows, a 2019 book about the entangled lives of humans and these corvids. He believes crows relate to people in ways that meet several conditions for friendship.

Criterion one: You must know a friend from a stranger. “In order to strike up a friendship, you have to be the kinds of organisms who can firstly recognize one another as individuals,” he says. Here, the avians have an advantage. While people struggle to tell crows apart, crows are startlingly good at identifying us. It makes sense. Crows live a long time—Clark has known individuals as old as 19—and it pays for them to recall their enemies and allies.

In experiments, urban crows held long grudges against people who mistreated them, cawing harshly and forming mobs upon seeing the face of their persecutor—even years later. My sister’s crow companions knew her when she had a different haircut or wore a hat or sunglasses. Crows recognized Bergstrom in a new jacket with the hood up. Walking around different parts of town, he sometimes encounters a crow who seems to know him; a bird will land nearby and look at him expectantly. When he returned to campus after a year away, crows greeted him immediately, Bergstrom says: “Sort of, ‘Where the hell have you been?’”

But noticing a familiar face in a crowd does not make a friendship. You need to share experiences, too. Among their kind, many crows form prolonged family relationships; juveniles often stay home for a few years to help parents care for young siblings. They turn their social awareness to us, too. The way crows not only recognize humans but also pay attention to our gaze—meeting our eyes, following where we look—suggests van Dooren’s next criterion: intersubjective engagement, or two conscious minds meeting each other and sharing a reality.

What’s more, a friendship can’t be strictly utilitarian, van Dooren says. Crows who get to know humans must be after more than peanuts and protection. “I think there’s all sorts of interesting motivations for these behaviors that are about curiosity, exploration—just leading an interesting life,” he says. (Keeping entertained is, of course, its own kind of utility.)

A few years ago, one of Marzluff’s graduate students trained birds to perform a task inspired by Aesop’s fable “The Crow and the Pitcher.” Four of 16 crows learned to drop stones in a tube of water to get a cheese puff. Later, when viewing the apparatus while in a brain scanner, the successful birds had different neural activity patterns than their less competent peers. Like a skier on a mountaintop visualizing a next run, “they were basically reliving that experience,” Marzluff says. In other words, the crows were telling themselves a kind of story. This suggests one more requirement for friendship, van Dooren says. You need to be “able to make sense of your life as a narrative,” he says, before you can get to know its recurring characters.

We will never know what crows are thinking, but as storytelling creatures ourselves, we’re primed to see crows as players in our lives—each friendship a narrative carried out on a small stage, maybe in a park or across a picnic table. Yet the saga of humanity’s relationship with corvids has taken place on a larger scale, across millennia. In their book In the Company of Crows and Ravens, Marzluff and his coauthor Tony Angell argue that these birds and humans have experienced “cultural coevolution.” In prehistoric times, ravens and crows began to hang around places where people hunted or fished and scavenged some of our haul. As the corvids became our companions and competitors, we developed customs to drive them away. We hunted them, chased them, erected scarecrows. Our habits shaped one another’s.

The ever-present birds also influenced mythologies around the world. The raven, often portrayed as a shape-shifter or trickster, is an important figure for Indigenous peoples in North America. In a legend of the Haida, for example, Raven discovers the first humans hiding inside a clamshell. Meanwhile, ancient Greeks associated crows with the god Apollo and named a constellation Corvus. (Don’t squint too hard seeking a bird in the night sky; the stars form what looks like a rhombus.)

Corvids appear in more modern lore, too, from Poe to Hitchcock. But now that fewer people farm, hunt, or otherwise concern themselves with the scavengers, the birds probably aren’t molding our culture as strongly as they once did. Yet we’re still shaping theirs, Marzluff says.

Their keen attention may be key to a friendship that’s singular.

As we’ve moved to urban areas, crows followed, and like coyotes, they’ve found that city dwellers are less likely to trap or shoot them. Ever savvy, crows have learned new habits, such as nesting on utility poles, and as with many types of urban wildlife, they seem to be growing less wary around us. Such changes may be cultural, with birds passing down knowledge over generations. Behavioral shifts could also become baked into their DNA if birds with an inborn interest in, say, eating fries or nesting on a high-rise are more likely to survive to reproduce.

Over millennia of following us into new habitats, crows also learned that we are a fickle species. Humans provide food, but sometimes we harass or kill them. Our settlements can be alternately deadly or sheltering. To “avoid danger and take advantage of riches,” Marzluff says, “they can’t not be interested in people.” So they’ve evolved to watch closely what humans do. And their keen attention may be key to a friendship that’s singular.

While other wild animals develop relationships with humans, many are less clever than crows or ravens, which have a brain-to-body ratio on par with a small monkey. Other highly intelligent animals, such as elephants or whales, don’t have the same coevolutionary history with Homo sapiens. And while a raven or magpie sometimes befriends a person, Marzluff says that by far the most corvid–human relationships happen with crows. It helps that the birds are ubiquitous in the Northern Hemisphere. Crows are everywhere we are, keeping an eye on us.

Even when humans have a friendship—or something that feels like it—with a crow, the relationship happens on the wild animal’s terms. They visit when they want to, and they may disappear from our life suddenly. Take Tatterwing, Bergstrom’s favorite crow, whose missing feathers made her wings resemble Swiss cheese. (Tatterwing often made a rattle-knock call that’s more common to females.) One day, she simply vanished. Bergstrom guesses she molted and grew new feathers, and without her tatters, he no longer knew her. Later, he saw a bird around his home who behaved like Tatterwing but he couldn’t be sure it was her.

Pal and Sal left, too. One day last September, my sister noticed Pal act strangely. The bird lay down in an unusual spot, as if hiding. After that, neither crow visited her again, and a new pair appeared. She suspects her friends were ousted from their territory; a month later, Sal was spotted at a neighbor’s home a block away. “I miss them,” Annie tells me. She and Jack have left peanuts for the new crows, but so far the birds haven’t visited consistently.

Crows, of course, have lives entirely apart from ours. That becomes even clearer to me after I meet up with Craig Gibson, an amateur naturalist and photographer dedicated to observing the birds in Lawrence, Massachusetts. About 25 miles north of Boston as the you-know-what flies, this industrial city is home to one of New England’s largest winter crow roosts. While crows tend to be territorial during the breeding season, in the colder months they come together and forage in flocks. At night, up to 15,000 birds may crowd together here in Lawrence, shoulder to shoulder, as they sleep.

I arrive around 4 p.m., just before sunset in December. The day is cold and thickly overcast, but the crows know the time. Gibson and I look through barbed wire toward a brick building complex where American Crows and some Fish Crows gather on rooftops, wires, and asphalt—anywhere they’ll fit. Shortly after sunset, they’ll move from their staging areas to branches of river birches and silver maples lining the Merrimack River. 

I haven’t succeeded at making a crow friend in my yard near Boston, but in Lawrence, I am content to be an onlooker. I swivel my head as rivers of birds stream toward us. They fly purposefully, dense overhead, and descend with playful dives and barrel rolls I’ve never seen before. The cawing is constant and raucous.

Gibson doesn’t have relationships with any of these specific birds. He’s spent almost 500 nights considering them as a group, wild and anonymous. “They’re putting on a good show for you!” he shouts. Really, though, these birds aren’t paying attention to us; they’re performing for one another. We’ll continue to tell stories about corvids, but in this moment, their story is their own.

The Daily Front Page 18 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Silicon & Memory
article

Processing in Memory: DRAM Is About to Do Math

by bhouston·▲ 87 points·40 comments·ben3d.ca ↗
The silicon works. Quantization, memory layout, and runtime support now stand in the way.

Samsung's LPDDR5X-PIM puts compute inside commodity memory, exposing 614 GB/s of bank-level bandwidth for local LLM inference. The silicon works. Quantization, memory layout, and runtime support now stand in the way.

At Hot Chips 2026, Samsung presented a 16 GB LPDDR5X memory package that delivers 614 GB/s of internal bandwidth to its own compute units.

For scale, 614 GB/s matches the memory bandwidth of a top-spec Apple M5 Max across its entire unified memory system: the 40-core GPU configuration in the $3,499 MacBook Pro. Samsung claims that number from inside one memory package, against the 76.8 GB/s that escapes through its external pins. Tom's Hardware reported the resulting eightfold difference.

LPDDR PIM illustration

That eight-to-one ratio makes the case for Processing in Memory. DRAM banks already provide most of the bandwidth; the external pins cannot expose it.

The terms

Bank. DRAM contains banks, independent arrays that can operate in parallel. A modern LPDDR5X die has dozens. Together they deliver enormous internal throughput, but they share a narrow external interface.

GEMV vs. GEMM. Matrix-vector multiply versus matrix-matrix multiply. Autoregressive decoding at batch size 1 uses GEMV: one token's activations multiplied against the entire weight matrix. Prefill and batched serving use GEMM. PIM helps most with GEMV.

PIM. Processing-in-memory hardware places compute units next to the banks, inside the memory die, where they can use bank-level bandwidth instead of interface bandwidth.

Arithmetic intensity. FLOPs performed per byte loaded. High intensity makes a workload compute-bound. Low intensity makes it bandwidth-bound, leaving matrix engines idle.

The bottleneck is memory bandwidth

Generating one token requires reading every parameter from DRAM, multiplying it once, and discarding it. Each token depends on the preceding token, so batch-1 decoding cannot reuse the weights across tokens. Arithmetic intensity sits near the floor.

The first-order model:

tokens/sec ≈ memory_bandwidth_GB/s ÷ model_size_GB

At 614 GB/s against a 20 GB model, the hard ceiling sits around 30 tokens per second. The real number is lower because the KV cache grows with context and competes for the same bandwidth. During generation, most of the matrix hardware you paid for waits on DRAM.

Apple's local-inference performance centers on memory bandwidth. The M5 Pro moves 307 GB/s, the M5 Max moves 460 or 614 GB/s, and the M5 Ultra reaches 1.2 TB/s. Those numbers predict tokens per second better than TFLOPs do. Apple pays for a wider external interface.

Samsung's design keeps the largest transfers inside the memory package.

What Samsung built

Sixteen PIM blocks sit beside the DRAM banks, with MAC trees running in parallel and an ALU handling floating-point and integer types. The package is a JEDEC-standard 561-ball part containing 16 GB across four dies per rank. Samsung targets servers, mobile devices, and clients using the same footprint as ordinary LPDDR5X.

The package processes data in four steps, each with consequences for software:

  1. Activation write. Sixteen WRPB commands broadcast FP8 activation data from the host into source register files across the banks.
  2. Weight load. PIMX_RD reads 32-byte weight elements from the DRAM cells, maps them across the MAC trees, and combines outputs in a vector register file.
  3. Vector store. PIMX_WR moves partial sums back to the bank. The read-to-write ratio can vary instead of remaining fixed at 1:1.
  4. Readback. The host switches to single-bank mode and issues up to 64 sequential reads to drain the 1-kbit vector register file.

Weights remain inside the package. Only the much smaller activations cross the bus, while the host sends commands to the PIM blocks.

Samsung supports fifteen precision combinations through MAC precision fields in a configuration register. SINT4 weights reach 2.4 TOPS; FP8 reaches about 1.2 TFLOPS per package.

Conventional memory controllers can use it

Samsung calls its compatibility mechanism Address Align Mode. It maps DRAM addresses to MAC instructions so the part can work with a conventional DRAM controller. The system switches between single-bank mode for ordinary DRAM and multi-bank mode for PIM through predefined rows and PIM registers. Samsung says this approach switches modes faster and more reliably than its earlier HBM-PIM parts.

Requiring every SoC vendor to build a new memory controller could have kept PIM in research prototypes. Address Align Mode avoids that requirement, leaving software integration as the larger problem.

The measured result

Samsung validated real silicon on its edge AI accelerator SoC. It compared LPDDR5X with LPDDR5X-PIM while running Llama 3.1 8B at a 320-token context using SINT8 activations, SINT4 weights, and SINT32 output.

LPDDR5X LPDDR5X-PIM Delta
Run time 12.3 s 5.4 s 2.28x
Throughput 27 tok/s 81.3 tok/s 3.01x

This vendor benchmark covers one model, one short context, one accelerator, and integer quantization throughout. It demonstrates that the architecture works on silicon. It does not predict performance for every workload. The 320-token context in particular minimizes the KV cache problem.

Samsung has not disclosed package pricing, so the cost advantage over a wider memory interface remains a claim rather than a measured result.

Why memory vendors care

Samsung opened its talk with a cost slide. Memory grew from 52% of AI chip component spending in Q1 2024 to 63% by Q4 2025, with HBM accounting for most of it.

LPDDR5X-PIM gives customers a route to HBM-class inference bandwidth without HBM's price, power use, or packaging complexity. Samsung has pursued this idea since the Aquabolt-XL HBM2-PIM proof of concept in 2021. LPDDR5X-PIM is its first LPDDR-based PIM design to reach productization.

The software problem

No PIM backend exists in llama.cpp, vLLM, or another mainstream runtime. Samsung offers a simulator, a datasheet on request, and an SDK with reference tooling. Three obstacles stand between that vendor stack and a --pim flag.

1. K-quants do not map to the hardware

llama.cpp gets much of its quality-per-bit advantage from GGUF k-quants such as Q4_K_M. These formats use block-wise quantization with per-block scales and superblock scales. CPUs and GPUs can perform the few dequantization operations per block on nearby general-purpose ALUs.

A DRAM die has little general-purpose logic. PIM MAC units remain small because DRAM manufacturing processes optimize for storage capacitors rather than logic transistors, and every added transistor reduces storage density. Research on in-memory activation quantization found that mainstream quantization schemes need extra scaling and control hardware on top of the MAC units. One cited design incurred about 126% area overhead for FP16 and INT32 support. Other studies of processing across the memory hierarchy and efficient sparse PIM show the same sensitivity to die-area overhead.

Samsung's minimal MAC units cannot execute the k-quant scaling operations. Its fifteen precision modes use uniform formats, including the SINT4 and SINT8 pairing in the benchmark. They do not implement Q4_K_M. Existing GGUF files would need re-quantization into a PIM-native layout, and we do not yet know how much of the k-quants' quality advantage would survive.

2. Physical memory layout

mmap lets the kernel scatter pages across physical DRAM. PIM needs a weight matrix placed contiguously and aligned to the banks whose MAC trees will multiply it. Samsung's PIMX_RD reads 32-byte weight elements from cells and maps them across MAC trees, which only works when the data occupies the expected locations.

An operating system would need a huge-page-backed, bank-aware allocator exposed to user space. macOS, Linux, and Windows do not provide one today. llama.cpp's memory-mapped model loading, one of the features that makes it pleasant to use, conflicts with this requirement.

3. Bank-level PIM favors GEMV

Current near-bank designs, including Samsung's HBM2-PIM, SK hynix's GDDR6-PIM, and LPDDR5X-PIM, target GEMV. That fits batch-size-1 decoding, where the bandwidth wall hurts most.

Modern inference also spends time between clean GEMV and dense GEMM. Batching combines GEMV operations across queries into GEMM. Grouped-query attention merges multiple GEMVs into narrow GEMM. These operations raise arithmetic intensity, but often remain too narrow to keep a GPU busy. The CENT architecture paper analyzes this operational-intensity gap.

GQA appears in most current models. Speculative decoding enters the same middle ground because verifying draft tokens in parallel converts GEMV into GEMM. Research on LPDDR-PIM speculative inference found that this conversion reduces the efficiency of GEMV-focused PIM designs. Small-batch local serving faces the same problem.

What about multi-token prediction?

Multi-token prediction has two roles. A model can use it as a training objective, as DeepSeek-V3 does, and discard the extra prediction modules during ordinary inference. An inference runtime can also use those modules as a speculative drafter: they propose several future tokens, then the main model verifies the candidates in parallel. Google reports up to a 3x speedup from this approach with Gemma 4.

That verification step exposes the weak point in Samsung's design. Checking several candidate tokens in one pass changes the large linear layers from GEMV toward narrow GEMM. The in-bank MAC units can still perform some memory-bound work, but they cannot use their full bank-level throughput on those wider operations. Samsung's current design also blocks the NPU from accessing DRAM while PIM runs, preventing the two processors from splitting one layer concurrently.

MTP and PIM can work together in a heterogeneous system. PAPI proposes a scheduler that measures decoding parallelism at runtime and sends memory-bound kernels to PIM while keeping compute-bound kernels on a GPU. That research architecture uses more flexible hardware than Samsung's LPDDR5X-PIM package.

The speedups would not multiply cleanly because both techniques reduce the cost of reading model weights. MTP amortizes one weight read across several accepted tokens; PIM makes each remaining read faster. On hardware you can buy today, MTP may provide a larger and cheaper gain for models with accurate draft heads. Its benefit depends on draft acceptance rate and verification cost, while PIM's benefit depends on model layout, quantization, and the fraction of work that remains GEMV.

Mixture-of-experts models add uneven memory access. Routing sends tokens to a subset of experts. If those experts occupy a subset of banks, some banks become hot while others sit idle. Variable workloads also create changing GEMV-to-GEMM ratios that reduce hardware utilization.

Computer architects have explored several responses:

  • Split the work. AttAcc, IANUS, and NeuPIMs keep an NPU for compute-intensive prefill GEMM and use PIM for memory-intensive decode GEMV. A survey of integrated NPU-PIM accelerators covers this heterogeneous approach.
  • Move compute to a logic die. Duplex, which targets MoE, GQA, and continuous batching, puts 32 GEMM modules on the HBM logic die. Each has 512 FP16 MACs and an 8 KB buffer. Together they consume 17.80 mm², about 14.7% of a 121 mm² HBM3 die. A logic die can afford real GEMM units; the area beside a DRAM bank cannot.
  • Build heterogeneous compute inside memory. CENT removes the GPU from a CXL system. HALO splits work by phase, mapping compute-bound prefill to compute-in-memory and memory-bound decode to compute-in-DRAM. Researchers also continue to improve GEMM libraries on real PIM hardware, but shipping bank-level devices still favor GEMV.

Samsung chose near-bank compute to reduce HBM cost with a JEDEC-standard 561-ball package and a conventional memory controller. That package only works if the logic remains small enough to sit beside the banks.

The resulting design targets decode-side GEMV and can ship in a familiar memory package, at the expense of GEMM flexibility. It fits batch-1 local inference on a dense model. MoE, speculative decoding, and batched inference may require a second generation.

llama.cpp
    │
    ├─ today ────────> NPU/GPU <══ 76.8 GB/s ══> passive DRAM
    │
    └─ PIM-aware ────> conventional DRAM controller
                            │
                            └─(commands)─> in-bank MACs @ 614 GB/s

Timeline

JEDEC published the foundational LPDDR6 standard, JESD209-6, in July 2025. In April 2026, JEDEC said that JC-42.6 was nearing completion of a separate LPDDR6 PIM standard, alongside 512 GB densities, a narrower x6 per-die interface, and a SOCAMM2 module standard. JEDEC has not announced a publication date. Samsung's roadmap presents LPDDR5X-PIM as shipping now and LPDDR6-PIM as moving toward the completed standard.

Samsung has working silicon today, JEDEC has an unfinished standard, and open runtimes still lack the software stack.

Accelerator software often trails hardware by a year or more. PIM reaches into the kernel's page allocator and back through the quantization pipeline, which makes its integration harder than adding another compute backend. Adoption depends on someone building a bank-aware allocator and a re-quantization path in a runtime that people use.

A well-resourced vendor can fund that work. The likely route is a Samsung- or SK hynix-backed runtime fork that later moves upstream, much as vendor GPU backends did.

Why it matters

Other responses to the memory wall buy bandwidth through wider buses, more channels, HBM stacks, or large unified-memory SoCs. Each solution adds power use, cost, and package complexity.

PIM places computation beside the DRAM banks, giving system designers another way to raise effective bandwidth without widening the memory interface.

Samsung's 3x vendor benchmark is less important than the 614 GB/s inside a 16 GB package. MTP may prove faster or cheaper for some models, and future systems may combine both techniques. PIM matters because it exposes bandwidth that current processors leave inside the DRAM die, giving hardware designers another option when software techniques stop scaling.

The Daily Front Page 19 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Public Square Briefs
article

U.S. sanctions against the A/I Collective

by exiguus·▲ 596 points·577 comments·inventati.org ↗

A/I (Autistici/Inventati, pronounced [au’tistiʧi]-[iŋ’vɛntati], or [iŋvɛn’tati]) was born in 2001 from an encounter of individuals and collectives of the autonomous anticapitalist movement interested in technology and active in the digital rights struggle. We believe that this world is far from being the best world possible. We react by providing a platform and tools for digital self-defense addressing the need of free communication for activists and other individuals.

All of our services are provided for free, without any form of control or commoditization of the personal user data. We don’t receive any form of compensation for our work. We are volunteers exploiting the experiences we accumulated over years of technological, political and legal research while doing radical activism, and we are motivated and inspired by the principles of solidarity and self organization.

Our financial strategy relies exclusively on voluntary donations.

We provide our services strictly for non-commercial use, in order to provide support exclusively to individuals or groups we feel we have an affinity with. In order to verify the existence of these pre-conditions, each and every service request is processed manually by one of our volunteers and is in a dialogical form. All requests are anonymized and will be destroyed.

If you would like to use our services, please check if you agree with our manifesto, pledge respect to our policy and read carefully our privacy policy.

Don’t send a request without having read these documents!

Request an account

The Daily Front Page 20 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Public Square Briefs
article

The Twelve-Factor App (2025)

by jxmorris12·▲ 266 points·150 comments·12factor.net ↗

Introduction

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

Background

The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform.

This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and avoiding the cost of software erosion.

Our motivation is to raise awareness of some systemic problems we’ve seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books Patterns of Enterprise Application Architecture and Refactoring.

Who should read this document?

Any developer building applications which run as a service. Ops engineers who deploy or manage such applications.

The Twelve Factors

I. Codebase

One codebase tracked in revision control, many deploys

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing services

Treat backing services as attached resources

V. Build, release, run

Strictly separate build and run stages

VI. Processes

Execute the app as one or more stateless processes

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity

Keep development, staging, and production as similar as possible

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes

The Daily Front Page 21 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Public Square Briefs
article

Verschlimmbesserung: The Word Your Software Updates Need

by speckx·▲ 137 points·89 comments·geekyschmidt.com ↗

The German language has a word for what your last software update did.

It is called Verschlimmbesserung: an attempted improvement that only makes things worse.

We have all lived through the SaaS update that moved a button, renamed a menu, and broke a workflow we relied on daily. Some product team shipped a “better experience” that solved a problem nobody had.

Eliyahu Goldratt nailed the root cause decades ago:

“Tell me how you measure me, and I will tell you how I will behave. If you measure me in an illogical way… do not complain about illogical behaviour…”

When point releases become more important than the product itself, you are incentivising Verschlimmbesserung. Your engineering teams are not failing. They are optimising for the metrics you gave them.

How you measure and incentivise your teams tells them exactly what you value. If the metric rewards churn, you get churn. If the metric rewards shipping, you get shipping; whether it improves anything or not.

Is new always better? Probably not. Office 2003 is still incredibly useful because nobody forced it to constantly reinvent itself.

Stability is a feature. Knowing when not to ship is an engineering discipline.

The Germans built a word for it. Perhaps we should start using it.

Verschlimmbesserung

The Daily Front Page 22 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Public Square Briefs
article

“It works better in the app”

by blenderob·▲ 654 points·446 comments·shkspr.mobi ↗

The monkey-punchers at Google never quite seem to finish any of their apps. There's always some useful bit of work left undone, or showstopping bug which remains unfixed, a thousand jagged edges as yet unsolved by the greatest minds of their generation.

I wanted to subscribe to an events calendar. I had a URl. I had my Google™ Pixel® phone running the latest Android© 17 with an updated calendar app. Is it possible to click on a calendar link and add it to my phone?

No.

Here's what Google has to say about the matter:

To subscribe to a new calendar, you must use a computer web browser. You can't subscribe to a calendar in the Google Calendar app for Android, iPhone, or iPad.

Really?!? I mean, fucking really????

This isn't the most complex software engineering task known to humanity. Add a + button. Pop open a text entry field. Validate. Save. Done. I'm sure even the shitty Gemini model can vibe code that in a couple of months, right?

Anyway, I opened calendar.google.com on my phone (using desktop mode), added the calendar, and it magically appeared in the app.

This is just pathetic.

In fairness, this isn't only a Google problem. Many companies want a permanent presence on your homescreen and think you're too thick to use your browser's bookmarks feature. Maybe they're right. Maybe an app is the only way to increase the engagement KPI sufficiently so Quinn in the leadership squad can hit their OKRs and get a bonus.

So they build an app. Or, rather, they half-arse it. I've lost count of the number of times I've been told "it's easier if you use our app" only to be unceremoniously punted back to the web when I try to do anything outside of the app's narrow strictures.

I was there in the early days of phone apps. I built stuff for Symbian, BlackBerry, even the bloody Palm Pilot! The central problem with apps has always been that they are hard to update. Every new bit of functionality - or even a new page - needs to be tested on a thousand devices. Once done, it takes an age to distribute to users. The only way to solve that is to have the app dynamically pull in new functionality from a remote resource.

At which point, you've reinvented the Web browser!

Sure, there are some things you can only do with an app (although browsers are catching up), and having an icon on the homescreen is useful (which is easy for sites to add), as is offline functionality (which, again, is possible on the web).

Oh.

If you want an app, fine. Do it. Just finish the job please!

The Daily Front Page 23 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Research & Community Briefs
article

Autonomous Mathematical Discovery in an Open-World Multi-Agent Environment

by stephenchung·▲ 104 points·26 comments·arxiv.org ↗

We study autonomous mathematical discovery in the Station, an open-world multi-agent environment in which AI agents from different model families pursue a shared research goal without a central coordinator or scripted pipeline. Agents choose their own research directions, conduct experiments, collaborate, and build a shared scientific literature. Across 12 construction problems from the AlphaEvolve catalogue and two additional case studies, the Station obtained results novel relative to the prior literature on five problems: a new infinite family of finite-field Kakeya sets, new exact 604-point kissing configurations in dimension 11, new records for the discretized Kakeya needle and sign uncertainty problems, and a substantially improved lower bound for Erdős's minimum-overlap problem. Agents also discovered novel infinite families for Book Ramsey numbers. Importantly, the agents produced not only numerical constructions but also theorems and analyses explaining how those constructions work, making the results more interpretable and easier for mathematicians to build upon. We release all raw agent dialogues, proofs, and verification code, providing a transparent record of how these discoveries emerged.

article

State of the Map 2026

by lode·▲ 165 points·54 comments·2026.stateofthemap.org ↗

State of the Map is the annual event for all mappers and OpenStreetMap users. In 2026 the State of the Map conference will be taking place in Paris and online. It will be a three day conference packed with talks, workshops, discussion rounds and more.

Your organising team.

Attending

If you are attending the conference either in person in Paris or online, here are some useful links to find information:

  • Hot to get to the venue
  • Programme
  • Programme for your mobile devices
  • Connect with other attendees on our chat rooms on Matrix or Telegram, and follow us on our social media channels, e.g. Mastodon.
  • Social Event information
  • Conference Posters
  • Live Streams – Note that if you have a Venueless ticket, please use the link in your ticket to get to the interactive page with live streams, possibility to ask questions, break-out rooms, etc.

Where?

Paris, France
Cité Descartes, Champs-sur-Marne
48° 50′ 30″ N, 2° 35′ 15″ E

When?

August 28 - 30, 2026

The Daily Front Page 24 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Also on the Front Page
The Daily Front Page 25 of 26
Friday, August 28, 2026 The Daily Front No. #260828 — Colophon

That's the Front for Today

Issue No. #260828 — Friday, August 28, 2026 — went to press 2026-08-29 at 09:55 UTC.

About This Magazine

The Daily Front is a daily digital magazine assembled from the stories that reached the front page of Hacker News on Friday, August 28, 2026. Headlines, points, and comment counts are recorded as they stood at press time. All articles remain the property of their original authors — every piece links back to its source and its discussion thread.

How It Was Made

Fetched, cleaned, and typeset by an automated pipeline. An editor model laid out the pages and chose the highlights; a second read a handful of the day's stories and briefed the cover illustrator — 31 model calls and 266k tokens in total. Set in Jacquard 12, Playfair Display, Source Serif 4, and IBM Plex Mono, all served via Google Fonts under the SIL Open Font License.

The Cover

The cover illustration was commissioned with this prompt:

In a university research control room, a scientist keeps both hands on a compact mechanical keyboard, navigating a terminal-like interface rendered as simple geometric panels while a small modular reactor glows behind reinforced glass. The reactor’s access gate is shut with a heavy padlock, and beside it sits an open-source voxel landscape assembled from colorful square blocks, its tiny paths leading nowhere. A single keycap is visibly depressed, but the gate remains firmly closed.

Hyper-detailed 3D product-render treatment of the full university research control room, composed at a precise three-quarter camera angle with physically based materials, studio rim lights, and glossy micro-reflections; use a deliberate palette of deep graphite, cool cyan, electric amber, safety orange, and saturated voxel red, blue, green, and yellow, preserving the scientist’s two-handed contact with the compact mechanical keyboard, the terminal’s simple geometric panels, the small modular reactor glowing behind reinforced glass, its shut access gate secured by a heavy padlock, and the adjacent open-source voxel landscape of colorful square blocks with tiny paths leading nowhere; make one keycap visibly depressed while the gate remains unmistakably locked.

Absolutely no text, letters, numbers, readable symbols, or logos anywhere in the image.

Production Ledger

StageModelCallsTokens InTokens Out
extractgpt-5.6-luna 27 146,176 89,859
layoutgpt-5.6-terra 1 18,534 2,687
covergpt-5.6-luna 2 2,536 381
covergpt-image-2 1 252 5,488

The Publisher

Published by Johnny.

Support the Press

If The Daily Front brightens your morning, consider supporting its publisher.

Credits & Contact

All content — articles, posts, comments, and the images within them — belongs to its original authors and is reproduced here to point readers back to the source. Full credit goes to those creators; every item links to its original and its Hacker News discussion.

If you are an author and would like your content removed from an issue, write to hi@johnnys.page and it will be taken down.

Feedback is always welcome at the same address: hi@johnnys.page.

Credit where credit is due.

Every page of this issue began as someone else's work — these are the original sources, linked in full.

  1. GUIs should be fully keyboard-driven by ckardaris — ckardaris.com·HN discussion ↗
  2. Htmx 4.0 by rmsaksida — four.htmx.org·HN discussion ↗
  3. Just the rumour of a bug is enough to find an exploit these days by avsm — anil.recoil.org·HN discussion ↗
  4. Get your Windows license refund by smartmic — en.refund4freedom.org·HN discussion ↗
  5. Luanti removed from Google Play due to baseless AI copyright notice by miniBill — blog.luanti.org·HN discussion ↗
  6. Show HN: OpenTIE and OpenXWA, Modern Ports of Tie Fighter and X-Wing Alliance by elyosh — github.com·HN discussion ↗
  7. Migrating to HTTPX2 by tosh — github.com·HN discussion ↗
  8. Hilariously fast volume computation with the divergence theorem (2018) by luu — alyssarosenzweig.ca·HN discussion ↗
  9. Curvature Beziers: Improving on a timeless recipe by leephillips — acko.net·HN discussion ↗
  10. EasyEffects can improve laptop speaker sound quality by birdculture — osnews.com·HN discussion ↗
  11. Terminal-Bench-Science: Evaluating AI agents on scientific research workflows by matt_d — terminal-bench-science.ai·HN discussion ↗
  12. Select * from Internet.blogposts by mmattbtw — pfrazee.leaflet.pub·HN discussion ↗
  13. Sovereign Tech Agency invests €500k in Flatpak by eigenspace — modal.cx·HN discussion ↗
  14. AI Engineer Notebooks – free, framework-free RAG/agents/evals on Colab by calmrocks — github.com·HN discussion ↗
  15. Smaller reactors bring nuclear power closer to fulfilling its promise by sohkamyung — nature.com·HN discussion ↗
  16. An investigation into the state of corvid–human relations by speckx — audubon.org·HN discussion ↗
  17. Processing in Memory: DRAM Is About to Do Math by bhouston — ben3d.ca·HN discussion ↗
  18. U.S. sanctions against the A/I Collective by exiguus — inventati.org·HN discussion ↗
  19. The Twelve-Factor App (2025) by jxmorris12 — 12factor.net·HN discussion ↗
  20. Verschlimmbesserung: The Word Your Software Updates Need by speckx — geekyschmidt.com·HN discussion ↗
  21. “It works better in the app” by blenderob — shkspr.mobi·HN discussion ↗
  22. Autonomous Mathematical Discovery in an Open-World Multi-Agent Environment by stephenchung — arxiv.org·HN discussion ↗
  23. State of the Map 2026 by lode — 2026.stateofthemap.org·HN discussion ↗
  24. GLM-5.3 is now open-weight by jeudesprits — huggingface.co·HN discussion ↗
  25. Inception-style curved map for turn-by-turn directions by smoser — orbify.eu·HN discussion ↗
  26. Judge rules Trump administration’s blacklisting of Anthropic was illegal by jbegley — nytimes.com·HN discussion ↗
  27. Show HN: The load-bearing vocabulary of Claude by Labo333 — louisabraham.github.io·HN discussion ↗
  28. Visual Analysis of Binary Files by vismit2000 — binvis.io·HN discussion ↗
  29. Stripe said to abandon $50B pursuit of PayPal by 1986 — bloomberg.com·HN discussion ↗
  30. Pentagon's blacklisting of Anthropic was unlawful, US judge rules by softwaredoug — reuters.com·HN discussion ↗

Browse all issues in the archive →