New Python/Django-based TorStatus
We're excited to announce that a group of students from Wesleyan has created a new TorStatus website written in Python. Their new website is a fine addition to Kasimir Gabert's Tor Network Status page. Kasimir's page is currently the most popular website to learn about running Tor relays.
We're glad that we now have a new Python/Django-based TorStatus, as many developers in the Tor community have been working on complementary Tor Python libraries.
The new TorStatus started out as a rewrite of the old PHP-based TorStatus, so we're building from Kasimir's great ideas. The new TorStatus adds a new landing page, paged results that decrease latency, and carefully crafted graphs with a focus on aesthetics. But it's not only the features that make this code so great. We believe that many more developers will be interested in modifying and extending the codebase! At least that's much simpler now with the move to Python/Django.
The new TorStatus project was done by Norman Danner's students during their summer The Humanitarian Free and Open Source Software at Wesleyan University course. Thanks to Jeremy, Diego, and Vlad for designing, coding, and testing this new TorStatus! Thanks to Damian for co-mentoring the students on Tor's side.
What's next? Want to help out with coding on the new TorStatus? You should start by looking at the codebase and the list of open tickets. Feel free to leave a comment here or drop by #tor-dev if you have suggestions or are interested in helping out!
Comments
Please note that the comment area below has been archived.
Could you guys quit using
Could you guys quit using KB/s and start using real
bandwidth units that ISP people recognize? That is
bits/sec in powers of ten. NOT 'K' which is ambiguous
and not even a real prefix. And 'bits', not bytes. We're
sorry if Linux adopted the incorrect unit specs. But
the rest of the real network world uses 'bits/sec'...
cisco/juniper, tier-n's, your bandwidth provider etc.
Tor is a bandwith application, NOT a disk storage
application. It should use 'bits/sec' in all areas.
See also: http://en.wikipedia.org/wiki/Binary_prefix
Decimal SI prefixes. Thank you!!! (those of us sick
of converting and dealing with ambiguous units :)
As a former network
As a former network engineer, this has been a gripe of mine forever. However, the consensus feels users understand kilobytes per second better than bits per second. Even though every bit of networking gear and bandwidth you buy is in bits per second.
Sure, they may understand it
Sure, they may understand it better from burning DVD's full of whatever with their storage app. If they're lucky... because not even Microsoft demonstrates correct usage. So they learn bad definitions in that space.
Then they break down when they try interfacing their purely network app (Tor) with their network provider (who happens to properly quote bits/sec). And the user is left trying to convert units and usually failing. Often because...
'K' is not defined in IEC or SI. It has no standard meaning. So Tor's 'K'B/sec could be binary or decimal. It's not documented. And 'B' looks like binary. So who's to know. Until they get their bill. And the words in ConstrainedSockSize present a conflicting view of 'K'B as well. Unless you're actually a coder who might recognize the implied meaning in light of system calls.
This isn't a voice to the Net Eng choir. It's a voice against continuing to choose to perpetuate the .consensus.look.feel.common.ambiguity.user. ways in the face of now well defined and long ratified international standards meant to finally fix those problems. Why be one of those non-standard apps?
I'd rather have a FAQ entry that tries to educate me than one that tries to placate me.
Tor's users aren't going to revolt from changing the display labels from KB to kbits or kB or even [K|M|..]iB, all where proper. Because the only place they are used is relay and exit ops (a very small subset of users at that). That subset will probably thank you for the sanity and making their interfacing, graphing, etc... with the network world, easier.
(Yes, I recognize AccountingMax as a good and proper feature to have too. Just not it's use of 'K' :)
There are multiple
There are multiple selections of the same title in the display options add/remove up/down page thing. Very confusing.
Relays per page needs bumped
Relays per page needs bumped to allow 'all', not just 200.
So that an export of the entire selected set under view can occur.
And there doesn't seem to be
And there doesn't seem to be a way to select a subset via a single get/post request. It seems driven by server side session cookie params. This is hugely bad because it breaks the ability to scrape for people who need it.
Also, add a reverse dns (PTR) display option.
Love it. Thanks :)