PiFS – The Data-Free Filesystem (February 20, 2021 — 1 points, 1 comments) - https://smackernews.com/item/26208704 HN

Πfs: Never worry about data again (October 25, 2019 — 3 points, 1 comments) - https://smackernews.com/item/21359338 HN

The π Filesystem for FUSE: Store Your Data in π (February 21, 2019 — 1 points, 1 comments) - https://smackernews.com/item/19223032 HN

pifs - Avoid disk space usage by saving your files in the digits of Pi (December 14, 2018 — 3 points, 1 comments) - https://smackernews.com/item/18687275 HN

πfs – A data-free filesystem (March 14, 2017 — 285 points, 105 comments) - https://smackernews.com/item/13869691 HN

Πfs: Stores your data in π (January 6, 2016 — 2 points, 1 comments) - https://smackernews.com/item/10856108 HN

Πfs: Never worry about data again (January 5, 2016 — 5 points, 1 comments) - https://smackernews.com/item/10847693 HN

In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.

I don't get it. we simply replace one byte (the data) in another byte, or even more than that (the index in pi) What am I missing?

Besides, why do you have to "search" pi? why not just make a table mapping all possible 2/3/4 bytes (256^(2/3/4) combinations) to it's corresponding positions in pi, and every subsequent compression will run much more efficiently.

BTW, it is very easy to show that a simple huffman code based compression yields a better compression ratio than this method.