[or-cvs] r13853: - translated volunteer page (removed many resolved issues) (website/trunk/de)

qbi at seul.org qbi at seul.org
Tue Mar 4 11:39:25 UTC 2008


Author: qbi
Date: 2008-03-04 06:39:24 -0500 (Tue, 04 Mar 2008)
New Revision: 13853

Modified:
   website/trunk/de/volunteer.wml
Log:
- translated volunteer page (removed many resolved issues)

Modified: website/trunk/de/volunteer.wml
===================================================================
--- website/trunk/de/volunteer.wml	2008-03-04 11:25:45 UTC (rev 13852)
+++ website/trunk/de/volunteer.wml	2008-03-04 11:39:24 UTC (rev 13853)
@@ -1,5 +1,5 @@
 ## translation metadata
-# Based-On-Revision: 11649
+# Based-On-Revision: 13843
 # Last-Translator: jens at kubieziel.de, peter at palfrader.org
 
 #include "head.wmi" TITLE="Mithelfen" 
@@ -99,13 +99,6 @@
 <h2><a class="anchor" href="#Documentation">Dokumentation</a></h2>
 
 <ol>
-  <li>Wir hören, dass Tornutzer diversen
-  Attacken von Javascript, Java, ActiveX, Flash etc. zu Opfer
-  fallen. Gibt es da draußen gute Plugins (wie NoScript für den
-  Firefox), die es den Nutzern erleichtern, diese Risiken zu meistern?
-  Was ist exakt das Risiko?</li>
-  <li>Gibt es eine komplette Seite mit Plugins, welche die komplette
-  Funktionalität von Privoxy für Firefox 1.5+ ersetzen?</li>
   <li>Bitte hilf Matt Edman mit der Dokumentation und HOWTOs für
   seinen <a href="http://vidalia-project.net/">Vidalia</a>.</li>
   <li>Kommentiere und dokumentiere unsere <a
@@ -136,38 +129,15 @@
   verwenden auf Windows den standardmäßigen <code>select</code>-Systemaufruf.
   Dies bereitet gerade auf mittelgroßen Servern <a
   href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">Probleme</a>.
-  Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine Lösung ist,
-  <a href="http://www.monkey.org/~provos/libevent/">libevent</a> beizubringen, Overlapped I/O statt <code>select()</code> zu wählen
-  und Tor dann an die neue libevent-Schnittstelle anzupassen.</li>
-  <li>Weil die Torserver jede Zelle speichern und weitergeben müssen,
-    brauchen die Torserver mit hoher Bandbreite Dutzende Megabyte an
-    Speicher. Wir benötigen bessere Heuristiken, wenn die Buffer zu
-    verkleinern/vergrößern sind. Wahrscheinlich sollte dies nach dem
-    Bufferdesign des Linuxkernels modelliert werden. Dort gibt es
-    kleinere Buffer, die sich gegenseitig verbinden.</li>
-  <li>Wir brauchen eine offizielle zentrale Seite, die die Frage "Ist das die
-  Adresse eines Torservers" beantwortet. Es sollte diverse Schnittstelle, wie
-  ein Webformular und DNSBL-ähnliche Abfrage, bieten. Es kann aktuelle
-  Informationen bieten, indem es einen lokalen Spiegel der
-  Verzeichnisinformationen anlegt. Du bekommst Bonuspunkte, wenn es aktiv
-  die Exitserver testet, wie die IP-Adresse ist.  Der schwierige Punkt ist, das
-  die Eigenschaft, Exitserver zu sein, nicht einfach mit ja oder nein zu
-  beantworten ist. Daher ist die Frage eher: "Ist diese IP-Adresse ein
-  Exiterver, der mich zur IP-Adresse:Port weitergibt?". Die DNSBL-Schnittstelle
-  wird wahrscheinlich Hunderte von Anfragen pro Minute bekommen. Daher sind hier
-  intelligente Algorithmen gefragt. <a
-  href="<svnsandbox>doc/contrib/torbl-design.txt">Hier</a> kannst du mehr dazu
-  lesen.</li>
-  <li>Manchmal stürzen Torserver ab oder die Computer, auf denen das Programm
-  läuft, verschwinden vom Netz. Manche Betreiber von Tor haben Interesse
-  geäußert, an einem Service teilzunehmen, der in regelmäßigen Abständen prüft,
-  ob der jeweilige Torserver noch läuft und Mails versendet, falls das nicht der
-  Fall ist. Eventuell möchte jemand ein paar CGI-Skripte und Webseiten schreiben
-  and einen wget-hack oder etwas komplexeres wie <a
-  href="http://nagios.org/">Nagios</a> für das Monitoring machen? Die erste
-  Version sollte nur den Directoryport prüfen. Beispielsweise könnte das
-  Programm durch die Netzwerkstatusseite nach der richtigen IP-Adresse sowie
-  Port schauen und dann nach der "/tor/server/authority"-Seite.</li>
+  Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine Lösung
+  wäre, <a href="http://www.monkey.org/~provos/libevent/">libevent</a>
+  beizubringen, Overlapped I/O statt <code>select()</code> zu wählen. Tor muss
+  dann an die neue libevent-Schnittstelle angepasst werden. Christian King hat
+  <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">einen guten
+  Anfang</a> gemacht.</li>
+  <li>Wie können wir die <a
+  href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a> leichter
+  zu warten, verbessern und zu dokumentieren machen?</li>
   <li>Wir brauchen ein verteiltes Testgerüst. Bisher haben wir Unittests. Es
   wäre großartig, ein Skript zu haben, welches ein Tornetzwerk startet und dort
   für einige Zeit testet, ob die Erneuerungen funktionieren.</li>
@@ -178,23 +148,6 @@
   href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Controller Protokoll
   </a> nutzt, um mit Tor eine Vielzahl von Verbindungen zu schaffen, diese zu
   messen und Anomalien festzustellen.</li>
-  <li>Wir brauchen eine Messung von <a
-  href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> und <a
-  href="http://www.privoxy.org/">Privoxy</a>. Ist Polipo wirklich schneller,
-  wenn man die Verlangsamung durch Tor mit einrechnet? Behandelt Polipo die
-  Webseiten korrekter als Privoxy? Gibt es Probleme mit der Stabilität bei den
-  häufig genutzten Plattformen?</li>
-  <li>Es wäre großartig, wenn es eine Live-CD mit den aktuellsten Versionen von
-  Tor, Polipo oder Privoxy, Firefox, Pidgin+OTR usw. gäbe. Es gibt hier zwei
-  Herausforderungen: Zum einen muss das System dokumentiert werden und zum
-  anderen müssen wir herausfinden, wie das leicht zu pflegen ist. Es sollte
-  nicht so schnell obsolet werden, wie AnonymOS. Bonuspunkte gibt es, wenn die
-  CD auf eine kleine CD (50MB) passt.</li>
-  <li>In Bezug auf das CD-Image sollten wir auch an einer sicheren und gut
-  dokumentierten USB-Variante für Tor und unterstützete Anwendungen arbeiten.
-  Der schwierige Teil ist zu entscheiden, welche Konfigurationen sicher sind,
-  diese Entscheidungen zu dokumentieren und etwas zu schaffen, das leicht zu
-  pflegen ist.</li>
   <li>Wir sollten damit anfangen unser <a href="<page
   documentation>#DesignDoc">gegen Blockierungen geschütztes Design</a> zu
   implementieren. Dies beinhaltet die Ausarbeitung des Designs, die
@@ -245,6 +198,9 @@
   <li>Wir sind nicht weit davon entfernt, Unterstützung für IPv6 bei
     Exitknoten zu haben. Falls du dich stark um IPv6 kümmerst, ist
     das wahrscheinlich der Platz, um zu starten.</li>
+  <li>Du magst keinen von den obigen Punkten? Schaue dir die <a
+  href="<svnsandbox>doc/design-paper/roadmap-future.pdf">weiteren Pläne</a> für
+  weitere Ideen an.</li>
 </ol>
 
 <a id="Research"></a>



More information about the tor-commits mailing list