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ń:
Kompresja i dekompresja […] nie mogą przebiegać jednocześnie. Nie było to poważnym problemem w latach 70., ale dziś nawet Raspberry Pi ma cztery rdzenie. Wykorzystywanie jednego wydaje się marnotrawstwem.
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.