Ocelot, their custom-made C++ tracker is a nice piece of code.
They were forced to drop out php-based and XBTT-based trackers some years ago when the server load from their became huge peer swarm became unmanageable.
PHP wasn't really the limiting factor, it's the architecture that XBTT uses that really kills you - an SQL query for every single announce! (With millions of peers that means hundreds of SQL queries per second just to maintain your swarm)
Some other cool trackers to look at are Shadowolf (although I believe that's discontinued, sadly) and Lioness if that's floating around anywhere (What.CD likes wildcat-based codenames)
Combined with AdBlock, I use Ghostery[1], which is a nice add-on (Chrome/FF/Safari/Opera/IE) : it blocks any javascript from ads networks, but also from analytics, trackers, socials plugins (and more) , and also cookies from the same trackers. Everything is configurable per-tracker and per-website.
It's quite a must-have if you don't want to be the product on the Internet. And a good failover over Ad-block.
The 2006 CIA Factbook stated that the "US is the only industrialized nation that does not mainly use the metric system", (in addition to non-industrialised Burma/Myanmar and Liberia).
This particular case is not English vs. Metric, but rather lack of cohesion in the metric system.
English: Use commas for separating thousands, use periods for decimals.
Metric: Use spaces for separating thousands, use periods OR commas for decimals.
In this instance, the English approach is obviously the superior one, as spaces are more confusing to use as a delimiter than commas, and there should only be one way to write decimals for consistency.
I´m european and the natural way for me is period for thousands and commas for decimals, although I´m aware of the imperial way, with commas for thousands and periods for decimals.
Another important difference is that in Europe we understand a billion as a million of millions (10^12), not a thousand of millions (10^9). For us, a 10^9 is a miliard. Luckily I´m also aware of the use of billions for 10^12 and whenever I read it on a US or UK text I understand correctly. Otherwise, saying that there are 7 billion people on Earth would be an extreme exageration...
There is some other system that uses periods for thousands and commas for decimals - the exact reverse of what you've listed as the english convention. I always thought it was a european convention. It makes more sense than what you've listed as the metric convention.
Indeed, and that is what I've seen from many Europeans.
However, I think that must be a convention from before the universal adoption of the metric system by the EU, as the 22nd General Conference on Weights and Measures (held in 2003) declared that the symbol for decimals should be "the point on the line or the comma on the line".
i.e. the official metric system symbol is period or comma, regardless of what actual Europeans use.
>i.e. the official metric system symbol is period or comma, regardless of what actual Europeans use.
Regardless? Those (and mainly comma) is exactly what Europeans use. It's not like there is some other symbol besides those too in use for that purpose.
Nginx works very well with PHP-FPM through FastCGI, and there is about zero configuration needed as everything is up and running after an apt-get (minus some commented configuration regarding php in Nginx).
I think more and more php-based app are powered by this kind of stack.
I've seen a good number of benchmarks that show modphp for Apache to be as fast or faster than FastCGI on nginx. If you're running a PHP application I'm not sure there's a huge impetus to switch from nginx over apache to just nginx (other than reducing a point of failure).
Of course modphp would be faster as php becomes part of Apache with this approach. The problem is that not every Apache process is going to serve php. Most of them will be serving static files but will have the overhead of the embedded php library. The real overhead though comes due to that you can't control how many Apache processes serve php and how many static files. Processing php eats a lot of RAM and you can quickly bring you server down to its knees. You could opt for less Apache processes but then you would end up serving much less visitors.
Anyway, Apache these days is mostly set-up with fastcgi or php-fpm due to these issues and this has the added good that you can use the worker or event mpm, though most benchmarks are still with the older prefork mpm.
I use nginx with php-fpm because (a) I find nginx easier to configure than Apache; (b) the configuration required for setting up nginx + php-fpm on Debian and Ubuntu is practically nil; and (c) this allows me to run PHP and Python apps on the same server on different subdomains.
The memory requirements of Apache with mod_php are one of the main reasons people hosting PHP applications use Nginx (or LigHTTPD, although enthusiasm for it has died down). I imagine it is still a common setup to have Nginx in front of Apache serving static content itself and forwarding the requests for dynamically-generated content to Apache.
Yuuuup. I remember discovering nginx/PHP-FPM a while ago. It's a pretty amazing combo, especially in terms of raw performance efficiency. Now it's even easier to do and a lot more sites are catching on.
TorrentFreak made a great story about this[1].
[1] http://torrentfreak.com/what-cd-debuts-lightweight-tracker-f...