Tor, Flask, MU-MIMO, TSDB, Aito.db


  1. A good blog post about: Deanonymizing Tor Circuits (@ hackerfactor.com ). Yes there are many kind of attacks running against Tor network and users all the time. Also the story about Facebook providing 0 day exploits to attack Tor users was quite interesting (no link). Tor de-anonymization, host identification, DDoS, etc. And some complaining about Tor IPv6 support. Somehow this doesn't surprise me at all. Using the known rendezvous nodes only makes prefect sense, it's strange that "non tor network" rendezvous node is allowed at all. That's a good point.

  2. Summer fun, migrated some older Python projects which use Bottle.py to use Flask instead. That wasn't hard at all. Those are just so similar frameworks to use, when you utilize just the basics. Sometimes all the framework discussion gets kind of silly. All of the frameworks are quite similar on basic level. Because it's just the way HTTP requests are handled in code. Some routing, and then processing the request itself. And even that routing can be handled by "catch all" if and when required, if the framework router doesn't suite you. Also there can be a load balancer in front, which basically means that every instance doesn't need to handle "everything the site can potentially need to do". Etc. Yet, for small monolithic setups, I kind of like the can handle everything, it makes testing so much easier when you can start the system and everything works.

  3. Well, because so much time has passed. I'll post it here too. We've been discussion possibilities of using MU-MIMO and beam forming high frequency radios, like mobile networks and WiFi as synthetic aperture radars. Maybe this is something what the intelligence services have thought of? I did quick Googling, when writing this. And it seems nobody's discussing this possibility publicly. Is it something which is inherently misthought and considered? To me it personally feels that the dual use of this technology is absolutely obvious. Maybe the stock software doesn't provide the capabilities, but I don't see any reason why the hardware couldn't be used as radar, when just replacing the software with something designed for it. - Any thoughts? Or maybe I'm totally wrong about this. And the satellite based SAR monitoring is already on such a high level, that they can basically monitor everything in real-time without land based radars. - Who knows. Probably not, because they got upset about the images Trump leaked, and those were good, but not that great.

  4. Had a too long (?) discussion with system architects about using time series database (TSDB) (@ Wikipedia ) to improve temporal availability statistics history information. My point was that once again, this is one of the cases where I really would like not to have yet another different technology linked to the product for small gains. First of all, the best approach would be to better utilize the existing tools like the SQL Server features. If we don't properly know our current tools, it doesn't make any sense to add new tools to solve problems which could be solved better than well, by using the existing tools, if we just would know the tools bit better. After running several synthetic batch tests with SQL Server (T-SQL), PostgreSQL and Riak-TS, I didn't find any meaningful benefits using Riak versus the SQL Server. It all boils down how the tables and queries are designed, and how (when possible, which is mostly possible) the data is pre-aggregation into sane slices. Also it's possible to use columnar compression and so on. By doing small changes how the data is stored, it was immediately obvious that there's no need for TSDB. Just making sure that the data is pre-stored in such way that it's easily retrieved when required. No, this is not rocket science. But a very common problem. There's some layout where data is pushed, and then it's fetched. But during the database design, nobody has thought how the data should be stored, so it would be easily retrieved to support most common queries run against the data. If nothing else help, then materialized views can be used. - Another problem with new flashy things is that when the project needs to be maintained for a decade or two, are you sure all the flashy things being used are being maintained properly for that time window as well? If not, well, then you've got a problem. Ref: Riak, QuestDB, GridDB.

  5. When working with the time series issues, I also encountered something interesting: aito.ai (@ aito.ai ), which is data prediction in "database way". Nice approach. I guess this is the next step of Machine Learning, when you're going to focus on results, and not the technology itself. Afaik, looks good an interesting when necessary. I personally could think several ways to utilize this already, because I've been talking so much about data under utilization. There's plenty of data, but it's not being used practically for anything.

2021-08-01