tvdw

I attempted an implementation of Tor in Rust, but because I implemented it in Go a few weeks before that I got bored quickly. That said, some ideas I had for the Rust version have made it to Tor itself (or soon will), such as my ideas on transparently load-balancing Tor hidden services: https://gitweb.torproject.org/torspec.git/tree/proposals/255...

[1] note that in the land of Tor, unpredictable performance (for example because of GC pauses) could lead to user deanonymization.

This could've been mitigated by applying backpressure in a bunch of places, and is ultimately a problem of Tor and not Go, but the nature of Go makes it hard to build code to do that.

As for renegotiation: my work on the Go version of Tor had some nice side-effects, and indeed, renegotiation was finally removed :-) https://gitweb.torproject.org/tor.git/tree/ChangeLog?id=55c4...

Yes, it broke the speed record: a multithreaded application outperformed the singlethreaded version. But I wasn't happy with the result. It consumed an order of magnitude more memory, and gc times were potentially harming users (not a widely researched subject, but gc times in low-latency mixnets can likely harm user anonymity). Oh, and it would occasionally crash with OOM errors.

* yes, more modern versions of Go would likely mitigate some of the memory pain * yes, crypto/tls is fast now * no, crypto/tls still has insufficient functionality for implementing this. crypto/tls implicitly assumes you want to authenticate the channel through certificates, which Tor doesn't do * I was using go 1.4 * yes, I tried Rust

Almost all people can read basic English (especially those who access Github), so translating the Github interface seems rather pointless to me. Of course, translating the support articles would really help accessibility for those who don't know English as well as native speakers.

Translating interfaces makes people think they can use their language to communicate on a site. Translating only the support articles helps people understand the site, but they will quickly realize that the site itself prefers English-only communication.

IIRC the entire Bitcoin community mines 6 blocks per hour, and it's the mining process that keeps Bitcoin going, because without miners there couldn't be any transactions.

Also, since xor is just a CPU instruction, you won't immediately notice it in the decompiled script (if you get that far). With all the overhead that decompilers tend to produce, it's really easy to miss.

In fact, I just realized that I never use a single "Modern UI" app for the simple reason that they force my entire screen (2560x1440, 27") to be filled by one app. Such a waste of space. In desktop mode I often have four 1280x720 windows on my screen.

Windows 8 might just be the push I needed to switch to Linux.

    Man has always assumed that he was more intelligent than
    dolphins because he had achieved so much... the wheel, 
    New York, wars and so on... while all the dolphins had
    ever done was muck about in the water having a good time.
    But conversely, the dolphins had always believed that
    they were far more intelligent than man... for precisely
    the same reason.

2. Backup servers. Make sure you have a way to quickly spin up more machines. If you're using EC2, just launch a few extra machines, it's really easy as long as it's not the database being the bottleneck.

3. Turn off anything unimportant. During the traffic spike of Obama, there were undoubtedly some background processes that could be ran later. Just pause those for a while and make them continue later. As long as it's a spike and the background processes aren't that important, this works well.

4. Turn off some front-end stuff. Reddit, for example, disabled commenting on Obama's IAMA for a while, instead forcing a cached version of the homepage. It really helps performance and doesn't really hurt the visitors too much. Sure, they can't comment, but with 15000 comments it's not likely that your comment gets read by Obama anyway.

On 1 and 2: always make sure you have room to handle spikes. Get backup servers ready but don't turn those into real production servers. Always ensure you have a buffer. Maybe embed some code that makes your site extra heavy, then give it a switch to turn off that extra code in case of a big spike? If you always run your site on full capacity hardware, you can't plan for spikes.

https://gist.github.com/38c0430b5084f8442858 for my entire implementation.

You only need 1 call per possible number for each chunk, yes. But since the numbers are random between 0 to 999, that averages to 500 requests per chunk. Additionally, you don't have to do any kind of port checking for the last chunk, so that saves on any overhead you might have for the port checks. Based on this I'd say there's (3x 500 requests + 20% overhead) + 500 requests for the final block. That's 2300 requests on average.

https://gist.github.com/38c0430b5084f8442858 for those who are interested. There aren't many comments in there though

    eval(unescape(/your escaped code goes here/.source))

Well, of course it is...

- It is a translated document

The Next Web (www.thenextweb.com)

Job title: Ruby developers and PHP developers needed, as well as some front end developers (HTML/CSS/JS plus some PHP) and a UX developer.

http://thenextweb.com/tnw-jobs/

Interns are welcome, so are people who work remotely.