On Dec 12, 11:50 pm, Tony Tung wrote:
>
> 1. On May 16, 2008, I sent an email to Dustin and Dormando, having gotten
> the impression that they were the de-facto maintainers of memcached, asking
> how we could merge our changes back into the mainline of development. We
> even offered to hos
As some of you may have noticed we've put facebook's version of
memcached up on github
http://github.com/fbmarc/facebook-memcached
We've done this for a couple of reasons.
First, as far as we know, we run the largest installation of memcached
in the world. We think this is true in terms of ops
Top Secret Fat Loss Secret ,burn The Fat Feed the Muscle
http://www.dispaying.com/fitness-c-21.html
Six kinds of Unofficial Phone Review
http://www.unofficialphone.cn
Only significant + GPS + WIFI-qi i9 smartphone evaluation
http://www.unofficialphone.cn/2008/12/only-significant-gps-wifi-qi-i9.html
Dual Screen + diamond shape up and down "LG K880" super-game Jiong
http://www.unofficialphone.
Branch friction aside, Paul Saab's description of the interesting
problems is really something worth expanding upon and learning from in
context of a real-world implementation going after C10K scalability.
For example, Paul notes that with thousands of open TCP connections,
memcached can start us
On Fri, Dec 5, 2008 at 10:10 PM, Dustin wrote:
>
>
>
> On Dec 5, 8:21 pm, ionous wrote:
>> i poked around on the faq and mail lists, but haven't seen anything
>> definitive;
>> does anyone know whether there is a guaranteed order to the items
>> returned in get_multi?
>
> You may observe some p
+2. Optimism is a welcome change to this discussion, though the proposed
merge-athon is good to hear, as well.
On Sat, Dec 13, 2008 at 12:45 PM, Aaron Stone wrote:
>
> Branch friction aside, Paul Saab's description of the interesting
> problems is really something worth expanding upon and learni
On Sat, Dec 13, 2008 at 12:45:58PM -0800, Aaron Stone wrote:
> For example, Paul notes that with thousands of open TCP connections,
> memcached can start using several extra gigabytes of memory for
> buffers. Well, that's interesting! I want to know more about that.
> What can we learn here?
And
And even if it was GPL licensed
1) They aren't distributing their version of memcached, so there is no
requirement for them to be sharing anything
2) And, even if they were distributing their work, they aren't
required to merge their patches anywhere, just publish them. Go look
at sony's website
Hey,
> Finally, I produced these branches by running git-svn and git-filter-
> branch against our internal SVN repositories. The addition of the
> root "src" directory and the lack of a clear branch from 1.2.3 make
> comparison with existing branches unnecessarily difficult. I
> apologize for t
I didn't mean anything negative by my post. Please don't take offense.
It was more about confirming the license details in my own head.
On Dec 13, 2008, at 2:53 PM, Todd Berman wrote:
And even if it was GPL licensed
1) They aren't distributing their version of memcached, so there is no
r
11 matches
Mail list logo
