πFS - o sistema de arquivos que armazena dados em π em vez de no disco rígido

• O πfs é um sistema de arquivos que implementa a ideia de armazenar dados em π em vez de em um disco rígido, para não ocupar espaço, com a premissa central de que π contém todos os arquivos possíveis
• A explicação se baseia na conjectura de que, se π for normal (normal number), então todos os arquivos finitos existem em sua representação hexadecimal
• Se você souber o índice e o comprimento do arquivo dentro de π, é possível extraí-lo com a fórmula de Bailey–Borwein–Plouffe; esta implementação consulta cada byte do arquivo individualmente em π por motivos de desempenho
• Na execução, usa-se o formato πfs -o mdd=<metadata directory> <mountpoint>, e o metadata directory armazena metadados como o nome do arquivo e sua posição dentro de π
• Para compilar, são necessários os pacotes autoconf, automake e libfuse, seguindo o fluxo ./autogen.sh, ./configure, make, make install
• A implementação atual é um protótipo inicial, e há um exemplo em que salvar um arquivo de texto de 400 linhas levou 5 minutos
• Como possibilidades futuras, são citados busca e consulta com comprimento de execução variável, Arithmetic Coding, consultas paralelas, consulta de π baseada em nuvem e πfs para Hadoop

[GN⁺]

Comentários do Hacker News

• Isso me lembra de quando tentei usar a Biblioteca de Babel como ferramenta de compressão de dados
  Acabei entrando num rabbit hole interessante e foi assim que tive meu primeiro contato com teoria da informação
  A conclusão é que representar o endereço da localização dos dados também exige quase a mesma quantidade de informação que os próprios dados, então isso não ajuda muito na compressão e fica mais como um experimento mental divertido
  O ponto interessante hoje é que os LLMs são uma forma de compressão com perdas que de fato alcança a essência do objetivo em que essas ferramentas falharam. Claro, há perda, e é preciso uma base gigantesca

  • Este vídeo parece interessante: Reinventing Entropy Compression is Intelligence Part 1, 3Blue1Brown
    https://youtu.be/l6DKRf-fAAM?is=ne73FCJ7ErXhzZ-v
  • O 3Blue1Brown acabou de publicar um vídeo sobre a conexão entre inteligência e compressão
    https://youtu.be/l6DKRf-fAAM
  • Em certo sentido, a ciência é a forma mais extrema de compressão. A mecânica newtoniana explica uma quantidade enorme de fenômenos em poucas linhas
  • Quando se pensa no nível de compressão, isso é bem impressionante. Acho que um comentário que escrevi antes ainda continua correto, embora eu tenha errado em um ponto: deveria ser em bits, não bytes: https://news.ycombinator.com/item?id=39559969
    Uma conta aproximada para armazenar 4-gramas válidos, isto é, sequências de quatro palavras, é 10 bilhões × 14 bits por palavra = cerca de 17 GB para o conjunto inteiro de 10 bilhões. Mesmo assim, um LLM 100 vezes menor consegue escrever prosa coerente

• Isso me lembra o nsafs, ou National Security Agency Filesystem. A ideia é que é “gratuito” porque o governo paga a conta: https://github.com/freedomtools/nsafs

  • Isso é uma memória somente de escrita com etapas extras
    https://en.wikipedia.org/wiki/Write-only_memory_(joke)
  • Numa entrevista de emprego, o entrevistador comentou certa vez que, como investidor de venture capital, tinha investido num projeto para gerar um enorme fluxo de números aleatórios
    A ideia era escolher um índice aleatório e compartilhar a chave privada correspondente com a outra parte; depois disso, o texto poderia ser usado como one-time pad. A lógica era que, para a NSA decifrar, ela teria de bufferizar e armazenar todo o fluxo gerado a GB/s, mas isso não me pareceu muito prático

• Vale observar que, à medida que o tamanho dos dados aumenta, a chance de que o índice e o comprimento dessa sequência dentro de π sejam menores que os dados originais se torna extremamente baixa

  • Parece fácil de resolver. Basta registrar o índice e o comprimento em π novamente como um índice e comprimento dentro de π
  • Na faculdade, pensei que dar meu número de telefone como um índice em π poderia ser uma forma de compressão, mas um número de telefone de 7 dígitos estava num índice de 8 dígitos
    Eu não tinha recursos computacionais para procurar um número de 10 dígitos com código de área incluso
  • O índice de um arquivo de 20 linhas vira um <número de 20 TB>
  • O texto original aborda esse ponto

    Now, we all know that it can take a while to find a long sequence of digits in π, so for practical reasons, we should break the files up into smaller chunks that can be more readily found.
    In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.

• São posts relacionados. Tem mais?
  πfs – A data-free filesystem - https://news.ycombinator.com/item?id=36357466 - junho de 2023, 107 comentários
  πfs – A data-free filesystem - https://news.ycombinator.com/item?id=28699499 - setembro de 2021, 30 comentários
  PiFS – The Data-Free Filesystem - https://news.ycombinator.com/item?id=26208704 - fevereiro de 2021, 1 comentário
  Πfs: Never worry about data again - https://news.ycombinator.com/item?id=21359338 - outubro de 2019, 1 comentário
  The π Filesystem for FUSE: Store Your Data in π - https://news.ycombinator.com/item?id=19223032 - fevereiro de 2019, 1 comentário
  pifs - Avoid disk space usage by saving your files in the digits of Pi - https://news.ycombinator.com/item?id=18687275 - dezembro de 2018, 1 comentário
  πfs – A data-free filesystem - https://news.ycombinator.com/item?id=13869691 - março de 2017, 105 comentários
  Πfs: Stores your data in π - https://news.ycombinator.com/item?id=10856108 - janeiro de 2016, 1 comentário
  Πfs: Never worry about data again - https://news.ycombinator.com/item?id=10847693 - janeiro de 2016, 1 comentário
  File system that stores location of file in Pi - https://news.ycombinator.com/item?id=8018818 - julho de 2014, 98 comentários
  100% Compression Using Pi - https://news.ycombinator.com/item?id=6698852 - novembro de 2013, 32 comentários
  Reposts costumam ser aceitáveis depois de cerca de 1 ano, e links para threads antigas servem para leitores que quiserem se aprofundar mais

  • Fico curioso sobre como esse tipo de lista é gerado

• Isso também me lembra isto: https://www.spronck.net/sloot.html
  Leitura adicional: https://en.wikipedia.org/wiki/Sloot_Digital_Coding_System

  • Pesquisei um pouco isso no passado, e o que o Sloot fez era, pelo menos em parte, algo novo
    O método de codificação real consistia em armazenar cada linha do vídeo em um banco de dados, codificar cada quadro como uma sequência de consultas de linhas e depois armazenar esse quadro codificado em outro banco de dados. Cada vídeo virava uma sequência de consultas de quadros
    Esse é o motivo de ele conseguir demonstrar 16 vídeos sendo reproduzidos suavemente ao mesmo tempo em hardware do fim dos anos 90. Como cada quadro é uma sequência de consultas de linhas, dividir a tela em 16 faixas horizontais e reproduzir 16 vídeos simultaneamente não é mais pesado do que reproduzir um único vídeo em tela cheia
    Da mesma forma, como cada quadro é decodificado individualmente, avançar e retroceder rapidamente também eram suaves. Como não era preciso calcular diferenças a partir de cada keyframe como na compressão de vídeo tradicional, reprodução em 2x não era mais difícil do que em 1x
    Claro que não daria para armazenar arquivos de vídeo em algo como 8 KB, mas, por exemplo, se uma temporada inteira de uma série de TV estivesse no banco de dados, os créditos de abertura e encerramento só precisariam ser armazenados uma vez

  • The SDCS is only possible if keys are allowed to become infinite, or the data store is allowed to become infinite (...) This would, of course, make the idea useless.
    Mas π é infinito. Então, contanto que a Lei de Moore continue do nosso lado, esse dispositivo genial vai funcionar

• One of the properties that π is conjectured to have is that it is normal
  A palavra-chave aqui é conjectured
  Fico feliz de ver um daqueles pequenos problemas de rigor que eu costumo martelar aparecer. Ainda não se provou nem que um irracional não construído seja normal, nem que contenha todas as strings finitas

  • Fico curioso sobre o que “não construído” quer dizer aqui

• In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.
  Olhar cada bit separadamente daria um desempenho ainda melhor. Você só precisaria dos índices 2 e 33, e seria possível mapeá-los de forma eficiente para bits no armazenamento

• É desconfortável perceber que π contém todo o conhecimento do passado e do futuro, inclusive quando vou morrer

  • O mesmo vale para qualquer outra sequência infinita aleatória de bits. A parte contraintuitiva não vem de π, e sim do infinito.
    Também não dá para dizer que ela contém todo o conhecimento do passado e do futuro. Isso porque todas as falsidades possíveis sobre o passado e o futuro também estão lá, de um jeito indistinguível da verdade.
    Codificar informação como um deslocamento em uma sequência pseudorrandômica é menos eficiente em armazenamento do que guardar a informação diretamente
  • O pior é que também estão lá os episódios 4 a 6 de Star Wars de uma linha do tempo alternativa em que Chris Pratt foi escalado como Han Solo
    Curiosidade: "Chrispratt" em antigo californiano significa "Joel McHale não quis o papel"
  • Você provavelmente vai gostar de ler The Library of Babel, de Jorge Borges
    https://dn760100.eu.archive.org/0/items/TheLibraryOfBabel/ba...
  • Quem começa a ler π na frente sempre pega os números mais frescos. Criptografia perfeita
  • Também contém todas as fake news do passado e do futuro, e não há como saber qual lado é o verdadeiro

• Lembro vagamente de uma inscrição em algum benchmark de compressão que burlou o teste ao tratar o nome do arquivo como parte da entrada do algoritmo de descompressão
  Como o benchmark media apenas o tamanho do arquivo, ela conseguiu vencer essa métrica

• Isso não depende de uma propriedade de π que ainda não foi provada? É preciso conter todas as strings finitas ou ter normalidade, e nenhuma das duas foi provada