πFS - Verileri sabit disk yerine π içinde sakladığını iddia eden dosya sistemi

 (github.com/philipl)
2 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • πfs, verileri sabit diskte saklamak yerine π içinde saklayarak alan kullanmama fikrini hayata geçiren bir dosya sistemi; temel varsayımı, π'nin var olabilecek tüm dosyaları içerdiği yönünde
  • Açıklama, π'nin normal sayı (normal) olduğu varsayımı doğruysa, onaltılık gösterimi içinde tüm sonlu dosyaların bulunduğu düşüncesine dayanıyor
  • Bir dosyanın π içindeki indeksi ve uzunluğu biliniyorsa, Bailey–Borwein–Plouffe formula ile dosya çıkarılabiliyor; bu uygulama performans için dosyanın her baytını π'den ayrı ayrı sorguluyor
  • Çalıştırmak için πfs -o mdd=<metadata directory> <mountpoint> biçimi kullanılıyor; metadata directory içinde dosya adı ve dosyanın π içindeki konumu gibi metaveriler saklanıyor
  • Derleme için autoconf, automake, libfuse paketleri gerekiyor ve ./autogen.sh, ./configure, make, make install akışı izleniyor
  • Mevcut uygulama erken prototip aşamasında; örnek olarak 400 satırlık bir metin dosyasını kaydetmenin 5 dakika sürdüğü belirtiliyor
  • Gelecekteki olasılıklar arasında değişken yürütme uzunluklu arama ve erişim, Arithmetic Coding, paralel sorgulama, bulut tabanlı π sorgulama ve Hadoop için πfs yer alıyor

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News yorumları

  • Babil Kütüphanesi'ni veri sıkıştırma aracı olarak kullanmayı denemeyi düşündüğüm zamanı hatırlattı
    Bu sayede eğlenceli bir rabbit hole'a daldım ve bilgi teorisiyle ilk kez tanıştım
    Vardığım sonuç, verinin konum adresini ifade etmek için de verinin kendisi kadar neredeyse aynı miktarda bilgi gerektiği, dolayısıyla sıkıştırma açısından pek etkili olmadığı ve daha çok ilginç bir düşünce deneyi olduğuydu
    Bugünün ölçütleriyle ilginç olan nokta, LLM'lerin bu araçların başaramadığı hedefin özünü fiilen gerçekleştiren bir kayıplı sıkıştırma türü olması. Elbette kayıp var ve devasa bir temel gerektiriyor

    • Şu video ilginç gelebilir: Reinventing Entropy Compression is Intelligence Part 1, 3Blue1Brown
      https://youtu.be/l6DKRf-fAAM?is=ne73FCJ7ErXhzZ-v
    • 3Blue1Brown az önce zeka ile sıkıştırma arasındaki bağlantıyı ele alan bir video yayımladı
      https://youtu.be/l6DKRf-fAAM
    • Bir bakıma bilim, sıkıştırmanın en uç biçimi. Newton mekaniği birkaç satır yazıyla muazzam sayıda olguyu açıklıyor
    • Sıkıştırma düzeyini düşününce oldukça etkileyici. Daha önce yazdığım yorumun hâlâ doğru olduğunu düşünüyorum, ama byte değil bit olması gerektiği için o noktada yanılıyordum: https://news.ycombinator.com/item?id=39559969
      Geçerli 4-gram'ları, yani dört kelimelik dizileri saklamaya dair kabaca hesap şu: 10 milyar × kelime başına 14 bit = 10 milyarın tamamı için yaklaşık 17 GB. Buna rağmen bundan 100 kat daha küçük bir LLM bile tutarlı düzyazı yazabiliyor

  • nsafs, yani National Security Agency Filesystem'ı hatırlattı. Ücreti devlet ödediği için “ücretsiz” sayılıyor: https://github.com/freedomtools/nsafs

    • Bu, üstüne biraz daha prosedür eklenmiş salt yazılabilir bellek
      https://en.wikipedia.org/wiki/Write-only_memory_(joke)
    • Bir zamanlar bir şirket mülakatında, görüşmeyi yapan kişi girişim sermayedarı olarak devasa bir rastgele sayı akışı üreten bir projeye yatırım yaptığını söylemişti
      Fikir şuydu: rastgele bir indeks seçip o özel anahtarı karşı tarafla paylaşırsanız, sonrasında metni tek kullanımlık şifre pedi olarak kullanabilirsiniz. NSA'nın bunu çözebilmesi için GB/s hızında üretilen tüm akışı tamponlayıp saklaması gerekeceği söyleniyordu, ama pek pratik görünmemişti

  • Veri uzunluğu arttıkça, π içindeki ilgili dizinin indeksi ve uzunluğunun özgün veriden daha kısa olma olasılığının son derece düşük olduğunu belirtmekte fayda var

    • Kolayca çözülebilir gibi görünüyor. π içindeki indeks ve uzunluğu yeniden π içindeki bir indeks ve uzunluk olarak kaydetmek yeterli
    • Üniversitedeyken telefon numaralarını π içindeki indeksleriyle vererek sıkıştırabileceğimi düşünmüştüm, ama 7 haneli telefon numarası 8 haneli bir indekste çıkmıştı
      Alan kodu dâhil 10 haneli bir numarayı bulacak hesaplama kaynağım yoktu
    • 20 satırlık bir dosyanın indeksi <20TB number> oluyor
    • Asıl yazı bu noktaya değiniyor

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

  • İlgili yazılar bunlar. Daha fazlası var mı?
    πfs – A data-free filesystem - https://news.ycombinator.com/item?id=36357466 - Haziran 2023, 107 yorum
    πfs – A data-free filesystem - https://news.ycombinator.com/item?id=28699499 - Eylül 2021, 30 yorum
    PiFS – The Data-Free Filesystem - https://news.ycombinator.com/item?id=26208704 - Şubat 2021, 1 yorum
    Πfs: Never worry about data again - https://news.ycombinator.com/item?id=21359338 - Ekim 2019, 1 yorum
    The π Filesystem for FUSE: Store Your Data in π - https://news.ycombinator.com/item?id=19223032 - Şubat 2019, 1 yorum
    pifs - Avoid disk space usage by saving your files in the digits of Pi - https://news.ycombinator.com/item?id=18687275 - Aralık 2018, 1 yorum
    πfs – A data-free filesystem - https://news.ycombinator.com/item?id=13869691 - Mart 2017, 105 yorum
    Πfs: Stores your data in π - https://news.ycombinator.com/item?id=10856108 - Ocak 2016, 1 yorum
    Πfs: Never worry about data again - https://news.ycombinator.com/item?id=10847693 - Ocak 2016, 1 yorum
    File system that stores location of file in Pi - https://news.ycombinator.com/item?id=8018818 - Temmuz 2014, 98 yorum
    100% Compression Using Pi - https://news.ycombinator.com/item?id=6698852 - Kasım 2013, 32 yorum
    Yeniden paylaşımlar yaklaşık 1 yıl geçince sorun olmuyor ve eski başlık bağlantıları da daha fazla merak eden okurlar için var

    • Böyle bir listenin nasıl oluşturulduğunu merak ediyorum

  • Bu da aklıma geldi: https://www.spronck.net/sloot.html
    Ek okuma: https://en.wikipedia.org/wiki/Sloot_Digital_Coding_System

    • Bir zamanlar biraz araştırmıştım; Sloot'un yaptığı şey en azından bir ölçüde yeniydi
      Gerçek kodlama yöntemi, videonun her satırını veritabanında saklayıp her kareyi satır sorgularının dizisi olarak kodlamak, ardından bu kodlanmış kareyi başka bir veritabanında saklamak üzerine kuruluydu. Her video da kare sorgularının bir dizisi oluyordu
      90'ların sonundaki donanımda 16 videoyu aynı anda akıcı biçimde oynatabildiğini göstermesinin nedeni buydu. Her kare satır sorgularından oluştuğu için, ekranı yatay olarak 16 parçaya bölüp 16 videoyu aynı anda oynatmak, tüm ekranı kaplayan tek bir videoyu oynatmaktan daha zor değildi
      Aynı şekilde, her kare ayrı ayrı çözüldüğü için ileri sarma ve geri sarma da akıcıydı. Geleneksel video sıkıştırmadaki gibi her ana karede farkları hesaplamak gerekmediğinden, 2x oynatma da 1x'ten daha zor değildi
      Elbette video dosyalarını 8KB gibi boyutlarda saklayamazdı, ama örneğin bir TV dizisinin bir sezonu veritabanında varsa açılış ve kapanış jeneriklerini yalnızca bir kez saklamak yeterli olurdu

    • 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.
      Ama π sonsuz. Yani Moore yasası bizim lehimize çalışmayı sürdürdüğü sürece bu dahiyane düzenek işe yarayacak

  • One of the properties that π is conjectured to have is that it is normal
    Buradaki kilit nokta conjectured
    Sık sık takıldığım küçük bir titizlik meselesinin ortaya çıkmasına sevindim. Yapısal olarak tanımlanmamış irrasyonel sayıların normal sayı olduğu ya da tüm sonlu dizeleri içerdiği henüz kanıtlanmış değil

    • Burada “yapısal olarak tanımlanmamış” ile ne kastedildiğini merak ediyorum

  • In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.
    Her biti ayrı ele almak performansı daha da artırırdı. Sadece 2 ve 33 indekslerine ihtiyaç olurdu ve bunlar depolamanın bitlerine verimli şekilde eşlenebilirdi

  • π’nin geçmiş ve gelecekteki tüm bilgileri, hatta ne zaman öleceğimi bile içerdiğini fark etmek rahatsız edici

    • Aynısı diğer tüm rastgele sonsuz bit dizileri için de geçerli. Sezgiye aykırı olan kısım π’den değil, sonsuzluktan kaynaklanıyor
      Ayrıca geçmiş ve geleceğe dair tüm bilgileri içerdiği de söylenemez. Çünkü geçmiş ve geleceğe ilişkin mümkün olan tüm yalanlar da, gerçekten ayırt edilemeyecek şekilde onun içinde yer alıyor
      Bilgiyi sözde rastgele bir dizinin ofseti olarak kodlamak, bilgiyi doğrudan depolamaktan daha verimli bir depolama yöntemi değildir
    • En kötüsü de, Chris Pratt’in Han Solo olarak seçildiği alternatif zaman çizgisindeki Star Wars 4~6’nın da içinde olması
      Eğlenceli bilgi: “Chrispratt”, antik Kaliforniya dilinde “Joel McHale o rolü istemedi” anlamına gelir
    • Jorge Borges’in The Library of Babel eserini muhtemelen keyifle okursunuz
      https://dn760100.eu.archive.org/0/items/TheLibraryOfBabel/ba...
    • π’yi önden okumaya başlayan kişi her zaman en taze rakamları alır. Mükemmel bir şifreleme
    • Geçmiş ve geleceğe dair tüm sahte haberler de içinde var ve hangisinin gerçek olduğunu bilmek mümkün değil

  • Eskiden bir sıkıştırma benchmark’ına katılan bir girişin, dosya adını açma algoritmasının girdisinin bir parçası olarak ele alıp benchmark’ı kurnazca geçtiğini belirsiz de olsa hatırlıyorum
    Benchmark yalnızca dosya boyutunu ölçtüğü için o metriği yenebilmişti

  • Bu, π hakkında henüz kanıtlanmamış bir özelliğe dayanmıyor mu? Tüm sonlu dizeleri içerme ya da normallik gerekiyor, ama ikisi de kanıtlanmış değil