As I talk to more and more people, they are confused by all of the different software packages we offer. From the simple,
"I just want to be a relay, why is this so hard?"
to
"I just want to safely get to the BBC, I don't care about configuration and such. Can't you just make it a simple download and have it work by default?"
I've written down my thoughts at https://svn.torproject.org/svn/projects/roadmaps/proposed-package-roadmap.tx....
I'm looking for your thoughts and feedback. The goal is to simplify what we produce and make it easy for people to get the software and configuration they want.
On workload and stuff...
the idea we had at the 2010 Potsdam meeting where we had primary and secondary developers for each product.
There is Tor core (ported to various platforms). This is code and docs. This is what matters. It is not config or packaging.
Above and beyond that, if there is a demand for it, why not introduce a secondary level of suitably trusted enthusiasts to develop and manage all the various modes of operation. Officially disclaim it appropriately as an unofficial vaporware framework, wikify it, put a couple public developer packaging boxes online and see what happens.
Also, you could easily publish just a set of torrc's tailored to various purposes. Or even create an online config generator with various feature checkboxes.
Also, a visible and similarly adjunct FAQ and docs team for those of us who ask silly questions like myself :) And I guess, a searchable and downloadable email archive. It could save some time of some of the people who reply to 'Subject: Please help' people.
TBB... Tor Browser Bundle... sure, this is useful. But a pain for each platform. I would punt it to the secondary team. Then focus on one, Torify everything, bootable Unix platform.
- If a user wants to run both a tor-client and >
tor-(relay|exit-relay|bridge) on the same host, we run into port
Goes to config generator or posted configs. Plus to some degree you get config modernization out there in Torland for free.
- The conversion from legacy to new packaging could be a mess.
I've never had a problem being forced to accept breakage of backward compatibility. Then again, I'm not Joe user. Still, assuming there is constant new user influx, such breakage won't lead to lost capacity. That's what major.minor.rev revision numbering is for.
- The *BSD ports system ... for non-exit, exit, and bridge relay.
Really? Users who can deal with ports can certainly deal with a little Tor config.
Conclusion
I've no objection to flag days that result in good long term gains.
On Wed, Jun 15, 2011 at 02:05:44AM -0400, grarpamp wrote:
On workload and stuff...
the idea we had at the 2010 Potsdam meeting where we had primary and secondary developers for each product.
There is Tor core (ported to various platforms). This is code and docs. This is what matters. It is not config or packaging.
Above and beyond that, if there is a demand for it, why not introduce a secondary level of suitably trusted enthusiasts to develop and manage all the various modes of operation. Officially disclaim it appropriately as an unofficial vaporware framework, wikify it, put a couple public developer packaging boxes online and see what happens.
Also, you could easily publish just a set of torrc's tailored to various purposes. Or even create an online config generator with various feature checkboxes.
I don't think most of the target audience knows (or wants to know) what a torrc is. They want one-click download, install, and run. And that's what we should give them.
I've no objection to flag days that result in good long term gains.
Well, Flag Day was yesterday, so you've got a whole year to figure out the plan for next time. ;-)
- Ian
There is...
BlackBelt Privacy. https://sourceforge.net/projects/blackbeltpriv/ Its a one click install package with sensible defaults. Its unofficial, with some people warning against using it and others embracing it.
Advanced Onion Router https://sourceforge.net/projects/advtor/ A zip file that provides an easy to use interface to Tor, I admit this is akin to Vidalia. Vidalia may be more elegant.
Ian Goldberg wrote:
On Wed, Jun 15, 2011 at 02:05:44AM -0400, grarpamp wrote:
On workload and stuff...
the idea we had at the 2010 Potsdam meeting where we had primary and secondary developers for each product.
There is Tor core (ported to various platforms). This is code and docs. This is what matters. It is not config or packaging.
Above and beyond that, if there is a demand for it, why not introduce a secondary level of suitably trusted enthusiasts to develop and manage all the various modes of operation. Officially disclaim it appropriately as an unofficial vaporware framework, wikify it, put a couple public developer packaging boxes online and see what happens.
Also, you could easily publish just a set of torrc's tailored to various purposes. Or even create an online config generator with various feature checkboxes.
I don't think most of the target audience knows (or wants to know) what a torrc is. They want one-click download, install, and run. And that's what we should give them.
I've no objection to flag days that result in good long term gains.
Well, Flag Day was yesterday, so you've got a whole year to figure out the plan for next time. ;-)
- Ian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Andrew Lewman -
another_base_name2001-debase＠yahoo.com -
grarpamp -
Ian Goldberg