Wednesday, November 4, 2026

Creating a crisis - or responding to signals we can't yet hear?

 

I'm sure many readers are aware of the sudden rush of articles and media reports, recommending that we make sure we have enough supplies stockpiled to take care of sudden, unexpected shortages.  Periods range from a week to 90 days, depending on who's talking.  The quality and trustworthiness of the warnings varies widely.  The more alarmist ones I tend to discount.  The ones that are based on solid evidence and knowledgeable analysis, I listen to more carefully.

One of the very best analyses I've read recently is "The Coming Food Crisis May Look Nothing Like a Crisis Until It’s Too Late".  It doesn't speak about the short term so much as how a long-building crisis will reveal itself over time.  As such, it'll repay reading more than once as you think about it.  You won't agree with all the author's points, but I suspect most of them are carefully thought through.  Here's a brief excerpt.


This article rests on three kinds of claims, and it is worth keeping them apart. First come the demonstrated problems: measured facts about the age of farmers, the drawdown of aquifers, the concentration of meatpacking, the cost of inputs, the price of food. Then comes an interpretation, which is mine and can be argued with: the suggestion that these separate trends, taken together, are eroding the system’s ability to absorb a shock. Last come scenarios, which are conditional rather than predictive, describing what could happen over the next decade or two if several pressures arrive at once and little changes. The text will say which is which as it goes.

What follows is not a forecast of collapse. It is an attempt to look past the grocery aisle at the people who grow the food, the water and soil they depend on, the infrastructure that moves it, and the habits of a public that has rarely had a reason to worry.


There's a lot more at the link.  Highly recommended.

As for more immediate problems and how to prepare for them, there are literally dozens of articles, both mainstream and otherwise, that address the issue.  Here are a few that caught my eye.

I'm not wanting to panic-monger here.  I've prepared for trouble for a long time, and I'm reasonably sure that my wife and I can weather up to 90 days of deprivation - apart from critical supplies such as water - without too much difficulty.  However, I know many people are nowhere near as prepared for trouble.  If things went badly wrong, very quickly - for example, urban unrest cutting off incoming food supplies in the wake of a disputed election result, or something like that - the more people who are prepared to look after themselves, the better.

One of the things that far too few "preppers" have adequately considered, IMHO, is the question of local authorities and law enforcement agencies seeking to confiscate the supplies of those who've prepared for an emergency.  They'll be labelled as "hoarders" and "selfish" for refusing to share.  The mass of the population, who won't have prepared as they should, will almost certainly echo such sentiments and demand that our supplies be handed over as our "fair share" towards coping with the disaster.  How are we going to handle such a situation?  If you think you can shoot your way out of it, you're living in cloud cuckoo land.  You might be able to fight off the first couple of police officers, but when a dozen of them show up, supported by a couple of dozen armed people from your neighborhood?  Not a chance.  There are ways to minimize the risk, and the loss, under such circumstances, but I won't go into them here.

Meanwhile, I suggest we all read at least a few of the articles mentioned above, particularly the first one, and behave like wise virgins rather than foolish ones.

Peter


Tuesday, November 3, 2026

Computer bugs, legacy programs, and the coming crime wave

 

Eric S. Raymond, well-known computer systems author and commenter, recently commented on the potential usefulness of artificial intelligence to detect and fix errors in computer software.  He observed on X:



I have to agree with him:  if we turn a blind eye to the capacity of AI to fix past errors, we basically give in to cybercriminals who will have no hesitation in using AI to find such errors, and then to exploit them rather than fix them.

The scale of the problem was recently revealed.


The prevalence of COBOL is hard to overstate. Created in 1959, the “common business-oriented language” is still widely used today. According to IBM, COBOL underpins over 40 percent of online banking systems, facilitates 80 percent of in-person credit card transactions, and manages 95 percent of ATM transactions. It also supports various government systems, including Social Security and IRS operations. One estimate suggests that COBOL’s inefficiencies cost the US GDP around $105 billion annually.

However, replacing COBOL is no easy task. The same goes for other legacy programming languages like Fortran, which are still utilized in scientific computing, weather forecasting, and critical nuclear security codes. These systems are often too vital to risk breaking, and many of the programmers who once understood them have retired or passed away.

. . .

In its latest update, OpenAI shared encouraging results in migrating COBOL code to more contemporary programming languages such as C++, Java, Kotlin, Python, and Rust, all while preserving the original software’s functionality ... “These evaluation results demonstrate progress toward more accurate, affordable code migration for teams modernizing the software their businesses depend on,” OpenAI stated.

. . .

Experts ... caution that the advancements highlighted by OpenAI are still far from enabling the safe replacement of critical legacy systems ... When dealing with systems as critical as those running on COBOL, experts stress the need for absolute certainty that replacements function correctly. “In many cases, even minor differences in system behavior before and after migration are unacceptable,” Zaytsev noted. While AI can certainly provide efficiencies and speed, the complexity of legacy systems means that partial automation isn’t sufficient.

“Suppose you have a magic AI wand that handles 99 percent of your code,” Zaytsev said. “What do you do with the remaining 1 percent? That 1 percent can be a million lines of code, scattered throughout the system and potentially failing in ways you can’t even imagine.”


There's more at the link.

I couldn't agree more, particularly given that "legacy" code - originally written years or even decades ago, and since then updated and maintained in operation because of various pressures that made it uneconomic to replace - can now be almost impossible to update any further, because of the myriad internal cross-references and patchings over the years.  Let me give you an example.

Way back when, I wrote the main computer program for BP South Africa's Price Book system.  Every day, this program ran in batch mode to update the price charged for every single item sold by BP - engine fuels, lubricants, chemicals, whatever.  When I was given the task to write it, I recommended that I do so in modular fashion:  one program for fuels, one for lubricants, one for chemicals, one for specialized products, and so on.  That way, if any one category needed a major update, its specialized program could be modified and updated without affecting the rest of the Price Book system.  However, I was told that wasn't acceptable.  I had to write one program covering every product in BP's catalog.  Rolling my eyes a little, I set to work.

By the time I finished, if I recall correctly, the program was 6-7,000 lines of COBOL code.  It called in dozens of computer files, moved data around through hundreds of working-storage entries to hold interim calculations and results, and had a test data file of over 5,000 product entries.  It took almost a year to write, test, correct, re-test, etc. and get it into production.

By the time I left South Africa in the mid-1990's, I was told that the program now had a team of three programmers permanently assigned to it;  a lead analyst/programmer designing the updates and fixes, and two programmers to implement them.  It had grown to more than twice the original size, and all of the documentation I had left with it was so far out of date it was almost useless.  The source code and diagrams of section activity were filled with handwritten notes, exclamation points, and even a few profanities.  That wasn't due to anything lacking in the program as I'd handed it over:  it was because so many modifications and changes had come down the pike that one single, monolithic program could not cope with their rapidity.  It wasn't unusual for one fix to be in preparation (design), one to be in the implementation phase (programming and testing), and one going into production - simultaneously.  If it was that bad then, I shudder to think what it's like today . . . assuming it's still in use, of course.

Now, imagine trying to analyze a program like that using AI.  It's comparatively small compared to some very large systems out there, yet I think most AI agents and systems would battle to follow all the convolutions of the design, the code and the output.  Whether authorized or malicious, they'd have a doozy on their hands!

Unfortunately, there are a lot of systems like that out there.  As Mr. Raymond says, "the only way out is through".  We have to gain control of the mess of our legacy systems, because if we don't, malicious actors will use them to rob us blind.  Let the battle begin!

Peter


Monday, November 2, 2026

Friday, October 30, 2026

Halloween, courtesy of Stephan Pastis

 

Click the image to be taken to a larger version at the "Pearls Before Swine" Web page.



That made me cackle loudly . . .

Peter


Thursday, October 29, 2026

On the road again

 

My wife and I are heading to Arkansas to join friends for the celebration of a significant wedding anniversary.  It's a day to get there, a day to celebrate, and a day to get home again.

Blogging will resume on Monday, God willing and the crick don't rise.

Peter