---BeginMessage---
Hello,
the Polipo in
https://www.torproject.org/dist/vidalia-bundles/vidalia-bundle-0.2.2.22-alpha-0.2.10-ppc.dmg
crashes on startup as follows:
dyld: /Applications/Vidalia.app.new/Contents/MacOS/polipo Undefined
symbols:
/Applications/Vidalia.app.new/Contents/MacOS/polipo
Been a fencesitter on this since posting the note about recording
traffic that helped send this thread over the top. For once, I'm
in agreement with Scott :) (and others)
Badexiting based on exit policy seems rather silly as it will prevent
nothing. And because of that, doing so is security
Simply because every good thing needs checks, balances and feedback.
Thus spoke Msr. Bennett:
The tor project until very lately has always promoted end user
understanding and responsibility. Now the project *appears* to
be undergoing a major philosophical change toward nannying the
tor user
On Thu, Feb 10, 2011 at 05:34:51PM -0500, grarpamp wrote:
Tor seems to be doing a good job indicating the usefulness and
application of anonymity to a wide variety of potential users.
Moreso than before. But it does hesitate from suggesting that it
can be used as a check and balance within the
Hi onion peeps,
I run a no-exit relay that can sustain about a hundred KB/s but I need
to limit to about 4 GB/day to stay under bandwidth caps. I have
accounting set up but what happens now is that it blows through that
in 12 hours and then hibernates until the next day. However, because
server
On Thu, Feb 10, 2011 at 06:19:27PM -0500, Joseph Lorenzo Hall wrote:
I run a no-exit relay that can sustain about a hundred KB/s but I need
to limit to about 4 GB/day to stay under bandwidth caps. I have
accounting set up but what happens now is that it blows through that
in 12 hours and then
Thanks, Roger!
I appreciate the clarification... if there is an effort to write a
relay operator's manual I'd contribute to that. I've had a series of
questions like this that could be answered by something less intense
than having to look at the C/specs but more detailed than the current
manual.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all, Hi Joseph,
On 09.02.2011 01:03, Joseph Lorenzo Hall wrote:
At what point can torservers be confident it can support $800/month?
It's a very tough decision to make. Our current funds ($2400) mean we
would survive 3 months. Three months of
On 2/10/2011 6:34 PM, Roger Dingledine wrote:
On Thu, Feb 10, 2011 at 06:19:27PM -0500, Joseph Lorenzo Hall wrote:
I run a no-exit relay that can sustain about a hundred KB/s but I need
to limit to about 4 GB/day to stay under bandwidth caps. I have
accounting set up but what happens now is
Thus spake grarpamp (grarp...@gmail.com):
Exit policy is currently at the operator's pleasure, need and design.
If exit policy mandates will help solve some Tor scalability or
attack vector issues, in a substantive way, from an engineering
standpoint, fine. But please, don't claim it makes
On Thursday 10 February 2011 21:02:15 Aplin, Justin M wrote:
I've been meaning to ask about this for awhile. Is it more helpful to
the network to have (using this example) a node running at 100KB/s for
12 h/d, or limit it to 50KB/s and have it run 24/7? At what point does
speed outweigh uptime
On Thu, 10 Feb 2011, Mike Perry wrote:
Exit policy is currently at the operator's pleasure, need and design.
If exit policy mandates will help solve some Tor scalability or
attack vector issues, in a substantive way, from an engineering
standpoint, fine. But please, don't claim it makes users
On Fri, Feb 11, 2011 at 6:58 AM, John Case c...@sdf.lonestar.org wrote:
No, there is no _technical_ reason to operate an exit in this fashion. There
is no reason, from a myopic, borderline autistic view of the externalities
involved, to run an exit in this fashion.
However, I can think of
On Fri, Feb 11, 2011 at 12:58 AM, John Case c...@sdf.lonestar.org wrote:
I think these reasons should be worked around or ignored.
I think you, and others on that side of this argument have a very, very
myopic view of the constraints and non-technical decisions that go into
running a
14 matches
Mail list logo