They wrote a small announcement in their forum. For anyone that can't read it:
This is an important change for Gazelle coders. You may have noticed that gazelle/ is now redirecting to http://whatcd.github.io/Gazelle/.
This is due to the fact that we are now hosting our public Gazelle repository on GitHub.
The old gazelle site had become severely outdated and a nuisance to maintain.
Luckily for us, GitHub is the perfect solution.
You can view our Gazelle repository here—it is accompanied by a GitHub page providing a brief overview of the project as well as a wiki with important information such as installation instructions, coding standards, and API documentation.
Cool, it's like watching how people did PHP 4-5 years ago when there weren't many frameworks available, and people used GLOBAL variables for accessing the DB/cache.
Yes, the thing I also noted first was that it doesn't have any bootstrap/router (only 'bootstrap' is the one that's included at the top of each .php-file, wordpress-style). Development must have been pure pain. :(
I really understand why people hate PHP so much when all they get to see is purely non-optimized shit. It generally has a really bad reputation which it doesn't deserve. Especially in HN-circles.
Yes I agree wholeheartedly. There are two very fair knocks against PHP: it's not the fastest, and the API uses somewhat inconsistent standards and conventions (isset vs. is_array for instance...so frustrating). But for the slowness aspect, it's not so slow that you are really hindered by this unless you are doing something that requires very intense performance, in which case why are you using a higher level language anyway. Pretty much the rest of its bad reputation is undeserved, and the downsides are on the level of give and take you get with any other language.
I guess coding standards where that locality trumped separation of concerns. Also, I find string interpolation in SQL kind of hot. Especially when magic quotes are deprecated.
I'm sure you can do nice things in PHP if you try hard enough, but you sure don't need to make any effort to do something absolutely terrible.
Well, the project is about 5 years old and grew over time. There were discussions about moving to a framework/a rewrite but that's something you can't pull of with < 5 developers while still keeping the current codebase up to date and fixing bugs.
It's not an age thing, the code we were writing was considered terrible back then too, and there were frameworks available. Wheel re-invention is fun though!
If you want to start a bittorrent tracker but don't want to bother with all of the trouble of things like Gazelle, you might like thehighseas, a straightforward bittorrent tracker I wrote:
Thanks - but having written a bittorrent tracker + web interface, I'm aware of the distinction. Most people who want to set up something simple don't actually care though, and my hope is that thehighseas helps people get started sharing with friends.
Sorry, I didn't mean to patronize your face off - was clarifying more for the benefit of other readers who are not so au fait with the infrastructure :)
This might get passed off as something for people looking do to evil/illegal/etc projects, but Gazelle is easily the best tracker front-end out there and it's super customizable (google "Gazelle tracker" and you'll likely find a bunch of screenshots of different sites implementing it differently—from skinning it to adding new features). Bittorrent is underused as a medium for legal downloads and I encourage anyone interested in a torrent site of any kind to check this out before they try to write their own.
There's pressure being put on Gazelle right now because Waffles and AnimeBytes are writing a replacement called Batter[1] using Django. I've also been working on a tracker in Go called Chihaya[2] that will replace Ocelot. I'm glad they finally opening things up more, but it might be a bit too late. If you're interested in working on a more modern rewrite of Gazelle's software stack that has actual software development practices (continuous integration, tests, style guidelines), check out the projects. Both projects are BSD 2 Clause, btw.
What's the motivation for replacing Ocelot? My understanding is that it's mostly a drop-in replacement for XBTT (please correct me if I'm wrong); is one of the design goals of Chihaya to modernize the API?
It's only gofmt with lines <80 chars; there is a function call or two broken into multiple lines to meet that. I'm scrapping that limit and just going to make it as readable as possible. The real crazy thing is GitHub using 8 spaces for tabs!
The tracker tells you who else has the files you want, in a nutshell.
Basic bittorrent outline:
You download a .torrent file which contains (amongst other things) a list of files, their hashes, and a list of trackers to connect to.
Your BitTorrent client connects to the tracker and says "Hi, who else has or is looking for these files"?
It returns a list of these people (aka "peers") and your BitTorrent client then connects directly to peers to download the files (and upload them to other people).
And all this time I thought a torrent file had the actual peers in it. So you don't even really need the .torrent if you have the addresses of some trackers that know where the files are that you want?
You would also need the torrent's hash (which enable you to specify to the tracker which files you want exactly). That's how magnet link [1] works - they contain the torrent's hash and optionally a list of trackers (most clients today support DHT [2], a decentralized tracker-less way to find peers).
I made a few simplifications for brevity and "these files" was one of them. What the .torrent actually contains is a list of the files and how those files are divided up into chunks of equal size (say half a megabyte per chunk). The bulk of the torrent is a list of hashes of each chunk, which allows your client to verify the data it has received from other peers. If you then take a hash of <<the part of the torrent that lists the files and the chunk hashes>> the resulting hash is known as the infohash. The infohash describes this particular torrent uniquely, and it's the infohash you send to the tracker when asking for peers.
Hopefully from this explanation you can see that you need it for two purposes, one so you can give the right infohash to the tracker, and two so you can verify the data you receive from peers.
A minor detail: The codebase was open source for a long time already, just on their own git and available on what.cd/gazelle and the IRC channel instead of GitHub.
I was an architect and coder on this project back at the very beginning and for a few years after launch, if you have any questions about the code then ask away :)
I respect those rules but I think they're stupid, as I havent met anyone in person who knew what waffles.fm or what.cd is but Ive been a member of what.cd since a few weeks after what.cd began (after the great oink piggie raid, what was that one called again?), its been years now.
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)
Because they just started to mirror their own git to GitHub and the documentation is more accessible there than the internal wiki on a private tracker.
