πFS - एक फ़ाइल सिस्टम जो डेटा को हार्ड ड्राइव के बजाय π में स्टोर करने का दावा करता है

 (github.com/philipl)
2 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • πfs एक फ़ाइल सिस्टम है जो इस विचार को लागू करता है कि डेटा को हार्ड ड्राइव में स्टोर करने के बजाय π में स्टोर किया जाए, ताकि डिस्क स्पेस का उपयोग न हो; इसका मूल आधार यह धारणा है कि π में मौजूद हो सकने वाली सभी फ़ाइलें समाहित हैं
  • यह इस व्याख्या पर आधारित है कि यदि π के normal number (normal number) होने का अनुमान सही है, तो उसके hexadecimal representation में सभी finite files मौजूद होंगी
  • यदि π के भीतर फ़ाइल का index और लंबाई ज्ञात हो, तो Bailey–Borwein–Plouffe formula से फ़ाइल निकाली जा सकती है, और यह implementation performance के लिए फ़ाइल के हर byte को π से अलग-अलग lookup करती है
  • चलाने के लिए πfs -o mdd=<metadata directory> <mountpoint> फ़ॉर्मेट का उपयोग होता है, और metadata directory में फ़ाइल नाम तथा π के भीतर फ़ाइल की स्थिति जैसी metadata संग्रहीत की जाती है
  • build के लिए autoconf, automake, libfuse पैकेज चाहिए, और ./autogen.sh, ./configure, make, make install क्रम से build किया जाता है
  • मौजूदा implementation अभी शुरुआती prototype है, और उदाहरण के तौर पर 400-लाइन की text file स्टोर करने में 5 मिनट लगे
  • भविष्य की संभावनाओं में variable execution length search/lookup, Arithmetic Coding, parallel lookup, cloud-based π lookup, और Hadoop के लिए πfs शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News टिप्पणियाँ

  • Babel की Library को data compression टूल की तरह इस्तेमाल करने की कोशिश याद आ गई
    उसी की वजह से मैं एक दिलचस्प rabbit hole में उतर गया था, और पहली बार information theory से परिचय हुआ
    निष्कर्ष यह था कि डेटा के location address को व्यक्त करने के लिए भी लगभग उतनी ही information चाहिए होती है जितनी खुद डेटा में, इसलिए compression के लिए यह खास उपयोगी नहीं है और ज़्यादा एक दिलचस्प thought experiment जैसा है
    आज के नज़रिए से दिलचस्प बात यह है कि LLM इन टूल्स के असफल लक्ष्य के सार को वास्तव में हासिल करने वाले lossy compression के एक रूप हैं। बेशक, इनमें loss होता है, और एक बहुत बड़ा आधार भी चाहिए

    • यह वीडियो दिलचस्प लग सकता है: Reinventing Entropy Compression is Intelligence Part 1, 3Blue1Brown
      https://youtu.be/l6DKRf-fAAM?is=ne73FCJ7ErXhzZ-v
    • 3Blue1Brown ने अभी-अभी intelligence और compression के connection पर एक वीडियो डाला है
      https://youtu.be/l6DKRf-fAAM
    • एक मायने में science compression का सबसे चरम रूप है। Newtonian mechanics कुछ ही पंक्तियों में बेहद बड़ी संख्या में phenomena को समझा देती है
    • compression के स्तर को देखें तो यह काफ़ी प्रभावशाली है। मुझे लगता है कि पहले लिखा मेरा कमेंट अब भी सही है, हालांकि bytes नहीं बल्कि bits होने चाहिए थे, इसलिए उस मामले में वह ग़लत था: https://news.ycombinator.com/item?id=39559969
      valid 4-grams, यानी चार-शब्द sequences, को store करने का मोटा हिसाब 10 अरब × प्रति शब्द 14 bits = कुल 10 अरब के लिए लगभग 17GB होता है। लेकिन इससे 100 गुना छोटा LLM भी सुसंगत prose लिख सकता है

  • nsafs, यानी National Security Agency Filesystem, याद आ गया। इसमें सेटिंग यह है कि सरकार पैसा देती है, इसलिए यह “free” है: https://github.com/freedomtools/nsafs

    • यह बस कुछ extra प्रक्रिया जोड़कर बनाई गई write-only memory है
      https://en.wikipedia.org/wiki/Write-only_memory_(joke)
    • पहले एक company interview में interviewer ने बताया था कि उसने venture investor के रूप में एक ऐसे project में निवेश किया था जो एक विशाल random stream generate करता है
      विचार यह था कि एक मनचाहा index चुना जाए और उसकी private key सामने वाले के साथ share की जाए, फिर उसके बाद के text को one-time pad की तरह इस्तेमाल किया जा सके। तर्क यह था कि NSA को इसे decrypt करने के लिए GB/s की रफ़्तार से generate हो रही पूरी stream को buffer और store करना पड़ेगा, लेकिन यह ज़्यादा practical नहीं लगा

  • यह बात ध्यान देने लायक है कि जैसे-जैसे डेटा की लंबाई बढ़ती है, π के भीतर उस sequence के index और length का मूल डेटा से छोटा होने की संभावना बेहद कम हो जाती है

    • यह तो आसानी से हल होता दिखता है। π के भीतर के index और length को फिर से π के भीतर के index और length के रूप में दर्ज कर दीजिए
    • कॉलेज के समय मैंने सोचा था कि अगर फ़ोन नंबर को π के भीतर के index के रूप में बताया जाए तो compression हो सकता है, लेकिन 7-अंकों का फ़ोन नंबर 8-अंकों के index पर मिला था
      area code समेत 10-अंकों के नंबर को खोजने लायक computing resources मेरे पास नहीं थे
    • 20 पंक्तियों की फ़ाइल का index <20TB number> बन जाता है
    • मूल लेख में इस हिस्से पर बात की गई है

      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 π."

  • ये संबंधित पोस्ट हैं। और भी हैं?
    πfs – A data-free filesystem - https://news.ycombinator.com/item?id=36357466 - जून 2023, 107 टिप्पणियाँ
    πfs – A data-free filesystem - https://news.ycombinator.com/item?id=28699499 - सितंबर 2021, 30 टिप्पणियाँ
    PiFS – The Data-Free Filesystem - https://news.ycombinator.com/item?id=26208704 - फ़रवरी 2021, 1 टिप्पणी
    Πfs: Never worry about data again - https://news.ycombinator.com/item?id=21359338 - अक्टूबर 2019, 1 टिप्पणी
    The π Filesystem for FUSE: Store Your Data in π - https://news.ycombinator.com/item?id=19223032 - फ़रवरी 2019, 1 टिप्पणी
    pifs - Avoid disk space usage by saving your files in the digits of Pi - https://news.ycombinator.com/item?id=18687275 - दिसंबर 2018, 1 टिप्पणी
    πfs – A data-free filesystem - https://news.ycombinator.com/item?id=13869691 - मार्च 2017, 105 टिप्पणियाँ
    Πfs: Stores your data in π - https://news.ycombinator.com/item?id=10856108 - जनवरी 2016, 1 टिप्पणी
    Πfs: Never worry about data again - https://news.ycombinator.com/item?id=10847693 - जनवरी 2016, 1 टिप्पणी
    File system that stores location of file in Pi - https://news.ycombinator.com/item?id=8018818 - जुलाई 2014, 98 टिप्पणियाँ
    100% Compression Using Pi - https://news.ycombinator.com/item?id=6698852 - नवंबर 2013, 32 टिप्पणियाँ
    रीपोस्ट लगभग 1 साल बाद ठीक मानी जाती है, और पुराने थ्रेड्स के लिंक उन पाठकों के लिए हैं जो और जानना चाहते हैं

    • सोच रहा हूँ, ऐसी सूची कैसे बनाई जाती है

  • यह भी याद आता है: https://www.spronck.net/sloot.html
    अतिरिक्त पढ़ाई: https://en.wikipedia.org/wiki/Sloot_Digital_Coding_System

    • मैंने इसे पहले थोड़ा देखा था, और Sloot ने जो किया था वह कम से कम कुछ हद तक नया था
      वास्तविक encoding तरीका यह था कि वीडियो की हर लाइन को database में स्टोर किया जाता था, और हर frame को line lookups के sequence के रूप में encode किया जाता था, फिर उन encoded frames को एक दूसरे database में स्टोर किया जाता था। हर वीडियो, frame lookups के sequence में बदल जाता था
      यही वजह थी कि 90 के दशक के आखिर के hardware पर 16 वीडियो को एक साथ स्मूद तरीके से चलाने का डेमो संभव था। क्योंकि हर frame, line lookups का sequence था, इसलिए स्क्रीन को क्षैतिज रूप से 16 हिस्सों में बाँटकर 16 वीडियो एक साथ चलाना, पूरी स्क्रीन पर एक ही वीडियो चलाने से ज़्यादा भारी नहीं था
      इसी तरह, क्योंकि हर frame को अलग-अलग decode किया जाता था, fast-forward और rewind भी स्मूद थे। पारंपरिक video compression की तरह हर keyframe से अंतर निकालने की ज़रूरत नहीं थी, इसलिए 2x playback भी 1x से ज़्यादा कठिन नहीं था
      बेशक, वीडियो फ़ाइलों को 8KB जैसे आकार में स्टोर करना संभव नहीं होता, लेकिन मान लें कि किसी TV series का एक season database में है, तो opening और ending credits को सिर्फ़ एक बार स्टोर करना पड़ता

    • 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.
      लेकिन π तो अनंत है। इसलिए जब तक Moore's law हमारे पक्ष में है, यह प्रतिभाशाली मशीन काम करेगी

  • One of the properties that π is conjectured to have is that it is normal
    यहाँ मुख्य शब्द conjectured है
    मुझे अच्छा लगा कि मेरी अक्सर रहने वाली छोटी-सी rigor वाली जिद यहाँ सामने आई। किसी non-constructive irrational number के normal number होने या उसमें सभी finite strings शामिल होने की बातों में से अभी तक कुछ भी सिद्ध नहीं हुआ है

    • यहाँ “non-constructive” का क्या मतलब है, यह जानने की जिज्ञासा है

  • In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.
    अगर हर bit को अलग-अलग देखा जाए तो प्रदर्शन और बेहतर होगा। सिर्फ़ index 2 और 33 चाहिए होंगे, और इन्हें storage के bits पर कुशलता से map किया जा सकता है

  • यह एहसास असहज करता है कि π में अतीत और भविष्य का सारा ज्ञान, यहाँ तक कि मैं कब मरूँगा यह भी शामिल है

    • यही बात बाकी सभी random infinite bit strings पर भी लागू होती है। जो हिस्सा सहज समझ के खिलाफ लगता है, वह π से नहीं बल्कि infinity से आता है
      साथ ही यह भी नहीं कहा जा सकता कि इसमें अतीत और भविष्य का सारा ज्ञान है। ऐसा इसलिए क्योंकि अतीत और भविष्य के बारे में हर संभव झूठ भी इसमें ऐसे ही मौजूद है कि उसे सच से अलग नहीं किया जा सकता
      जानकारी को pseudorandom sequence के offset के रूप में encode करना, जानकारी को सीधे store करने से storage efficiency के लिहाज़ से बेहतर नहीं है
    • सबसे बुरी बात यह है कि इसमें उस वैकल्पिक timeline का Star Wars 4~6 भी है जिसमें Chris Pratt को Han Solo के रूप में cast किया गया है
      मज़ेदार तथ्य: प्राचीन कैलिफ़ोर्नियाई भाषा में “Chrispratt” का मतलब है “Joel McHale वह भूमिका नहीं चाहता था”
    • लगता है आपको Jorge Borges की The Library of Babel मज़े से पढ़ने लायक लगेगी
      https://dn760100.eu.archive.org/0/items/TheLibraryOfBabel/ba...
    • जो व्यक्ति π को आगे से पढ़ना शुरू करता है, उसे हमेशा सबसे ताज़े अंक मिलते हैं। यह एक परफ़ेक्ट cipher है
    • इसमें अतीत और भविष्य की सारी fake news भी है, और यह जानने का कोई तरीका नहीं कि असली कौन-सी है

  • धुंधली-सी याद है कि पहले किसी compression benchmark की एक entry ने file name को decompression algorithm के input के हिस्से की तरह मानकर benchmark को चालाकी से पार कर लिया था
    benchmark सिर्फ file size मापता था, इसलिए वह उस metric को हरा पाई

  • क्या यह π के ऐसे गुण पर निर्भर नहीं करता जो अभी तक सिद्ध नहीं हुआ है? हर finite string का शामिल होना या regularity चाहिए, लेकिन दोनों में से कोई भी सिद्ध नहीं है