Pack: un nuevo formato de contenedor para archivos comprimidos

Resumen de Pack

• Nuevo formato de archivo/contenedor construido sobre SQLite3 para la estructura y Zstandard para la compresión.
• Tiene como objetivo un manejo muy rápido de muchos archivos (especialmente muchos archivos pequeños), acceso aleatorio al contenido, una CLI simple e integración futura con el sistema operativo.
• Escrito en Pascal usando FreePascal/Lazarus; diseñado para que el código se lea como pseudocódigo.

Rendimiento y referencias

• El autor afirma grandes mejoras frente a tar/zip/7‑Zip, especialmente en árboles con decenas de miles de archivos pequeños; cita ejemplos como el árbol de fuentes de Linux empaquetado en ~1–1.3 s con una salida más pequeña.
• Otros vuelven a ejecutar las pruebas y ven mejoras menores pero reales (a menudo ~1.3–1.7× frente a tar+zstd cuando ambos están bien ajustados), no las “órdenes de magnitud” que sugieren algunos gráficos.
• Hay escepticismo sobre que parte de la aceleración se deba al multihilo y a patologías de Windows/NTFS más que a una idea fundamentalmente nueva.
• La relación velocidad/compresión de Zstandard es ampliamente elogiada y se ve como un factor importante en el rendimiento de Pack.

Uso de SQLite3 y Zstandard

• Partidarios: el formato de archivo de SQLite es estable, está bien documentado, se usa ampliamente y tiene compromiso de compatibilidad hasta 2050; facilita implementaciones alternativas si se usan bindings de SQLite.
• Críticos: ata la especificación a una única implementación en C y a sus peculiaridades; es malo para streaming/pipes porque SQLite quiere una base de datos completa; la recuperación de archivos dañados y el comportamiento con remoto/NFS pueden ser complicados; SQLite no es ideal como formato general de intercambio.
• Pack reemplaza los bytes mágicos de SQLite, por lo que los archivos no se pueden abrir directamente con herramientas genéricas de SQLite; hay tablas personalizadas (Content, Item, ItemContent) pero aún no existe una especificación explícita en disco.
• El autor ofrece un modo CLI para transformar archivos Pack a “SQLite3 real” para depuración y viceversa, y usa un VFS personalizado con un esquema interno de versionado.

Características del formato y decisiones de diseño

• El acceso aleatorio y la extracción selectiva (--include) son objetivos centrales; el autor informa haber extraído un único archivo de archivos grandes en decenas de milisegundos.
• Los archivos se fragmentan en “contents” de ~8–32 MB; las regiones incomprimibles (por ejemplo, partes de archivos multimedia) pueden almacenarse sin comprimir, mientras que otras partes se comprimen.
• No se almacena metadatos del sistema de archivos (propietarios, modos, marcas de tiempo); esto es deliberado para evitar desajustes entre sistemas operativos y filtrar detalles locales, aunque algunos usuarios quieren metadatos opcionales.
• Actualmente no hay soporte para streaming/pipes (tar | ssh tar); el autor dice que está previsto pero todavía no es prioritario.
• El ajuste de compresión se simplifica a propósito (normal vs --press=hard), algo que a algunos usuarios les gusta, mientras que otros quieren un control más fino de los niveles de Zstd.

Elección del lenguaje (Pascal)

• A muchos les sorprende ver una nueva herramienta de sistemas en Pascal; las reacciones van desde el entusiasmo hasta “¿por qué no Rust/Go/C++?”.
• El autor sostiene que Pascal es estable, legible y duradero; algunos comentan sobre los lenguajes de la familia de Wirth, enfatizando las restricciones y la corrección frente a la “narrativa de C”.

Comparaciones con formatos existentes

• Se mencionan Squashfs y dwarfs como sólidos sistemas de archivos comprimidos, de solo lectura y con acceso aleatorio; Pack se diferencia por ser actualizable (en principio) y más “orientado al usuario” como herramienta de archivo.
• Se cita sqlar (archivo basado en SQLite) como arte previo; el autor muestra que Pack lo supera significativamente en velocidad y tamaño en sus pruebas.
• Se critica a Tar por estar orientado a cinta, ser difícil de paralelizar y carecer de acceso aleatorio; otros señalan su fortaleza para streaming y pipes.
• Se elogia a Zip por su ubicuidad y simplicidad, pero se le critica por peculiaridades de metadatos y mala documentación en casos límite.
• Se mencionan ZPAQ/PAQ y compresores de alta relación; Pack apunta explícitamente a velocidad + compresión suficiente, no a relaciones extremas.

Adopción, portabilidad y confianza

• Actualmente hay binarios para Windows y Linux; aún no hay compilaciones para macOS, y compilar desde el código fuente requiere seguir scripts específicos del proyecto.
• Algunos reportan errores de ejecución o anomalías de tamaño con binarios tempranos; hay preocupaciones sobre que SQLite esté compilado sin seguridad de hilos mientras el código parece usar multihilo.
• Varios comentaristas se sienten incómodos con un mantenimiento anónimo y la falta de una especificación formal; el autor responde que la confianza debe venir del código, la licencia y las compilaciones reproducibles, no de la identidad.
• Consenso general: idea interesante con características de rendimiento prometedoras, pero necesita una especificación más clara, mayor soporte de plataformas, garantías robustas de threading y mejor documentación antes de poder considerarse un reemplazo “universal” serio para tar/zip.