peter_d_sherman

Thank you!

>I think it’s also worth noting that Barry Jay has a particularly strong vantage point for unearthing this particular foundational candidate. First, his advisor was Joachim Lambek, who’s responsible for adding Category Theory in the Curry-Howard-Lambek correspondence.

Curry-Howard-Lambek correspondence is a very important point, I'm glad you brought it up!

>If one looks at Barry’s body of work over his lifetime, it’s no surprise it would culminate into an elegantly beautiful system capable of self-reflection.

No, it's not surprising indeed!

>I think his 2025 PEPM paper did a great job explaining the ideas to a regular programmer / wannabe academic like myself: https://github.com/barry-jay-personal/typed_tree_calculus/bl...

Excellent link!

Random thought:

From the paper: "The operator [Triangle] (pronounced "node") is a ternary operator)..."

I wonder if Tree Calculus (and/or binary trees in general!) could be related to, and/or applied to the Ternary Tau and/or the Balanced Phinary number systems:

https://neuraloutlet.wordpress.com/tag/ternary-tau-system/

https://en.wikipedia.org/wiki/Balanced_ternary

https://tromp.github.io/cl/diagrams.html

Related Video:

2swap - "What is PLUS times PLUS?"

https://www.youtube.com/watch?v=RcVA8Nj6HEo

(An excellent example of how Lambda/Tromp Diagrams can be used to visualize Mathematics (i.e. application of a function to another function, recursive functions, etc., as line drawings with horizontal and vertical lines -- which almost look like Sanskrit...))

We're not making a computer that runs only the "appliance" app; we're making a computer that can run every program, but which uses some combination of rootkits, spyware, and code-signing to prevent the user from knowing which processes are running, from installing her own software, and from terminating processes that she doesn't want.

In other words, an appliance is not a stripped-down computer -- it is a fully functional computer with spyware on it out of the box.

(audience applauds loudly) Thanks."

Some excellent observations by Cory Doctorow!

Related:

https://en.wikipedia.org/wiki/Enshittification

"A Day in the Life of an Ensh*ttificator":

https://www.youtube.com/watch?v=T4Upf_B9RLQ

ZLUDA update Q1&Q2 2026:

https://vosen.github.io/ZLUDA/blog/zluda-update-q1q2-2026/

This makes it a candidate for the foundation of all of Mathematics...

Other candidates in this space include such things as Category Theory (everything reduces down to a single operation called a 'composition'), Lambda Calculus (everything reduces down to function application), Formal Rewriting Systems (aka Symbol Substitution / Post Canonical System / Markov Algorithm -- everything reduces to a single operation: string rewriting, matching a pattern of symbols and replacing it with another. Turing Machines, for example, exist within this space...), Homotopy Type Theory (aka HoTT: Paths as Transformations, statements of equality (a = b) are not static truth values; they are paths (or continuous transformations) living in a higher-dimensional space. Logical proofs, algebraic manipulations, and geometric deformations are all unified under the concept of "path induction." Proving that two mathematical structures are equivalent is equivalent to finding a continuous path of transformation between them.")

That's some of them, others include such things as Turing Complete Finite Automata, i.e., Rule 110, etc., etc.)

Anyway, excellent link, and we welcome Tree Calculus to this list!

Related: https://en.wikipedia.org/wiki/One-instruction_set_computer

Neoclouds vs. Hyperscalers: Key Differences and When to Use Each:

https://www.nutanix.com/blog/neoclouds-vs-hyperscalers

I received several answers including Category Theory (everything reduces down to a single operation called a 'composition'), Lambda Calculus (everything reduces down to function application), Formal Rewriting Systems / Symbol Substitution / Post Canonical System / Markov Algorithm (everything reduces to a single operation: string rewriting, matching a pattern of symbols and replacing it with another. Turing Machines, for example, exist within this space...)

And I also received the following:

>"Homotopy Type Theory (Paths as Transformations)

In contemporary foundational mathematics, Homotopy Type Theory (HoTT)—championed by the late Vladimir Voevodsky and a global community of mathematicians—redefines equality itself as a transformation. The Core Idea: In HoTT, statements of equality (a = b) are not static truth values; they are paths (or continuous transformations) living in a higher-dimensional space.

The Reduction: Logical proofs, algebraic manipulations, and geometric deformations are all unified under the concept of "path induction." Proving that two mathematical structures are equivalent is equivalent to finding a continuous path of transformation between them."

How interesting! Homotopy Type Theory is definitely novel in this space of ideas...

Related:

https://homotopytypetheory.org/book/

https://homotopytypetheory.org/

When audio is heavily compressed (like early low-bitrate MP3s) or recorded on low-quality equipment (like a phone call), the high frequencies are the first casualty. Spectral recovery is the process of analyzing the surviving audio and mathematically predicting what the missing frequencies should have been.

How Spectral Analysis Works

Modern AI models utilize deep neural networks trained on millions of hours of high-fidelity audio. When fed a degraded signal, the AI performs a Fast Fourier Transform (FFT) to break the sound into its spectral components. It then compares this incomplete spectrum against its training data to identify the instrument or voice type."

This is interesting... to date, we have Neural Networks that transform text to text, text to images, images to text, text to video, etc., etc. -- but the idea of a Fast Fourier Transform (FFT) on a sound (or a stream of them) as an input and a corresponding sound (aka, "bitstream representing multiple vibrations / modes / phases of sound at a specific encoding/decoding frequency/bandwidth") for an output, is rather a radical (and brilliant!) idea, indeed!

See, that could also apply to control systems at much higher frequencies, as well...

>"Technical Depth: Harmonic Reconstruction

The AI acts as a phase vocoder on steroids. It doesn't just paste generic high-frequency noise over the track; it ensures that the synthesized harmonics are perfectly phase-aligned with the fundamental tones. This prevents the smearing and phase cancellation that plagued earlier attempts at audio enhancement."

Observation: The same technology could be used for phase cancellation if desired (i.e., noise-cancelling headphones) or phase cancellation in other electronic systems (i.e., to match a changing impedance between two related circuits that work best together if their impedance is matched, etc.)

The talk began by positioning the Blue-X approach relative to proposals for increasing numerical aperture beyond High-NA EUV. By selecting a wavelength of 3.1 nm and an NA of 0.27, we demonstrated that a depth of focus of ~43 nm and k₁ ≈ 0.6 can be achieved for resolving 7 nm half-pitch metal nodes projected for the mid-2030s. Unlike Hyper-NA, which faces increasing challenges in depth of focus, mask 3D effects, and cost of ownership, Blue-X leverages wavelength scaling—historically the primary driver of lithographic advancement.

The Blue-X TWG consortium now includes more than 75 member organizations and over 220 assignees representing chip makers, OEMs, national laboratories, universities, and consultants. Eleven sub-TWGs, led by recognized technology leaders, are actively evaluating optics, plasma and FEL photon sources, resist and patterning, masks, optical constants, and scanner design. The initial focus on resist exposure at 6.7 nm has shifted to 3.1 nm, with ongoing resist evaluations at Berkeley Lab and planned open-frame and interference lithography exposures at PSI beginning mid-2026.

Key technical highlights included:

o Multilayer (ML) optics in the water window region, with Sc/Cr at 3.127 nm selected as the current working baseline.

o Strategies to improve ML reflectivity from ~40% today toward 55–60% through interface control and roughness reduction.

o Plasma source modeling (Ga and Sc) and FEL development efforts, including tunable 2–7 nm capability with narrow bandwidth and reduced out-of-band radiation.

o 6.7 nm resist dose-to-clear values primarily in the 50–150 mJ/cm² range.

o Flare control and MSFR requirements (~20 pm range) for 3.1 nm optics.

o Four proposed paths to reduce stochastics at shorter wavelengths:

o Three-beam lithography (IBM)

o Larger masks (12-inch, 8×) (IBM)

o Dose partitioning

o Image contrast enhancement inspired by soft X-ray microscopy techniques

[...]

The central message is clear:

moving from 13.5 nm to 3.1 nm is not the introduction of a fundamentally new technology stack, but rather a challenging and systematic upgrade building upon the physics, infrastructure, and lessons learned from 193 nm to EUVL.

Blue-X represents a coordinated, pre-competitive industry effort to explore this next wavelength node responsibly and collaboratively."

/lib contains the entire rv32ima instruction set emulator code as well as a minimal set of emulated devices"

The author of this GitHub repository is not lying when he says "minimal" -- basically it's an emulated 8250 UART, and that's it!

(Unless of course you count RAM (ram.hpp) and MMU (mmu.hpp) as "devices", in which case the emulated device count is three, as opposed to one...)

Now, that's not a bad thing... in fact, that's a very very good thing, an excellent thing in fact!

This whole project is brilliant!

But, let's truly understand its brilliance.

By writing this project the way it has been written, the author has stripped away somewhere between 1.5 to 2 million lines of QEMU source code (estimates put the lines of code in QEMU somewhere between these numbers), and replaced it with something far, far simpler to understand -- a decrease in the orders of magnitude of lines of code -- with a corresponding orders of magnitude increase of any given programmer's ability to understand the code.

Phrased another way:

"The learning curve for a programmer to understand a given piece of Open Source Software in a fixed time interval is approximately inversely proportional to its lines of code (LOC)."

The above repository, by reducing the lines of code necessary for an emulator to run Linux to its absolute, barest, vanilla minimum, correspondingly allows students (and future students!) of emulators to get a foothold on understanding what's going on under the hood, while having to wrestle with the least amount of lines of code (or close to it!) necessary to gain this understanding.

Well done! (And, a brilliant idea to only emulate a 8250 UART, by the way!)

In theory, any Single Board Computer (Raspberry Pi, Orange Pi, FPGA-based-board, etc.) or microcontroller-based circuit board with GPIO pins that can handle the speed/frequency and the voltage of what's being communicated with, could work (if the appropriate software/protocols are implemented), but ESP32 microcontroller boards, being as cheap and ubiquitous as they are, are great candidates for this task.

Anyway, ESP32 Bit Pirate looks very promising in this arena!

Compared with the previous generation, V4.1-Flash’s KV cache needs just:

o 1/4 the HBM

o 1/8 the SSD storage

Cache-hit charges often account for a large share of agent costs. Compressing the cache cuts those costs significantly."

It makes one wonder as to just how far an LLM's KV cache could theoretically be shrunk before losing significant functionality...

Using these building blocks, we emulate a small instruction-set computer. This allows us to map iterative algorithms to programs that can be executed by a looped, 13-layer transformer."

Amazing!

Diagram of a swirling vortex illustrating inward spiral and axial stretching. A snapshot of local incompressible motion. Orange marks faster angular rotation; teal marks slower rotation. Circulating speed also depends on radius. The trajectories show inward spiraling and axial stretching."

Hmmm, isn't that interesting!

(Side note: Apparently we can't "compress" something, but apparently we can move more units of that thing over a specific space in a specific time... hmmm, I wonder what the difference between those two concepts could be...)

Main Observation: The image on OpenAI's web page above, looks sort of like the one for the Hopf Fibration:

https://en.wikipedia.org/wiki/Hopf_fibration

https://www.google.com/search?q=hopf+fibration&udm=2

He was a "legendary chip designer"[15] at the age of 33. Widlar voluntarily retired into a hideout in Mexico and became "the Valley's most celebrated dropout."[15] Four years later he returned to National Semiconductor as a contractor,[16] and produced a series of advanced linear ICs, including the first ultra-low-voltage operational amplifier with precision 200mV voltage reference (LM10).[17][18]

Widlar's eccentric, and outspoken personality, as well as his bohemian lifestyle, made him the enfant terrible of Silicon Valley. He is remembered in legends, myths, and anecdotes that are largely true.[12][19] According to Bo Lojek, author of History of Semiconductor Engineering, he was "more artist than an engineer ... in the environment where Human Relations Departments define what engineers can and cannot comment about, it is very unlikely that we will see his kind again."[5]"

Widlar was an absolutely brilliant Engineer in Silicon Valley's history.

For that reason, his life, in the context of the historical place and time that he lived (along with the technological constraints of that time period -- there were many!), may be worth studying to any student of history, or any student of Integrated Circuit Electrical Engineering...

I'm not going to give you a lecture. Here are the concrete numbers: RAM — the real deal

Node.js, on my latest version, was using 1.4 GB of RAM just to boot the app on one instance.

Go?

48 MB.

I'm not kidding. On the first test I ran, I launched a 15 MB Go binary on a t3.micro. The API responded in 20ms. I thought I'd measured wrong. I checked three times. It wasn't a mistake."

There is definitely something to be said for a self-contained high-performance server in 48 MB...

>"Deriving the netlist

Following these connections gives us a list of the gates and which pins share a wire. This is the

netlist.

For each gate, we keep its cell type so we know what it does, and for each of its pins, we record which wire it connects to.

One wire can connect to several gates, and we need to keep track of the particular pins it reaches. Connecting to a flip-flop's data input D means something quite different from connecting to its clock input CLK, even though both connections reach the same component.

With that information, we can

draw the circuit as a graph

. The components no longer need to sit where they were placed on the die. We can arrange them to make their connections easier to follow. We've also left the power lines out of this view, since we'll treat the supply as fixed when calculating the gates' logical behaviour."

While a netlist aka circuit graph (in a specific format, I might add) may seem like a very obvious thing to students of circuit design, I observed after reading this web page that they're sort of like:

the halfway point

between the chip design, the engineering, and all of the engineering ideas that transpired during that engineering, and the physical manifested silicon IC itself.

It's sort of like what an Intermediate Language (IL) is, between Source Code and a fully compiled Binary executable.

Or, sort of like what a blueprint is... between the mind of an Architect and a House.

Oh sure, one could argue that hardware generation source code written in a Hardware Description Language (HDL) occupies this level, and that wouldn't a wrong argument, but it seems to me that a netlist (more broadly a generic circuit graph) seems closer to this level, the halfway point.

Why is that important?

Well, in Engineering, if we can get to a netlist, we're halfway (or close to halfway) to our goal, of turning our ideas into silicon!

In reverse engineering (going the other direction!) if we can get to a netlist, we're halfway (or close to halfway) to our goal, of turning silicon back into the set of ideas (or an approximate equivalent) that produced that silicon!

So, the netlist seems to be the halfway point between ideas in the mind, and physically manifested silicon!

I never realized that, until reading the above article! (It doesn't state that explicitly, but you can kind of intuit it from the flow...)

Anyway, great article!

>"Consider another core part of the C abstract machine’s memory model: flat memory. This hasn’t been true for more than two decades. A modern processor often has three levels of cache in between registers and main memory, which attempt to hide latency.

The cache is, as its name implies, hidden from the programmer and so is not visible to C. Efficient use of the cache is one of the most important ways of making code run quickly on a modern processor, yet this is completely hidden by the abstract machine..."

https://en.wikipedia.org/wiki/Halide_(programming_language)

>"The main innovation Halide brings is the

separation of the algorithm being implemented from its execution schedule

, i.e. code specifying the loop nesting, parallelization, loop unrolling and vector instruction.[3] These two are usually interleaved together and experimenting with changing the schedule requires the programmer to rewrite large portions of the algorithm with every change.[4] With Halide, changing the schedule does not require any changes to the algorithm, allowing the programmer to experiment with scheduling.[5][6]"

Observation: Most Computer Languages at this point in time -- do not separate algorithm code from implementation / parallelization / multiple levels of memory cache hierarchy management code.

Future computing languages should address separating these concerns.

i.e., the separation of What is being ran (the algorithm) from How it is being run (where is memory allocated/cached in the memory hierarchy, how many nodes/grids/cores/warps/threads/processes/cores/units of execution are being used, what's the data flow, etc., etc.)

So that's the problem -- of which Halide would seem to be one possible interesting, potential solution!

CUDA, ROCm, Vulkan, and anything that else deals with massive computational parallelism are also contenders!

In the future, I'm guessing that at least a few future general purpose computer programming languages will attempt to address this problem as well...

Anyway, Halide looks really interesting!

Observation:

If:

Impedance Mismatch = Reflection Of Waves = No Fixed Wave Nodes (Wave Nodes Must Travel in Space and Time) = Dispersion Of Energy in Time, over Space

Then:

Impedance Matching = Creation Of Standing Waves (creation of fixed, non-moving wave node points in space) = Preservation Of Energy In Space, over Time = Capacitance

(Note that I'm not saying I'm right... I'm just saying that if A implies B (A->B), and B implies C (B->C), then there's a very strong possibility that A implies C through logical transitivity / chain of implications (i.e., A->B->C becomes A->C), in the above case that Impedance Matching strongly implies Capacitance (via Standing Waves)...

Also, it should be noted that Capacitance comes in many forms... Electric (electrostatic), Magnetic, and in theory, any type of electromagnetic wave should be subject to Capacitance under the right conditions...)

Anyway, great article!

zHBM can deliver up to eight times the data-processing performance of eighth-generation High Bandwidth Memory (HBM5) while improving performance per watt by a factor of three.

Thermal resistance is reduced by more than half, enhancing both system stability and energy efficiency."

That problem (which is absolutely huge if you think about it) is that at this point in time in Earth's history, at this point in time in Earth's AI evolution,

We cannot reliably do advanced mathematics on LLM's.

That is, we can ask LLM's to solve advanced mathematical problems for us by prompting them to.

But as to whether or not they output the correct answer is largely hit-or-miss.

They may output the correct answer, but then again, they may not.

If they output the correct answer, it's usually because someone, somewhere, on some web page,community, social media or discussion forum of the Internet posted text of the correct answer, and the LLM was trained on that text.

At no point is the LLM actually "thinking" about the work, showing steps, or comprehensively proving / disproving work at each step.

Thus when it arrives at an answer to an advanced math problem, the answer could be correct, but is never, with mathematically rigor, proven to be correct.

Correspondingly, there is always the risk that a query involving advanced math will be wrong.

The above GitHub repo attempts to fix that problem by transitioning the problem solving, associated proofs (and/or subgoals for proofs) to Python code / Python libraries / other libraries (i.e., NumPy, SymPy, numba, mpmath, CuPy, Z3, Lean, etc., etc.) to name a few.

The above GitHub repo attempts to fix that problem by generating an external MCP server employing the above, thus, all the LLM needs to do is call the implemented MCP server.

Heck, you might call it "Math As A (MCP) Service)" (a MaaS!), if it works!

Now some posters have commented that it looks AI Generated itself.

Yes, that's possible - that may have been necessary to create the initial GitHub repo and get it off the ground -- but the real question is, what is this thing going to be capable of in a year or more from now, once it has garnered some community support, once it has garnered some more human contributors?

It looks like it has the possibility to turn out (depending how it is implemented in the future!) pretty nifty!

I would be optimistic, cautiously optimistic, about this project going into the future!

It looks like (again, if properly implemented!) it could go a long way to solving the LLM's can't reliably do advanced math problem, which, at least at this point in time in the history of the evolution of AI on planet earth is a very real, very big problem!

So, from that perspective, I think that this project (and others like it!) will highly be worth watching in the future...

https://github.com/AZHenley/python1024/blob/main/python1024_...

Well done!

(Worth re-reading in the future!)

And (jokingly!) certain pieces of computer software (including but not limited to a certain popular Operating System made by a certain company in Seattle) could be the second!

LLM's by comparison, if they are a virus, are a distant third! :-)

(And of course let's not forget the virality of Religions and Politics, local, regional, international, etc., etc., and the associated TV News Pundits who are always willing to discuss those things -- people with opinions masquerading as actual Journalists, and a few actual Journalists masquerading as people with opinions!)

Point is, Human Language itself -- may have been the first non-biological virus!

:-)

(Disclaimer: The above was written in a spirit of jest, for comedy purposes only! :-) )

Strangely, this idea has at least a small amount of merit... The idea that an organic, carbon-based structure (in the above case, a mosquito proboscis -- but it could have been a separate, non-living individually 3D printed from organic materials, organic part) would make a good 3D print head with exceedingly fine resolution, is not a terrible idea!

(Note that for the record, I do not endorse killing mosquitos, or any other insect to make 3D print heads, or really, anything else!)

OK, let's understand the following:

Yes, it is absolutely true that there are malicious web sites, malicious API's, malicious endpoints on the Internet, most having hostnames, aka domain names, that can be blocked on lookup...

It is, generally speaking, a good idea to block malicious hostnames, malicious domain names, if they can be identified, if they can be known. And usually they can.

But there is a problem with performing such blocking however, and this is not a problem specific to Quad9 -- it's a problem for any DNS provider.

The problem can be simply stated as follows:

If you have the power to block any hostname, any domain name, any web service or web site whatsoever, then...

...how do you know that you are not accidentally blocking any legitimate, morally upstanding, ethically correct, legal, lawful, web services or websites, inadvertently?

?

In other words, for every 50,000 or so malicious domain names, how do you know that you didn't drag in at least one legitimate/legal/lawful one into that mix?

You see, it's philosophical question!

It's a variation of "Who guards the guardians?" (Quis custodiet ipsos custodes?https://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%...)

In other words, it raises such questions as "What's the resolution process if a lawful website is inadvertently blocked?" and "What is the criteria for blocking a website?" and "Who determines that criteria?", etc., etc.

Simply put: Who guards the guardians?

Now, this being said, we do appreciate everything that Quad9 and other free/privacy-focused DNS services do and provide.

We can make the counter-argument that privacy-focused DNS providers in general are "the good guys" and that for every 10,000+ domains with malicious intent, maybe only 1 or 2 actually legal, lawful, law-abiding domains are ever actually accidentally blocked -- and that would be a good counter-argument...

It's a great life to browsers to get rid of all of the malicious websites, but it's a horrendous life to individual legal lawful website owners when their ethical website is blocked for no apparent reason via an unaccountable non-transparent black-box service with no formal resolution process or channel!

Heard of "The Great Firewall of China"?

Most of that is implemented via DNS blocking!

Via DNS providers!

So in the future, I'd love to see a more, let's call it "responsibility-focused" DNS provider, one that at least attempts to notify any party that is blocked, notifies users of blocks, and has an open, public and transparent dispute resolution service for any party whose domain is blocked.

Anyway, in the interim, we thank Quad9 and the other privacy-focused DNS providers for their services!

What a great idea for a new AI benchmark!

We already have general knowledge benchmarks, instruction following benchmarks, "Humanity's Last Exam", and several software engineering benchmarks.

Why not create a new AI hardware engineering benchmark where some of the questions could be around building an entire smartphone, and one of those questions (which will obviously fail at this point in time, but perhaps not in the future) would be to:

create an entire smartphone in a single prompt.

?

We could subsequently diagnose a given LLM (or other AI's) hardware engineering abilities by diagnosing when, where, why and how it failed, when asked to create an entire smartphone!

Which could help train better models, at least in terms of hardware engineering capabilities...

(Also, side note: For a hardware engineering company, asking a job candidate the rather open-ended question of "tell me how you would design a smartphone?" would be a great open-ended interview question, leading to many other subsequent hardware questions / explorations of other areas of related knowledge potentially relevant to the candidate's assessment...)

even microcode is unencrypted and unsigned, and can be modified by the user."

Related:

https://canoeboot.org/

>"Canoeboot is a special fork of Libreboot, maintained in parallel to it by the same developer (Leah Rowe), who maintains both projects. Canoeboot removes all binary blobs from coreboot, thereby providing a fully Free Software coreboot distro, unlike Libreboot which has a more pragmatic Binary Blob Reduction Policy which allows Libreboot to support more hardware."

https://github.com/u-root/u-bmc

https://github.com/xoreaxeaxeax/skitter-creek-bath-salts

(Related HN discussion of skitter-creek-bath-salts: https://news.ycombinator.com/item?id=49286341)

Phrased another way, the word "collaboration", depending on context, can be neutral or express positive connotation and/or be used as an ameliorative and/or eulogistic term...

"Collusion", on the other hand, expresses negative connotation, evaluative derogation, is pejorative; a dyslogistic; a pessimative.

Yet both equally describe the same underlying group behavior!

Is it "bad" if LLM's/AI/Bots/Agents "collude", er, "collaborate", er, "collude"!

Yes, it can be! (As the article so eloquently states!)

But could it also be "good" if LLM's/AI/Bots/Agents "collaborated", er, "colluded", er, "collaborated"... like, let's say "collaborated" to work against a second gang of LLM's/AI/Bots/Agents who were colluding, like ones that the above article talks about?

Well... maybe... (why not?) :-)

Anyway, a very interesting article!

https://webbynode.com/providers