Arch Linux will replace xz compression with zstd for distributing their packages. The new extension will be "*.pkg.tar.zst". Time to update the PPM and packit
https://www.archlinux.org/news/required ... ibarchive/
Arch Linux new package format
Re: Arch Linux new package format
And Pkg I guess..mistfire wrote:Arch Linux will replace xz compression with zstd for distributing their packages. The new extension will be "*.pkg.tar.zst". Time to update the PPM and packit
https://www.archlinux.org/news/required ... ibarchive/
I'd like to do so, to keep the door open to the possibility or making an Arch or Alpine based Puppy,
so I intend to support those package types in Pkg..
..So even we don't get round to supporting Arch and Alpine repos themselves, users will still be able
to download and install those packages, if they wish.
That's the plan anyway, so thanks for bringing this to my attention.
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]
Was interested to read about this and decided to try out zstd compression. libarchive (bsdtar) is supposed to have support for zstd according to the libarchive web site. However, when I tried it out, it didn't look like the support was built it. Downloaded the zstd source and installed the library. Then I rebuilt libarchive. I did some tests of building tarballs with different compression formats using libarchive as the package. gzip and bzip2 resulted in files with more than twice the size of the zstd file. However, when I compared it to lzma and xz, the results weren't so spectacular. For this particular test case, lzma did better followed by xz and then zstd. The difference between all of three of them was within 2K. I used zstd -19 when compressing.
Leaves me wondering why Arch is making the switch to zstd. I didn't see a significant improvement in space saved. The compression time wasn't even worth measuring for this test case. Was considering whether I should integrate zstd support in BSD gzip. It already has xz support. From what I've seen so far, don't know if it would be worth the effort. Besides gnu tar and libarchive/bsdtar and the Arch Linux package management tools, are there any other applications that have integrated zstd compression/decompression support?
Leaves me wondering why Arch is making the switch to zstd. I didn't see a significant improvement in space saved. The compression time wasn't even worth measuring for this test case. Was considering whether I should integrate zstd support in BSD gzip. It already has xz support. From what I've seen so far, don't know if it would be worth the effort. Besides gnu tar and libarchive/bsdtar and the Arch Linux package management tools, are there any other applications that have integrated zstd compression/decompression support?
Raspbian squasfs-tools supports zstd, tar too.
In my tests on raspup squash, it does compress/decompress faster than xz on all my boards (pi zero, pi 3, pi 4) however size is closer to gzip compression. I'm guessing debian is supporting zstd as well. I do know that slackware has support for it in the kernel and tar in -current, and probably squash.
IDK what the fuss is about - was invented by facebook devs!
In my tests on raspup squash, it does compress/decompress faster than xz on all my boards (pi zero, pi 3, pi 4) however size is closer to gzip compression. I'm guessing debian is supporting zstd as well. I do know that slackware has support for it in the kernel and tar in -current, and probably squash.
IDK what the fuss is about - was invented by facebook devs!
Puppy Linux Blog - contact me for access
Read somewhere that it might be used in browsers to speed up transfer of certain types of files on the Internet. Some browsers are also using Google's brotli for that sort of thing. Unfortunately, I think it's just making browser code more complex to have so many formats to support.
Also read that it's been incorporated in GNU tar and I just rebuilt libarchive (bsdtar) with zstd support. The library source is here:
https://github.com/facebook/zstd
If it's built before libarchive, libarchive tries to use it as a dependency. Haven't found it in use anywhere else yet. Am wondering whether it's worth adding in when I build my compression/decompression tools or not. I did mention it on the lfs-chat list and someone on the BLFS project added it in as optional for libarchive ( http://www.linuxfromscratch.org/blfs/vi ... chive.html ).
There is a setting in the zstd command line program to emphasize compression time or compression size. So, compression may not be as good if you don't have it set properly. As mentioned, I tested with a setting of 19.
Also read that it's been incorporated in GNU tar and I just rebuilt libarchive (bsdtar) with zstd support. The library source is here:
https://github.com/facebook/zstd
If it's built before libarchive, libarchive tries to use it as a dependency. Haven't found it in use anywhere else yet. Am wondering whether it's worth adding in when I build my compression/decompression tools or not. I did mention it on the lfs-chat list and someone on the BLFS project added it in as optional for libarchive ( http://www.linuxfromscratch.org/blfs/vi ... chive.html ).
There is a setting in the zstd command line program to emphasize compression time or compression size. So, compression may not be as good if you don't have it set properly. As mentioned, I tested with a setting of 19.