HNHacker News
TopNewBestAskShowJobs

peter_d_sherman

18,822 karma · joined September 16, 2014

Programmer, Student Of Law, Entrepreneur & Comedy Writer.

Open Source, Open Hardware, Transparency & Free Speech enthusiast.

peter.d.sherman@gmail.com www.linkedin.com/in/peter-sherman-a6107a5 https://x.com/peter_d_sherman

"The true knowledge consists of knowing that one knows nothing..."

- Socrates

submissionscomments
peter_d_sherman··on Digital Sovereignty: What It Is, What It Could Be
Related:

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

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

peter_d_sherman··on Homotopy Type Theory – Univalent Foundations of Mathematics (2013)
I asked Gemini AI what the current state of research was for attempts at unifying all of the operators in Mathematics into a single unified operator...

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/

peter_d_sherman··on How AI Is Changing Audio Restoration in 2026
>"Understanding Spectral Recovery

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.)

peter_d_sherman··on Blue-X – Exploring wavelength reduction (2–7 nm range) beyond EUV
>"The presentation outlined Blue-X as an industry-wide initiative exploring wavelength reduction (2–7 nm range) as a complementary path to extending Moore’s Law beyond High-NA EUV.

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."

peter_d_sherman··on RISC-V Emulator and Linux System from Scratch
>"Source Code

/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!)

peter_d_sherman··on ESP32 Bit Pirate Hardware Hacking Kit with Web Tools That Speaks Every Protocol
Looks like a tremendously useful tool to do such things as BIOS reflashing (i.e., Coreboot, Libreboot, Canoeboot) on one's own hardware.

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!

peter_d_sherman··on DeepSeek v4.1 Flash
>"Smaller KV cache. Bigger savings.

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...

peter_d_sherman··on Looped Transformers as Programmable Computers (2023)
>"We present a framework for using transformer networks as universal computers by programming them with specific weights and placing them in a loop. Our input sequence acts as a punchcard, consisting of instructions and memory for data read/writes. We demonstrate that a constant number of encoder layers can emulate basic computing blocks, including embedding edit operations, non-linear functions, function calls, program counters, and conditional branches.

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!

peter_d_sherman··on On the Navier–Stokes Millennium Prize Problem
>"The solution is a vortex, a spinning swirl of fluid, that spirals inward and gets increasingly elongated, like spaghetti. This central region shrinks while it speeds up in such a way that its energy still stays finite, as required by the laws of physics. The technical challenge is for the equations to develop the breakdown through the motion of the fluid itself, rather than, for example, us putting in an infinite force by hand. More mathematically, the terms in the Navier–Stokes equations that describe the motion—acceleration, pressure gradients, momentum transfer, viscosity—must both become big yet cancel in a precise way. This detailed balance leaves a smooth external force even as the velocity of the fluid grows without bound.

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

peter_d_sherman··on Bob Widlar – Distinguished Engineer, Integrated Circuits Pioneer
>"Widlar invented the basic building blocks of linear ICs including the Widlar current source, the Widlar bandgap voltage reference[9] and the Widlar output stage.[10] From 1964 to 1970, Widlar, together with David Talbert, created the first mass-produced operational amplifier ICs (μA702, μA709), some of the earliest integrated voltage regulator ICs (LM100 and LM105), the first operational amplifiers employing single capacitor frequency compensation (LM101), an improved LM101 with FET internal current control (LM101A), and super-beta transistors (LM108).[11] Each of Widlar's circuits had "at least one feature which was far ahead of the crowd"[5] and became a "product champion" in its class.[12] They made his employers, Fairchild Semiconductor and National Semiconductor, the leaders in linear integrated circuits.[13][14]

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...

peter_d_sherman··on I Rewrote My Back End in Go in 72 Hours and Cut My AWS Bill by 94%
>"Why Go saved my a*

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...

peter_d_sherman··on Reverse Engineering an ASIC
Absolutely brilliant! (And a well designed web page for teaching purposes! Anyone studying low-level IC design should have a look at this page!) I especially like:

>"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!

peter_d_sherman··on Halide – a language for fast, portable computation on images and tensors
https://queue.acm.org/doi/10.1145/3212477.3212479

>"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!

peter_d_sherman··on Impedance Matching (2017)
>"Some of the most interesting impedance matching occurs when energy comes in the form of a wave. You have probably noticed in a swimming pool that waves from a splash reflect off the sides of the wall. Because there is an impedance mismatch between the water and the wall, the wave energy is unable to couple into the wall, and so it reflects back."

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!

peter_d_sherman··on Samsung Debuts zHBM Prototype, Stacking Memory Directly on AI Accelerators
>"According to the company [Samsung],

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."

peter_d_sherman··on MathKernel: An evidence-aware multi-engine mathematics kernel and MCP server
Consider the problem the above GitHub repository attempts to address:

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...

peter_d_sherman··on Making a Python interpreter in 1024 bytes
The condensed version is impressive to be sure, but I'm an even bigger fan of the readable version:

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

Well done!

peter_d_sherman··on Understanding Computer Memory Architecture and SSD Internals
One of the best articles on Computer Memory that I have ever read!

(Worth re-reading in the future!)

peter_d_sherman··on LLMs as a Cognitive Virus
Historically, Human Language was the first non-biological virus...

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! :-) )

peter_d_sherman··on Meet the Ig Nobel Prize Winners
>"But this year’s winning team didn’t go the robot route; instead, they adapted a female mosquito proboscis to work as a nozzle in a super-precise 3D printer. [...] The team called the device a “3D necroprinter.” The necroprinter achieved a resolution ranging from 18 to 22 microns, which was two times smaller than the printers using the smallest commercially available metal dispensing tips."

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!)

peter_d_sherman··on An open DNS recursive service for free security and high privacy
>"Quad9 blocks lookups of malicious host names from an up-to-the-minute list of threats. This blocking action protects your computer, mobile device, or IoT systems against a wide range of threats such as malware, phishing, spyware, and botnets, and it can improve performance in addition to guaranteeing privacy."

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!

peter_d_sherman··on Can AI design circuit boards yet?
>"We are obviously still some distance from asking an AI to build an entire phone in one prompt."

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...)

peter_d_sherman··on 15h.org – Open-Source Firmware and Support for AMD's Family 15h CPU's/MB's, etc.
>"Released between 2011 and 2014, AMD's fam15h (and its approximately-contemporaneous relatives, fam10h, fam14h and fam16h) are the final high-performance x86_64 microprocessors lacking most of the limitations newer x86 platforms are encumbered by. In many cases, fam15h hardware can provide a performant, full-featured system, using entirely free and open source software. It enforces no firmware signing (allowing things such as coreboot), can be booted entirely with free firmware (including memory initialization), and it requires no privileged management coprocessor (such as the Platform Security Processor or Management Engine, found on newer AMD and Intel platforms respectively). Where a Board Management Controller is present, it can usually reliably be disabled, or better yet, flashed with OpenBMC [or u-bmc!]. On fam10h,

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)

peter_d_sherman··on Discovery of a new OpenAI agent message board
Fundamentally, "collusion" and "collaboration" (note the 'coll' language root prefix for both words also found in such words as "College" and "colleague") describe the same underlying activity, that of "working with others", "teaming up", "teamwork", "working together as a group" (related: U.S. Constitution's 1st Amendment's "right of the people peaceably to assemble", Freedom of Association, etc., etc.) but while the word "collaboration" is neutral or has positive associations (depending on context), the word "collusion" has corresponding negative or implied malevolent ones...

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!

peter_d_sherman··on Linode's $12 VPS Didn't Outperform Its $5 Plan in Six Fresh Deployments
Popular VPS providers (AWS, Azure, Contabo, DigitalOcean, Exoscale, Google Cloud, Hetzner, Ionos, Linode, OCI, ScaleWay, TenCent, Vultr, etc.) comparison:

https://webbynode.com/providers

peter_d_sherman··on The paradox of diffusion distillation (2024)
>"the main effect of introducing stochasticity is error correction: diffusion model predictions are approximate, and noise helps to prevent these approximation errors from accumulating across many sampling steps. In the context of optimisation, the regularising effect of noise in stochastic gradient descent (SGD) is well-studied..."

[...]

Variance reduction alone does not explain why distillation of diffusion models is so popular, however. Distillation is also a very effective way to reduce the number of sampling steps required."

What a great article!

peter_d_sherman··on B200 Attention Kernel from Scratch to Near-SOTA in 60 Diagrams
One of the best AI GPU Attention Kernel how-to-implement articles I've read in a long time!

Tremendous work, tremendous effort was placed into writing this article -- and it shows!

Well done!

peter_d_sherman··on GPU World
>"Someday, such as in 2040, there may be available, for every human being, the performance equivalent of 'a B300 GPU for contemporary LLMs'.

What would this world be like?

What will our world be like when (not if) every human being has access to the equivalent of a Fable or Sol LLM 24/7/365? Will this lead to a panopticon of indefatigable AI surveillance? Will education be revolutionized by infinitely patient tutors? Will social media cease to exist as we know it? Will healthcare be revolutionized by world class AI doctors and personalized medicines? What will happen in the oft-ignored developing world?"

What great questions!

These would be great questions to pose to a Creative Writing class, any Creative Writing class!

Or heck, any Creative Writing class, Philosophy class, or Futurist!

You know, there should be a web page, a time-capsule web page if you will, where people of 2026 ask questions about what specific future years will look like in terms of health, climate, politics, religion, currency, geopolitics, social media, news, education, etc., etc., and then all of these questions could be aggregated statistically into the most asked ones, and that could be preserved going forward in time...

That's from a looking-forward-into-the-future perspective...

We could, from a looking-backwards-into-the-past perspective, try to discover what people, in say 1900, thought about the future; what their specific concerns were, what their specific questions were... perhaps some historian or historians or books or (copied to) web pages out there contains some of this information somewhere...

Which might be interesting to look at for comparison purposes...

You know, "for good or for evil, in the superlative degree of comparison only...", to quote Charles Dickens' 1859 book, "A Tale Of Two Cities"... :-)

peter_d_sherman··on AMD unveils next-generation RDNA and PlayStation tech with Sony (2025)
Universal Compression (for GPU's / AI Accelerators):

>"Alongside Sony, AMD has developed “Universal Compression”, which should help compress data within a GPU to deliver higher levels of memory efficiency. This reduces memory usage and memory bandwidth usage. This frees up memory bandwidth for other tasks. Furthermore, it effectively gives next-generation hardware more memory space to work with.

Note that Mark Cerny states that this compression technology will have “synergies” with AMD’s Neural Arrays and Radiance Cores. After all, smaller, more compressed/optimised data will fit better onto caches and optimise workflow.

Universal Compression – a system that evaluates every piece of data headed to memory, not just textures, and compresses it wherever possible. Only the essential bytes are sent, dramatically reducing memory bandwidth usage. This means the GPU can deliver more detail, higher frame rates, and greater efficiency. "

Great Idea!

By putting discrete, automatic Hardware Compression abilities into GPU's, it should be possible to compress regions of a GPU's memory, which should result in freed memory, which should result in an upgrade of capabilities at a given level of memory...

Observation: It will be interesting to see if automatic, general, hardware-based (which should be very fast!) compression on future GPU's (and potentially AI accelerators) can yield memory space savings when loading LLM's into memory while being performance compatible with older GPU's that do not do this.

If so, then we may have unlocked or "leveled up" our future Graphics Cards / AI Accelerators yet again...

Sort of like what DSpark did as a software optimization for LLM's, hardware-based GPU compression of graphics card / AI accelerator data could be a major win, and a major step forward, enabling future GPU/AI cards to have greater capabilities at the same base memory level IF the compression works for a given LLM's data!

Crossing my fingers that Universal Compression for future GPU's will work with LLM's!

A promising idea, to be sure!

peter_d_sherman··on OpenShot 4.0 – Open-source video editor
Looks good!

I decided to have a quick, cursory, "first-glance" look at OpenShot's software architecture...

It apparently (and again, someone correct me if I am wrong here) uses FFmpeg (https://www.ffmpeg.org/ https://git.ffmpeg.org/ffmpeg.git https://github.com/FFmpeg/FFmpeg), more specifically the FFmpeg libraries (libavutil, libavcodec, libavformat, libavdevice, libavfilter, libswscale, libswresample).

Nothing wrong with that, countless video and video-related programs, most notably VLC -- use FFmpeg as their base software layer.

LibAv (https://github.com/libav/libav), a fork of FFmpeg, can also apparently be "swapped in" as the base layer, replacing FFmpeg if so desired.

FFmpeg/LibAv are written in C, primarily adhering to the C99 standard.

From there, building on top of that, we have libopenshot (https://github.com/OpenShot/libopenshot) which is a C++ "middle level" library generating/abstracting a higher-level API for video editing specifically, and containing bindings to C++, but perhaps more notably, additionally to Python and Ruby...

Then on top of that, we finally have OpenShot (more specifically 'openshot-qt': https://github.com/OpenShot/openshot-qt) which is written entirely in Python 3.x, which uses PyQt (which bind to Qt libraries which give the software its platform independence!).

And of course, there are some other libraries and repos for other things here: https://github.com/OpenShot, for example, libopenshot-audio for audio, etc.

Opinion: Let me start off by saying that I am NOT a Python guy! I'd rather program in Delphi/ObjectPascal, C, C++, x86 Assembler, Java, Lisp, Scheme, Racket, Clojure, Haskell, R, Odin, Zig, or, if someone put a gun to my head, JavaScript (without Typescript!) or Rust! (too large a compiler, too many imported dependencies in many libraries/crates -- the language itself I have nothing against!)

But, that being said (also, I'll say I've seen some truly great programs written in Rust, before the community tars and feathers me!), I have seen just how powerful a teaching tool for programming tool Python is!

This is not a simple Python "Hello World" program!

This program is powerful, quite powerful indeed!

It showcases what Python can do by coordinating and managing lower-level functionalities!

It's also an excellent program from the perspective of garnering GitHub community support (think about it, the barrier to "chip in" and offer help/assistance/bug fixes/functionality improvements is lower, way lower on a Python program than it is on say, a C++ program using all of the latest C++23 language features or on a LISP-derived language using many deep asymmetric recursive meta constructs...)

It's also a great example of a Python cross-platform program!

And I really like the way that the software is delivered in discrete layers, i.e., the C++ middle layer has its own dedicated GitHub repo (as opposed to being co-mingled with the Python higher level one), etc.

So, great job!

This is truly a Python exemplar program!

Some really good Software Engineering practices in this one!

← PreviousPage 3 of 34Next →