peter_d_sherman

Related:

https://nuvacore.ai/

Related:

https://cs.wheatoncollege.edu/mgousie/comp335/guide2langs.pd...

Other alternative Rust compilers/transpilers/grammars:

https://github.com/Rust-GCC/gccrs

https://github.com/rustic-compiler/rustc_codegen_c

https://github.com/rrevenantt/antlr4rust

>"low-effort comments"

I have never heard that term used before, prior to reading this thread...

All I know is that "low-effort comments" -- is going into my 2026 lexicon!

(Admittedly this comment, my comment, the words I have written, above -- is admittedly somewhat of a "low-effort comment" in and of itself(!) A low-effort comment about other low-effort comments (a "meta" low-effort comment, if you will!), but I digress... I guess at times "we all fall short of the glory of the highest of high effort comments"... :-) )

Anyway, "low-effort comment" is a great piece of terminology, isn't it? :-)

It's going into my 2026 lexicon...

>"Within one scale unit, the platform spans nearly 160 CPU nodes with 30K cores and ∼250 TB of DRAM. It manages petabytes of layers and images. On a typical day, a single scale unit serves about 3 M sandbox instances, with peak concurrency reaching ∼380K and a creation rate exceeding 5,000 instances per second."

Impressive numbers!

Whoever would have thought (in prior years) that in 2026 AI Agents (not people or corporations, at least not directly) seem to be (or seem to be rapidly becoming) the biggest consumers of cloud computing resources...

Anyway, a very interesting paper and environment!

>"they’re having trouble keeping up with the onslaught of AI-generated papers."

What an interesting problem to have!

So, let's see, we have a hosting site, much like GitHub is for code, or DropBox is for files, or Pastebin is for text, or YouTube is for Videos, except that this website is tailored to hosting academic papers as opposed to other specific file types...

Now in 2026 we have a problem, and that is that AI (or people using AI) are apparently writing crappy AI-written academic papers, and uploading them to ArXiv (and other academic paper hosting sites) in large amounts...

What to do, what to do?

Hmmm, this sounds very similar to the problem of many crappy AI-generated videos being uploaded to YouTube...

Or, the "AI-generated-file-of-specific-type-was-uploaded-where-the-file-contents-of-uploaded-files-of-that-type-are-NOT-supposed-to-be-AI-generated-on-this-specific-file-type-hosting-website" problem...

What to do, what to do?

Well, heck, I don't know!

What shall we all do?!?!?!?!?!?

Observation (if I might!): The "people using AI to upload crap to the Internet" problem is a subset of the (older, larger!) "people just plain uploading crap to the Internet" pre-AI problem... :-)

>"Lots of suggestions in the comments but no magic bullets."

This is Hacker News after all; what were you expecting? Silence? :-)

>"One might as well ask how it's possible that our complex 3 dimensional world can be contained in the flat surface of a mirror, film strip, or camera sensor."

Space filling curves with three dimensions could potentially provide us with some clues:

https://en.wikipedia.org/wiki/Z-order_curve

"In mathematical analysis and computer science, functions which are Z-order, Lebesgue curve, Morton space-filling curve,[1] Morton order or Morton code map multidimensional data to one dimension while preserving locality of the data points (two points close together in multidimensions with high probability lie also close together in Morton order)."

Also, to answer the question, potentially Octrees might be interesting to research:

https://mathworld.wolfram.com/Octree.html

"An octree is a rooted tree that represents a three-dimensional region by recursively subdividing it into eight congruent, axis-aligned cuboids, usually cubes (Meagher 1982, Samet 1990). Each internal node represents a spatial cell and has eight children, one for each octant of the cell. A tree leaf represents a cell that is not subdivided further."

But, since "a picture is worth one thousand words":

https://www.google.com/search?q=octree&udm=2

Another thing to consider is that according to the Knuth Transform (aka Left-Child Right-Sibling (LCRS) representation), apparently any k-ary tree (Octree = 8-ary tree) can apparently be converted into a Binary Tree without losing information:

https://en.wikipedia.org/wiki/Left-child_right-sibling_binar...

So, is there a 1D (or 2D) representation for 3D reality?

Well, I personally don't know!

What I do know is that a certain popular rock group sang the following lyric in one of their popular rock songs, back in 1999:

"Space may be the final frontier -- but it's made in a Hollywood basement..."

-The Red Hot Chili Peppers, "Californication"

So, you decide! :-)

>"We propose SIREN, a simple neural network architecture for implicit neural representations that uses the sine as a periodic activation function: [...]

Interestingly, any derivative of a SIREN is itself a SIREN, as the derivative of the sine is a cosine, i.e., a phase-shifted sine (see supplemental).

Therefore, the derivatives of a SIREN inherit the properties of SIRENs, enabling us to supervise any derivative of SIREN with “complicated” signals. In our experiments, we demonstrate that when a SIREN is supervised using a constraint Cm involving the derivatives of φ, the function φ remains well behaved, which is crucial in solving many problems, including boundary value problems (BVPs).

We will show that SIRENs can be initialized with some control over the distribution of activations, allowing us to create deep architectures.

Furthermore, SIRENs converge significantly faster than baseline architectures, fitting, for instance, a single image in a few hundred iterations, taking a few seconds on a modern GPU, while featuring higher image fidelity..."

SIRENs look interesting... the idea of using Sine as an Activation Function seems like a brilliant one!

Related:

TileLink

https://bar.eecs.berkeley.edu/projects/tilelink.html

WISHBONE

https://opencores.org/howto/wishbone

This is interesting -- not from the perspective of different fonts (although that's interesting too!), but from the perspective of it's a web page that can apparently render fonts on the fly...

That means that it's probably using some library in JavaScript or WASM to implement that.

If that's the case, then I'm thinking, you know, that functionality, that is, font rendering on demand could, in theory, be placed into a CloudFlare Worker (or other Serverless service, i.e. AWS Lambda, Azure Functions, Google Cloud Functions, OCI Funcions, IBM Cloud Code Engine, Alibaba Function Compute, etc., etc.)...

That could be useful for a variety of applications... including (but not limited to!) word processors, typesetting software, homemade browsers, online games, heck, really anything where custom fonts are needed...

There could be two distinct benefits with this, let's call it a "FaaS" (Fonts as a Service!) idea:

1) No need to bundle/ship/include a font rendering engine with software that needs one.

2) Extra layer of security -- Local font rendering software is typically Turing-Complete, and as such, the local font renderer could potentially run viruses and other unwanted programs. I.e., local font rendering is a security risk. By hermetically sealing that code into serverless function, offsite of the local machine and having that serverless function send only fully rendered font data one way, the attack surface of the font rendering engine is effectively removed from any local PC.

This being said, the disadvantage is that it couldn't be used if the Internet or server or cloud provider is down for any reason.

Graphical font data, once created and downloaded, could however be cached by clients for offline situations / offline usage / offline work.

So, there are some interesting ideas here...

>"CLM-8B also sets a new SOTA on challenging agentic coding benchmarks, including DeepSWE (81.6%) and Terminal Bench 2.1 (87.6%). [...]

A full pre-training run on the Nemotron DQA dataset takes about an hour on a single RTX 4090 GPU.

Most importantly, since states and actions are disaggregated, their embeddings can be cached independently. In settings where the state evolves continuously (e.g., Super Mario) while the action set remains fixed, we only need to recompute the state embedding at each step and can reuse the cached action embeddings. This substantially reduces inference cost, with the efficiency gains becoming increasingly significant as the number of candidate actions and context length grows."

There does definitely seem to be something there with respect to Contrastive Language Models.

They are probably worth studying for people (like myself!) who want to wring the absolute last cycle of local AI training and inferencing performance out of consumer-grade (i.e., not datacenter scale nor cost) hardware...

>"The first chip Huang worked on had 200 transistors, each of which he said he knew by name, while today’s engineers assemble systems from chips containing hundreds of trillions of them without ever working at that level. “Some of the lower-level knowledge is gone,” he acknowledged, and he later described AI as “clearly” a new abstraction level in the same progression."

Jensen gets it!

Related:

https://en.wikipedia.org/wiki/Coupling_(computer_programming...

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

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

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

https://en.wikipedia.org/wiki/Prat%C4%ABtyasamutp%C4%81da

>"Classes of manycore systems

GPUs, which can be described as manycore vector processors"

That's arguably a much better description of a GPU than merely "Graphics Processing Unit"! :-)

>How does HERMES connect remote locations?

Peter Bloom: We use the ionosphere as our satellite—or mirror—which helps us move information, voice, and data over really long distances. We’re using small radios that put out about 20 watts of power, and we can pretty reliably do 400 to 600 kilometer links between two radios."

That is some amazing distance for a very small amount of power!

Microsoft should open-source FoxPro, at least some version of it, because as of 2026, it has no commercial viability (no ability for it to make the company money) compared to say SQL Server, Access and/or Visual Basic with the appropriate back-end database drivers. If Visual FoxPro V9 (2007) is too late because there are unexpired patents or other issues, then Microsoft should open-source an earlier version.

Even open-sourcing FoxPro 2.6a for DOS (the last DOS version, August 1994, > 30 years ago) would be better than open-sourcing no FoxPro version.

Fundamentally, FoxPro, at its core, is 4 things:

1) It's own low-level database engine

2) It's own SQL parser/interpreter/engine sitting on top of #1.

3) Simple (but very data-aware of the underlying data!) scripting language (based on dBase, referred to as "xBase" -- or more specifically the FoxPro dialect of xBase) sitting on top of #1 (except for the SQL commands, SELECT, INSERT, UPDATE, DELETE, etc., which sit on top of #2)

4) Form / GUI / Data-entry and Data-search Form Designers that exist on top of #1, #2 and #3. Basically a primitive (although very functional and elegantly simple) windowed App building environment.

Now, all of those 4 things could be replaced and/or outsourced to other open-source projects...

For example, to read/write/index/seek in FoxPro database files (the low-level database engine):

https://github.com/MPSystemsServices/CodeBase-for-DBF

I'm not sure if CodeBase comes with its own SQL engine/parser -- but if not, SQLite has a pretty good one which could probably be used with some modifications. If not, ANTLR has various SQL grammars for it floating around on the net (here's a quick blog post of someone using ANTLR to create a query language: https://markandrewperry.medium.com/using-antlr-to-create-a-q...)

For the scripting language, any scripting language could potentially work, but special attention should be paid to the way FoxPro variables are aware of data in underlying open tables in the current work area (SCATTER and GATHER commands and how they work, etc.), which is one of the unique features of FoxPro. (Also, for command / line / expression evaluation, you'd probably want to use or at least know about Dijkstra's Shunting Yard Algorithm: https://en.wikipedia.org/wiki/Shunting_yard_algorithm)

For the GUI / Form designers, well, any data-aware form-designing graphical toolkit could work, but of course, FoxPro has/had its own nuanced "flavor" of these.

Generically speaking, FoxPro is/was a database engine, SQL engine, very-data-aware scripting language and form/gui/app designer -- all rolled into one package.

I'd love to see an app where all of these components are open source, where there are clear interfaces between those components (separate compilation options for codebases, depending on which components you want), where the original FoxPro/dBase/xBase scripting language is used (because it was great!) and where any underlying database engine and/or SQL engine could be "swapped out" for any other (i.e., SQLite, Postgres, etc.)

Anyway, FoxDevStudio looks interesting in this space!

Related:

Quack: Scalable Remote Measurement of Application-Layer Censorship:

https://www.usenix.org/system/files/conference/usenixsecurit...

Global Measurement of DNS Manipulation:

https://www.usenix.org/system/files/conference/usenixsecurit...

Reachability index of Internet blockade circumvention tools:

https://explorer.ooni.org/circumvention

Psiphon:

https://forge.psiphon.ca/en/what-is-psiphon

I'd like a search engine that de-ranks any website where any of the following things are present:

1) There's a no-bot verification screen

2) There's a cookie acceptance popup

3) There's a paywall prior to the content.

4) There's a sign-in page prior to the content.

5) There's anything else, any other kinds of popups or re-routes or "you-can't-have-your-content-directly-after-your-click" that prevents a sub-ms response between clicking on a link and getting to the actual content.

I want a Search Engine like that.

Like the Internet of old.

De-rank any and all ensh-ttified websites from the search results at the user's request.

Give the user that option.

I want a Search Engine like that...

>"The evidence for each of these properties is already public. On raw speed, parallelism gives diffusion decoding headroom that serial generation cannot reach: Fast-dLLM, an NVIDIA-led study, showed that decoding many tokens per step delivers up to a 27.6× throughput improvement on open diffusion models with minimal accuracy loss - from training-free acceleration alone.

Bidirectional context also closes a significant capability gap. Autoregressive models suffer from the reversal curse: trained that "A is B", they fail to infer "B is A" - GPT-4 answers 79% of forward questions about celebrity relationships but only 33% of the reversed ones. LLaDA, an 8B diffusion model that attends to the whole sequence at every step, breaks the pattern, surpassing GPT-4o on reversal reasoning."

This is an interesting aspect of Autoregressive Vs. Diffusion models, that is, "can they get reversed reasoning correct?"

One aspect of this, of course, is the philosophical one... that is, if a cup is half empty, it is also (equal-and-oppositely!) half-full!

If a fact, fact A is related to another fact, fact B in some way, then there equal-and-oppositely must exist a reverse relationship (sometimes called an inverse relationship, sometimes called a reciprocal relationship, sometimes called a complementary relationship -- there are many names for it!) between fact B and fact A, when reasoning starting with fact B as the starting point.

Future AI's, if they are to truly understand the physical universe (reason absolutely correctly about it, all of the time, a must for subjects like Math and Physics), must understand reverse relationships.

That's why the above quote, from the above article, is interesting...

That's also why AI models based on Diffusion -- may be worth studying, or studying more about, as the case may be!

Hmmm, this is interesting, because one might think of Software as a series of lower-level "laws", that is, specified in terms of the lines of the source code itself in whatever programming language it was written in, and (more recently, in the AI coding era) a set of higher-level, specified in human language "laws" that a coding assistant AI must also take into consideration (in addition to the code itself) when working on the code.

Because it is never 100% guaranteed that an AI produces the right answer or the right set of changes, the need for an intermediary level of "laws" between the low level and the high level arises, and that is the domain occupied by mathematical and programmatic Proof Checkers, aka "Proof Assistants" aka "Theorem Provers" (Lean, Rocq, Agda, Idris, Metamath, F*, etc., etc.) and the corresponding software harnesses that drive them...

Bend is one example of what's emerging in this space.

As one of the contenders in this emergent space, Bend looks like it should be worth following...

Related:

https://huggingface.co/ISTA-DASLab

https://github.com/IST-DASLab

https://ist.ac.at/en/research/alistarh-group/

>"They fabricate their superconducting transistors on a 6-inch (150-mm) silicon wafer. Their CMOS-compatible process involves laying a graphene channel upon the wafer and shaping three electrodes from an aluminum-based superconductor. Two of these electrodes touch the graphene channel to create an aluminum-and-graphene Josephson junction. Then, controlling the voltage through the third electrode—the gate—can change the critical current or switch the superconductivity on or off.

Graphene isn’t normally a superconductor, but with the right conditions, the electrodes can “leak” their superconductivity into the graphene.

The researchers spent years fine-tuning their process to achieve those conditions. Their device’s geometry, materials, and engineering had to be just right."

Isn't that interesting! Graphene, or at least a very small 150nm-scale "nano surface" of Graphene becoming a superconductor under the right conditions! It'll be interesting to see where that goes in the future...

>"These two models are basically the two extremes of the spectrum; where ARM is the most relaxed, allowing significant hardware optimizations; and x86 is the most strict, enforcing a very strong coherency model that doesn’t allow a lot of room for optimization. [...] The best way to explain how the differences in memory models work is to start with how x86 handles this. With TSO being very strict in how it operates, the programmer can assume that when a memory store occurs, that this will be coherently visible to all other processors in the system. The weak memory model that ARM has is a bit less intuitive about how it operates. By default the regular memory loads and stores that ARM uses aren’t strictly coherent across processors in your system, allowing the CPU to operate more efficiently most of the time. When a store instruction executes, that piece of memory (the cacheline) isn’t immediately visible to other processors in the system. Saving on precious power and efficiency because it’s expensive in hardware to invalidate other core’s cachelines, or allow them to snoop another processor’s caches."

First of all great article! It's an absolute must-read for anyone who would design a CPU, GPU, NPU, xPU, Compiler, or Operating System.

It's an absolute must-read for any low-level Programmer.

We can almost think of these different ways of doing things (x86 vs. ARM) as a "battle of virtues" -- on the one hand, with x86, the low-level programmer gets guaranteed memory read consistency across all cores when any one core executes any single instruction which writes something to memory.

Virtuous! But, at the expense of constantly running a whole lot of extra circuits per instruction which use power and generate heat. It's necessary, damn necessary, for some instructions though!

But it isn't necessary for all instructions that write to memory, because whether it's necessary or not is determined by a lot of factors -- the program it's in, is the memory address used for shared communication or a shared data dependency between cores, etc., etc.

So, on the flip side, ARM uses what is called a "relaxed" model.

The low-level programmer gives up the x86 memory-consistent-across-all-cores-guarantee for every memory write, and now has the responsibility to issue additional instructions to get other cores to see that updated memory.

On the one hand, you've got more hardware complexity to make software simpler, on the other, you've got more software complexity to make hardware simpler.

Which is the "right" solution? Well I don't know. Both have their plusses and minuses from either side of the equation, hardware designer or low-level software designer. Still, it is a great issue to be aware of, and even though some posters had some good-faith and possibly very valid critiques of the article, I liked it! It's an important issue to be aware of, for hardware and software designers alike.

>"Features of matrix multipliers differ across vendors and architectures of the same vendor [...] As a result, reproducibility of small matrix multiplier results [differences] across devices is not possible and cannot be achieved by software control. Implementation details of matrix multipliers are not documented, making it difficult to interpret discrepancies in the computed results."

I'm guessing (but not knowing) that small subtle differences in matrix multiply across different vendor's architectures (and product generations of an individual vendor's architecture) is responsible for a good portion of software crashes when trying to run a local LLM on a different architecture or with a different stack (ROCm vs. CUDA, for example) than the ones it has been explicitly tested on.

As such, this marks a rather significant problem for the future, which can basically be stated as:

There needs to be a standard matrix multiply specification (much like IEEE-754 is/was for floating point operations) that all future vendors of AI accelerators (any GPU, CPU, NPU or IC manufacturer whose circuits implement matmul) adhere to, such that the matmul of one vendor is exactly and precisely compatible with the matmul of another.

Hardware vendors of course, are free to compete in terms of speed, power efficiency, number of matmul engines on a given piece of silicon, parallelization optimizations, etc., but the basic matmul operation should be exactly and precisely compatible across vendors and across future product versions.

Step 1: We need a spec for this... (Maybe IEEE is already working on one? If so, that's a good step forward!)

Step 2: Hardware vendors need to implement it, to be universally compatible in all of their IC's that use matmul, in the future...

This has to be one of the most clever old/vintage computer things I've seen for awhile...

Basically, instead of a rigid hardware bus (fixed metal traces on a PCB motherboard), it uses a soft, flexible multi-pin cable with multiple connectors -- as its bus!

Brilliant!

Yes, these would be frequency-limited because they couldn't be designed with the same precision as the buses on the circuit boards today, but for older computers running in the lower Mhz regime, this would not have been a problem.

And yes, you could argue that the S-100 bus had cable versions of it, and SCSI was a bus extension, and both of these would be valid arguments, but I've never thought of using a soft multi-pin cable as an actual low-Mhz early computer bus -- until watching this video.

Anyway, great video!

>"To reduce switching stresses, losses, and electromagnetic interference (EMI), soft-switching techniques have been developed for power converters since the 1970s [1]. There are many topologies of soft-switching inverters [1]–[10], such as resonant dc link, resonant snubber, and zero-current transition inverters [8]. Soft-switching inverters can be grouped into two main categories: resonant dc link and resonant snubber. The resonant dc link provides zero dc-link voltage or current intervals to all phase legs during switching instants, whereas the resonant snubber diverts current from and/or provides zerovoltage intervals to each main device at switching instants. The active clamped resonant dc link converter [1] and the auxiliary quasiresonant dc link converter [2], [10] are examples of resonant dc link inverters. Auxiliary resonant snubber inverters such as the auxiliary resonant commutated pole (ARCP), zerovoltage transition, and resonant snubber inverters [9] belong to the second resonant snubber category."

What it is: A "snubber" (terrible terminology btw, IMHO, but we'll go with it for now!) basically adds a resonant circuit part to a previously non-resonant switch or switched circuit, such as those common in switched power supplies and inverters.

Basically, the "switch-on, switch-off, repeat" circuits that drive electrical transformers of all sorts.

Well, take that, add a resonant circuit component to it (which basically "smooths" the immediate presence of a voltage during the on phase and the immediate drop of a voltage to 0 during the off phase) and that's what "snubber" is.

I should point out that There are power snubbers that do the same thing but for current, i.e., snubbers of one type for voltage, snubbers of another for current, but the basic idea is the same -- smooth things out, smooth the waveform out -- don't allow immediate (instantaneous) dips or spikes, smooth it out over milliseconds, microseconds, nanoseconds, whatever the frequency of the waveform requires...

Anyway, that's a "snubber" (an added resonant circuit component).

Added to power supplies and inverters and transformers of all sorts, once resonance is established, heat/heating/heat losses drop, and power conversion efficiency increases rather significantly.

Switch/switching circuit life is also extended.

Anyway, it's a fascinating topic!

Second Addendum:

Böhm Trees:

https://en.wikipedia.org/wiki/B%C3%B6hm_tree

Seem like they might be related to this discussion in some way...

>"So that only left socialist countries to source coffee from, but the Soviet Union had decided to stop its coffee exports to the GDR in 1954. So the GDR regime had to buy it wherever it could and whatever the cost, spending around 150 million West German marks a year to do so. They also relied on West Germans sending their eastern pals and relatives coffee, which covered around a fifth of demand. For a long time that worked sort of okay.

Coffee wasn’t always easy to get hold of. You might have to visit several shops or draw on some connections to get hold of some, but it was still proper coffee and by and large available. Then the coffee crisis of 1977 hit the world."

Compare (cf.) and contrast with the U.S. of 2026 -- there's like what, 7 competing coffee shops on every block of the downtown of every major city, and in Seattle that number is at least doubled, to at least 14... in other words, we have no shortage of coffee in the U.S., quite the opposite!

(Possibly we have too much coffee, if such a thing is possible, and apparently, it is! :-))

>"XLS enables the rapid development of hardware IP that also runs as efficient host software via "software style" methodology. An XLS design runs at native speeds for use in host software or a simulator, but that design can also generate hardware block output -- the XLS tools' correctness ensures (and provides tools to help formally verify) that they are functionally identical."

The ability to run and verify hardware designs quickly in software simulators is the key to rapid iteration of hardware designs, which is the key to more robust hardware, faster.

For that reason, XLS should be worth watching in this space...

Observation: A panel of Judges (multiple Judges), whether it's multiple AI's or not, is fundamentally -- a Jury!

>Holy cow, a 386 with VGA and SoundBlaster on a $1 MCU?

The right software -- really does add value(!) to (let's-just-say-it-isn't-an-nVidia-GB300!) hardware, now doesn't it? :-)

I don't know about anyone else -- but I'm sold!

The value proposition on this one is truly awesome!