[tor-relays] Metrics for assessing EFF's Tor relay challenge?
kostas at jakeliunas.com
Wed Apr 9 01:34:33 UTC 2014
On Wed, Apr 9, 2014 at 4:18 AM, Kostas Jakeliunas <kostas at jakeliunas.com>wrote:
> On Wed, Apr 9, 2014 at 4:06 AM, Lukas Erlacher <tor at lerlacher.de> wrote:
>> Hi Kostas,
>> right now, we're coding challenger against what exists in debian wheezy,
>> which means version 0.1.2 of the requests lib using the python-requests
>> package you mentioned, where response.json is correct, and not
>> response.json() to get json content from the response.
>> I'd recommend that if you want to make your own "grab stuff from onionoo"
>> script suite, to work with onion-py . It's very new, very spiffy and
>> uses python 3 and the newest requests lib. (full disclosure: It's my baby
>> and I'm desperately looking for testers/users, but that should be obvious
>> to anyone who read this thread.)
>> Alternatively, convince the right people (presumably Karsten and arma)
>> that challenger should switch to a more sustainable runtime than "what we
>> can get from wheezy's repositories". ;-)
> A-ha! :) That makes sense. (fwiw, i used pip under virtualenv in wheezy;
> requests lib version ancient indeed; such is life. fwiw, convincing wheezy
> cavepeople to use what you suggest makes sense. It's a false dichotomy
> between 'ensures dependences vs. breaks dependencies.')
> - the timeout stuff might be useful to everyone involved; it's rough
> - the 'fix' might be useful for people using old 'requests'
Actually, I might have that one kind of backwards. So timeout stuff for
everyone (who wants to use things from the
'luk3duk3-onionoo-integration' branch), the 'fix' for *certain* people
(for example, for those using pip.)
> - your onion-py sounds nice
>>  https://github.com/duk3luk3/onion-py
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-relays