幹壞事是進步最大的原動力
看到「Django 3.1 Released」這邊的公告，比較完整的改變可以在「Django 3.1 release notes」這邊翻到。
這應該是第一次要把手上的專案跳 minor version 升級，看起來應該是還好，但天曉得會有什麼狀況... 看起來主要會是 sha1 要被換成 sha256 會有影響到。
另外看到這個：
SimpleTestCase now implements the debug() method to allow running a test without collecting the result and catching exceptions. This can be used to support running tests under a debugger.
看起來應該也蠻有用的，可以玩看看...
看起來應該是找 Percona 的人幫忙轉移到 MyRocks 上，然後整理出來的成功案例：「The Road Story of a MyRocks/MariaDB Migration」。
看起來是跑在獨立機器上，而不是雲端的虛擬機上，所以不是想 scale up 就可以把硬體規格拉上去 (說不定記憶體插槽已經滿了之類的...)：
Replicas run on bare metal servers, usually Dual Xeon E5 v3 or v4, with 192 GB to 384 GB of RAM.
這次遇到的主要的問題是發現效能跟不上。另外在文章裡面沒寫到，但可以猜到的是，他們目前不打算改架構，而是想要藉由改善資料庫的效能來解決問題：
The servers were close to their limits and were slow to catch up with replication after a maintenance period
後面可以看到不少過程，主要是重新編一份 MariaDB，讓 MyRocks 支援 Zstandard (MyRocks 支援 Zstandard，不過 MariaDB 內的 MyRocks 不知道為什麼關掉了...)，這點大幅降低了空間的佔用。
另外是遇到 OOM 問題，在改用 jemalloc 解決記憶體用量的問題後就解決了 (這個在使用 InnoDB 的時候也算是標配了)。
不過在「Increased Read Load Over Time」那段還是看到了 workaround：
The read load was still rising a bit but at a much smaller pace. Instead of hours, it was days. That’s kind of expected given the workload and we were already planning for periodic manual compactions.
目前看起來 MyRocks 的強項主要是在省資源，但缺點就是有不少眉眉角角得小心處理。這樣的話，一般應該還是會先用 InnoDB，真的搞大了再考慮要不要換過去...
前幾天在 Hacker News Daily 上看到的專案：「GPU.js - GPU accelerated JavaScript」，對應的 GitHub 頁面在 gpujs/gpu.js 這邊。
看起來是用 WebGL 接進去的，不過他用來 benchmark 的硬體頗暴力啊：
Hardware: Xeon Gold 5217 + 8 x RTX 2080ti
這邊用了八張 2080Ti，如果一張就大約是 1/8 效能的話，看起來好像還好... 一張 2080Ti 跟 Xeon Gold 5217 跑出來差不多？價錢也在同一個範圍區間...
暫時不知道用途...
Cloudflare 推出了 BYOIP 的服務，用客戶的 IP address 放 routing 出去：「Bringing Your Own IPs to Cloudflare (BYOIP)」。
照敘述上看起來應該是 anycast，不過這邊沒明講：
When you BYOIP with Cloudflare, this means we announce your IP space in over 200 cities around the world and tie your IP prefix to the service (or services!) of your choosing.
裡面沒有提到 IPv4 或是 IPv6，在 https://developers.cloudflare.com/byoip/ 這邊看起來也沒提到，以 Cloudflare 的技術架構，應該是都支援？
用自己的 IP 的好處，一個明顯的方向就是 firewall 會好設不少，另外如果需要服務中國或是其他管制地區，比較不會因為 IP space 混用誤殺受到影響？
Cloudflare 改善了 Workers 的 cold start 時間：「Eliminating cold starts with Cloudflare Workers」。
傳統的作法是連線結束後 application 層收到時去拉 worker 起來跑：
他們想到的方法是在收到 TLS 的 ClientHello 封包時就可以拉起來等了：
這點利用了 TLS 啟動時的交換時間，把 cold start 的時間疊起來，不過缺點應該就是同一個 domain 下的所有的 worker 都得拉起來，不過因為只有 cold start 的部份，應該是還好...
在「The German Problem with Tor」這邊提到了 Tor 在德國的 Relay 節點比重過高的問題，遠超過第二名的法國：
This is where we come to Germany, which has the highest amount of Tor relay capacity in the World at 167Gbps, in contrast France is in 2nd place with 64.5Gbps of capacity aka more than 100Gbps lower than Germany.
從 Welcome to Tor Metrics 這邊可以拉資料出來看，在「rs.html#aggregate/cc」這頁可以看到差距，現在德國的 Relay 是第一名，比重約 37.7%，法國則是第二名，但卻只佔了 16.7%。
主要還是頻寬費用的關係吧？畢竟網路上租主機時也可以感覺到，德國的頻寬真的很便宜...
Amazon Lightsail 也推出 CDN 服務了：「Amazon Lightsail now offers CDN distributions to accelerate content delivery」。
這個服務是用 CloudFront 為底：
This native service, called Lightsail CDN, is backed by Amazon CloudFront, Amazon Web Services’ CDN platform that uses a global network of servers in over 200 locations across 42 countries to store and deliver your content throughout the world. Lightsail CDN distributions can be created and configured with just a few clicks for a low, predictable monthly price, and you can get started for free.
看了一下價錢，免費方案可以有 50GB/month，一般自己架個 WordPress 之類的 blog 應該是可以涵蓋在內。
付費方案中，USD$10/month 可以給 200GB，但 USD$35/month 只能給 500GB？這邊是用愈多愈貴，沒看懂這個定價方式啊...
但看起來是有不少機會比 CloudFront 便宜 (如果非歐美的流量不少的話)，再來就是 Lightsail CDN 這邊沒有列出每個 request 的費用，所以應該是不算這塊？這樣小檔案很多的話應該也是個選擇？
Amazon Lightsail 一直拿 AWS 自家東西出來市場上打架，現有的 VPS 不知道會怎麼提供類似的方案，搭 Cloudflare 嗎？或是找 Fastly 這些服務搭？(不過話說回來，Fastly 的牌價好貴 XD)
在 Hacker News Daily 上看到的專案，針對現在很多演算法可以抓出照片上的人臉進行防禦：「Image "Cloaking" for Personal Privacy」。
這算是 Evasion 的應用，這個專案想要提供演算法，可以在照片上「隱形」，使得演算法偵測不到「人臉」，程式碼可以在 Shawn-Shan/fawkes 這邊翻到，可以看到是在 Python 上用 TensorFlow 與 Keras 實做出來的。
不過會覺得比較有趣的反而不是裡面的方法，而是這篇論文的六個作者：
Shawn Shan†, PhD Student
Emily Wenger†, PhD Student
Jiayun Zhang, Visiting Student
Huiying Li, PhD Student
Haitao Zheng, Professor
Ben Y. Zhao, Professor† Project co-leaders and co-first authors
從名字上來看五個是華人，而且一路搜下來會發現掛在最後一位的 Ben Y. Zhao 教授在 Quora 上常常回答問題，而且這些問題 (與回答) 還蠻有趣的，可以自己搜看看...
應該是直接在 Hacker News 上看到的東西，有人丟出一個二分搜尋法實做，宣稱比標準實做快不少：「Binary Search: A new implementation that is up to 25% faster (github.com)」。
實做的程式碼放在 GitHub 的「scandum/binary_search」這邊，讀了 source code 後可以看到一臉就要利用現代 CPU 預測平行化的能力加速 XDDD
另外看了 Hacker News 上的討論，這種寫法會透過 CPU 預測平行化的能力善用記憶體頻寬，這應該是測起來比較快的主因。
不過這只算是個開頭，丟出一些方向讓社群可以研究，實際上還是得看看負面影響的部份，像是比較舊的 CPU 會不會有很重的 penalty (overhead)，以及其他類型 CPU 上的情況...
一樣還是 Hacker News Daily 上看到的東西，不過這個東西主要就是趣味性為主而已。這次看到的是純 HTML + CSS 做出來的踩地雷 (Minesweeper)，沒有 JavaScript 在內：「css-sweeper from PropJockey」。
自從 HTML + CSS3 證明是 Turing-complete 後，再加上 CSS 本身又一直加各種互動性質的操作，出現這些東西好像不太意外就是了 XDDD
依照他的說明，這邊用到的 CSS 技巧主要是 Space Toggle 這個技巧 (也就是 --toggler 這個)，但試著找了對應的文獻說明居然沒翻到，有人可以給個 hint 嗎...