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? :)
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
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
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 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 with -mx=9 it
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
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 all so
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. I
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
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
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
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.
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
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
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
>
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
38064
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
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 everything.
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.
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 majordomo
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
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
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..
[
24 matches
Mail list logo
