[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r9761: update it volunteer.wml translation (website/trunk/it)
Author: jan
Date: 2007-03-07 07:49:41 -0500 (Wed, 07 Mar 2007)
New Revision: 9761
Modified:
website/trunk/it/volunteer.wml
Log:
update it volunteer.wml translation
Modified: website/trunk/it/volunteer.wml
===================================================================
--- website/trunk/it/volunteer.wml 2007-03-07 12:00:28 UTC (rev 9760)
+++ website/trunk/it/volunteer.wml 2007-03-07 12:49:41 UTC (rev 9761)
@@ -1,5 +1,5 @@
## translation metadata
-# Based-On-Revision: 9231
+# Based-On-Revision: 97509231
# Last-Translator: jan@xxxxxxxx
#include "head.wmi" TITLE="Partecipa"
@@ -20,18 +20,6 @@
comunicazioni, fagli conoscere il progetto Tor.</li>
</ol>
-<a id="Bugs"></a>
-<h2><a class="anchor" href="#Bugs">Bachi</a></h2>
-<ol>
-<li>Attualmente i server Tor su Windows XP non sono stabili,
-perché usiamo centinaia di socket che il
-kernel di Windows non é in grado di gestire. <a
-href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems";>Aiutaci
-a risolvere questo problema!</a> Probabilmente la soluzione migliore è fare in modo che libevent
-usi un IO overlapped invece di libevent() in Windows, e poi adattare Tor
-in modo che usi la nuova interfaccia libevent.</li>
-</ol>
-
<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Applicazioni di supporto</a></h2>
<ol>
@@ -111,12 +99,54 @@
a mantenere le traduzioni esistenti in italiano, francese e svedese -
vedi lo <a href="<page translation-status>">stato delle
traduzioni</a>.</li>
+<li>Puoi aiutarci a usare
+<a href="http://www.cacert.org/";>cacert</a> per il nostro
+<a href="<page documentation>#Developers">SVN repository</a>SSL?</li>
</ol>
<a id="Coding"></a>
<h2><a class="anchor" href="#Coding">Programmazione e design</a></h2>
<ol>
+<li>I server Tor non funzionano bene su Windows XP. Su
+Windows, Tor usa la normale chiamata di sistema <tt>select</tt>,
+che usa spazio nel pool non-page. Ciò significa
+che un server Tor di medie dimensioni esaurirà il non-page pool, <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems";>causando
+confusione e crash</a>. Probabilmente dovremmo usare overlapped IO.
+Una soluzione otrebbe essere fare usare a libevent overlapped IO
+invece che select() su Windows, e poi adattare Tor alla nuova interfaccia
+libevent.</li>
+<li>Poiché i server Tor devono fare store-and-forward di ogni cella che gestiscono
+i server Tor a banda larga consumano molta memoria solo come
+buffer. Serve migliore conoscenza di quando restringere o espandere i
+buffer. Forse lo si potrebbe modellare seguendo il design buffer nel kernel
+Linux, in cui vi sono molto buffer più piccoli linkati l'un l'altro,
+invece di un buffer monolitico.</li>
+<li>Serve un sito centrale per rispondere a domande come "Questo indirizzo IP è un
+server Tor?". Il sito dovrebbe avere varie interfacce, compresa una interfaccia
+web e una interfaccia simile a DNSBL. Può fornire le risposte più
+aggiornate tenendo un mirror locale delle informazioni di directory
+Tor. Meglio ancora se verifica ogni exit node
+per scoprire con che indirizzo IP esce realmente.</li>
+<li>Abbiamo bisogno di uno studio quantitativo che confronti <a
+href="http://www.pps.jussieu.fr/~jch/software/polipo/";>Polipo</a>
+con <a href="http://www.privoxy.org/";>Privoxy</a>. Polipo è veramente
+più veloce anche contando il rallentamento dato da Tor? I risultati
+sono gli stessi su Linux e Windows? Inoltre Polipo gestisce bene un maggior
+numero di siti web di Privoxy, o viceversa? Ci sono problemi di
+stabilità sulle piattaforme più comuni, come, Windows?</li>
+<li>Sarebbe bello avere un CD live contenente le versioni
+più recenti di Tor, Polipo o Privoxy, Firefox, Gaim+OTR, etc. Ci sono
+due problemi: il primo consiste nel documentare il sistema e le opzioni con chiarezza
+tale da permettere a chi si occupa di sicurezza di esprimere un giudizio sulla
+sua sicurezza; il secondo problema è trovare un modo per renderlo di facile manutenzione,
+così da non divenire obsoleto rapidamente come AnonymOS. Meglio ancora se
+l'immagine CD sta su un mini-D.</li>
+<li>Ci serve un framework di testing distribuito. Abbiamo unit tests,
+ma sarebbe bello avere uno script che avvii una rete Tor, la usi per
+un po' e verifichi che almeno una parte di essa funzioni.</li>
+
<li>Per ora i descrittori dei hidden service sono contenuti in solo in
pochi directory server. È uno svantaggio per la privacy e per la robustezza. Per
una maggiore robustezza dovremo rendere ancora meno privati i descrittori dei
@@ -131,15 +161,10 @@
rivelarne uno falso. In secondo luogo, va bene qualsiasi sistema affidabile
di storage distribuito, fintanto che permetta aggiornamenti automatici, ma per ora
pare che nessun codice DHT implementato supporta gli aggiornamenti automatici.</li>
-<li>Tor 0.1.1.x include il supporto per acceleratori crittografici hardware
-tramite OpenSSL. Nessuno tuttavia lo ha ancora testato. C'è qualcuno che vuole
+<li>Tor 0.1.1.x e successivi includono il supporto per acceleratori crittografici hardware
+tramite
+OpenSSL. Nessuno tuttavia lo ha ancora testato. C'è qualcuno che vuole
prendere una scheda e farci sapere come va?</li>
-<li>Dato che i server Tor fanno store-and-forward di ogni cellula che gestiscono,
-i server Tor a larga banda finiscono ad usare dozzine di megabyte di memoria
-solo per i buffer. Dobbiamo sapere quando restringere o espandere
-i buffer. Forse si potrebbe modellare una soluzione come i buffer nel kernel
-Linux, dove ci sono buffer più piccoli che si collegano l'un l'altro,
-invece che dei buffer monolitici?</li>
<li>Effettuare una analisi di sicurezza di Tor con <a
href="http://en.wikipedia.org/wiki/Fuzz_testing";>"fuzz"</a>. Determinare
se esistono delle buone librerie di fuzzing adatte al nostro scopo. Guadagnati la fama