64-bit time_t 的事情

看到「The perils of transition to 64-bit time_t (gentoo.org)」這篇，原文在「The perils of transition to 64-bit time_t」，Gentoo 的人在討論將 time_t 從 32-bit 換成 64-bit 遇到的困難。

這邊會想把 32-bit time_t 換到 64-bit time_t 的動力是 32-bit 的 time_t 會在 2038 年遇到 integer overflow，這是接下來的十幾年得想辦法的問題。

不過有意思的是 id=41684857 這邊提到了，當初 FreeBSD 在 porting amd64 時 (大約二十年前) 就直接把一堆變數換成 64-bit 了，其中也包括了 time_t，從第一天解決掉相容性的問題：

Every time I see people struggling with this, I am so incredibly glad that I forced the issue for FreeBSD when I did the initial amd64 port. I got to set the fundamental types in the ABI and decided to look forward rather than backward.

The amd64 architecture did have some interesting features that made this much easier than it might have been for other cpu architectures. One of which was the automatic cast of 32 bit function arguments to 64 bit during the function call. In most cases, if you passed a 32 bit time integer to a function expecting a 64 bit time_t, it Just Worked(TM) during the platform bringup. This meant that a lot of the work on the loose ends could be deferred.

We did have some other 64 bit platforms at the time, but they did not have a 64 bit time_t. FreeBSD/amd64 was the first in its family, back in 2003/2004/2005. If I remember correctly, sparc64 migrated to 64 bit time_t.

這算是個 Day 1 沒換就會有技術債包袱的問題 (遲早還是得換)，只是要討論哪種善後的方式是可以接受的。

BCD Watch：觀察 MDN 的 Browser Compatibility Data 有什麼變化

看到 Eric Meyer 弄了 BCD Watch 觀察 MDN 上面的 Browser Compatibility Data 變化：「Announcing BCD Watch」。

看起來是每個禮拜更新一次，而網站有提供 RSS feed 可以訂閱，所以不用自己一直跑去翻。

這種網站果然是掛在 GitHub Pages 上面 (+ GitHub Actions)，專案則是在 https://github.com/bkardell/bcd-watch 這邊可以看到。

AWS Payment Cryptography

在看「How to migrate 3DES keys from a FIPS to a non-FIPS AWS CloudHSM cluster」這篇的時候看到一個沒有印象的服務，叫做 AWS Payment Cryptography，查了一下是去年推出的新服務：「New – Move Payment Processing to the Cloud with AWS Payment Cryptography」。

這個服務從名字大概知道跟金流用到的密碼學演算法有關，從「What is AWS Payment Cryptography?」這頁可以看到是把 HSM 的部分包起來：

AWS Payment Cryptography is a managed AWS service that provides access to cryptographic functions and key management used in payment processing in accordance with payment card industry (PCI) standards without the need for you to procure dedicated payment HSM instances.

另外從文件上可以看到圍繞在很多 PCI SSC 發佈的標準，所以理論上自己兜 AWS CloudHSM 或是 AWS KMS 應該都是可以用的，只是自己實作的部分就得另外 auditing？

AWS CloudHSM 的 compliance 資訊在「Compliance」這邊，可以看到 CloudHSM 在服務層級上掛了 PCI DSS、PCI PIN (看起來是個資相關) 以及 PCI-3DS。

而 AWS KMS 的 compliance 資訊在「Compliance validation for AWS Key Management Service」這邊，可以看到 KMS 主要就只有 PCI DSS 的報告部分。

也許 AWS KMS 在這塊上面能提供的功能比較少？

除了 PCI compliance 相關的整合外，另外一個切入點應該是價錢的部分，CloudHSM 因為就是租硬體，一個單位就是 US$1.6/hr，一個月就是固定 US$1152/mo 在燒；而 AWS Payment Cryptography 則是只收 US$1/mo 的 active key 費用，然後每 10k call 收 US$2，換算下來是每個月 5.7M API call 左右會跟一個 CloudHSM 差不多。

看起來交易量沒有很大的情況下也還不錯？如果兩邊在功能上是有辦法等價交換的話...

GKE 在推廣拿 240.0.0.0/4 來當 Private IP 用

看到「Leveraging Class E IPv4 Address space to mitigate IPv4 exhaustion issues in GKE」這篇，GKE 在推 240.0.0.0/4 當作 Private IP 用，可以看到文章裡面一直在說 240.0.0.0/4 跑起來沒有什麼問題，也可以透過 NAT 連到 internet 上的其他服務...

看到想用 240.0.0.0/4 大概是 10.0.0.0/8 不夠用的概念，本來一開始腦袋閃過去是 65536 個 IP 不夠用 (心裡覺得「喔在 microservice 架構下公司大一點，把 container 開成這樣好像也合理」)，突然發現不對，10.0.0.0/8 是三個 256 的乘積，是 16M 個 IP address...

16M 的 IP address，如果一個 IP address 對應到一個 container，以 Google 在 2023 年全球有 182K 員工來看，平均下來每個員工可以開 87 個 container？(不能再多了？)

有這樣的概念後回頭讀這篇還蠻「有趣」的...

AWS 推出了 c8g 與 m8g 機種

AWS 宣布了新的 c8g 與 m8g 產品線：「Introducing Amazon EC2 C8g and M8g Instances」、「Run your compute-intensive and general purpose workloads sustainably with the new Amazon EC2 C8g, M8g instances」。

比較特別的是沒有提到 CPU 效能提升的數據 (通常在發表 c 系列時都會提)，在 2022 年推出 c7g 時的「New – Amazon EC2 C7g Instances, Powered by AWS Graviton3 Processors」有提到：

Our next generation, Graviton3 processors, deliver up to 25 percent higher performance, up to 2x higher floating-point performance, and 50 percent faster memory access based on leading-edge DDR5 memory technology compared with Graviton2 processors.

不確定是不同作者之間的寫作風格？不過這種效能數字應該是重點...

翻了一下本來的作者 Sébastien Stormacq 與這次的作者 Veliswa Boya，從 LinkedIn 上看不太出來什麼資訊。

Anyway 回來看價錢的話，看 c7g.16xlarge (c7g 中最大台的) 是 US$2.32/hr，對應到 c8g.16xlarge 是 US$2.55232/hr，這次新架構大約就是貴 10%。

依照提到的內容，與效能改善有關的主要會是記憶體速度快 75%，以及兩倍的 L2 cache：

C8g and M8g instances offer larger instance sizes with up to three times more vCPUs (up to 48xl), three times the memory (up to 384GB for C8g and up to 768GB for M8g), 75 percent more memory bandwidth, and two times more L2 cache over equivalent 7g instances.

這兩個堆起來沒有 10% 成長嗎？也許等後續有人測試後會知道... (yeah，目前沒動力測？)

NIST 的密碼原則將禁止服務商要求「混合字元」

在「NIST to forbid requirement of specific passwords character composition (mastodon.social)」這邊看到的消息，出自 Fediverse 上的「Lukasz Olejnik: "GREAT change is approaching. NIST will standardis…" - Mastodon」這則，在講密碼規則中不得要求「混合字元」，像是要求要有「至少一個大寫 + 一個小寫 + 一個特殊符號」這樣的條件被禁止了。

現行的 NIST Special Publication 800-63B 是在 2017 年發表的第三版：「NIST Special Publication 800-63B」，這個版本關於混合字元的說明是 SHOULD NOT：

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

這次第四版 draft (目前可以在「https://pages.nist.gov/800-63-4/sp800-63b.html」這邊看到) 則是改成 SHALL NOT：

Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

這邊的 SHOULD NOT 與 SHALL NOT 有定義在文件開頭，這邊的定義與 RFC 2119 類似：

The terms “SHALL” and “SHALL NOT” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.

The terms “SHOULD” and “SHOULD NOT” indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.

也就是說從建議變成強制性的要求了。

NIST SP 800-63B 算是重要的 reference，我記得前陣子有看到社群在蒐集整理密碼要求，要送到政府單位當作外部意見的，裡面也是引用了不少 NIST SP 800-63B 的內容，但一時間沒找到... (好像是放在 HackMD 上？)

Automattic 與 WP Engine 打架中

請注意這邊是為了好理解的說明方式，時間線請自己對一下...

先用 Hacker News 這邊的背景說明當作開頭，在 id=41614406 這邊提到 WP Engine 的員工因為直接吐槽 WP Engine 的官僚不同意參與貢獻 WordPress (但先前有公開講會參與貢獻) 而被 fire：

It looks like people here are missing the context of the source of the issue between Matt and WP engine. Couple days ago he posted on X that wpengine has similar revenue to automattic, yet doesn’t contribute back to open source as much as they promised to (5 hour per week per employee or something like that). A wpengine employee replied to a post saying that management doesn’t allow them to contribute to WordPress open source because it doesn’t align with KPI targets. That employee got fired the next day. That’s when Matt’s issue with wpengine escalated.

另外的資訊是 Matt Mullenweg (WordPress 的專案發起人，以及 Automattic 的 CEO) 發了「WP Engine is not WordPress」這篇，接著是 WP Engine 發了 C&D letter 給 Automattic，然後也公告 X (Twitter) 上：

事情還在發展中，預期會有更多戳來戳去的情況。不過記得這畢竟是商業公司的互戳，雙方鐵定只會挑自己有利的講，不用太早下結論... 拿著爆米花桶看就好。

追 MediaWiki 頁面很慢的問題

我自己有個 wiki 拿來堆一些資料，前陣子覺得 Live 這頁很慢，實際測試發現要跑五秒多，想說到底是什麼鬼...

先從 MediaWiki 的各種 optimization 設定開始看，像是 Manual:Cache 這邊提到的東西，一路看下來看起來都已經設好最佳化了。

只好拿 profiling 工具來翻，在 PHP 上面用的是 Xdebug，裝了以後希望是特殊的情況才跑 profiling，所以參考了「Profiling」這邊的說明，在 php.ini 裡面這樣設定：

xdebug.mode=profile
xdebug.start_with_request=trigger
xdebug.trigger_value=StartProfileForMe

接著依照說明，你要找個地方把這個值傳進去：

Xdebug's profiler will only start when either the environment variable XDEBUG_TRIGGER is set to StartProfileForMe, the GET or POST variable XDEBUG_TRIGGER is set to StartProfileForMe, or when the cookie XDEBUG_TRIGGER has the value StartProfileForMe.

我是在網址列上直接用 ?XDEBUG_TRIGGER=StartProfileForMe 觸發，預設值會把 profiling 結果丟到 /tmp 下面，接下來就是把 callgrind 檔案視覺化了。

首先是把 xdebug 的 callgrind 格式輸出檔案轉成 DOT 格式，這邊參考「Interpreting callgrind data」的說明，先裝 gprof2dot，這個軟體在 PyPI 上有，所以可以用 pipx 裝，接著把 callgrind 轉完後再轉成 PNG 檔案。

我把圖放到最後面 (點開可以看大圖)，第一張是 Live 這頁的 profiling，第二張是 Hosting 這頁的。

我注意到在 Live 這頁 php::mysqli 這邊被呼叫了幾千次，這邊就算是本地端的資料庫，幾千次的 latency 累積起來還是很驚人，畢竟是跨 process 之間的溝通，而且已知是 ping-pong 要等待的情況。

接著去翻是什麼造成的，看起來跟 selectRow 有關，但線索到這邊就斷掉了，上面的 User->load 看起來並沒有 loop 導致大量呼叫 selectRow。

但至少有個方向，從網路上沒什麼討論看起來，應該不會是本體的效能問題，而是 extension 造成的，從這個角度開始追與帳號 & 權限有關的 extension，第一發懷疑是 Extension:AccessControl 造成的，結果果然沒錯... 拔掉後頁面的速度就從 5.1 秒左右降到 1.5 秒左右了。

沒有實際追程式碼，但猜測是 wiki 裡面用的 Template 造成 AccessControl 都會去檢查權限，加上這邊沒有上 cache，造成頁面上 Template 一多效能很差...

最後，這是 Live 頁的 profiling graph：

這是 Hosting 頁的 profiling graph：

Python 下追蹤程式建立哪些 HTTP(S) 連線的工具：httpdbg

在「Show HN: Httpdbg – A tool to trace the HTTP requests sent by your Python code (github.com/cle-b)」這邊看到的，看起來是作者自己貼到 Hacker News 上的。

作者開發了 httpdbg 套件，可以看 Python 程式有哪些 HTTP(S) 連線，看起來對於開發追蹤還蠻好用的。

從官網可以看到支援了常見的 HTTP(S) library，包括常用的 requests 以及其他套件。

不過特地想提的是看到 urllib3 這個套件，第一次看到這個東西... 這名字看起來就跟以前 Python 2 年代時搞出來的 urllib 以及 urllib2 有關？

Makefile 的雜事

看到「I Like Makefiles」這篇講作者喜歡 Makefile，看了一下裡面只是把 Makefile 當作堆 script 的應用，基本上也還 okay，如果把 dependency 設好的話其實會蠻好用的。

我想提的是另外一個小事情，我發現我好像沒寫過... make 這個指令剛好是「右手-左手-右手-左手」的節奏，打起來比起其他指令順很多，像是 JS 社群這邊 npm 全部都是右手，而 gulp 以及 grunt 也都沒有那麼順。

(我這邊指的是常用的 QWERTY 鍵位)

算是個打 make 的小確幸 (?)