Zstandard compression tools
Zstd, short for Zstandard, is a fast lossless compression algorithm,
targeting real-time compression scenarios at zlib-level compression ratio.
Zstd can also offer stronger compression ratios at the cost of compression speed. Speed vs Compression trade-off is configurable by small increments. Decompression speed is preserved and remains roughly the same at all settings, a property shared by most LZ compression algorithms, such as zlib or lzma.
- Developed at Archiving
- Sources inherited from project openSUSE:Factory
-
8
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout openSUSE:Factory:zSystems/zstd && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
_constraints | 0000000165 165 Bytes | |
baselibs.conf | 0000000192 192 Bytes | |
pzstd.1.patch | 0000000784 784 Bytes | |
zstd-1.5.5.tar.gz | 0002368543 2.26 MB | |
zstd-1.5.5.tar.gz.sig | 0000000858 858 Bytes | |
zstd.changes | 0000025178 24.6 KB | |
zstd.keyring | 0000001668 1.63 KB | |
zstd.spec | 0000005216 5.09 KB |
Revision 32 (latest revision is 38)
Dominique Leuenberger (dimstar_suse)
accepted
request 1082541
from
Bernhard Wiedemann (bmwiedemann)
(revision 32)
now without cmake again - update to 1.5.5: * fix: fix rare corruption bug affecting the high compression mode, reported by @danlark1 * perf: improve mid-level compression speed * lib: deprecated bufferless block-level API (#3534) by @terrelln * cli: mmap large dictionaries to save memory, by @daniellerozenblit * cli: improve speed of --patch-from mode (~+50%) (#3545) by @daniellerozenblit * cli: improve i/o speed (~+10%) when processing lots of small files (#3479) by @felixhandte * cli: zstd no longer crashes when requested to write into write-protected directory (#3541) by @felixhandte * cli: fix decompression into block device using -o, reported by @georgmu * misc: improve seekable format ingestion speed (~+100%) for very small chunk sizes (#3544) by @Cyan4973 * misc: tests/fullbench can benchmark multiple files (#3516) by @dloidolt
Comments 0