diff options
Diffstat (limited to '')
| -rw-r--r-- | doc/faq.txt | 24 | ||||
| -rw-r--r-- | doc/history.txt | 58 |
2 files changed, 41 insertions, 41 deletions
diff --git a/doc/faq.txt b/doc/faq.txt index 36182c2c..333bee09 100644 --- a/doc/faq.txt +++ b/doc/faq.txt @@ -26,7 +26,7 @@ Q: There are many LZMA related projects. How does XZ Utils relate to them? A: 7-Zip and LZMA SDK are the original projects. LZMA SDK is roughly a subset of the 7-Zip source tree. - p7zip is 7-Zip's command line tools ported to POSIX-like systems. + p7zip is 7-Zip's command-line tools ported to POSIX-like systems. LZMA Utils provide a gzip-like lzma tool for POSIX-like systems. LZMA Utils are based on LZMA SDK. XZ Utils are the successor to @@ -42,7 +42,7 @@ Q: Why is liblzma named liblzma if its primary file format is .xz? A: When the designing of the .xz format began, the idea was to replace the .lzma format and use the same .lzma suffix. It would have been quite OK to reuse the suffix when there were very few .lzma files - around. However, the old .lzma format become popular before the + around. However, the old .lzma format became popular before the new format was finished. The new format was renamed to .xz but the name of liblzma wasn't changed. @@ -73,7 +73,7 @@ A: For now, no. Since XZ Utils supports the .lzma format, it's usually Technically, there is a way to make the conversion relatively fast (roughly twice the time that normal decompression takes). Writing - such a tool would take quite a bit time though, and would probably + such a tool would take quite a bit of time though, and would probably be useful to only a few people. If you really want such a conversion tool, contact Lasse Collin and offer some money. @@ -84,7 +84,7 @@ Q: I have installed xz, but my tar doesn't recognize .tar.xz files. A: xz -dc foo.tar.xz | tar xf - -Q: Can I recover parts of a broken .xz file (e.g. corrupted CD-R)? +Q: Can I recover parts of a broken .xz file (e.g. a corrupted CD-R)? A: It may be possible if the file consists of multiple blocks, which typically is not the case if the file was created in single-threaded @@ -94,7 +94,7 @@ A: It may be possible if the file consists of multiple blocks, which Q: Is (some part of) XZ Utils patented? A: Lasse Collin is not aware of any patents that could affect XZ Utils. - However, due to nature of software patents, it's not possible to + However, due to the nature of software patents, it's not possible to guarantee that XZ Utils isn't affected by any third party patent(s). @@ -105,8 +105,8 @@ A: The .xz format is documented in xz-file-format.txt. It is a container filters. Documenting LZMA and LZMA2 is planned, but for now, there is no other - documentation that the source code. Before you begin, you should know - the basics of LZ77 and range coding algorithms. LZMA is based on LZ77, + documentation than the source code. Before you begin, you should know + the basics of LZ77 and range-coding algorithms. LZMA is based on LZ77, but LZMA is a lot more complex. Range coding is used to compress the final bitstream like Huffman coding is used in Deflate. @@ -148,7 +148,7 @@ A: See the documentation in XZ Embedded. In short, something like xz --check=crc32 --powerpc --lzma2=preset=6e,dict=64KiB - Adjust dictionary size to get a good compromise between + Adjust the dictionary size to get a good compromise between compression ratio and decompressor memory usage. Note that in single-call decompression mode of XZ Embedded, a big dictionary doesn't increase memory usage. @@ -184,10 +184,10 @@ A: It is planned and has been taken into account when designing The third method is pigz-style threading (I use that name, because pigz <http://www.zlib.net/pigz/> uses that method). It doesn't affect compression ratio significantly and scales to many cores. - The memory usage scales linearly when threads are added. It isn't - significant with pigz, because Deflate uses only 32 KiB dictionary, + The memory usage scales linearly when threads are added. This isn't + significant with pigz, because Deflate uses only a 32 KiB dictionary, but with LZMA2 the memory usage will increase dramatically just like - with the independent blocks method. There is also a constant + with the independent-blocks method. There is also a constant computational overhead, which may make pigz-method a bit dull on dual-core compared to the parallel match finder method, but with more cores the overhead is not a big deal anymore. @@ -197,7 +197,7 @@ A: It is planned and has been taken into account when designing can cut the memory usage by 50 %. It is possible that the single-threaded method will be modified to - create files indentical to the pigz-style method. We'll see once + create files identical to the pigz-style method. We'll see once pigz-style threading has been implemented in liblzma. diff --git a/doc/history.txt b/doc/history.txt index c97492e8..9d3c6032 100644 --- a/doc/history.txt +++ b/doc/history.txt @@ -4,11 +4,11 @@ History of LZMA Utils and XZ Utils Tukaani distribution - In 2005, there was a small group working on Tukaani distribution, which - was a Slackware fork. One of the project goals was to fit the distro on + In 2005, there was a small group working on the Tukaani distribution, which + was a Slackware fork. One of the project's goals was to fit the distro on a single 700 MiB ISO-9660 image. Using LZMA instead of gzip helped a lot. Roughly speaking, one could fit data that took 1000 MiB in gzipped - form into 700 MiB with LZMA. Naturally compression ratio varied across + form into 700 MiB with LZMA. Naturally, the compression ratio varied across packages, but this was what we got on average. Slackware packages have traditionally had .tgz as the filename suffix, @@ -30,13 +30,13 @@ Tukaani distribution First steps of LZMA Utils The first version of LZMA Utils (4.22.0) included a shell script called - lzmash. It was wrapper that had gzip-like command line interface. It + lzmash. It was a wrapper that had a gzip-like command-line interface. It used the LZMA_Alone tool from LZMA SDK to do all the real work. zgrep, - zdiff, and related scripts from gzip were adapted work with LZMA and + zdiff, and related scripts from gzip were adapted to work with LZMA and were part of the first LZMA Utils release too. LZMA Utils 4.22.0 included also lzmadec, which was a small (less than - 10 KiB) decoder-only command line tool. It was written on top of the + 10 KiB) decoder-only command-line tool. It was written on top of the decoder-only C code found from the LZMA SDK. lzmadec was convenient in situations where LZMA_Alone (a few hundred KiB) would be too big. @@ -48,31 +48,31 @@ Second generation The lzmash script was an ugly and not very secure hack. The last version of LZMA Utils to use lzmash was 4.27.1. - LZMA Utils 4.32.0beta1 introduced a new lzma command line tool written + LZMA Utils 4.32.0beta1 introduced a new lzma command-line tool written by Ville Koskinen. It was written in C++, and used the encoder and - decoder from C++ LZMA SDK with little modifications. This tool replaced - both the lzmash script and the LZMA_Alone command line tool in LZMA + decoder from C++ LZMA SDK with some little modifications. This tool replaced + both the lzmash script and the LZMA_Alone command-line tool in LZMA Utils. Introducing this new tool caused some temporary incompatibilities, - because LZMA_Alone executable was simply named lzma like the new - command line tool, but they had completely different command line + because the LZMA_Alone executable was simply named lzma like the new + command-line tool, but they had a completely different command-line interface. The file format was still the same. Lasse wrote liblzmadec, which was a small decoder-only library based - on the C code found from LZMA SDK. liblzmadec had API similar to zlib, + on the C code found from LZMA SDK. liblzmadec had an API similar to zlib, although there were some significant differences, which made it non-trivial to use it in some applications designed for zlib and libbzip2. - The lzmadec command line tool was converted to use liblzmadec. + The lzmadec command-line tool was converted to use liblzmadec. - Alexandre Sauvé helped converting build system to use GNU Autotools. - This made is easier to test for certain less portable features needed - by the new command line tool. + Alexandre Sauvé helped converting the build system to use GNU Autotools. + This made it easier to test for certain less portable features needed + by the new command-line tool. - Since the new command line tool never got completely finished (for - example, it didn't support LZMA_OPT environment variable), the intent + Since the new command-line tool never got completely finished (for + example, it didn't support the LZMA_OPT environment variable), the intent was to not call 4.32.x stable. Similarly, liblzmadec wasn't polished, but appeared to work well enough, so some people started using it too. @@ -85,16 +85,16 @@ Second generation File format problems - The file format used by LZMA_Alone was primitive. It was designed for - embedded systems in mind, and thus provided only minimal set of - features. The two biggest problems for non-embedded use were lack of - magic bytes and integrity check. + The file format used by LZMA_Alone was primitive. It was designed with + embedded systems in mind, and thus provided only a minimal set of + features. The two biggest problems for non-embedded use were the lack of + magic bytes and an integrity check. Igor and Lasse started developing a new file format with some help from Ville Koskinen. Also Mark Adler, Mikko Pouru, H. Peter Anvin, and Lars Wirzenius helped with some minor things at some point of the development. Designing the new format took quite a long time (actually, - too long time would be more appropriate expression). It was mostly + too long a time would be a more appropriate expression). It was mostly because Lasse was quite slow at getting things done due to personal reasons. @@ -102,7 +102,7 @@ File format problems that was already used by the old file format. Switching to the new format wouldn't have caused much trouble when the old format wasn't used by many people. But since the development of the new format took - so long time, the old format got quite popular, and it was decided + such a long time, the old format got quite popular, and it was decided that the new file format must use a different suffix. It was decided to use .xz as the suffix of the new file format. The @@ -125,13 +125,13 @@ Transition to XZ Utils The early versions of XZ Utils were called LZMA Utils. The first releases were 4.42.0alphas. They dropped the rest of the C++ LZMA SDK. The code was still directly based on LZMA SDK but ported to C and - converted from callback API to stateful API. Later, Igor Pavlov made - C version of the LZMA encoder too; these ports from C++ to C were + converted from a callback API to a stateful API. Later, Igor Pavlov made + a C version of the LZMA encoder too; these ports from C++ to C were independent in LZMA SDK and LZMA Utils. The core of the new LZMA Utils was liblzma, a compression library with - zlib-like API. liblzma supported both the old and new file format. The - gzip-like lzma command line tool was rewritten to use liblzma. + a zlib-like API. liblzma supported both the old and new file format. The + gzip-like lzma command-line tool was rewritten to use liblzma. The new LZMA Utils code base was renamed to XZ Utils when the name of the new file format had been decided. The liblzma compression @@ -139,7 +139,7 @@ Transition to XZ Utils caused unnecessary breakage in applications already using the early liblzma snapshots. - The xz command line tool can emulate the gzip-like lzma tool by + The xz command-line tool can emulate the gzip-like lzma tool by creating appropriate symlinks (e.g. lzma -> xz). Thus, practically all scripts using the lzma tool from LZMA Utils will work as is with XZ Utils (and will keep using the old .lzma format). Still, the .lzma |