> > > Marco Bonetti > > BT3 EeePC enhancing module: http://sid77.slackware.it/bt3/ > > Slackintosh Linux Project Developer: http://workaround.ch/ > > Linux-live for powerpc: http://workaround.ch/pub/rsync/mb/linux-live/ > > My webstuff: http://sidbox.homelinux.org/ > > People like you should be banned from the tor network and from the whole > internet. If you want music, pay for it. I you want books, pay for it, > but please don' t use the tor network via bittorrent to steal books and > music from composers and authors who worked hard. I don' t know if you > do that for sure, but asking for bittorent support, makes it likely. If > you are really this >
I dont know how in Italy, but downloading music is legal in my country. Im absolutely OK with downloading music from Internet, because when is my favorite band in my country, I spend hundreds of czech crowns for ticket. > I'm not the Internet Gestapo! Me not too. But I like to decide what I want to support. Scott: > Okay, Marek, I apologize. I did not understand from your earlier > postings that you were referring only to tor *exit* traffic, rather than > tor > traffic at all stages of transit. I don't see any showstoppers offhand for > plans to use, say, packet filter-based QoS support for exiting traffic. It > is unclear to me whether attempting to use QoS support for external traffic > entering the exit for transmission back to the tor client would have the > desired effect if the filter-based QoS support is running on the same > system > as the tor relay. If the prioritizations are instead implemented on a > separate router through which the tor process's traffic passes, then they > ought to work as well as the output prioritizations. You are right, it can be probably handled by external QoS. My idea was about build simple support into Tor, because QoS is much more difficult than set up your torrc. But I agree with your standing, it probably keeps Tor "KISS". Marek