The Whole Point of Computing is That Computers Are Deterministic (Speed With Predictable Accuracy)

posted by Roy Schestowitz on Oct 06, 2026

Unlike stochastic parrots that stochastically utter out lies

Earlier today Andy published some "Passing Thoughts" in The Cyber Show. This was about GNU tar failing to accomplish its #1 mission: do it properly every time (irrespective of speed). To quote Andy:

Probably good enough computing

I had a revelation today. Regular computing went stochastic.

Ardour crashed again and I sent a "zip" of the broken project to Paul Davis, who very kindly, (heroically), offered to examine the situation again.

I used the usual

$ tar xzcf project.tar.gz ./project

This produced the expected project.tar.gz file, but Paul found it would not decompress. I tried again, this time testing the archive in situ immediately after creation

$ gzip -t  project.tar.gz

and WTF! it threw a CRC check failure! Now, there's nothing unusual about this data. Okay its quite large at 5G, but it's all a regular old folder of wave files, well ordered collections of floats, some JSON and XML files that are plain text, no filenames with weird characters, no symbolic links, nothing sus at all.

I was worried, so I checked:

1. Disk integrity using: smartctl -a /dev/sda
2. Memory health: memtester 32G 1

Both showed everything as fine.

I tried generating a 5GB folder of random 10M files with random data, and that worked fine using the default gz setup.

It seemed to be just my project that had some incompressible data that it choked on.

Reading up on the few Stack-overflow and Reddit threads still accessible on the remains of the Internet, I found the general sense that gzip is a bit fussy. Sometimes it fails because of big files, or sparse files, or too many files. Crucially its default settings (compression level 6) occasionally fails to create a good archive. I solved my problem by first making a verified tar and then compressing separately with a less aggressive compression factor.

$ tar cvf project.tar ./project
$ gzip --fast project.tar                                                                                                                

And everything went fine again.

I'm still trying to digest this. Gzip is used in thousands of backup solutions, right? Do people know that under some conditions with its default settings there's a reasonable chance it will not make a good archive?

No wonder "AI" is thriving at a time when we accept "probably good enough computing" in critical paths.

Gzip. Reliable data compression? We'll give it a go!

Andy rightly compares this to the quality and reliability some companies came to expect (and want everyone else, clients included, to expect) when they mandate LLM slop for development.

Even MIT is staining computing with this ill mindset. It gets paid to do this. Yesterday it published "People really hate AI [sic], so why can’t they get enough?"

As an associate points out, this article ignores the reality that people do not choose this; it "intentionally ignores that most users are forcibly *required* by their bosses at work to shoehorn LLMs into all activities at work..."

This means software will get worse and less reliable, more so if its makers tolerate sloppers (cheaters). █