幹壞事是進步最大的原動力
前幾天在噗浪的偷偷說上看到有人提到 npmtrends 上的 redis (官方的) 與 ioredis：「https://www.plurk.com/p/p6wdc9」。
意外發現以下載量來看，ioredis 已經超越官方的 redis 了：
找了一下差異，看起來的確有些團隊在 loading 很高的情況下會考慮用 ioredis 取代 redis：「Migrating from Node Redis to Ioredis: a slightly bumpy but faster road」。
但沒有特別需求的話應該還是會用官方版本？
看到「Mountpoint for Amazon S3」這個專案，AWS 自己推出了自己的 Amazon S3 FUSE 套件。Hacker News 上也有一些討論：「Mountpoint – file client for S3 written in Rust, from AWS (github.com/awslabs)」。
Amazon S3 的價錢比其他 AWS 提供的 storage 都便宜不少。以美東第一區 us-east-1 來說，S3 是 $0.023/GB，而 EBS (gp3) 要 $0.08/GB，即使是 EBS (st1) 也要 $0.045/GB。
S3 相較於 EBS 來說，多了 API call 的費用，所以對於不會產生大量 API call 的應用來說 (像是常常會寫很大包的資料到檔案裡)，透過 FUSE 操作 Amazon S3 可以讓現有的套裝軟體或是程式直接跑上去。
另外一個常見的應用是讓套裝軟體或是現成的程式可以讀取 S3 的資料。
之前這類應用馬上會想到的專案是 s3fs-fuse，這個專案很久了，大家也都知道多人寫入的部份會是痛點。
這次 AWS 自己出來做的事情有點重工，看起來他想做的事情 s3fs-fuse 都解的差不多了，目前看起來唯一的賣點應該只有 Rust-based，但 s3fs-fuse 主要是 C++，其實也沒差到哪裡：
Mountpoint for Amazon S3 is optimized for read-heavy workloads that need high throughput. It intentionally does not implement the full POSIX specification for file systems.
目前專案還是 alpha release，不確定專案的方向到底是什麼...
看到 CloudFront 宣佈支援帶入 JA3 資訊了：「Amazon CloudFront now supports JA3 fingerprint headers」：
Details: Amazon CloudFront now supports Cloudfront-viewer-ja3-fingerprint headers, enabling customers to access incoming viewer requests’ JA3 fingerprints. Customers can use the JA3 fingerprints to implement custom logic to block malicious clients or allow requests from expected clients only.
JA3 的頁面上可以看到說明，針對 SSL/TLS 這個複雜的 handshake 過程中，就可以從中得知不同的 client 實做，比起容易偽造的 User-agent 有效：
JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.
像是 Tor 的 SSL/TLS 連線就會有對應的 fingerprint 可以偵測：
JA3 fingerprint for the standard Tor client:
e7d705a3286e19ea42f587b344ee6865
先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」裡面提到的 curl-impersonate 就是反制這類偵測的方式。
在 Hacker News 上看到「A userspace WireGuard client that exposes itself as a proxy (github.com/octeep)」看到這個有趣的東西，可以把自己當作是一個 WireGuard client，然後透過 SOCKS5 界面讓使用者使用... 專案則是在 GitHub 上的「Wireguard client that exposes itself as a socks5 proxy」這邊可以看到。
除了軟體本身有支援 SOCKS5 的可以用以外，另外可以搭配透過 LD_PRELOAD 把 TCP 連線都轉進 SOCKS5 服務的套件來用，像是 tsocks 或是 redsocks 這種工具。
在 Hacker News 上看到「Mutt 2.2.0 (mutt.org)」這篇，Mutt 的維護者 (應該是 Kevin McCarthy) 將只會負責 fix 類的事情了：
This obviously isn't a feature, but I wanted to mention that I will be moving away from Mutt maintainership after this release. There isn't a transition plan, so I'll keep maintaining the 2.2.x series with bug fixes and security issues.
It's been my pleasure to keep the releases coming since version 1.5.24. Unfortunately the past year, my time and energy available has been decreasing. So my plan is to focus the time I do have on keeping Mutt stable, secure, and bug free; until someone else has the desire to head up (and support) new-feature releases. Thank you everyone!
有人在討論串裡提到了 NeoMutt，也許之後會找機會看看...
目前還是有一套 email system 是跑在 Postfix + Procmail + Bogofilter + Mutt 上面，短期內應該不會換...
在「Thursday January 06th 2022 - qBittorrent v4.4.0 release」這邊可以看到 qBittorrent v4.4.0 支援 BitTorrent v2 (BEP 52) 了：
FEATURE: Support for v2 torrents along with libtorrent 2.0.x support (glassez, Chocobo1)
先前在「libtorrent 宣佈支援 BitTorrent v2」這邊有提到過 libtorrent 要支援 BitTorrent v2 的消息，而 qBittorrent 算是 libtorrent 的使用大戶，支援 BitTorrent v2 後會讓 BitTorrent v2 的使用率增加不少。
用了一年多才出現一個比較大的 client 跳進去支援，看起來大家的動力的確不高...
整理資料的時候看到以前就看到的資訊，Akamai 有提供工具，可以看 DNS resolver 的資訊：「Introducing a New whoami Tool for DNS Resolver Information」。
這拿來分析 168.95.1.1 或是 8.8.8.8 這些服務還蠻好用的，這些對外雖然有一個 IP address 在服務，但後面是一整個 cluster，所以可以利用 Akamai 的這個工具來看分析。
像是 8.8.8.8 會給接近的 EDNS Client Subnet (ECS) 資訊 (ip 的部份看起來是隨便給一個)：
$ dig whoami.ds.akahelp.net txt @8.8.8.8 [...] ;; ANSWER SECTION: whoami.ds.akahelp.net. 20 IN TXT "ns" "172.217.43.194" whoami.ds.akahelp.net. 20 IN TXT "ecs" "111.250.35.0/24/24" whoami.ds.akahelp.net. 20 IN TXT "ip" "111.250.35.149"
而 1.1.1.1 會給假的 ECS 資訊：
$ dig whoami.ds.akahelp.net txt @1.1.1.1 [...] ;; ANSWER SECTION: whoami.ds.akahelp.net. 20 IN TXT "ns" "2400:cb00:80:1024::a29e:f134" whoami.ds.akahelp.net. 20 IN TXT "ip" "2400:cb00:80:1024::a29e:f134" whoami.ds.akahelp.net. 20 IN TXT "ecs" "111.250.0.0/24/24"
然後 168.95.1.1 則是連 ECS 都不給 XDDD
$ dig whoami.ds.akahelp.net txt @168.95.1.1 [...] ;; ANSWER SECTION: whoami.ds.akahelp.net. 20 IN TXT "ns" "2001:b000:180:8002:0:2:9:114"
之前在找 DNS 類問題的時候還算可以用的工具...
在「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」這邊引用的文章本來在討論又多了一家免費的 SSL certificate 可以用，但結果討論的主力都在講除了 Certbot 外還有什麼比較好用...
大家之所以厭惡 Certbot，先不講他需要依賴一堆 Python 的套件包，最主要的問題在於現在 Certbot 官方建議的指引裡面都要求你裝 Snap，而 Snap 這東西超級吃資源...
既然是資源問題，裡面可以看到 Dehydrated 又被拿出來推薦了，另外也有提到 acme.sh，不過我個人不太愛 acme.sh，主要是預設值跑去用 ZeroSSL 的 CA。
這種單檔就可以跑的很適合包進像是 Ansible 這類的管理工具，至少目前用起來沒什麼大問題...
前幾天在 Hacker News 首頁上看到的東西，而且也是當天熱度超高的話題，Open Source 且非 Electron 版本的 Spotify 播放器 Psst：「Psst: Fast Spotify client with native GUI, without Electron, built in Rust (github.com/jpochyla)」。
因為使用 Rust 與 native GUI library，加上沒有一堆 Spotify 內建的廣告系統，整個速度快到爆炸 XDDD
專案的擁有者 jpochyla 在「make provided binaries more prominent #89」這邊有提到有 nightly build 可以用：「nightly.link | Repository jpochyla/psst | Workflow build.yml | Branch master」，不過我抓下來發現不會動，所以就自己花了些時間編看看...
剛被推上 Hacker News 的時候 README.md 上的指示還沒那麼清楚，編不起來，後來這兩天陸陸續續被修正了。
桌機是 Ubuntu 20.04，而用 Ubuntu 20.04 內包的 rustc (1.51.0) 是沒辦法編的，需要自己先透過 rustup 裝新版 1.54.0 來編，基本上照著 README.md 的指示先把 dependency 裝起來，然後照著對應的指令操作就可以了。
這樣之後聽音樂方便不少...
在 Hacker News Daily 上看到的：「Official Elasticsearch Python library no longer works with open-source forks (github.com/elastic)」，連結所指向的是 GitHub 上的 pull request，在「Verify connection to Elasticsearch #1623」這邊。
講白了也就是 Elasticsearch 官方的 Python client 開始阻擋 AWS 主推的 OpenSearch。
另外 AWS 這邊也出手，把本來的 client 都 fork 出來：「Keeping clients of OpenSearch and Elasticsearch compatible with open source」，這場戰爭還有得打...