There is a water shortage?

The design is very human

Or use yEnc: https://en.m.wikipedia.org/wiki/YEnc

each file is minimum 4kb

(base64.length/max_character) * min_filesize < actual_file_size

For this to pay off

I'd go with a prefix, so it's ls-friendly.

Even better! According to no hiding theorem, you can't destroy information. With black holes you maybe possibly could be able to recover the data as it leaks through the Hawking radiation.
Perfect for long term storage

That's the kind of manager that also tells you that you just lack creativity and vision if you tell them that it's not possible. They also post regularly on LinkedIn

You can give me any file, and I can create a compression algorithm that reduces it to 1 bit. (*)

https://xkcd.com/1381/

u can have everthing in a single bit, if the decompressor includes the whole universe

Send him your work: 1 (or 0 ofc)

Well he's not wrong. The decompression would be a problem though.

that's awesome! I'm just migrating all my data to πfs. finally mathematics is put to a proper use!

Finally someone uses the fact that compute time is so much cheaper than storage!

That story is immediately what came to mind.

What about a hard drive made of network pings?

https://m.youtube.com/watch?v=JcJSW7Rprio

I remember a project where someone booted Linux off of Google Drive. Cursed on many levels.

"Harder Drive"

Store the data in pings that constantly get resent to keep the data in the internet

per page

I mean, yes. obviously.

If you had 1000 bytes of text on 1 page before, you now have 1byte per page on 1000 pages afterwards

Have a macro that decreases all font size on opening and then increases all again before closing.

Follow me irl for more compression techniques.

When you run out of characters, you simply create another 0 byte file to encode the rest.

Check mate, storage manufacturers.

255, generally, because null termination. ZFS does 1023, the argument not being "people should have long filenames" but "unicode exists", ReiserFS 4032, Reiser4 3976. Not that anyone uses Reiser, any more. Also Linux' PATH_MAX of 4096 still applies. Though that's in the end just a POSIX define, I'm not sure whether that limit is actually enforced by open(2)... man page speaks of ENAMETOOLONG but doesn't give a maximum.

It's not like filesystems couldn't support it it's that FS people consider it pointless. ZFS does, in principle, support gigantic file metadata but using it would break use cases like having a separate vdev for your volume's metadata. What's the point of having (effectively) separate index drives when your data drives are empty.

Link?