https://wiki.archlinux.org/api.php?action=feedcontributions&user=Nemo+bis&feedformat=atomArchWiki - User contributions [en]2024-03-29T14:49:42ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Lrzip&diff=279555Lrzip2013-10-24T07:34:18Z<p>Nemo bis: https://github.com/ckolivas/lrzip</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data compression and archiving]]<br />
[http://lrzip.kolivas.org/ Long Range ZIP] or Lzma RZIP is a compression program optimised for large files. The larger the file and the more memory you have, the better the compression advantage this will provide, especially once the files are larger than 100MB. The advantage can be chosen to be either size (much smaller than bzip2) or speed (much faster than bzip2).<br />
<br />
==Installing Lrzip==<br />
<br />
[[pacman|Install]] {{Pkg|lrzip}}, available in the [[Official Repositories]].<br />
<br />
==Usage==<br />
===Compression===<br />
Compression of directories (recursive) requires lrztar which first tars the directory, then compresses the single file just like tar does when users compress with gzip or xz (tar zcf ... and tar Jcz ... respectfully).<br />
<br />
This will produce an [[Wikipedia:LZMA|LZMA]] compressed archive "foo.tar.lrz" from a directory named "foo".<br />
$ lrztar foo<br />
<br />
This will produce an lzma compressed archive "bar.lrz" from a file named "bar"<br />
$ lrzip bar<br />
<br />
For extreme compression, add the -z switch which enables [[Wikipedia:ZPAQ|ZPAQ]] but takes notably longer than lzma.<br />
$ lrztar -z foo<br />
<br />
For extremely fast compression and decompression, use the -l switch for [[Wikipedia:LZO|LZO]].<br />
$ lrzip -l bar<br />
<br />
===Decompression===<br />
<br />
To completely extract an archived directory.<br />
$ lrzuntar foo.tar.lrz<br />
<br />
To decompress "bar.lrz to "bar".<br />
$ lrunzip bar.lrz<br />
<br />
== Details ==<br />
Lrzip uses an extended version of [[Wikipedia:Rzip|rzip]] which does a first pass long distance redundancy reduction. The lrzip modifications make it scale according to memory size. The data is then either: <br />
<br />
# Compressed by lzma (default) which gives excellent compression at approximately twice the speed of bzip2 compression <br />
# Compressed by a number of other compressors chosen for different reasons, in order of likelihood of usefulness: <br />
## ZPAQ: Extreme compression up to 20% smaller than lzma but ultra slow at compression AND decompression.<br />
## LZO: Extremely fast compression and decompression which on most machines compresses faster than disk writing making it as fast (or even faster) than simply copying a large file.<br />
## GZIP: Almost as fast as LZO but with better compression. <br />
## BZIP2: A defacto linux standard of sorts but is the middle ground between lzma and gzip and neither here nor there.<br />
# Leaving it uncompressed and rzip prepared. This form improves substantially any compression performed on the resulting file in both size and speed (due to the nature of rzip preparation merging similar compressible blocks of data and creating a smaller file). By "improving" I mean it will either speed up the very slow compressors with minor detriment to compression, or greatly increase the compression of simple compression algorithms.<br />
<br />
The major disadvantages are:<br />
#The main lrzip application only works on single files so it requires the lrztar wrapper to fake a complete archiver. <br />
#It requires a lot of memory to get the best performance out of (as much memory as the size of the data to compress; but see the sliding mmap below), and is not really usable (for compression) with less than 256MB. Decompression requires less ram and works on smaller ram machines. Sometimes swap may need to be enabled on these lower ram machines for the operating system to be happy.<br />
# STDIN/STDOUT works fine on both compression and decompression, but larger files compressed in this manner will end up being less efficiently compressed.<br />
<br />
The unique feature of lrzip is that it tries to make the most of the available ram in your system at all times for maximum benefit. It does this by default, choosing the largest sized window possible without running out of memory. It also has a unique "sliding mmap" feature which makes it possible to even use a compression window larger than your ramsize, if the file is that large. It does this (with the -U option) by implementing one large mmap buffer as per normal, and a smaller moving buffer to track which part of the file is currently being examined, emulating a much larger single mmapped buffer. Unfortunately this mode can be many times slower.<br />
<br />
== Benchmarks ==<br />
<br />
See the [http://ck.kolivas.org/apps/lrzip/README.benchmarks README.benchmarks] included in the source/docs.<br />
<br />
== FAQ ==<br />
<br />
See the [http://ck.kolivas.org/apps/lrzip/README README] included with the source package.<br />
<br />
== Repository and issue tracker == <br />
<br />
On https://github.com/ckolivas/lrzip</div>Nemo bishttps://wiki.archlinux.org/index.php?title=Lrzip&diff=279336Lrzip2013-10-22T07:18:31Z<p>Nemo bis: /* Details */ it's really as much memory as the size of the data to compress</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data compression and archiving]]<br />
[http://lrzip.kolivas.org/ Long Range ZIP] or Lzma RZIP is a compression program optimised for large files. The larger the file and the more memory you have, the better the compression advantage this will provide, especially once the files are larger than 100MB. The advantage can be chosen to be either size (much smaller than bzip2) or speed (much faster than bzip2).<br />
<br />
==Installing Lrzip==<br />
<br />
[[pacman|Install]] {{Pkg|lrzip}}, available in the [[Official Repositories]].<br />
<br />
==Usage==<br />
===Compression===<br />
Compression of directories (recursive) requires lrztar which first tars the directory, then compresses the single file just like tar does when users compress with gzip or xz (tar zcf ... and tar Jcz ... respectfully).<br />
<br />
This will produce an [[Wikipedia:LZMA|LZMA]] compressed archive "foo.tar.lrz" from a directory named "foo".<br />
$ lrztar foo<br />
<br />
This will produce an lzma compressed archive "bar.lrz" from a file named "bar"<br />
$ lrzip bar<br />
<br />
For extreme compression, add the -z switch which enables [[Wikipedia:ZPAQ|ZPAQ]] but takes notably longer than lzma.<br />
$ lrztar -z foo<br />
<br />
For extremely fast compression and decompression, use the -l switch for [[Wikipedia:LZO|LZO]].<br />
$ lrzip -l bar<br />
<br />
===Decompression===<br />
<br />
To completely extract an archived directory.<br />
$ lrzuntar foo.tar.lrz<br />
<br />
To decompress "bar.lrz to "bar".<br />
$ lrunzip bar.lrz<br />
<br />
== Details ==<br />
Lrzip uses an extended version of [[Wikipedia:Rzip|rzip]] which does a first pass long distance redundancy reduction. The lrzip modifications make it scale according to memory size. The data is then either: <br />
<br />
# Compressed by lzma (default) which gives excellent compression at approximately twice the speed of bzip2 compression <br />
# Compressed by a number of other compressors chosen for different reasons, in order of likelihood of usefulness: <br />
## ZPAQ: Extreme compression up to 20% smaller than lzma but ultra slow at compression AND decompression.<br />
## LZO: Extremely fast compression and decompression which on most machines compresses faster than disk writing making it as fast (or even faster) than simply copying a large file.<br />
## GZIP: Almost as fast as LZO but with better compression. <br />
## BZIP2: A defacto linux standard of sorts but is the middle ground between lzma and gzip and neither here nor there.<br />
# Leaving it uncompressed and rzip prepared. This form improves substantially any compression performed on the resulting file in both size and speed (due to the nature of rzip preparation merging similar compressible blocks of data and creating a smaller file). By "improving" I mean it will either speed up the very slow compressors with minor detriment to compression, or greatly increase the compression of simple compression algorithms.<br />
<br />
The major disadvantages are:<br />
#The main lrzip application only works on single files so it requires the lrztar wrapper to fake a complete archiver. <br />
#It requires a lot of memory to get the best performance out of (as much memory as the size of the data to compress; but see the sliding mmap below), and is not really usable (for compression) with less than 256MB. Decompression requires less ram and works on smaller ram machines. Sometimes swap may need to be enabled on these lower ram machines for the operating system to be happy.<br />
# STDIN/STDOUT works fine on both compression and decompression, but larger files compressed in this manner will end up being less efficiently compressed.<br />
<br />
The unique feature of lrzip is that it tries to make the most of the available ram in your system at all times for maximum benefit. It does this by default, choosing the largest sized window possible without running out of memory. It also has a unique "sliding mmap" feature which makes it possible to even use a compression window larger than your ramsize, if the file is that large. It does this (with the -U option) by implementing one large mmap buffer as per normal, and a smaller moving buffer to track which part of the file is currently being examined, emulating a much larger single mmapped buffer. Unfortunately this mode can be many times slower.<br />
<br />
== Benchmarks ==<br />
<br />
See the [http://ck.kolivas.org/apps/lrzip/README.benchmarks README.benchmarks] included in the source/docs.<br />
<br />
== FAQ ==<br />
<br />
See the [http://ck.kolivas.org/apps/lrzip/README README] included with the source package.</div>Nemo bishttps://wiki.archlinux.org/index.php?title=Help_talk:I18n&diff=279286Help talk:I18n2013-10-21T12:51:59Z<p>Nemo bis: /* Finnish external wiki */ archived</p>
<hr />
<div>{{Box BLUE|1=Regarding ArchWiki internationalization:|2=''There have been a number of discussions about this over the years: [https://bbs.archlinux.org/viewtopic.php?id=27039 2006], [https://bbs.archlinux.org/viewtopic.php?id=37513 2007], [https://bbs.archlinux.org/viewtopic.php?pid=675478 2009], and [https://bbs.archlinux.org/viewtopic.php?id=95360 2010]. In short, there are a number of potential solutions; none are perfect. Currently, the interwiki implementation is considered "best" because it provides non-English users with a fully-localized experience and isolates each language. Other "good" solutions include the creation of language-specific [http://www.mediawiki.org/wiki/Help:Namespaces namespaces] or migration to a different wiki which provides "better" internationalization options -- but require more effort to implement.'' -- [[User:Pointone|pointone]] 16:07, 21 October 2011 (EDT)<br />
<br> ''See also [[#Language namespace(s) in place of suffixes?]] for a more recent discussion.'' -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:06, 3 June 2012 (UTC)}}<br />
<br />
==<s>Serbian</s>==<br />
<br />
Clarification needed: there are currently articles tagged with Srpski (Serbian Latin) and others with Српски (Serbian Cyrillic). Are there objections to tagging Srpski articles with Српски instead? (For example: ''Main Page (Srpski)'' to [[Main Page (Српски)]]) Would this be confusing?<br />
<br />
It is my understanding that most Serbians are literate in both scripts, and Cyrillic is considered the "official" script.<br />
<br />
-- [[User:Pointone|pointone]] 16:11, 17 January 2010 (EST)<br />
<br />
:''Main Page (Srpski)'' is currently [https://wiki.archlinux.org/index.php?title=Special%3ASearch&profile=advanced&search=Srpski&fulltext=Search&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&redirs=1&profile=advanced the only] page/redirect with the Serbian Latin suffix; the problem is that now [[Main Page (Српски)]] exists too... -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:06, 26 September 2012 (UTC)<br />
<br />
::Fixed, ''Main Page (Srpski)'' is now [[Main Page/Latin (Српски)]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:12, 7 June 2013 (UTC)<br />
<br />
== MediaWiki translation extension ==<br />
Speaking of multi language support for MediaWiki. It does have an extension to support translation. See: http://translatewiki.net/wiki/Main_Page. Here is forum proposal [https://bbs.archlinux.org/viewtopic.php?id=128610] and bug {{bug|26638}}. As a user of KDE userbase and techbase, I think this extension is exactly what Arch wiki need. But again, lack of man power to do it.<br />
:Exactly, time's not ripe for talking about this. Please for now let's use the suffix method as consistently as possible: if one day another method will be enforced, it will be much easier to handle at least some parts of the transition automatically with bots or other scripts. -- [[User:Kynikos|Kynikos]] 06:01, 30 March 2012 (EDT)<br />
<br />
==Language namespace(s) in place of suffixes?==<br />
This discussion is about the possibility of replacing the current system of classification of the articles by language, using suffixes in the title, with a namespace-based system. <s>This issue has currently a '''lower''' priority than [[#"Dummy" interlanguage links and deprecation of Template:i18n]].</s><br />
<br />
The main advantage would be that it would be possible to have only English articles as results when using the search engine, and, depending on the implementation of this idea, it may be possible also to select the language of the search.<br />
<br />
Another advantage would be that in article-list pages (such as those in [[Special:SpecialPages]]) that list articles alphabetically, all the articles for a language would be grouped together.<br />
<br />
There are many ways we can implement this solution, and each has its advantages and disadvantages; I'd like to also keep the current suffix solution in the discussion, for comparison and also because it has its advantages too.<br />
<br />
1) <u>Every language has its own namespace</u><br />
*This can be done either with '''local''' or '''English''' language names. '''Note''' that it's not possible to have namespaces named like interlanguage links! <s>For example an article named [[:Ru:Some Title]] could currently be created, but once the ru interlanguage links are activated, that article won't be accessible anymore, and it will be possible to edit/delete it only via the API using its ID (this has already happened with an article that was named with "tr:...").</s><br />
*This solution would create 2*N namespaces (where N is the number of languages) because every namespace must have a _talk namespace; I don't know what effect this would have on select menus and other interfaces that list the namespaces (e.g. in special pages filters).<br />
*Examples:<br />
:[[Dansk:Some Article]], [[Dansk talk:Some Article]], [[Magyar:Some Article]], ...<br />
:[[Danish:Some Article]], [[Danish talk:Some Article]], [[Hungarian:Some Article]], ...<br />
<br />
2) <u>There's one big namespace for non-English languages</u><br />
*There are various possible choices for the name of the namespace: "Lang", "Local", "i18n", ???...<br />
*The language can be separated from the title with a colon, a slash or some other punctuation mark<br />
*We could use language tags or full language names<br />
*Language names could still be suffixes or be part of the prefix<br />
*This solution just adds 1 namespace and its associated talk<br />
*Examples:<br />
:[[Lang:pl/Some Article]], [[Lang talk:pl/Some Article]], [[Lang:zh-CN/Some Article]], ...<br />
:[[Local:Some Article (Polski)]], [[Local talk:Some Article (Polski)]], [[Local:Some Article (简体中文)]], ...<br />
<br />
3) <u>Some languages can have a proper namespace according to some objective rules based on the number of translations</u><br />
*This is a hybrid solution (1-2)<br />
*The rules could also require the translation of some important articles, see also http://meta.wikimedia.org/wiki/List_of_articles_every_Wikipedia_should_have<br />
<br />
<br />
Note that the namespace solution wouldn't be able to separate the languages completely, in fact we'd have to keep mixed Template and Category namespaces: how would we deal with those cases? Case 2) may have the simplest solution by using [[Template:es/Lorem Ipsum]] and [[:Category:es/Lorem Ipsum]] or something like that, and we'd still have the advantage of having templates and categories grouped by language in alphabetical lists. About the Help and ArchWiki namespaces we could do something similar.<br />
<br />
Note that solution 2) would break the use of [[Template:Lowercase title]] in non-English articles. The only way to solve that problem would be using an extension that can parse substrings, or force using <nowiki>{{DISPLAYTITLE:...}}</nowiki>.<br />
<br />
The bot algorithm to implement such a change should avoid creating redirects for every title, and instead it should update all the backlinks of every article (Wiki Monkey should be able to do that, it has already done a similar thing when removing the English suffix from category names, although in this case it would be a much bigger job).<br />
<br />
References:<br />
*http://meta.wikimedia.org/wiki/Help:Namespace<br />
*http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces<br />
**http://www.mediawiki.org/wiki/Manual:$wgContentNamespaces<br />
*http://www.mediawiki.org/wiki/Project:Language_policy<br />
*http://wiki.openstreetmap.org/wiki/Wiki_Translation seems to be using namespaces (though with kind of an i18n template and note it doesn't use interlanguage inks)<br />
<br />
I think this can be enough for now, as you can see it's quite intricate, I don't even have a clear idea about what's my preference at the moment, let's see if somebody can help sort out the ideas.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 20:48, 2 June 2012 (UTC)<br />
<br />
:I like (2) -- a single non-English namespace. I had never even considered this option before! This will solve the biggest problem with our current implementation -- non-English articles polluting search results and other special pages -- whilst still promoting external wikis with interlanguage links as the "ideal" solution. <br />
:(We must keep in mind that, in the end, separate external wikis is the only ''complete'' solution to provide non-English readers with a fully-internationalized interface (as long as we are running MediaWiki, that is). Everything else at this point is simply a stepping-stone toward that goal.)<br />
:Creating separate namespaces for each language would quickly complicate maintenance, as you note, and add little benefit over the single-namespace solution. -- [[User:Pointone|pointone]] ([[User talk:Pointone|talk]]) 14:27, 3 June 2012 (UTC)<br />
<br />
::Yeah I too tend to prefer solution (2), especially in the form of [[Lang:pt/Lorem Ipsum]] because that would group articles by language in alphabetical lists.<br />
::I'd use [[Template:pt/Lorem Ipsum]] and [[:Category:pt/Lorem Ipsum]], but [[Lang:pt/Help:Lorem Ipsum]] and [[:Lang:pt/ArchWiki:Lorem Ipsum]] for special namespaces.<br />
::The bot should be able to convert <nowiki>{{Lowercase title}}</nowiki> to <nowiki>{{DISPLAYTITLE:...}}</nowiki> in existing articles, but when a user copies an English article for translating it, he should remember to do that conversion by himself. Alternatives can be abolishing Template:Lowercase_title or using parser functions to detect the actual title (without the prefix).<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:16, 3 June 2012 (UTC)<br />
::Note that the format [[Lang:es/Title]] wouldn't be possible, only [[Lang:Es/Title]] or [[Lang:ES/Title]] would. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:42, 23 September 2012 (UTC)<br />
::Alternative formats (better isolate the title from the prefix, for readability when displayed in the h1 at the top of the page, especially with short titles): [[Lang:UK / KDE]], [[Lang:UK KDE]], [[Lang:UK - KDE]], [[Lang:UK ~ KDE]], [[Lang:(uk) KDE]] (parentheses should allow lowercase tags, note that square brackets would require html entities to be used in links), [[Lang:Українська KDE]], [[Lang:Українська - KDE]]... -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:11, 27 September 2012 (UTC)<br />
::Some considerations about restricting searches to a particular language:<br />
::*both solutions (1) and (2) would give English-only results by default;<br />
::*solution (1) would allow to select the right language namespace in the advanced search interface;<br />
::*solution (2) would require to add the name of the language to the search keywords (this is how it's already working), but only if the full language names are retained in the titles (i.e. they aren't replaced by language tags like in [[Title (Español)]] -> [[Lang:ES/Title]])<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:08, 16 January 2013 (UTC)<br />
<br />
:Moving here the considerations about interlanguage links and Templates/Categories (interlanguage links cannot be used directly with Templates and Categories if language namespaces are implemented):<br />
:*Use special i18n templates for Categories and Templates<br />
:*Create a redirect for each category and template: for example [[Lang:it/Category:Laptops]] redirects to [[:Category:it/Laptops]] which would make it possible to use an interlanguage link like [[:it:Category:Laptops]] from e.g. [[:Category:Laptops]]<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 19:36, 15 June 2012 (UTC)<br />
<br />
== Finnish external wiki ==<br />
<br />
Is Finnish external wiki still accessable. I can not access it here. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 14:20, 4 June 2013 (UTC)<br />
<br />
:Can't access it from here either :( Let's wait a bit and hope it comes back. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:39, 4 June 2013 (UTC)<br />
<br />
::It's online now, but it seems almost empty? I archived it at [https://archive.org/details/wiki-archlinuxfi_w] to be on the safe side. [[User:Nemo bis|Nemo bis]] ([[User talk:Nemo bis|talk]]) 12:51, 21 October 2013 (UTC)</div>Nemo bishttps://wiki.archlinux.org/index.php?title=Talk:Lrzip&diff=279280Talk:Lrzip2013-10-21T12:37:39Z<p>Nemo bis: blank talk is ugly</p>
<hr />
<div>[https://wiki.archlinux.org/index.php?title=Talk:Lrzip&oldid=201496 Archive 1]</div>Nemo bishttps://wiki.archlinux.org/index.php?title=Lrzip&diff=279279Lrzip2013-10-21T12:34:20Z<p>Nemo bis: /* Details */ easily 1 GB, with a 1 GB directory</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data compression and archiving]]<br />
[http://lrzip.kolivas.org/ Long Range ZIP] or Lzma RZIP is a compression program optimised for large files. The larger the file and the more memory you have, the better the compression advantage this will provide, especially once the files are larger than 100MB. The advantage can be chosen to be either size (much smaller than bzip2) or speed (much faster than bzip2).<br />
<br />
==Installing Lrzip==<br />
<br />
[[pacman|Install]] {{Pkg|lrzip}}, available in the [[Official Repositories]].<br />
<br />
==Usage==<br />
===Compression===<br />
Compression of directories (recursive) requires lrztar which first tars the directory, then compresses the single file just like tar does when users compress with gzip or xz (tar zcf ... and tar Jcz ... respectfully).<br />
<br />
This will produce an [[Wikipedia:LZMA|LZMA]] compressed archive "foo.tar.lrz" from a directory named "foo".<br />
$ lrztar foo<br />
<br />
This will produce an lzma compressed archive "bar.lrz" from a file named "bar"<br />
$ lrzip bar<br />
<br />
For extreme compression, add the -z switch which enables [[Wikipedia:ZPAQ|ZPAQ]] but takes notably longer than lzma.<br />
$ lrztar -z foo<br />
<br />
For extremely fast compression and decompression, use the -l switch for [[Wikipedia:LZO|LZO]].<br />
$ lrzip -l bar<br />
<br />
===Decompression===<br />
<br />
To completely extract an archived directory.<br />
$ lrzuntar foo.tar.lrz<br />
<br />
To decompress "bar.lrz to "bar".<br />
$ lrunzip bar.lrz<br />
<br />
== Details ==<br />
Lrzip uses an extended version of [[Wikipedia:Rzip|rzip]] which does a first pass long distance redundancy reduction. The lrzip modifications make it scale according to memory size. The data is then either: <br />
<br />
# Compressed by lzma (default) which gives excellent compression at approximately twice the speed of bzip2 compression <br />
# Compressed by a number of other compressors chosen for different reasons, in order of likelihood of usefulness: <br />
## ZPAQ: Extreme compression up to 20% smaller than lzma but ultra slow at compression AND decompression.<br />
## LZO: Extremely fast compression and decompression which on most machines compresses faster than disk writing making it as fast (or even faster) than simply copying a large file.<br />
## GZIP: Almost as fast as LZO but with better compression. <br />
## BZIP2: A defacto linux standard of sorts but is the middle ground between lzma and gzip and neither here nor there.<br />
# Leaving it uncompressed and rzip prepared. This form improves substantially any compression performed on the resulting file in both size and speed (due to the nature of rzip preparation merging similar compressible blocks of data and creating a smaller file). By "improving" I mean it will either speed up the very slow compressors with minor detriment to compression, or greatly increase the compression of simple compression algorithms.<br />
<br />
The major disadvantages are:<br />
#The main lrzip application only works on single files so it requires the lrztar wrapper to fake a complete archiver. <br />
#It requires a lot of memory to get the best performance out of (easily 1 GB RAM, with 1 GB data), and is not really usable (for compression) with less than 256MB. Decompression requires less ram and works on smaller ram machines. Sometimes swap may need to be enabled on these lower ram machines for the operating system to be happy.<br />
# STDIN/STDOUT works fine on both compression and decompression, but larger files compressed in this manner will end up being less efficiently compressed.<br />
<br />
The unique feature of lrzip is that it tries to make the most of the available ram in your system at all times for maximum benefit. It does this by default, choosing the largest sized window possible without running out of memory. It also has a unique "sliding mmap" feature which makes it possible to even use a compression window larger than your ramsize, if the file is that large. It does this (with the -U option) by implementing one large mmap buffer as per normal, and a smaller moving buffer to track which part of the file is currently being examined, emulating a much larger single mmapped buffer. Unfortunately this mode can be many times slower.<br />
<br />
== Benchmarks ==<br />
<br />
See the [http://ck.kolivas.org/apps/lrzip/README.benchmarks README.benchmarks] included in the source/docs.<br />
<br />
== FAQ ==<br />
<br />
See the [http://ck.kolivas.org/apps/lrzip/README README] included with the source package.</div>Nemo bis