Re:Why you should always use gzip instead of deflate compres...
by pmjordan on Monday March 26, 2012 @06:20AM
(#3755947)
Even where the GPL is fine, LZO consists of some pretty scary code. Though at this point, I think probably enough people smarter than me have understood it and deemed it safe (it's part of the Linux kernel).
Snappy is fine as long as you can use compile C++ and link against the C++ standard library as it uses std::string for byte buffers for some strange reason. I can only assume it's mainly used for compressing strings at Google, but unless someone ports it to C or at least rips out the standard library dependency, that will preclude its use from some embedded systems, or the Linux kernel.
As a substitute for LZO or Snappy, I recently integrated the BSD-licensed LZ4 [1] into a project where no C++ standard library was available. Dependencies are minimal, memory use is predictable and the code is actually readable. Speed and ratios are comparable to LZO and Snappy.
Snappy is fine as long as you can use compile C++ and link against the C++ standard library as it uses std::string for byte buffers for some strange reason. I can only assume it's mainly used for compressing strings at Google, but unless someone ports it to C or at least rips out the standard library dependency, that will preclude its use from some embedded systems, or the Linux kernel.
As a substitute for LZO or Snappy, I recently integrated the BSD-licensed LZ4 [1] into a project where no C++ standard library was available. Dependencies are minimal, memory use is predictable and the code is actually readable. Speed and ratios are comparable to LZO and Snappy.
[1] http://code.google.com/p/lz4/