幹壞事是進步最大的原動力
查資料的時候翻到的，寫 commit 常有 feat: 或是 fix: 這樣的 prefix，剛剛才突然想到這應該是有人訂規範的，翻了一下應該是「Conventional Commits」這個，裡面也引用了另外一個專案：「commitlint」。
所以 type 的部分可以有很多種類，剛剛前面提到的 feat: 以及 fix: 都在裡面：
build chore ci docs feat fix perf refactor revert style test
對於有規範用英文寫 commit log 的單位可以直接套用，不算太複雜。
馬上想到的好處大概是這樣對於 junior engineer 可以很自然的把 fix 與 feat 拆開 (其他的也類似)，而且對於 code reviewer 也可以注意變化。
在「Bots, so many bots (wakatime.com)」這邊看到的，原文在「Bots, so many Bots」這邊。
作者用釣魚的方式 (對 LLM 的 prompt injection) 以及分析的方式保守估算 ProductHunt 上面至少有 60% 的帳號是 bot，但也提到了一個悲哀的事實，想辦法讓機器人 upvote 以及留言，讓你得到更多正面的回饋，就有機會登上 newsletter 並且得到更多對「真人」的曝光：
Is launching on ProductHunt worth it? Even though most comments and upvotes are bots, there’s probably still some real humans using ProductHunt... maybe. If you pay the bots and get featured in the newsletter, my guess is more real humans will see your product.
yeah，這也是產業鏈...
前幾天看到「Amusing Ourselves to Death (2009) (archive.org)」這則，原文很久前就下架了，所以指到的是 Internet Archive 上的版本：「Amusing Ourselves to Death by Stuart McMillen - cartoon Recombinant Records」。
標題的兩部作品分別是 George Orwell 的 Nineteen Eighty-Four (所以常被簡寫成 1984，中文書名常用《一九八四》來翻譯)，以及 Aldous Huxley 的 Brave New World (中文書名常用《美麗新世界》來翻譯)，都是反烏托邦小說 (Dystopian novel) 的經典作品，需要讀過這兩部作品才比較容易理解這篇漫畫在講的比較。
最後面提到的：
這個角度的確是之前沒有想過的，有種在指出現在 (2009 年當時) 就已經是 Brave New World 的世界了，以 15 年後 2024 年的角度再回頭看就更明顯了...
整包故事大概都在「uBOL version updates missing in Firefox add-ons store #197」這邊了。
Raymond Hill (uBlock Origin 以及這次提到的 uBlock Origin Lite 的作者) 被 Mozilla 的 Add-ons Team 亂搞以後不爽，決定徹下 Mozilla Add-ons 平台上的 uBlock Origin Lite，改成自己 host。
先是「#issuecomment-2329365796」這邊提到他收到 Mozilla Add-ons Team 兩封信件，開頭就提到這是 manual review：
Your Extension uBlock Origin Lite was manually reviewed by the Mozilla Add-ons team in an assessment performed on our own initiative of content that was submitted to Mozilla Add-ons.
然後 Raymond Hill 提到三個 Mozilla 亂搞的問題，其中第三個我覺得是第一個的延伸，所以我這邊就只講第一個與第二個。
第一個是 Mozilla 指控他傳輸資料但卻沒有取得使用者同意：
Consent, specifically Nonexistent: For add-ons that collect or transmit user data, the user must be informed and provided with a clear and easy way to control this data collection.
這邊 Mozilla 提出來的檔案是 web_accessible_resources/googlesyndication_adsbygoogle.js。
第二個 Mozilla 指控的問題是放了 minified 的檔案但沒有提供 source：
Sources, specifically Sources or instructions missing: Your add-on contains minified, concatenated or otherwise machine-generated code. You need to provide the original sources, together with instructions on how to generate the exact same code used in the add-on.
這邊 Mozilla 提出來的檔案是 web_accessible_resources/fingerprint2.js、web_accessible_resources/google-analytics_analytics.js、web_accessible_resources/google-analytics_ga.js 以及 web_accessible_resources/googletagservices_gpt.js 這四個。
然後這五個檔案打開來看，完全可以同意 Raymond Hill 說明的，完全看不到 Mozilla 指控的東西。
最後是 Mozilla 的處置方法也超級奇怪，將除了最早的版本以外的所有版本都 takedown，但最早的版本也被 flag 上面五個檔案... 這樣就導致用戶會裝到一堆 bug 的版本，逼的 Raymond Hill 也得把最早的這個版本 disable。
最後他已經講的很客氣了：「I am unable to see this as a mistake」，原文大概是「他媽的你 Mozilla 故意搞事」：
@Rob--W I appreciate you trying to build a bridge, but as much as I have tried over and over, I am unable to see this as a mistake, it takes only a few seconds for anyone who has even basic understanding of JavaScript to see the raised issues make no sense, and that the steps taken (disable all but the oldest version instead of all but the most recent) were the worse for both the extension and new users interested in it.
看到「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 沒換就會有技術債包袱的問題 (遲早還是得換)，只是要討論哪種善後的方式是可以接受的。
看到 Eric Meyer 弄了 BCD Watch 觀察 MDN 上面的 Browser Compatibility Data 變化：「Announcing BCD Watch」。
看起來是每個禮拜更新一次，而網站有提供 RSS feed 可以訂閱，所以不用自己一直跑去翻。
這種網站果然是掛在 GitHub Pages 上面 (+ GitHub Actions)，專案則是在 https://github.com/bkardell/bcd-watch 這邊可以看到。
在看「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 差不多。
看起來交易量沒有很大的情況下也還不錯？如果兩邊在功能上是有辦法等價交換的話...
看到「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 產品線：「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 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 上？)