Custom Query (10494 matches)
Results (7 - 9 of 10494)
|#12262||not a bug||Relay is not working, Vidalia 0.2.21||Jude-fruit||cypherpunks|
I use Vidalia's graphic interface on my mac under Os X. 10.9.3. The graphic interface is the easiest way for me to set up a relay as I don't understand much in computers (I tried to read the wiki but really it's all Chinese to me). So I has a non-exit relay working for a while but since a few weeks it does not work anymore. I don't remember changing anything though.
So I use Vidalia 0.2.21 and my TOR is up to date. Here are the settings in Vidalia: Relay port: 9001 Directory port: 9150 Miror Relay directory is checked Attemped to automatically configure port forwarding is checked. The test is successful. When I click on "launch", Tor starts but Vidalia remains black with that red cross and obviously nothing is happening. There is no message on the message log either.
Here are the settings of TOR: It's a manual proxy config everything is blank, except: SOCKS Host: 127.0.0.1 Port 9150 Socks v5.
Hopefully, someone here will be able to tell me what is wrong and why my relay is not working anymore.
Thank you so much for your help
|#1568||wontfix||Implement new dirreq share in ERNIE to fix "Recurring users" graphs||Karsten||karsten|
The current dirreq-v3-share that directory mirrors report and that we use to generate "Recurring users" graphs is broken. That means these graphs are broken right now. Once we have a replacement (based on the descriptor archives), implement the new dirreq share calculation in ERNIE and fix the graphs.
|#1630||implemented||Extend database schema by materialized views||Karsten||karsten|
The current database schema in ERNIE consists of tables and views. In order to support ad-hoc queries for dynamic graphs, we need to have materialized views plus a good concept to keep them updated. Update strategies range from (1) periodically re-generating the whole materialized views, (2) collecting changes on base tables and updating only those parts of materialized views that might have changed, and (3) triggering materialized view changes from table changes. While (1) is easiest to implement, it's infeasible for the amount of data in the database. (2) and (3) are harder to implement, but better fit the use case of having data covering multiple years in the database and adding data covering an hour or two. (2) is probably more efficient than (3), but even harder to implement. Kevin is working on this and might have results in July 2010.