Zack Weinberg <zackw@xxxxxxx> wrote:
Relay diversity and client diversity are two different things. Last I heard
People who run relays usually started out as people running clients.
They liked tor and decided to help out by running a relay, *too*. Do you
really believe they would choose to install some OS other than what they
already use just to help diversify the relay population? I haven't used the
tor browser bundle for Windows in a long time. Does its controller's GUI
still offer the option of running a relay in addition to being a client while
tor is up and running? Some of us only run one computer. Are you suggesting
that we spin up a VM to install an unfamiliar OS on which to run a relay,
just to help with relay diversity? What current client-user will leap at
the idea of learning to do all that and do it safely in order to run a relay,
which he also will need to learn to do safely, when he could instead just run
a relay on a system he already knows, thereby reducing his learning load to
only the stuff he needs to know about tor? The volume of material needed to
learn an OS vastly exceeds what a new relay operator needs to know about tor,
after all.
it was a bad idea to run a relay on the same computer as a client, so I
It's arguably a bad idea to do that if your relay is an Exit, but then
it's usually an even worse idea to run an Exit at home. Some people think
it's a bad idea to run tor outside of a jail, too. (Unfortunately, most OS
do not have jails.)
don't think Tor Browser for server OSes like Solaris is a great use of
developer effort.
I suggest you ponder more on the matter of where relay operators come
from and what they might be willing to do or have the resources to devote to
running OS foreign to their normal uses for their computers. Either you
want to recruit for diversity or you just want to serve the OS that are
already most abundantly running relays. If you want to recruit for diversity,
then you need to consider how you're going to do that successfully. I contend
that that generally means recruiting people who are already running those OS.
That, in turn, means getting them to learn about tor by giving them something
they can use to try it out. Telling them, "We'd like you to run a tor relay
on your Bitrig system, though you won't be able to get much use out of it
yourself, not even to try it out", doesn't seem to me to be very likely to cut
it. That idea also seems to be corroborated by the current relay diversity,
which is the situation that has brought us to the current discussion.
Running a relay safely and smartly has a significant learning curve to
climb at the outset. Making it appealing enough to them to climb it is
called recruiting.
Windows is certainly the highest-value target for client diversity efforts.
How so? (Unless by target you mean client users to be eliminated? That
would certainly be *an* approach to increasing client OS diversity, but not
an acceptable one, IMHO.) It already has the most clients. Anyway, we're
not discussing increasing client OS diversity in this thread, but rather
increasing the OS diversity of relays. Please stop to consider what
diversification and diversity actually mean, which is the opposite of what
you argue for here. They don't mean piling most of the resources into
growing the dominant subpopulation. The same applies to LINUX.
I hear the Brave company is hiring someone to work specifically on Tor
integration, maybe you want to apply: https://brave.com/jobs/?gh_jid=781438
Windows is already running a huge percentage of the tor relay population.
How are you going to recruit Windows users to run relays on an OS they don't
already use? I contend that you won't. Instead, you must recruit current
users of such OS.
In my opinion, the best way to improve relay diversity would be to work on
system administration automation. For instance, as far as I know there is
no equivalent of Debian's 'unattended-upgrades' tool for any of the BSDs,
or even for most Linux distributions.
Are you kidding? Debian's "unattended-upgrades" tool must be something
spectacular then. Please tell us what it does that isn't handled by, say,
freebsd-update for the base OS and "pkg upgrade --yes" for the installed
packages like tor? IIRC, DragonflyBSD uses pkg, too. Or how about pkgsrc
on NetBSD? I've forgotten what OpenBSD uses, but it may well be pkgsrc. As
for how the other BSDs perform binary updates of their base OS, I couldn't
tell you, but I'd be astonished if they didn't have something for that. Just
use crontab entries to run these tools unattended and periodically. On
FreeBSD, if you build your ports from source via the ports tree, you could
run "svn update /usr/ports" and either use portmaster or poudriere to build
them and install the newly built versions. A lot of people do something
similar for updating the base system from source in the other BSDs. The
FreeBSD developers are in the process of setting up large blocks of the base
OS as packages that can be automatically updated just like any packages built
from ports, although I don't think that's quite ready for prime time yet.
NetBSD may already have this capability; I just don't recall.
Relay operators do not come into existence like virtual particle pairs
from a vacuum. We're talking about humans, and those come from real-life,
individual contexts. If you want to recruit them, then understanding and
accepting that fact are critical to doing it successfully.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays