This one time, at band camp, Philipp Kern said: > On Sat, Aug 31, 2013 at 04:12:11PM +0000, Luca Filipozzi wrote: > > I'm curious why there's no apparent appetite for hdfs / solr / etc. > > I don't know how far regex matching is with solr these days. This > implementation is AFAIK based on [1]. But then the tool exists and > would need to be thrown away completely for no obvious gain. How would > you store the solr index? How would lookups be faster than a custom > built index where it's basically known how many seeks you need per > request? > > It's akin asking you to port everything to Chef just for the sake of > it, except that the target language would actually be Java, which > likely consumes even more resources than the Go binary. That's looking at it upside down, I think. chef was the new shiny after we'd already started down the puppet road. Michael's implementation did not, in fact, exist before solr. luca is not asking, "why aren't you using the new shiny", he's asking, "why hasn't a proposal for a project that does string searching used one of the already available, off the shelf string searching programs". Asking someone why they didn't choose off the shelf tools to do a job that is largely a solved problem is a reasonable thing to do, especially when being asked to support new, custom code that is certain to come with its own quirks, bugs, and security issues. I think the answer here is, "more code could be reused by borrowing work from google" - the NIH syndrome appears to be google's, rather than Michael's, if I understand correctly. That's probably a fine answer, but the question also needed to be asked. Cheers, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature