Facebook 放出 Pysa，靜態分析 Python 程式碼的工具

Facebook 丟出來的靜態分析工具，可以拿來分析 Python 程式碼：「Pysa: An open source static analysis tool to detect and prevent security issues in Python code」，專案在「facebook/pyre-check」這邊可以取得。

不過軟體居然是用 OCaml 寫的啊，另外已經包好了，可以用 pip 直接裝 pyre-check。

官方的說明裡面有提到要裝 watchman，不過這算是選擇性安裝，不裝 watchman 直接執行也可以用，只是會跳個訊息跟你說裝了可以遞增檢查：

To enable pyre incremental, you can install watchman: https://facebook.github.io/watchman/docs/install

最近在寫的專案都是用 Python，剛好可以拿來掃這些專案...

最近洩漏出來的 Intel 程式碼...

已經有不少新聞都有報導提到最近被丟出來的 Intel 程式碼：

這些程式碼都是需要簽 NDA 或類似的合約才能拿到，這次被丟出來可以看到不少東西... 發佈的人有提到可以搜尋一些「關鍵字」，像是 backdoor 這個：

然後結果還蠻有趣的，看起來這包 20GB 的檔案可以讓不少人研究一陣子...

KataGo 最近的進展

KataGo 是目前 open source 裡最強的計算引擎了，不過先前的缺點就是得透過 OpenCL 或是 CUDA 才能跑，所以基本上得有張夠力的顯示卡才行。

如果要想要在 CPU 上跑 (不透過硬體顯示卡)，一種方式是透過 OpenCL 的方式模擬，在 Linux 下可以透過 pocl 達成，效能就普普通通，但算是會動的東西，不過 Windows 下好像不太好弄... 這也是先前蠻多人還是繼續使用 Leela Zero 的原因。

最近 KataGo 在 1.5 版實做了純 CPU 版本的程式碼，是透過 Eigen 這套 library 達成的，不過大家測過以後發現慢到爆炸 XDDD

因為作者沒有提供 CPU 版本的 binary，我自己在 Linux 下抓程式碼 compile 後測試發現只會用一個 CPU (沒有 multi threading)，對比於在 1080Ti 上跑 OpenCL 版本大約 150 visits/sec (40b)，但 CPU 版本是 0.0x visits/sec 啊 XDDD

作者自己在 GitHub 上討論時也有提到這個版本只有確認正確性，完全沒有考慮效能...

不過就有其他人跳出來改善了，在「Optimization of Eigen backend #288」這邊可以看到 kaorahi 拋出了不少修改，可以看到從一開始的 eigen_naive_loop (對比 1.5 版有 13x 的成長) 一路到 borrow_tensorflow (1400x) 的版本，使得在 CPU 上面跑 15b 也有 10 visits/sec 了：

"borrow_tensorflow" version: x1400 speed up from 1.5.0 (70% of libtensorflow backend). Now 15b net is usable for me. I get 19 visits/s in benchmark and 10 visits/s in GUI with 15b net.

這樣看起來已經快了不少，這樣子 Leela Zero 應該會逐漸淡出了，CPU-only 算是最後一塊 Leela Zero 還可以爭的地盤...

GitLab.com 將不支援免費使用者的 2FA reset

好像是在 Hacker News 的首頁上看到的，GitLab 宣佈他們的服務將不提供免費使用者 2FA reset：「GitLab Support is no longer processing MFA resets for free users」，對應的討論串在「Gitlab Support is no longer processing MFA resets for free users (gitlab.com)」這邊可以看到。

官方的公告，從今年的 8/15 開始就不再提供 reset：

As of Aug. 15th, 2020, GitLab Support will no longer process MFA resets for free accounts.

這反而是鼓勵使用者不要開啟 2FA，在討論裡面有人就講到這件事情，這個方法讓設定 2FA 的人受到處罰：

Think about the psychology of what you are telling people: "You have two choices - one is normal security, which you use on 80%+ of the rest of the internet, and one is 2fa which you only use on the annoying services that badger you into it. On the first one, if you lose your password you can do a password reset. On the second one, if your laptop and phone get fried in a rainstorm / car crash / act of children, you lose access to everything forever, no recourse and no recovery. And by the way, we totally encourage you to choose the second one... "

主因是，不是每個用 2FA 的人都知道要怎麼保護自己的帳號：像是同時有多把硬體的 U2F 放在不同地方，並且還有手機的 TOTP，另外還會把 backup code 放到安全的地方。

這次可以看出來 GitLab 的安全概念其實又出包了...

不停機把 server 搬到兩百米外的機房

在 Hacker News Daily 上看到的有趣故事，作者在 Reddit 上描述怎麼不停機把實體的伺服器搬到兩百米外的機房，中間還經過了停車場：「[Rant... sorta] Physically moved a server today...」，另外作者的 FAQ 在「[FAQ][Rant... sorta] Physically moved a server today...」這邊可以看到。

我會把這個當故事看一看就好，裡面還是有一些細節沒有被敘述 (像是網路不斷線的部份)，感覺不太對，但就一個故事來看是蠻有趣的 XD

搬運的過程中間包括了使用 UPS 與多顆 switch 對接，另外中間經過一個停車場，算是很有趣的方式？

Django 3.1

看到「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.

看起來應該也蠻有用的，可以玩看看...

MyRocks/MariaDB 的 tuning 過程

看起來應該是找 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，真的搞大了再考慮要不要換過去...

GPU.js

前幾天在 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 的服務

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 時間的方法...

Cloudflare 改善了 Workers 的 cold start 時間：「Eliminating cold starts with Cloudflare Workers」。

傳統的作法是連線結束後 application 層收到時去拉 worker 起來跑：

他們想到的方法是在收到 TLS 的 ClientHello 封包時就可以拉起來等了：

這點利用了 TLS 啟動時的交換時間，把 cold start 的時間疊起來，不過缺點應該就是同一個 domain 下的所有的 worker 都得拉起來，不過因為只有 cold start 的部份，應該是還好...