Pack: संपीडित फ़ाइलों के लिए एक नया कंटेनर फ़ॉर्मैट

मूल लेख ↗ Hacker News चर्चा ↗

Pack का अवलोकन

  • SQLite3 पर संरचना और Zstandard पर संपीड़न के लिए निर्मित नया आर्काइव/कंटेनर फ़ॉर्मैट।
  • बहुत सारी फ़ाइलों (खासकर बहुत छोटी फ़ाइलों) को बेहद तेज़ी से संभालने, सामग्री तक random access, सरल CLI, और भविष्य के OS एकीकरण का लक्ष्य।
  • Pascal में FreePascal/Lazarus का उपयोग करके लिखा गया; ऐसा डिज़ाइन कि कोड स्यूडोकोड की तरह पढ़ा जाए।

प्रदर्शन और बेंचमार्क

  • लेखक का दावा है कि tar/zip/7‑Zip की तुलना में बड़े लाभ मिलते हैं, खासकर उन ट्रीज़ पर जिनमें दसियों हज़ार छोटी फ़ाइलें हों; Linux source tree जैसे उदाहरणों को ~1–1.3s में छोटे आउटपुट के साथ पैक करने का उल्लेख करता है।
  • अन्य लोग बेंचमार्क दोहराते हैं और छोटे लेकिन वास्तविक लाभ देखते हैं (अक्सर अच्छी तरह ट्यून किए गए tar+zstd की तुलना में ~1.3–1.7×), लेकिन कुछ ग्राफ़ों से संकेतित “orders of magnitude” नहीं।
  • कुछ को संदेह है कि गति-लाभ का एक हिस्सा multithreading और Windows/NTFS pathologies के कारण है, न कि किसी मौलिक रूप से नए विचार के कारण।
  • Zstandard की speed/ratio tradeoff की व्यापक प्रशंसा की जाती है और इसे Pack के प्रदर्शन का बड़ा कारक माना जाता है।

SQLite3 और Zstandard का उपयोग

  • समर्थक: SQLite फ़ाइल फ़ॉर्मैट स्थिर, अच्छी तरह प्रलेखित, व्यापक रूप से उपयोग किया जाता है, और 2050 तक संगत रहने की प्रतिबद्धता है; यदि SQLite bindings का उपयोग करें तो वैकल्पिक implementations आसान बनती हैं।
  • आलोचक: यह spec को एक ही C implementation और उसकी quirks से बाँध देता है; streaming/pipes के लिए खराब है क्योंकि SQLite को पूरा database चाहिए; damaged-file recovery और remote/NFS व्यवहार कठिन हो सकते हैं; SQLite सामान्य interchange format के रूप में आदर्श नहीं।
  • Pack SQLite के magic bytes को बदल देता है, जिससे archives generic SQLite tools में सीधे नहीं खुलते; custom tables (Content, Item, ItemContent) हैं, लेकिन अभी तक कोई स्पष्ट on-disk spec नहीं है।
  • लेखक debugging के लिए Pack files को “real” SQLite3 में और वापस बदलने के लिए CLI mode देता है, और एक internal versioning scheme के साथ custom VFS का उपयोग करता है।

फ़ॉर्मैट की विशेषताएँ और डिज़ाइन निर्णय

  • Random access और selective extraction (--include) मुख्य लक्ष्य हैं; लेखक बड़े archives से एक single file को दर्जनों milliseconds में निकालने की रिपोर्ट करता है।
  • फ़ाइलों को ~8–32MB “contents” में chunk किया जाता है; असंपीडनीय regions (जैसे media files के हिस्से) uncompressed संग्रहीत हो सकती हैं, जबकि अन्य हिस्से compressed होते हैं।
  • कोई filesystem metadata (owners, modes, timestamps) संग्रहीत नहीं की जाती; यह cross-OS mismatch और local details के leakage से बचने के लिए जानबूझकर किया गया है, हालांकि कुछ उपयोगकर्ता वैकल्पिक metadata चाहते हैं।
  • फिलहाल streaming/pipe support (tar | ssh tar-style) नहीं है; लेखक कहता है कि यह योजनाबद्ध है लेकिन अभी प्राथमिकता नहीं है।
  • compression tuning जानबूझकर सरल रखी गई है (normal बनाम --press=hard), जिसे कुछ उपयोगकर्ता पसंद करते हैं, जबकि अन्य Zstd levels पर अधिक सूक्ष्म नियंत्रण चाहते हैं।

भाषा का चुनाव (Pascal)

  • कई लोग एक नए systems tool को Pascal में देखकर हैरान हैं; प्रतिक्रियाएँ खुशी से लेकर “Rust/Go/C++ क्यों नहीं?” तक हैं।
  • लेखक का तर्क है कि Pascal स्थिर, पठनीय, और दीर्घायु है; कुछ लोग Wirth-परिवार की भाषाओं पर चर्चा करते हैं जो C narrative के बजाय constraints और correctness पर ज़ोर देती हैं।

मौजूदा फ़ॉर्मैट्स से तुलना

  • Squashfs और dwarfs को read-only, random-access compressed filesystems के मज़बूत विकल्पों के रूप में उल्लेख किया गया है; Pack उनसे इस मायने में अलग है कि यह (सिद्धांततः) updatable है और archive tool के रूप में अधिक “user-facing” है।
  • sqlar (SQLite-based archive) को prior art के रूप में उद्धृत किया गया है; लेखक अपने परीक्षणों में Pack को speed और size दोनों में उससे काफ़ी बेहतर दिखाता है।
  • Tar की आलोचना इसे tape-oriented, parallelize करने में कठिन, और random access से रहित होने के लिए की जाती है; अन्य लोग streaming और pipes में इसकी ताकत को नोट करते हैं।
  • Zip की ubiquity और सरलता के लिए प्रशंसा की जाती है, लेकिन metadata quirks और edge cases में poor documentation के लिए आलोचना भी होती है।
  • ZPAQ/PAQ और उच्च ratio compressors का उल्लेख होता है; Pack स्पष्ट रूप से speed + पर्याप्त अच्छी compression को लक्ष्य करता है, अत्यधिक ratios को नहीं।

Adoption, Portability, और Trust

  • वर्तमान में binaries Windows और Linux के लिए मौजूद हैं; macOS builds अभी नहीं हैं, और source से build करने के लिए project-specific scripts का पालन करना पड़ता है।
  • कुछ लोग शुरुआती binaries के साथ runtime errors या size anomalies की रिपोर्ट करते हैं; SQLite के बिना thread safety compile होने और code के multithreaded दिखने को लेकर चिंताएँ हैं।
  • कई टिप्पणीकार anonymous maintainership और formal spec की कमी को लेकर असहज हैं; लेखक जवाब देता है कि trust identity से नहीं, बल्कि code, license, और reproducible builds से आना चाहिए।
  • सामान्य सहमति: विचार दिलचस्प है और प्रदर्शन की विशेषताएँ आशाजनक हैं, लेकिन इसे एक गंभीर “universal” replacement for tar/zip माने जाने से पहले स्पष्ट specification, व्यापक platform support, मजबूत threading guarantees, और बेहतर documentation की आवश्यकता है।