Re: Faster compression, again

Well, the patent argument, used like this, looks like a wild card, which
can be freely interpreted as a mortal danger for some, and a non-issue for
others. A perfect scare-mongerer.
Quite frankly, I don't buy that one implementation is safer because there
is "Google backing it". I can't think of any reason why byte-aligned LZ77
algorithm could face any risk. And btw, just look at the number of
companies which had to pay protection money to Microsoft or face litigation
with Apple because they were using Google's Android. It looks to me that
Google is more a magnet for such dangers than a protector.

Regarding test tools : Yes, this is correct, Snappy C has more fuzzer tools
provided within the package.

Regarding integration to BTRFS, and therefore into Linux, both
implementation look on equal terms. I haven't seen anything which tells
that one has more chances than the other being part of Linux 3.5. In fact,
maybe both will be integrated at the same time.

However, a little publicized fact is that quite a few people tried both
implementation (Snappy C and LZ4), and there were more
failures/difficulties reported on Snappy C. It doesn't mean that Snappy C
is bad, just more complex to use. It seems that the LZ4 implementation is
more straightforward : less dependancies, less risks, less time spent to
properly optimize it,
well, in a word, simpler.

Le 5 avril 2012 01:11, Daniel Farina-4 [via PostgreSQL] <
ml-node+s1045698n5619199h50(at)n5(dot)nabble(dot)com> a écrit :

> On Tue, Apr 3, 2012 at 7:29 AM, Huchev <[hidden email]<http://user/SendEmail.jtp?type=node&node=5619199&i=0>>
> wrote:
> > For a C implementation, it could interesting to consider LZ4 algorithm,
> since
> > it is written natively in this language. In contrast, Snappy has been
> ported
> > to C by Andy from the original C++ Google code, which lso translate into
> > less extensive usage and tests.
>
> From what I can tell, the C implementation of snappy has more tests
> than this LZ4 implementation, including a fuzz tester. It's a
> maintained part of Linux as well, and used for btrfs --- this is why
> it was ported. The high compression version of LZ4 is apparently
> LGPL. And, finally, there is the issue of patents: snappy has several
> multi-billion dollar companies that can be held liable (originator
> Google, as well as anyone connected to Linux), and to the best of my
> knowledge, nobody has been held to extortion yet.
>
> Consider me unconvinced as to this line of argument.
>
> --
> fdr
>
> --
> Sent via pgsql-hackers mailing list ([hidden email]<http://user/SendEmail.jtp?type=node&node=5619199&i=1>)
>
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://postgresql.1045698.n5.nabble.com/Faster-compression-again-tp5565675p5619199.html
> To unsubscribe from Faster compression, again, click here<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5565675&code=aHVnb2NoZXZyYWluQGdtYWlsLmNvbXw1NTY1Njc1fDc3NzM5MzkwMA==>
> .
> NAML<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Faster-compression-again-tp5565675p5619870.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.