In message: <20100304102158.ga8...@nobby.geeknest.org>
Ulf Lilleengen writes:
: On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
: > Hi,
: > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
in connection with this is an issue best left lzma
On Thu, Mar 04, 2010 at 04:38:31PM +0200, Alexandr Rybalko wrote:
> On Thu, 4 Mar 2010 15:28:19 +0100
> Joerg Sonnenberger wrote:
>
> >> On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote:
> >> > LZMA compression optimized for fast decompression.
> >>
> >> It is still measurable sl
On Thu, Mar 04, 2010 at 03:54:05PM +0100, Dimitry Andric wrote:
> On 2010-03-04 15:28, Joerg Sonnenberger wrote:
> >It is still measurable slower than gzip and it is certainly not free.
>
> Ehm, the LZMA SDK is in the public domain, how much more "free" would
> you want it?
Free as in "time it ta
On 2010-03-04 15:28, Joerg Sonnenberger wrote:
It is still measurable slower than gzip and it is certainly not free.
Ehm, the LZMA SDK is in the public domain, how much more "free" would
you want it?
___
freebsd-hackers@freebsd.org mailing list
http:/
On Thu, 4 Mar 2010 15:28:19 +0100
Joerg Sonnenberger wrote:
>> On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote:
>> > LZMA compression optimized for fast decompression.
>>
>> It is still measurable slower than gzip and it is certainly not free.
>> Most hard disks have linear read
On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote:
> LZMA compression optimized for fast decompression.
It is still measurable slower than gzip and it is certainly not free.
Most hard disks have linear read times >> 10 MB/s but the decompression
can easily need half a second even on
On Thu, 4 Mar 2010 11:21:59 +0100
Ulf Lilleengen wrote:
>> On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
>> > Hi,
>> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with
>> > lzma), in connection with this is an issue best left
>> > lzma code in the file "ge
On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
> Hi,
> I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
> in connection with this is an issue best left lzma
> code in the file "geom_ulzma.c" or store lzma library separately. If
> separately, then wher
On Thu, 4 Mar 2010 17:31:18 +0800
Adrian Chadd wrote:
>> On 4 March 2010 00:29, Tim Kientzle wrote:
>>
>> > Interesting question: What is the impact on boot speed?
>> > It could be a lot faster to load 5MB from disk and
>> > decompress to a 24MB image than to wait for 24MB from
>> > disk.
>>
On 4 March 2010 00:29, Tim Kientzle wrote:
> Interesting question: What is the impact on boot speed?
> It could be a lot faster to load 5MB from disk and
> decompress to a 24MB image than to wait for 24MB from
> disk.
Linear reads from disk are fast. :) Linear reads from the SPI flash
are slowe
On Wed, 3 Mar 2010 16:01:59 +0800
Adrian Chadd wrote:
>> On 21 February 2010 02:20, Adrian Chadd wrote:
>> > Oh I know that! I'm just saying that I may try lzma'ing the kernel and
>> > rootfs's to see what kind of savings I get over gzip. :)
>>
>> The answer is "whoa". 24 megabyte compressed ke
On Wed, 3 Mar 2010 07:35:55 +0100
Pawel Jakub Dawidek wrote:
>> On Tue, Mar 02, 2010 at 08:32:20PM +0100, Dimitry Andric wrote:
>> > On 2010-03-02 09:47, Alexandr Rybalko wrote:
>> > >>>Definiatelly separately, not sure where. There is ongoing discussion
>> > >>>somwhere on importing this algorit
On Wed, Mar 03, 2010 at 08:29:14AM -0800, Tim Kientzle wrote:
> Adrian Chadd wrote:
> >On 21 February 2010 02:20, Adrian Chadd wrote:
> >>Oh I know that! I'm just saying that I may try lzma'ing the kernel and
> >>rootfs's to see what kind of savings I get over gzip. :)
> >
> >The answer is "whoa".
Adrian Chadd wrote:
On 21 February 2010 02:20, Adrian Chadd wrote:
Oh I know that! I'm just saying that I may try lzma'ing the kernel and
rootfs's to see what kind of savings I get over gzip. :)
The answer is "whoa". 24 megabyte compressed kernel + MDROOT drops to
6.5 megabytes with gzip -9 a
On 21 February 2010 02:20, Adrian Chadd wrote:
> Oh I know that! I'm just saying that I may try lzma'ing the kernel and
> rootfs's to see what kind of savings I get over gzip. :)
The answer is "whoa". 24 megabyte compressed kernel + MDROOT drops to
6.5 megabytes with gzip -9 and a few bytes shy o
On Tue, Mar 02, 2010 at 08:32:20PM +0100, Dimitry Andric wrote:
> On 2010-03-02 09:47, Alexandr Rybalko wrote:
> >>>Definiatelly separately, not sure where. There is ongoing discussion
> >>>somwhere on importing this algorithm to the base for tar(1) to use, it
> >>>would be best to have only one co
On Tue, 02 Mar 2010 20:32:20 +0100
Dimitry Andric wrote:
> On 2010-03-02 09:47, Alexandr Rybalko wrote:
> >>> Definiatelly separately, not sure where. There is ongoing discussion
> >>> somwhere on importing this algorithm to the base for tar(1) to use, it
> >>> would be best to have only one copy
On 2010-03-02 09:47, Alexandr Rybalko wrote:
Definiatelly separately, not sure where. There is ongoing discussion
somwhere on importing this algorithm to the base for tar(1) to use, it
would be best to have only one copy of code in the tree.
I have already said, that it would be good for embedde
Hi,
On Tue, 2 Mar 2010 08:17:36 +0100
Pawel Jakub Dawidek wrote:
>> On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
>> > Hi,
>> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with
>> > lzma), [...]
>>
>> Wouldn't it be better to modify geom_uzip to be unive
On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
> Hi,
> I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
> [...]
Wouldn't it be better to modify geom_uzip to be universal decompression
class with various algorithms implemented as plugins?
This is basci
I see no reason to not import the current
version [of liblzma and xz] into the FreeBSD base system. I plan
to do so but may not get to it very soon; I
certainly would not complain if someone else
beat me to it. ;-)
Thanks for that info.
GEOM_ULZMA contain two parts mkulzma and GEOM module.
lib
On Sat, 20 Feb 2010 21:43:03 -0800
Tim Kientzle wrote:
> b. f. wrote:
> >>> The code organization depends on what you want to do with it and how you
> >>> want to update the code in the future, if your lzma library is third
> >>> party.
> >> LZMA made by Igor Pavlov, and since 4.62 it licensed u
>> The code organization depends on what you want to do with it and how you
>> want to update the code in the future, if your lzma library is third party.
>
>LZMA made by Igor Pavlov, and since 4.62 it licensed under Public Domain.
>So we can use it, if we need.
>
>>
>> If you never intend to updat
b. f. wrote:
The code organization depends on what you want to do with it and how you
want to update the code in the future, if your lzma library is third party.
LZMA made by Igor Pavlov, and since 4.62 it licensed under Public Domain.
So we can use it, if we need.
If you never intend to updat
Oh I know that! I'm just saying that I may try lzma'ing the kernel and
rootfs's to see what kind of savings I get over gzip. :)
Adrian
On 21 February 2010 02:15, Alex RAY wrote:
> Hi,
>
> On Sat, 20 Feb 2010 22:36:02 +0800
> Adrian Chadd wrote:
>
>> On 20 February 2010 04:26, Alex RAY wrote:
Hi,
On Sat, 20 Feb 2010 22:36:02 +0800
Adrian Chadd wrote:
> On 20 February 2010 04:26, Alex RAY wrote:
>
> > :) No, I don`t think about "magically faster", now I near to release
> > FreeBSD firmware for D-Link DIR-320 router which have only 4MB of flash
> > memory. Maybe in next time I try
On 20 February 2010 04:26, Alex RAY wrote:
> :) No, I don`t think about "magically faster", now I near to release FreeBSD
> firmware for D-Link DIR-320 router which have only 4MB of flash memory. Maybe
> in next time I try to make it for some router with only 2MB of flash. In that
> way,
> I n
On Fri, 19 Feb 2010 16:36:40 +0100
Ivan Voras wrote:
> On 02/19/10 15:36, Alexandr Rybalko wrote:
> > Hi,
> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
> > in connection with this is an issue best left lzma
>
> One of the (relatively) unexpected problems with s
On 02/19/10 15:36, Alexandr Rybalko wrote:
Hi,
I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), in
connection with this is an issue best left lzma
One of the (relatively) unexpected problems with such block-level
compression is its efficienty - since you need to com
29 matches
Mail list logo
