The Analog Approach to CSV Compression
Description
This image is a screenshot of a post on the Q&A website Quora. A user has asked the question, 'What is the best way to compress a CSV?'. Below the question, an answer from a user named Rich is shown. Rich's response begins by clarifying the definition of 'best'. When the implied user specifies the goal is 'To save the most disk space', Rich provides a hilariously impractical and literal solution: 'Print the file in a good OCR font and delete the file. It'll take zero disk space. Later you can scan it back in and OCR it.' The humor stems from this absurdly 'out-of-the-box' thinking, which takes the request to its logical but useless extreme. Instead of suggesting a standard digital compression algorithm (like gzip or bzip2), the answer proposes a physical, analog storage method. This satirizes the kind of pedantic, 'technically correct' but unhelpful answers often found on technical forums, and the potential pitfalls of poorly defined requirements
Comments
31Comment deleted
Finally, a compression algorithm that's both stateless and has guaranteed physical-layer backups. The only downside is the OCR process introduces more data corruption than a failing hard drive
At last, a codec that out-performs zstd - the VOID format. Just remember: if your DR plan involves a printer, your RTO is now gated by toner delivery SLAs
This is the same energy as solving scalability issues by printing your database and hiring interns to manually query it with highlighters - technically correct, practically insane, and guaranteed to make your SRE team question their life choices
Ah yes, the classic O(paper) compression algorithm - infinite compression ratio with only a slight performance penalty of several hours per read operation. Bonus points: it's naturally air-gapped for security, though the disaster recovery plan requires a working scanner and hoping your OCR doesn't interpret that '1' as an 'l'. Still better latency than waiting for S3 Glacier Deep Archive to restore your data
Paper+OCR: the only codec with compression ratio practically infinite, throughput effectively zero, and an RPO determined by how fast an intern finds the scanner
Infinite compression ratio achieved: rm the bits, store in ink - OCR your eventual consistency nightmare
We replaced gzip with the Cellulose codec - zero disk usage, retrieval handled by Facilities via OCR with p99 latency measured in fiscal quarters
bro do be spitting the facts tho Comment deleted
screw digital we goin back to paper Comment deleted
not entirely a bad idea actually Comment deleted
Oh, just use SSD or tape, they are not a disk. Comment deleted
isn't ssd for "super speed disk"? Comment deleted
💀💀💀💀 Comment deleted
lmao i know "solid state drive" is the right answer Comment deleted
i know that you know Comment deleted
No, it stands for super strong dick. Comment deleted
super sussy disk Comment deleted
Disk is not the same as disc. The word "disk" may be synonymous to "volume" — that is, a block device with a file system on it. This is more of a logical construct rather than a physical storage hardware (which may consist of an entire RAID bundle). The word "disc", on the other hand, refers to the physical rotational medium, like in Compact Disc. Comment deleted
If that is so, then the paper medium can also be considered a "disk", right? Comment deleted
If you write a driver for it to be mounted as a disk volume (even read-only), then yes. 🤓 Comment deleted
just dump it all to qr codes Comment deleted
Just memorize it. Comment deleted
Along with some checksums just for good measure Comment deleted
Oh gosh. What an idea Comment deleted
data nerds are just built different Comment deleted
use an indexed dictionary of repeatative phrases and use those indices as pointers Comment deleted
Safe code💀💀 Comment deleted
red(); Comment deleted
Now we can use a laser engraver to convert this CSV file into a QR code. Comment deleted
isn't qr easier to scan Comment deleted
Remove all the commas! 🤪 Comment deleted