Down	2026-04-21 15:47:27	PING 168.95.192.1 (168.95.192.1) 56(84) bytes of data. --- 168.95.192.1 ping statistics --- 47 packets transmitted, 0 received, 100% packet loss, time 47091ms
Up	2026-01-28 03:04:37	
Down	2026-01-28 03:02:14	PING 168.95.192.1 (168.95.192.1) 56(84) bytes of data. --- 168.95.192.1 ping statistics --- 47 packets transmitted, 0 received, 100% packet loss, time 47091ms
Up	2026-01-04 14:53:03	
Down	2026-01-04 14:52:03	PING 168.95.192.1 (168.95.192.1) 56(84) bytes of data. From 172.16.0.1 icmp_seq=17 Destination Net Unreachable --- 168.95.192.1 ping statistics --- 17 packets transmitted, 0 received, +1 errors, 100% packet loss, time 16385ms
Up	2025-09-18 03:20:02	
Down	2025-09-18 03:18:07	PING 168.95.192.1 (168.95.192.1) 56(84) bytes of data. --- 168.95.192.1 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 219ms
Up	2025-05-17 00:09:50	
Down	2025-05-17 00:05:17	PING 168.95.192.1 (168.95.192.1) 56(84) bytes of data. --- 168.95.192.1 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 203ms

新莊老家的倒是沒有被擋，理論上這組 DNS 服務應該是上 anycast 架構沒錯，但有這麼細嗎？

前幾天 CQD 在 Plurk 上提到可以用 status line 的功能把目前使用到的 context 大小顯示 status line 上面：(https://www.plurk.com/p/3ijzhoimal)

官方有列出來帶入 script 的資訊有哪些：「Customize your status line」，我自己是列了 model 資訊、context 資訊，還有 rate limit 資訊：

[Opus 4.6 (1M context)] ▓░░░░░░░░░░░░░░░░░░░ 6% | 5h (14:00): 15% | 7d (04/18 14:00): 30%

這樣的確是方便不少，而且有看到資訊就會記得三不五時 /clear 清一下 context。

Support for Encrypted Client Hello (ECH, RFC 9849). See doc/designs/ech-api.md for details.

記得目前 Cloudflare 已經在 service 端採用了，接下來愈來愈多 client 支援就會有更多人使用。

之前有提過，這個算是隱私基礎建設的一環，通常是搭著 DNS over HTTPS 或是 DNS over TLS 用，避免 ISP 得知流量的目的地。

在這之前算是團隊合作上面比較麻煩的一點，有些 PR 需要基於其他還沒有被併入 dev branch 的 PR，以往會需要透過 3rd-party 的工具來處理，像是 ejoffe/spr 這樣的工具，現在有機會轉成原生的。這功能等十幾年了...

在 0.x 版上面弄 LTS 好像是第一次看到，目前的計畫可以在「Servo LTS releases」這頁上看到，目前是叫做「best-effort LTS」：

Besides our monthly releases, the Servo community provides best-effort long-term support (LTS) releases.

然後每六個月一版，支援九個月，只處理 security 相關的問題：

A new LTS release / branch is introduced every 6 months, based on the current regular release at the time.

The expected support duration is 9 months, giving embedders time to migrate to the next LTS release.

The LTS release will receive security fixes only.

看起來是讓一些想開始測試的開發者可以有比較穩定的環境可以用。

無條件基本頻寬的設計跟「無條件基本所得 (Unconditional Basic Income)」有點像，中文版維基百科提到的這段：

《世界人權宣言》第二十五條揭示：「人人有權享受其本人及其家屬康樂所需之生活程度，舉凡衣、食、住、醫藥及必要之社會服務均包括在內；且於失業、患病、殘廢、寡居、衰老或因不可抗力之事故致有他種喪失生活能力之情形時，有權享受保障。」

「無條件基本頻寬」有點是把網路連線 (取得資訊的權利) 也當作基本人權的一環的延伸。目前南韓提出來的方案是，無論是什麼方案用完頻寬後，都應該提供 400kbps 的頻寬：(可以丟到 AI 工具裡面讓他翻譯)

官方的新聞稿：「2만 원대 5G 출시…데이터 소진 시에도 메신저·지도검색 등 가능 (2萬韓元左右的 5G 方案登場……即使數據用完，仍可使用通訊軟體、地圖搜尋等功能)」、「'데이터 소진되어도 연결은 지속' 언제든 기본적인 데이터 이용을 보장하는 요금제 개편 추진 (「即使資料用完也會持續連線」 推動資費方案改革，確保隨時都能基本使用數據服務)」。

20k 韓元大約台幣 $50 左右？400kbps 對非影片類的應用來說還算 OK，這邊提到 IM 與地圖應該是堪用。

如果考慮到影音，會用 400kbps 方案的主力族群，Android 手機的硬體支援度目前應該還是只能先考慮到 VP9 而非 AV1？對 YouTube 的應用來說，400kbps 的流量應該有機會用到 360p，在手機上加減算是能看？如果是軟解 AV1 的話 (比較耗電) 有機會上 480p。

400kbps 這個數字在這個時間點算是抓的還不錯？

Lambda 的 vCPU 與 RAM 的比例接近 EC2 c 系列的分配，所以比較的時候就拉 c 系列出來看。先是美東 us-east-1 (以及美西 us-west-2，一樣的價錢)：

c5a.large (2 vCPU + 4GB RAM) 是 $0.077/hr，Lambda 是 $0.24/hr，ratio 是 3.12；ARM 的 c6g.large 是 $0.068/hr，Lambda 是 0.192/hr，ratio 是 2.82。

再來是東京 ap-northeast-1：

c5a.large 是 $0.096/hr，Lambda 是 $0.24/hr，ratio 是 2.5；c6g.large 是 $0.0856/hr，Lambda 是 $0.192/hr，ratio 是 2.24。

再來是新加坡 ap-southeast-1：

c5a.large 是 $0.088/hr，Lambda 是 $0.24/hr，ratio 是 2.72；c6g.large 是 $0.0784/hr，Lambda 是 $0.192/hr，ratio 是 2.45。

前面幾區的 Lambda 價錢都一樣，差異都是在 Amazon EC2 上。然後是台北 ap-east-2，這邊因為是新的區域，沒看到 c?a 這些 AMD 的機種，所以用 Intel 的來算：

c6i.large 是 $0.0963/hr，Lambda 是 $0.216/hr，ratio 是 2.24；c6g.large 是 $0.077/hr，Lambda 是 $0.1728/hr，ratio 是 2.24。

okay，接下來是結論的部分。

在抓感覺時要用倍數等級的差距來想：美國區會高一些，亞洲區會低一些，再加上 request 本身也要錢 + 啟動本身也有 overhead，更不用說非設備 cost 部分的考慮 (像是 vendor lock-in issue)，可以知道量夠大的時候不划算，搬回 EC2 instance 會省不少，更不用說還有 t 系列的機器可以參考進來用。

看起來適合的場景只有在瞬間與一般時間的量差距很大，而且無法等 EC2 instance 開起來的情況，而且這邊要差到 t 系列的 credit 也不夠補... 也許是搶票架構的售票系統？平常的量低到開兩台 HA 都有點浪費，但接近活動的時候就需要開一堆機器起來，卻又很難預估要開多少才夠。

另外一種是用量極低 (像是 cron job 每個小時跑個一次的任務)，但又需要 HA 架構。

一般的 cache 機制會把熱門的項目 cache 住，但 bot 砍站的機制會導致很多冷門的東西塞進 cache，造成熱門的項目能放的空間變少，這個算是已知的問題。

在 Cloudflare 的文章裡面看到了兩個演算法，SEIVE 與 S3-FIFO：

For mixed human and AI bot traffic, however, our initial experiments indicate that a different choice of cache replacement algorithm, particularly using SEIVE or S3FIFO, could allow human traffic to achieve the same hit rate with or without AI interference.

裡面兩個連結到的網站長的超像，發現幾乎是同一批人發展出來的，SEIVE 是：

Yazhuo Zhang
Juncheng Yang
Yao Yue
Ymir Vigfusson
K. V. Rashmi

而 S3-FIFO 是：

Juncheng Yang
Yazhuo Zhang
Ziyue Qiu
Yao Yue
Rashmi Vinayak

看起來有四個人重複。

後來提出來的 SEIVE 比較新，而且實作上也比 S3-FIFO 更簡單，兩者的效能差不多。

可以看到這兩個演算法相比於老牌的 LRU 都好不少，看起來是 2023 與 2024 年發表的，算是 AI 興起後研究出來的演算法？

之前的方法要換掉系統的 window manager，甚至要關掉 SIP 就不是很喜歡，就一直忍受著這個問題，這也是我不是很愛在 macOS 上開發的原因之一。

這次看到的方案是 InstantSpaceSwitcher 這個專案，他不是直接解決觸控板左右翻的時候的動畫，而是用快速鍵的方式設定切換 Space 的方式，測了一下確實有效果，而預設的 shortkey 也還行，學一下肌肉記憶就好，總算是有還可以的 workaround 了。

一個是 Google 的進展：「Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly」，裡面提到的新算法大幅減少了解 ECDLP-256 所需的 physical qubit 到 500k 個，比起在這之前已知的算法大約減少了 20 倍：

Specifically, we have compiled two quantum circuits (a sequence of quantum gates) that implement Shor's algorithm for ECDLP-256: one that uses less than 1,200 logical qubits and 90 million Toffoli gates and one that uses less than 1,450 logical qubits and 70 million Toffoli gates. We estimate that these circuits can be executed on a superconducting qubit CRQC with fewer than 500,000 physical qubits in a few minutes, given standard assumptions about hardware capabilities that are consistent with some of Google’s flagship quantum processors. This is an approximately 20-fold reduction in the number of physical qubits required to solve ECDLP-256 and a continuation of a long history of gradual optimization in compiling quantum algorithms to fault-tolerant circuits.

Google 這邊有個比較特別的是透過 zero-knowledge proff 證明自己有這個算法，但不用實際把這個算法提供給外部：

Second, we substantiate our resource estimates without sharing the underlying quantum circuits by publishing a state-of-the-art cryptographic construction called a "zero-knowledge proof", which allows third parties to verify our claims without us leaking sensitive attack details.

另外一個是 Oratomic 的「Shor's algorithm is possible with as few as 10,000 reconfigurable atomic qubits」這篇，直接對目前最常用的 P-256 下手，提到了新的方法大幅降低了 physical qubit 的數量到 26k 個，而 RSA-2048 看起來也是已經在射程範圍內了：

Here, by leveraging advances in high-rate quantum error-correcting codes, efficient logical instruction sets, and circuit design, we show that Shor’s algorithm can be executed at cryptographically relevant scales with as few as 10,000 reconfigurable atomic qubits. Increasing the number of physical qubits improves time efficiency by enabling greater parallelism; under plausible assumptions, the runtime for discrete logarithms on the P-256 elliptic curve could be just a few days for a system with 26,000 physical qubits, while the runtime for factoring RSA–2048 integers is one to two orders of magnitude longer.

這些算法上的進展算是強迫加密協定加速導入 PQC 了。