On Tuesday 16 October 2007 14:31, Andreas Schwab wrote:
> Denys Vlasenko <[EMAIL PROTECTED]> writes:
>
> > I'm with Al on this. 50 Mb for decompression?
> > Embedded and small device folks will not love this, I'm sure.
>
> How often do you unpack the kernel sources on an embedded device? :)
Oops
On Oct 16 2007 14:19, Denys Vlasenko wrote:
>Sizes in Kb again:
>
>32392 linux-2.6.16.17.tar.7z
>33520 linux-2.6.16.17.tar.lzma
>
>P.S. sorting files by extension in tarball generally helps, but in case
>of Linux kernel, they are all C code anyway, so no measurable gain there.
Extension is not al
Denys Vlasenko <[EMAIL PROTECTED]> writes:
> I'm with Al on this. 50 Mb for decompression?
> Embedded and small device folks will not love this, I'm sure.
How often do you unpack the kernel sources on an embedded device? :)
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Pr
On Sunday 14 October 2007 21:58, Justin Piszcz wrote:
>
> On Sun, 14 Oct 2007, Al Viro wrote:
>
> > On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:
> >> (Obviously we shall pick .7z)
> >
> > The hell it is. Take a look at memory footprint of those suckers...
>
> For compression
On Sun, 14 Oct 2007, Jan Engelhardt wrote:
On Oct 14 2007 16:58, Justin Piszcz wrote:
compress:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
10544 war 20 0 700m 681m 1632 S 141 20.7 1:41.46 7z
Just how you can utilize a CPU to 141% remains a mystery..
[
On Oct 14 2007 16:58, Justin Piszcz wrote:
>
> compress:
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 10544 war 20 0 700m 681m 1632 S 141 20.7 1:41.46 7z
Just how you can utilize a CPU to 141% remains a mystery..
[ to be noted this is sqrt(2)*100 ]
-
To unsu
On Sun, 14 Oct 2007, Al Viro wrote:
On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:
(Obviously we shall pick .7z)
The hell it is. Take a look at memory footprint of those suckers...
For compression with -mx=9 it does use 500-900 MiB of RAM, that is true.
For decompressio
On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:
> (Obviously we shall pick .7z)
The hell it is. Take a look at memory footprint of those suckers...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Sun, 14 Oct 2007, Jan Engelhardt wrote:
On Oct 14 2007 15:53, Justin Piszcz wrote:
What's with all these odd formats, and where is .zip? :)
Somehow... have you tried lrzip?
$ apt-cache search lrzip
$
I tried most of the main ones in the standard testing distribution within
Debian.
De
On Oct 14 2007 15:53, Justin Piszcz wrote:
>>
>> What's with all these odd formats, and where is .zip? :)
>> Somehow... have you tried lrzip?
> $ apt-cache search lrzip
> $
>
> I tried most of the main ones in the standard testing distribution within
> Debian.
Debian is not a solution to everythi
On Sun, 14 Oct 2007, Jan Engelhardt wrote:
On Oct 14 2007 15:34, Justin Piszcz wrote:
It turns out the one I did not test, was actually the best:
Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar
$ du -sk * | sort -n
32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma
33
On Oct 14 2007 15:34, Justin Piszcz wrote:
>
> It turns out the one I did not test, was actually the best:
>
> Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar
>
> $ du -sk * | sort -n
> 32392 linux-2.6.16.17.tar.7z
> 33520 linux-2.6.16.17.tar.lzma
> 33760 linux-2.6.16.17.tar.rar
> 3806
12 matches
Mail list logo
