Rok 2017 przełomowy dla kompresji? Współtwórca GNOME szuka następcy tar

Początek roku jest z reguły okazją do podzielenia się swoimi przewidywaniami na kolejne 12 miesięcy. Internet zasypały dziś zatem futurologiczne publikacje o trendach, oczekiwaniach, itp. Na ich tle wyróżnia się wpis blogowy Jussiego Pakkanena, zaangażowanego między innymi w rozwój środowiska GNOME. Chce on, by 2017 był rokiem końca archiwizatora tar.

Przez lata, a nawet dekady, tar stał się jednym z najważniejszych programów wykorzystywanych przez użytkowników kolejnych dystrybucji Linuksa. Pakkanen twierdzi jednak, że czas już, by tar został zastąpiony innym programem archiwizującym. Nie ze względu na brak skuteczności w kompresji, ale na niewykorzystywanie potencjału dzisiejszych urządzeń:

Przykładem ma być więc nieobsługiwany przez tar dostęp do pojedynczych plików bez dekompresji całego archiwum oraz możliwość równoczesnej kompresji i dekompresji archiwum. Sytuacji mają także nie poprawiać takie próby implementacji symultaniczności, jak pigz.

Tar ma jednak przewagę pod względem kompresji. Przykładem może być jądro Linuksa w wersji 4.9 (762 MB), które Pakkanem skompresował z wykorzystaniem kompresji xz do tarballa o wielkości 92 MB. Następnie wychodzi on z założenia, że następcą tara może być archiwizator oferujący zbliżonej wielkości archiwa, a jednocześnie obsługujący równoległą kompresję.

Jak widać powyżej, optymalnym rozwiązaniem ma być jpa, który w przypadku dzielenia archiwum na nieskompresowane części o wielkość 1 MB, stworzył archiwum jądra Linuksa o wielkości 102 MB. Podzielenie go na części o wielkości 100 MB dało już jednak wynik na poziomie 91 MB, a zatem mniej niż tarball z kompresją xz. Problem rozwiązany? Niekoniecznie.

Jak widać sam autor nieźle musiał się napracować, aby znaleźć archiwizator kompresujący (tylko odrobinę) skuteczniej niż tar i xz. Proponowane przez niego jpa obchodzi (poprzez stosowanie części), a nie rozwiązuje problem braku dostępu do pojedynczych składników archiwum. A przecież to właśnie wielkość pliku wyjściowego jest wciąż kwestią kluczową. Różnice rzędu kilku megabajtów raczej nie będą argumentem na korzyść porzucenia wykorzystywanego od lat archiwizatora.