Some Thoughts On Quantum Computing

Some remarks by a speaker at a recent professional event inspired me to rant a bit on the topic of quantum computing. For sure, it's not my area of expertise, but I do have a dilettante interest in quantum physics, plus I took a short course at University of Denver a few months ago that was a kind of "Quantum Computing for Dummies", and it is the area of expertise by the Ph.D. physicist who taught it.

[1] Quantum computers will not replace conventional computers. There is a lot of interest in QCs because it is believed that they can do calculations that are not feasible for today's computers. But those calculations are only possible for problems for which there are known - or believed - to be QC-type algorithms. You will never be running a web browser or a spreadsheet on a QC.

[2] One example is Peter Shor's quantum algorithm for large number factorization, which could be used to break encryption schemes that rely on the difficulty of such factorization. Shor is a theoretical computer scientist who developed Shor's Algorithm while at Bell Labs. This is why governments are interested/concerned about QC. A lot of encrypted secrets have been stolen by hackers (theirs and ours), but are just useless bits until they can be decrypted.

[3] Not all encryption is based on large number factorization. Maybe there are as yet undiscovered QC algorithms for the "trap door functions" that those schemes use instead of large number multiplication and factorization. Maybe not. Until then - if ever - such schemes are described as quantum resistant. Switching to such schemes is probably a good idea for sensitive data, just in case QCs eventually work.

[4] QC may never work. Although scaling up quantum computers is talked about as if it were an engineering issue, the people trying to do it are - in my opinion, and whether they realize it or not - trying to solve what physicists call the measurement problem. What constitutes a "measurement" in a quantum system - an action that causes the wave function describing a superposition of states to collapse or decohere into one state - is unknown. QCs work by causing the superposition created by the quantum algorithm to collapse into a state representing the answer, possibly solving a problem what would take a conventional computer years, or centuries, or ... Engineers working on QCs are trying to prevent a measurement - whatever that is - from occurring and the system decohering until they want it to. Defining what constitutes a quantum measurement is Nobel Prize territory, a problem that reaches into the very definition of reality in the transition from the realm of the very small to the realm we perceive. It is a problem that may never be solved, despite what investors are told.

I hope quantum computers do come to fruition. Not just for the practical reasons of solving some very difficult optimization problems and such, but because of the light it would shed on the measurement problem in physics. But I remain cautiously pessimistic.

The Negative Feedback Loop of AI Summaries

I've already ranted about how using Large Language Models (LLMs) - what passes for "AI" these days - to replace entry level employees will disrupt the very talent pipeline used to create the experienced senior employees used to generate and curate the enormous (terabytes to petabytes) quantities of data used to train the LLMs in the first place. LLMs are merely gigantic "autocomplete" programs making statistical guesses based on their training data. That's why I say this effort isn't sustainable.

But there's another negative feedback loop in the use of LLMs that I just became aware of. Various web and social media tools are starting to provide "AI summaries" in response to user queries. You've probably already experienced these, and have seen that these LLM generated summaries range from usably good or laughably bad.

Here's the problem: studies have shown that between 80% to 90% of humans making queries for which there are AI summaries never go past the summary. They never click on the web links leading to the data on which the summary is based (if such links are even made available). This is in stark contract to conventional web searches, in which the web links are the result of the search, and the user almost inevitably clicks on the link to get the answer for which they were searching.

Because the user never visits the source web page, they never see the advertising used to pay for the generation of the web page. The web site is visited perhaps once and only once, by the LLM web crawler, and never by a human being. This destroys the business model used to pay for the web site in the first place. So the use of AI summaries will eventually result in the loss of the very data used to create the summary.

The only solution I see to this is to paywall all of the news and data sources being used by the AI summary algorithms. Lawsuits are already in progress against the AI companies extracting copyrighted data from advertising supported web sites. Clearly copyrighting the web site alone isn't sufficient to keep their value from being extracted without payment.

Sources

Edd Gent, "AI coding is now everywhere. But not everyone is convinced.", MIT Technology Review, 2025-12-15, https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/

Sabine Hossenfelder, "AI Is Breaking The Internet As We Know It", Backreaction, 2025-12-14, http://backreaction.blogspot.com/2025/12/ai-is-breaking-internet-as-we-know-it.html

Real-Time versus Real Time

Interesting article from IEEE Spectrum: "How AI’s Sense of Time Will Differ From Ours" [Popovski, 2026-08-13].

Human cognition integrates events from different senses - especially seeing and hearing - using a temporal window of integration (TWI). Among other things, it's the ability that lets us see continuous motion with synchronized sound in old school films at 24 frames per second. But under the hood, everything is asynchronous with different sensing and processing latencies. Which is why we don't automatically integrate seeing distant lightning strikes with the thunderclap, even though intellectually we may know they're the same event.

Machines have to deal with this as well, especially AI in applications like self-driving vehicles. It's non-trivial. "Computers put timestamps, nature does not" as the author remarks. Anyone that develops real-time software - or has spent time analyzing log files - has already had to think about this. I talked about this issue in a prior blog article: "Frames of Reference".

I've also pointed out in a prior article, "Frames of Reference III", that our human sense of simultaneity continuously gives us a false view of reality. If I look towards the back of my kitchen, I see the breakfast table and chairs a few feet away. Since light travels about a foot per nanosecond, I'm actually seeing events that occurred a few nanoseconds ago (plus the communication and processing latency inside me). The back yard that I can see through the window: a few tens of nanoseconds ago. The house across the street: a hundred nanoseconds ago. The mountains to the west: microseconds ago. If I can see the moon on a clear evening: over a second ago. I see all of these things as existing in the same instant of time, but nothing could be further from the truth; my perception is at best an ensemble of many instants in the past, and the present is just an illusion.

AI perception of the real-world will have similar complications.

What do we mean when we say we don't know how Large Language Models work?

Large Language Models - what passes for "AI" these days (there are other kinds, but this is what most people today mean when they use the term) - are in effect gigantic autocomplete algorithms, implemented using a technique called "machine learning", which is based on artificial neural networks (from how we currently believe the brain works), scaled up to use trillions of parameters, computed from terabytes of training data, much of which is copyrighted and used without the creators' permission. An LLM produces the output that its algorithm deems the most likely to be a response to your input prompt, based on its model of that training data. If that output represents actual truth or facts, it's only because the training data made that seem probable.

LLMs "hallucinating" isn't a bug; it's fundamental to how they operate.

I've read several articles on LLMs whose basic theme is "no one knows how LLMs work". This is true, but probably not in the way that most people think. The LLM developers that work for the AI companies know exactly how the software algorithms work - it's not only just code, it's code that they for the most part wrote. It's the trillions of parameters, derived algorithmically from the terabytes of training data, the is the big mystery.

Imagine a vast warehouse, on the scale of the scenes at the end of Citizen Kane or Raiders of the Lost Ark. That warehouse is full of file cabinets. Each file cabinet is full of paper files about every person that has ever lived in the United States, for as long as the U.S. Government has been keeping records. Your job: tally the number of people in those files whose first name ends in "e", who had a sibling whose first name ends in "r".

You understand the job. The task is straightforward. The algorithm you could use to accomplish this is obvious. But could you do it? No. The dataset is too ginormous. You literally won't live long enough to get it done, even if you could maintain your interest.

But if all that information were to be digitized, stored in a huge database, the database indexed to link records of family members together, and a program written to answer the original question, a computer could come up with the answer after a few minutes. These kinds of mundane repetitive tasks are what computers excel at.

(This isn't the perfect metaphor but it's the best I've got at the moment.)

LLMs are more complicated than that, and more probabilistic, but it's the same idea. We understand how the code part of the task works. But it's the data, the artificial neural network and its implications, we don't understand. We can't understand. Not just the training data - which is far too much for us to read and digest - but the interconnections between the trillions of parameters that are formed and the statistical weights that are computed as the training data are processed.

If someone asks "How did the AI come up with that response?", that's the part we have to say "We don't know." The artificial neural network is just too big, and stepping through it manually, tracing every single step the algorithm made, while technically not impossible, is just too tedious and time consuming. And relating the parameters and weights of the neural net back to the original training data would be like trying to unscramble an egg.

Knowing how the code works will get more complicated as we use LLMs themselves to revise or rewrite the code. This isn't a crazy idea, and if it's not happening now, it will happen, perhaps soon. And then the code, the part we thought we knew how it worked, will evolve such that we no longer know how it works.

Admittedly, artificial neural network based machine learning models aren't my area of expertise. But I'm not completely ignorant about how they work. I think there are myriads of applications for them. For example, I think we'll use them to discover new drug pathways, just waiting to be found in existing voluminous clinical datasets (although any such results will have to be carefully experimentally verified by human researchers). But I'm becoming increasingly skeptical about the more grandiose claims made for them - sometimes by people who should know better.

Update (2026-02-26)

AI researchers have started instrumenting LLMs to see how they arrive at their conclusions. They do this by adding a kind of tracing to the algorithm, "chain of thought reasoning". The results are surprising. Turns out the answer an LLM gives to a question may depend a lot on exactly how the question is asked. For example, "What color are bananas?" and "Are bananas yellow?" may yield very different results depending on the original training data. This tracing mechanism is too expensive, in terms of time and memory, to always use, so it is only implemented on limited research versions of the model.

Another technique is to examine the context that the LLM maintains as it is working through a problem. Apparently however this context, which comes "free" as part of the model's normal operation, turns out to be relatively obscure and hard for humans parse and understand.

I've been toying with LLMs using my own paid subscriptions to OpenAI (ChatGPT) and Anthropic (Claude). I have yet to have much luck making any productive use of them for the kinds of things I need to do. That doesn't mean they aren't useful.

I continue to see LLMs as a kind of clever parlor trick with some real world applications, but I think most business use cases for them have negative feedback loops that will ultimately destroy the sources of the models' training data. AI generated summaries means you don't see the advertising that pays for the creation of the data they are summarizing. AI replacing entry level employees wipes out the talent pipeline that creates the senior level employees that created the training data for the AI. And AI-generated training data frequently leads to "model collapse" - where the LLM's results depart from reality - because errors in the training data are reinforced.

Finally, having worked for years in the defense and intelligence sector, I remain concerned about the applications of LLMs in this realm.

Events 2

I read a transcript of a science explainer by Dr. Sabine Hossenfelder about physicist David Deutsch's "Constructor Theory", which I had not heard of before, and how it accounts for time.

It sounds like just the 180º opposite of what I've been talking about: creating a model of physics that seems more like the kind of real-time systems I work on as a basis for reality. The shortest time period (Planck Time?) is the recycle time of a kind of null task, a term right out of Real-Time Operating Systems. That's basically how I think of the world around me - based solely on decades of professional experience - but it seems weird to think of it as a legitimate Theory of Everything.

Down deep, real-time computer systems - with their asynchronous, concurrent, and parallel behavior - are a lot more non-deterministic than people might think. It's one of the reasons that it's hard to debug such systems - a bug might only reveal itself under certain timing or certain order of events. Determinism is a kind of emergent property created by engineers who are hiding the details under the hood from the user - kind of like Newtonian physics layered on top of relativity and quantum mechanics.

Once you become accustomed to architecting, implementing, and debugging such systems, it's easy - it was for me, anyway - to start seeing the entire world through the same lens. Maybe I should not be surprised that there's one candidate for a Theory of Everything that takes this viewpoint.

Events

 I've spend decades as a software/firmware developer of real-time systems, going all the way back to the 1970s when I was writing software in the assembler languages of the IBM 360/370 and the PDP-11. The term "real-time" always seemed kind of ironic, since it is easy, when closely scrutinizing such systems - with their asynchronous, concurrent, and parallel behavior - to come to the conclusion that time doesn't exist. Only ordered events. We don't have a way to measure time, except by counting events produced by some oscillator that ultimately derives its periodicity from nature. We call such devices a "clock", Since the only way to test the accuracy and precision of a clock is with a better clock, it's turtles all the way down.

Turing award winning computer scientist Leslie Lamport even wrote what came to be a classic paper on this topic, "Time, Clocks, and the Ordering of Events in a Distributed System" [CACM, 21.7, 1978-07]. He proposed a "logical clock" which was simply a counter that incremented every time it was read, allowing events to be placed in a clear order. I remember reading this paper as a graduate student. And again, later. And again, even later. I may read it again today.

Years ago I mentioned this line of thought to a colleague of mine, who happened to have a Ph.D. in physics and had worked at Fermi Lab. (It's handy to keep such folks around just for this reason.) He immediately brought up the now obvious to me fact that time must exist: Einstein's special and general relativity.

Einstein's theories of SR and GR have been experimentally verified time and again (no pun intended). You can synchronize two atomic clocks side by side, then take one up to the top of mountain (where it experiences less gravity due to being further from the center of the Earth, and hence time runs faster: that's GR) and back down, and find they they now differ by just the predicted amount. This experiment has been done many times.

The U.S. Global Positioning System (and indeed all other Global Navigation Satellite Systems) work by just transmitting the current time to receivers on the Earth. Fundamentally, that's it. All the heavy lifting, computationally, is done by the GPS receiver in your hand. But the atomic clocks inside every GPS satellite have to be carefully adjusted by controllers on the ground to account for GR (because the satellites in their orbits are further from the center of the Earth than you are, and so their clocks run faster), and for SR (because the satellites in their orbits are centripetally accelerated more than you are, and so their clocks run slower). GPS wouldn't give useful results if this correction weren't performed.

The resonant frequency of cesium-133 is the definition of the "second" in the International System (SI) of units. Count off exactly 9,192,631,770 pulses of the microwaves emitted by cesium-133 during the hyperfine transition of their electron in the element's outer electron shell, and that's one second. If cesium is lying to us, we'll never know.

Or maybe we would. Experimental atomic clocks using elements like ytterbium are running in national metrology labs. These are called "optical" atomic clocks because they operate at terahertz frequencies using lasers instead of microwaves at gigahertz frequencies, and their periods are measured in attoseconds instead of nanoseconds. The time is very near in which the definition of the SI second will be changed to use these clocks.

Clocks that are so precise that their position has to be determined by careful surveying because their results are different if the altitude of the laboratory optical bench changes by a centimeter, thanks to GR.

Clocks that are still nothing more than oscillators and counters.

(I took the photograph below in 2018: a survey marker embedded in the concrete floor of an optical atomic clock laboratory at NIST's Boulder Colorado facility.)

We Got The Beat

Time: it's a funny thing. We can't measure it directly. The best we can do is construct mechanisms that have some kind of periodic behavior and then count the "beats" (as watchmakers call it) that they produce. There have been all kinds of sources of periodicity used during human history. The heart beat for short periods of time. The movement of the Sun across the sky for the day. The phases of the Moon for periods of a "moonth". The seasons for the year. There were many attempts to make time keeping devices - candles with marks drawn on them, water clocks that counted drips, sundials, hourglasses. But none of these were accurate enough to measure longitude, the angular east-west distance across the Earth. (Latitude can be determined by the height of the Sun above the horizon, taking the season and the hemisphere into account. There are almanacs still published today with the numbers you need to do this.) Navigators going all the way back at least to the ancient Greeks and Polynesians had known that timekeeping could be used to determine longitude, by comparing local time (e.g. local noon, determined by the sun) with a clock set to the time at the port from which you departed. But it wasn't until the mid-to-late 1700s that there was a "chronometer" design accurate, precise, stable, and reliable enough to carry on board ship that navigators were able to use it to determine their longitude. All "modern" clocks, from those initial chronometers until today, consist of an oscillator - a source of stable precise beats - and a counter - the watch face. And all oscillators are made of three basic components: a resonator (a source of periodicity derived from nature), a power source (a falling weight, a spring, a battery, the mains), and a feedback loop (known as an "escapement" in a mechanical clock). Many things have been used as resonators over the centuries (and all of these are still used today): a pendulum, a balance wheel, a quartz crystal, an atom of cesium, rubidium, aluminum, ytterbium. But no matter how sophisticated clocks become, they still have the three components that can be classified as a resonator, a power source, and a feedback loop. The clock below - on display at NIST in Boulder Colorado and whose photograph I took in 2018 - was sold by IBM in 1956. It is an electric pendulum "Type 37" clock that set itself from the NIST WWV/WWVH telegraphic time code using a vacuum tube radio receiver. It was typically used in factories as the master clock from which all other clocks were set.

NIST Time and Frequency Seminar 2025

Once again I attended the fire hose of information that is the U.S. National Institute of Standards and Technology (NIST) Time and Frequency Seminar. This three day, typically annual, event, held at their Boulder Colorado laboratories (commuting distance for me), covered such wide ranging topics as optical atomic clocks, practical measurement techniques for time and frequency, how to characterize and analyze frequency and phase errors in data, ways in which television and radio broadcasters might augment GPS for timing and positioning, and much more.

In honor of the event I wore my Rolex Milgauss. Felt cute, might delete later.

* * *

My understanding is that virtually all national time and frequency metrology laboratories, including NIST (civilian) and the USNO (military) in the U.S., use an ensemble of cesium beam atomic clocks and hydrogen maser atomic clocks, the average of which is used to determine their contribution to the measurement of the SI second and the international definition of UTC. These are commercial devices, not laboratory experiments, and aren't astronomically expensive.

They use a combination of both because, even though the cesium resonant frequency is the (current) definition of the second in the international system of units, cesium atomic clocks suffer from jitter (short term variation), while hydrogen masers are more stable. The jitter in commercial atomic clocks is well understood, and the difference between a rack-mounted commercial cesium beam clock and a much larger and far far more expensive cesium fountain atomic clock in labs at places like NIST is all the extra hardware to try to reduce that jitter.

The image below is of the NIST F-3 cesium fountain clock. The collection of commercial cesium beam standards are kept locked up in another room.

Here's the thing: all hydrogen maser clocks suffer from drift (long term variation). And they all drift by a different amount. And it is not understood why. One hypothesis is it's some mechanism of aging of the components. If the manufacturers could eliminate this, they certainly would (and charge more).

The image below is of a decommissioned commercial hydrogen maser clock that I saw at NIST in 2018. You can't typically find one of these at NIST where it can be photographed because the running ones are kept locked in temperature controlled chambers adapted from commercial egg incubators.

* * *

The blinking 1Hz LEDs in this brief video clip literally represent the real-time manufacture of the UTC(NIST) time scale (the U.S. civilian time base) and the U.S. contribution to the international determination of UTC.

* * *

Next to the toe of my shoe is a survey marker embedded in the floor of one of the NIST labs. Atomic clocks are so precise now that centimeter changes in altitude have to be adjusted for, thanks to general relativistic effects.

* * *

This was my fourth (2018, 2023, 2024, and 2025) and probably last time attending the Time and Frequency Seminar. It is so popular that not only does it sell out, but the waiting list is lengthy too. Could be time to let someone else become a certified Time Lord.

AgTech

It was World War II that permanently took my parents out of the agricultural (or maybe the vice) industry in rural eastern Kentucky where they grew up in families that were tobacco farmers and "distillers" (really): my dad joined the Navy, deployed on the U.S.S. Yorktown in the Pacific theatre, and my mom was literally a riveter at a defense plant in Columbus Ohio. Maybe it was the old family businesses that left me with a latent interest in the "ag" industry. Last week I attended another of the Colorado Technology Association's Insights Series: "Innovations in AgTech: How Technology is Shaping Colorado Agriculture". It was a terrific learning experience.

There were two keynote speakers, one from CoBank and the other from American AgCredit. These are cooperative banks that are part of the member-owned - like a credit union - Farm Credit System, a government-sponsored enterprise established by Congress in 1916 to insure farmers had access to loans. Why are these guys talking to an org like the CTA? Because by law they can only lend money to farmers; they can't lend money to agricultural technology startups trying to develop new technology for farmers, who are often running US$10Ms+ businesses with huge capital investments managed only using spreadsheets. 

So the banks find themselves trying to put venture capitalists together with AgTech startups to solve the problems their members have. Technology is a big deal in agriculture because labor is a huge cost. (Remarkably, land is another big cost, and many of the efficiency drivers provided by technology only scale with more land; a modern tractor can mow 175 acres of hay in four hours, and costs as much as a house.)

The event included a panel discussion with the two bankers (one of whom was formerly a rancher himself - he showed a photograph of him wrestling a steer to the ground), three former founders of successful AgTech startups, and a really interesting faculty member at Colorado State University - a land-grant university that was formerly Colorado Agricultural College - who is the Director of Ag Innovation at CSU.  (I learned that agriculture in Colorado, where I call home, is pretty unique in that the state has many different biomes, so that it lends itself to growing different crops and livestock, unlike, say, states in the Midwest.)

My work with Differential GNSS and Inertial Measurement Units, which I've written about here previously, was inspired by my interest in precision agriculture, used in applications like auto-steer for tractors, a technology which has led to a huge cost savings for farmers.

It's events like this that keep me renewing my membership in the CTA, a professional society I've been a member of since 2018. I'm not there to hire, to find work, to buy, or to sell; mostly just there to learn and to get ideas for my own projects. Although I routinely attend networking events like their upcoming C-Level at Mile High that are relatively expensive to attend, I do so mostly to support the organization, and because, in the case of C-Level, its fun to wander around on the party floor of Empower Field, a part of the Bronco's football stadium fans rarely if ever see. Also, the food is not bad. But when people choose to chat with me, I feel kind of guilty that I'm probably wasting their time. (I admit left the AgTech event as soon as it transitioned to the networking stage.)

Population Implosion

The March 3rd edition of The New Yorker had a long article (it was the only thing I got read this AM during my usual Saturday AM breakfast out) about the global declining birth rate. The whole thing reads like science fiction, not unlike Children of Men.

https://www.newyorker.com/magazine/2025/03/03/the-population-implosion

The poster child for this issue is South Korea (half of whose population lives in Seoul, BTW), whose birth rate stands at 0.7. (2.1 is considered a "replacement rate"). Each successive generation is a fraction of the size of the previous one. There are schools in the country that had one thousand students at their peak that now have five.

The U.S. rate isn't nearly that low: 1.66, but still well below replacement. But even immigration won't address the issue of who is going to do the work and pay the taxes that fund Social Security, since for the U.S. the nations from which people immigrate also have declining birth rates.

Reasons? Lots of them. But a big part was the deliberate planning on the parts of non-governmental organizations and governments who panicked about population growth, the food supply, and the environment decades ago. If you think about it, NGOs and governments have, at best, very coarse control over the "birth rate" knob, so getting it tuned perfectly to the desired rate - whatever that may be - is almost impossible. Most got it too low. South Korea got it way too low.

I won't live long enough to have to worry much about this. But eventually we'll have to use AI and automation just to do fundamental stuff like farming and distribute basic goods; there won't be anyone to do the work, and the people that do exist will be too old.

This won't really effect the climate change issue, since climate change is happening on the span of decades, while population decline is on the span of generations.

It occurred to me that this would be an interesting SF story: aliens - perhaps "obligate reproducers" (adults have to procreate or they die) - show up and say "Hey, no sweat, we're patient, we'll stick around until you aren't using your planet anymore. It's just a matter of time."

Edit: capitalism seems to depend on an ever growing population of consumers. What it really means when the population explosion trend reverses - as inevitable as this may seem - is anyone's guess... but it can't be good.

Let Them Burn

A recent article in MIT Technology Review (probably paywalled) is about dealing with electric vehicle battery fires.

https://www.technologyreview.com/2025/02/24/1111551/ev-lithium-ion-battery-fire-first-responders-firefighters/

It's based on the research by an EV battery pack designer who is also a volunteer firefighter, and who now consults with fire departments on this issue. His conclusion: let them burn, while trying to isolate them from surrounding vehicles and structures. Isolating can mean anything from covering them with a fire blanket, to (as one case study illustrated) moving the EV to a vacant lot with a forklift while it is burning. Wow.

Fires need three things to continue to burn: fuel, oxygen, and heat. Typical firefighting techniques involve interrupting one or more of these constituents. But lithium battery packs provide all three all by themselves, as part of a "thermal runaway" chemical reaction.

Traditional vehicle fires are typically centered around the easily accessible engine compartment, and can usually be put out in minutes with hundreds of gallons of water. EV fires are centered around the huge battery pack often underneath the vehicle, and - if they can be put out at all - may take hours and thousands of gallons of water, and may later spontaneously reignite.

The article has many worrisome case studies, including one where an EV owner accidentally drove his car off a pier in Florida. When the battery pack became saturated with electrically conductive salt water, it shorted and ignited... and continued to burn under thirty feet of water. Wow again. EV batteries igniting when saturated with salt water from flooding in coastal areas due to hurricanes is apparently a growing phenomena.

As a typical homeowner with lots of lithium battery packs - some quite large, for power tools - I've gotten concerned enough about this that I don't leave the packs on chargers when no one is at home (not even phones, laptops, or tablets). And I have a small chest of drawers inside the house just inside the door from the garage in which I store my expensive charged lithium battery packs (which don't like the cold either, but that's more of a longevity issue). I do keep rechargeable gear in both automobiles and on both motorcycles (jumper battery packs, tire inflators), and I worry about that.

Mrs. Overclock recently bought some small fire blankets, one of which is now out in the garage next to the wall mounted fire extinguisher.

Update: another recent article on the same topic from the same source, the gist being preventing EV battery fires is a lot more practical than extinguishing them.

https://www.technologyreview.com/2025/02/27/1112556/battery-fire-safety/

When The Minimum Viable Product Is Too Minimal And Not Viable

All technology product development is fractally iterative, whether you want it to be or not. The agile development processes at least recognizes this. But agile, and its idea of a Minimum Viable Product (MVP), replaces the waterfall development process' requirements - which consumes a lot of thought, research, and consensus ahead of time - with a competent product manager and close proximity to the customer. My long professional experience working in both waterfall and agile processes suggests that this can work. Except when it doesn't.

This past spring I was the victim of a Minimum Viable Product strategy when I bought BMW Motorcycle's latest GPS device, the Connected Ride Navigator (CRN-1), for my 2024 BMW R1250GS Adventure ("The Horse With No Name"), my fourth BMW motorcycle. I spent about US$800 on the CRN-1, and it was a disaster. Prior BMW Motorrad navigators were built by Garmin, and to be fair, had their own hardware issues. But this one was a BMW product, reportedly with TomTom maps like those used in the in-dash navigation system in my 2016 Subaru WRX Limited ("The Batmobile"). The hardware seemed pretty solid, but it was as if the software had been designed and written by someone who had never used a navigator (BMW's or otherwise), and had never even ridden a motorcycle.

Besides having lots of professional experience writing code to use GPS devices and to use Open Street Maps, I had used an old Garmin standalone unit on many car trips, and my Subaru WRX has an in-dash TomTom. My basic navigation needs are simple. I want to know what road I'm on. I want to know what the next cross street is. I want to know what direction I'm going. Basic stuff like that. The CRN-1 couldn't do any of that. On a recent trip through northern New Mexico, the screen typically was all gray with a single green line - presumably indicating the road - on it; no labels, no other information - no speed, no direction, etc. And when there were labels, the font was so tiny as to be unreadable with my old eyes using my progressive spectacles.

Here's the MVP thing: since I bought the CRN-1, there have been two software updates, and with each one the device has gotten a little better. But after the New Mexico debacle I had already bought a Garmin Zūmo XT2 navigator, a motorcycle-specific model from BMW's now-competitor, for about US$500. Since I had to modify the navigator cradle on the motorcycle for the XT2, I am unlikely to ever go back.

Sure wish I hadn't spent the money on the CRN-1. You'd think I'd know better than to buy the first release of any tech product. After all, that's why I bought the R1250GS instead of its R1300GS replacement. I'm used to BMW's motorcycle products being well designed and overpriced; the new BMW navigator got one of those right. The MVP CRN-1 was too little and too late.

Update (2025-03-11)

After just short of a year with the eye-wateringly expensive BMW Connected Ride Navigator sitting on a shelf in the garage while the Garmin Zumo was mounted on the bike, I am prepared to give the CRN another shot. Although I haven't road tested it yet, this latest software update looks promising. I can actually read the labels on the streets as I walk around my semi-rural neighborhood between Denver and Golden Colorado.

But this experience - deeply personal with respect to my wallet - has not made me a fan of agile software development, a process I have worked in professionally (and kind of liked). Advocates of agile processes will note - probably correctly - that the mistake wasn't the process itself, but in BMW (or to whomever they contracted this out) not having the right definition for what constitutes a Minimum Viable Product. But, see: those same agile advocates will claim the process eliminates the need for requirements. But I say: the definition of the MVP are the requirements. Shipping a product many months before it was useable is a great - or maybe a terrible - example of casting your users as unpaid (in fact, just the opposite) beta testers.

For sure, I'm keeping the Garmin Zumo XT2 handy.

Large Language Models and the Fermi Paradox

(I originally wrote this as a comment on LinkedIn, then turned the comment into a post on LinkedIn, then into a post for my techie and science fictional friends on Facebook, and finally turned it into a blog article here. I've said all this before, but it bears repeating.)

The destruction of the talent pipeline by the use of AI for work normally done by interns and entry-level employees not only threatens how humans fundamentally learn, but leads to AI "eating its own seed corn". As senior experts leave the work force, there will be no one left to generate the enormous amount - terabytes - of content necessary to train the Large Language Models.

Because human generated content will generally be perceived to be more valuable than machine generated content, humans using AI to generate content will be highly incentivized to not identify AI generated content as such. More and more AI generated content will be swept up along with the gradually diminishing pool of human content to use as training data, in a kind of feedback loop leading to "model collapse", in which the AI produces nonsense.

A former boss of mine, back in my own U.S. national lab days, once wisely remarked that this is why the U.S. Department of Energy maintains national labs: experienced Ph.D. physicists take a really long time to make. And when you need them, you need them right now. Not having them when you need them can result in an existential crisis. So you have to maintain a talent pipeline that keeps churning them out.

It takes generations in human-time to refill the talent pipeline and start making more senior experts, no matter what the domain of expertise. Once we go down this path, there is no quick and easy fix.

The lobe of my brain that goes active at science fiction conventions suggests that this anti-pattern is one possible explanation for the Fermi Paradox.

A Science Fictional Idea: Noise and the Fermi Paradox

Today, Sabine Hossenfelder, "my favorite quantum physicist", had an article about an academic paper in which the author proposed that aliens using really advanced technologies might be able to modulate the quantum properties of photons in order to carry information. (Note: this is not the SFal idea of using entangled particles to communicate faster than light, which - sorry - is not possible; there is no way to modulate the effect to carry information.) Such a modulation scheme could carry a lot more information than our current schemes that modulate properties like amplitude, frequency, phase, etc. A communication beam with quantum modulation would have to be extremely narrowly focused, lest it run into some other matter which would cause the quantum properties to decohere, losing all the information content.

The author wrote a possible approach would be to use frequencies in the infrared, which would require antennas on each end about one hundred kilometers across, which is, actually, not a completely crazy idea. Dr. Hossenfelder also mentioned that because of the decoherence issue, the aliens would be careful NOT to aim the beam near any planet, like, you know, ours. But even if we did receive it, we would have no clue how to demodulate it. I got to thinking about this. (That's why I follow Dr. Hossenfelder, and even support her work on Patreon.)

I recently spent three days at the NIST Time & Frequency Seminar held at the National Institute for Standards and Technology (NIST) Boulder laboratories. A big part of that seminar were demonstrations on how to measure and characterize noise in precision frequency sources. Precision frequency sources like the NIST-F2 cesium fountain clock, shown below, which is the principal frequency reference for the definition of UTC(NIST), the United State's contribution to the international definition of Universal Coordinated Time or UTC. This noise measurement and characterization is not completely removed from measuring noise in communications systems, which, by the way, depend on precision frequency references to work. (A big Thank You to Dr. Jeffrey Sherman, below, for the tour!)

Along the commuter train line from our neighborhood to downtown Denver there is an old AT&T Long Lines tower with the giant microwave horn antennas that used be the backbone of the long distance telephone system. This was before fiber optic cables were run along every railroad track - because the railroads owned the right of ways (an effort which gave the telecommunications company SPRINT its name: "Southern Pacific Railroad Internal Networking Telephony").

The Spousal Unit is so very tired of me telling the story - which I do virtually every time we ride the train (sorry) - of the two Bell Labs engineers who were tasked with figuring out and eliminating the source of the noise in the early models of these microwave antennas (which were big enough you could easily stand up inside of them). Alas, they ultimately weren't able to eliminate it: they determined the noise was the Cosmic Background Microwave Radiation that was the result of the Big Bang. They were picking up the noise from the birth of the Universe. As a consolation, however, they did win a Nobel Prize in physics. And invented the entire realm of radio astronomy. (I eventually took a little motorcycle ride and found that Long Lines tower, shown below.)

Noise exists in every communication link, whether it's radio, wire, optical, etc. You can't get rid of it completely. Eventually maybe you give up and just declare it's "cosmic background", or "thermal noise", or "electrical noise from other equipment in the room". But noise in communication systems is no small problem; given enough, it can jam your GPS, your WiFi, your mobile phone, etc., or just make your vintage vinyl albums sound bad.

I very dimly recall a result from Information Theory that says something like: the output of a theoretically optimal data compression algorithm is indistinguishable from noise. That is: there is no statistical test that can tell you whether the data stream you're looking at is just noise, or is optimally compressed data. (That's not quite the same as saying, however, that it is random.)

What if the aliens have a nearly optimal compression algorithm? (A perfectly optimal one is impossible.) Sending data from one star system to another is bound to be really expensive, not to mention take a long time. So they would be highly incentivized to use such an algorithm. What if part of the noise we see and hear and receive every day in our own radio communications systems is really alien data transmissions?

We could be awash in extraterrestrial data communications and not even know it.

Ancient History

I bought a four terabyte (4TB) SSD the other day at the local big box store. A Samsung T7 Shield (which I think just means it comes with a rubberlike case around it). It was substantially discounted, probably because the new T9 model is out. Easily fits in my shirt pocket. Hooked it up via the included USB cable to our network-attached storage box, and I'm now using it to automatically back up two Mac laptops and a Mac desktop at the Palatial Overclock Estate.

Mind blown.

Because I am ancient almost beyond belief - it's a miracle I'm still alive, especially considering my hobbies - I remember thirty years ago helping to write a proposal to DARPA to build a one terabyte (1TB) hierarchical storage system that would have included rotating disks and a robotic tape library. It would have taken up an entire room. Can't blame them for not funding it. Someone smarter than me (which could have been just about anyone) probably saw this all coming.

That same organization, the National Center for Atmospheric Research (NCAR) in Boulder Colorado, had the only CRAY-3 supercomputer outside of Seymour Cray's Cray Computer Corporation. Today, your Raspberry Pi Single Board Computer (SBC) - and not even the latest Pi model 5 - has more horsepower than that CRAY-3. And the SBC would fit in your shirt pocket as well.

Don't bet against Moore's Law.

Although as I am always quick to point out, what exactly Moore's Law implies has changed over the past few years. Which is why I was tickled when someone who is using my Diminuto C systems programming library passed along a command line to build the software by running make across sixteen parallel threads of execution - taking advantage of the trend towards multicore processors, now that it's become difficult to make individual processors faster. Between much of the build process being I/O bound, and having four processor cores on the Raspberry Pi 5, this approach really speeds up the makefile.

That's me, about thirty years ago, leaning against the world's most expensive aquarium; the CRAY-3 logic modules were visible under the transparent top, fully immersed in Fluorinert.

Converting GPIO from the legacy sysfs ABI to the ioctl ABI in Diminuto and Hazer

It could be that no one but me is using my "Hazer" GNSS library and toolkit, or the "Diminuto" C-based systems programming library on which it depends. But just in case: I'm close to finishing testing of the develop branch of both repos, both of which have some major changes to how General Purpose Input/Output (GPIO) - the generic term for controlling digital input and output pins in software - and merging develop back into the master branch.

This was all motivated by my being one of the lucky few to get a backordered Raspberry Pi 5, and putting the latest version of Raspberry Pi OS, based on Debian "bookworm" and Linux 6.1, on it, only to find when unit and functional testing my code that the deprecated sysfs-based GPIO ABI no long worked. This wasn't a big surprise - I had read at least two years ago that the old ABI was being phased out in favor of a new ioctl-based ABI. My code makes heavy use of GPIO for a lot of my stuff, e.g. interrupts from real-time sensors, the One Pulse Per Second (1PPS) signal from GNSS receivers, status LEDS, etc. So it was finally time to bite the bullet and replace all the places where I used the sysfs-based Diminuto Pin feature (diminuto_pin) with a new ABI using the ioctl. Hence, the Diminuto Line (borrowing a term from the new ABI) feature (diminuto_line).

Line is now used in place of Pin in all of the Diminuto functional tests that run on  hardware test fixtures I wired up many years ago just for this purpose, and all the functional tests work. The Hazer gpstool utility has similarly been converted to using Line instead of Pin and has been tested with an Ardusimple board using a u-blox UBX-NEO-F10T GNSS receiver.

(That's a Pi4 on the left connected to my test fixture, and a Pi5 on the right connected to the GNSS receiver.)

Two complaints.

[1] The new ABI is woefully under documented. However, I found some code examples in the Linux kernel source repo under tools/gpio that were essential to my understanding. (I chose not to use the new-ish libgpiod for my work, for reasons, but that is a story for another time. I have no reason to believe that it's not perfectly fine to use.)

[2] The way the ioctl GPIO driver is implemented on older versus newer Raspberry Pi OS versions makes it difficult - I am tempted to say impossible, but maybe I'm just not that smart - to write code that easily runs on either platform using the new ABI. Specifically, the GPIO device drivers in the OSes use a different symbolic naming scheme, making it impossible for application code to select the correct GPIO device and line offset portably on the two platforms. But maybe I'm just missing something. (I hope so.)

I like the new ioctl ABI, and expect to use it exclusively moving forward, even though this will orphan Pis I have that might run older versions of the OS. (I think I have at least one example of every Pi version ever sitting around the Palatial Overclock Estate. Ten of them run 24x7 in roles such as a web server, an Open Street Map server, a Differential GNSS base station, and an NTP server with a cesium atomic clock for holdover.) I have tagged the last version of both repos that still use the sysfs ABI.

That's it.

Update (2024-03-23)

I merged the develop branch in to the master branch this morning. Both the Diminuto build and the Hazer build passed sanity and functional testing (and I'm currently running the long-running "geologic" unit test suite against Diminuto). I had tagged the old master branch in both repos with the name sysfsgpio in case I needed to build them, but I don't anticipate any further development of the old code.

AI in the Battlefield

The name, "Tactical Intelligence Targeting Access Node" (TITAN), is pretty clever. Peter Thiel's Denver-Based Palantir Technologies, a software-driven data analytics company in the defense and intelligence domain, just won a US$178M contract to build an AI-driven mobile battlefield sensor fusion platform. From Palantir's home page: "AI-Powered Operations, For Every Decision". In this context, TITAN consumes a huge amount of data from remote sensors and tells soldiers what to destroy.

Cool. And absolutely necessary. Soldiers on the battlefield are inundated with information, more than humans can assimilate in the time they have. And even if we didn't build it, our peer adversaries surely will (or more likely, are).

This is the kind of neural network-based AI that's going to mistake a commercial airliner for an enemy bomber and recommend that it be shot down, even if its own cyber-finger isn't on the trigger. Because time is short, and if no other information is forthcoming, someone will pull that trigger.

In the inevitable following Congressional investigation, military officers, company executives, and AI scientists and engineers will be forced to admit that they have no idea why the AI made that mistake, and in fact they can't know, because no one can. When you have an AI with over a trillion - not an exaggeration - variables in its learning model, no one can understand how Deep Learning really works.

Seriously, this is a real problem in the AI field right now. AIs do things their own developers did not anticipate, and cannot explain.

Accidental commercial airliner shoot downs are so common they have their own Wikipedia page. And it's just a matter of time before the cyber-finger is on the trigger, because it can respond so more quickly than its overwhelmed human operators.

The worst thing that could happen is for TITAN be an unqualified success. Someone will get the idea that maybe such a system should have its cyber-finger on the red button for strategic ICBMs.

Update (2025-03-03)

The Associated Press recently had an interesting article on the use of U.S. large language models by the Israeli Defense Force.

Pig Butchering with Large Language Models

I have my Facebook default privacy settings locked down so that only my FB friends can see my posts on my timeline. And I only accept friend requests from folks I feel I know pretty well, and typically only those I know in meat space. But when I shared my post about selling a BMW motorcycle to my motorcycle club's group on FB, I had to change the privacy setting of that particular post from private to public so that members who weren't on my FB friends list could see it. The comments below are the result.

Take a close look at them. All of course claim to be from attractive young women. The first two of them are just short comments trying to get me to engage. The fourth one is a long missive that is probably a standard form letter with no specific detail. But the third one has enough specificity that it had me looking up the commenter's profile: a young divorced Asian woman in the fashion industry who lives in San Francisco. Possible but not likely in the BMW motorcycle owner demographic.

It was almost certainly written by an AI, using the current technology based on an artificial neural network, like the Large Language Models such as ChatGPT use. It has all sorts of detail about my post, and at first seems legit, but is really nothing much more than a rewording of what I originally posted to the group.

This is where LLMs are taking the pig butchering or romance scam artists. As they are trained with more and more data, they are just going to get better and better.

Are AI Generated Works Intellectual Property?

The U.S. Patent and Trademark Office (USPTO) has once again stressed that only humans can be listed as inventors on patents. And the U.S. Copyright Office, part of the Library of Congress and typically a small bureaucracy with just a few people, is about to make big news as it evaluates whether AI generated works can be copyrighted.

If the USPTO declines to recognize AI "inventors", and the Library of Congress similarly disallows copyrighting of AI generated material, that's going to really put a crimp in the monetization of AI generated intellectual property, since it cannot be protected.

My current thinking is that right now it's right thing to do.

The current technology of Generative Pre-Trained (GPT) AIs are nothing more than gigantic text or image prediction engines based on huge artificial neural network-based statistical models trained with enormous amounts of human created and curated input - input for which the original authors and artists are not being compensated, despite the fact that their work may have been copyrighted. There's no cognition or creativity involved.

But the counter argument is worth thinking about.

We ourselves are nothing but gigantic text or image prediction engines based on huge natural neural network-based statistical models trained with enormous amounts of human created and curated input - material we have read or examined - for which the original authors and artists are not being compensated, despite the fact that their work may have been copyrighted.

The difference is that when we write or make art, we may be trying use the trained neural network in our brain to create what others have not done before. That's creativity.

Update (2024-02-20)

Another counter argument is that there is creativity and cognition involved in the prompt engineering - the term used for the creation of the prompt, or series of prompts, the human operator gives the AI to produce its output. Perhaps, in this respect, using an AI is no different than using tools like Microsoft Word or Adobe Photoshop for your writing or art.

I'm still leaning towards not providing IP protection for AI generated output. But this is a complicated issue. As the subtitle of my blog reminds you, 90% of this opinion could be crap.

Sources

(Perhaps ironically, this article is based on the no doubt copyrighted work of several others that I would like to cite... if only I could remember them. As I do, I'll add the citations here.) 

Emilia David, "US patent office confirms AI can't hold patents", The Verge, 2024-02-13, https://www.theverge.com/2024/2/13/24072241/ai-patent-us-office-guidance

Cecilia Kang, "The Sleepy Copyright Office in the Middle of a High Stakes Clash over A.I.", The New York Times, 2024-01-25, https://www.nytimes.com/2024/01/25/technology/ai-copyright-office-law.html

Louis Menand, "Is A.I. the Death of I.P.?", The New Yorker, 2024-01-15, https://www.newyorker.com/magazine/2024/01/22/who-owns-this-sentence-a-history-of-copyrights-and-wrongs-david-bellos-alexandre-montagu-book-review

Shira Perlmutter, "Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence", U.S. Copyright Office, Federal Register, 2023-03-10, https://copyright.gov/ai/ai_policy_guidance.pdf

Katherine Kelly Vidal, "Inventorship Guidance for AI-assisted Invention", U.S. Patent and Trademark Office,  Federal Register, 2024-02-13, https://public-inspection.federalregister.gov/2024-02623.pdf

Large Language Models/Generative Pre-trained Transformers

Regarding the current state of Artificial Intelligence (AI) applications: my concern is that by the time we figure out we need an enormous volume of high quality content created and curated by human experts to correctly train Large Language Models (LLMs) like ChatGPT, we will have eliminated all the entry-level career paths of those very same human experts by using those same LLMs. As the existing cohort of experts retire, die, move into management, or otherwise quit producing content, there will be no one to take their place. We will have destroyed the very talent pipeline that creates the necessary training data.

We will have “eaten our own seed corn”.

Because human-created and -curated content will be more expensive to produce, organizations will be strongly incentivized to use LLM-created content to train other LLMs - or perhaps even the same LLM. This tends to cause errors in the training data to be amplified, leading to model collapse, where the LLM produces nonsense. (This is less likely to happen with human-created content because humans, unlike an algorithm, are unlikely to make exactly the same mistakes.)

Because human-created and -curated content will be deemed to be of higher quality, organizations will be strongly incentivized to not label LLM-created content as such. This will be problematic for LLM developers who are looking for the enormous amounts of high quality data necessary to train their models. 

We will have "salted our own fields".

The seeds of the destruction of LLMs lies in the economics of creating and using LLMs.

I believe that LLMs have a future in being used as tools by experienced users in the same way such users today use tools like Wikipedia, Google Search, and StackOverflow - with much of the same risk. But even if we retain the people in the entry level positions, encouraging them to use LLMs in their work may prevent them from the very experience in that entry level work they need to move onto more advanced tasks.