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+s1045698n5619199...@n5.nabble.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.
