幹壞事是進步最大的原動力
在「Reserving .INTERNAL for Private-Use Applications」這邊總算是看到通過保留 .internal 的決議了。
整個程序意外的長，大致上有幾個時間區塊，第一個區塊是 2020 年的時候提案以及告知相關單位 (IETF 以及 IAB)，並且得到配合的回覆。
然後就到 2022 年的時候 (2021 年不見了，不確定是不是與 COVID-19 有關) 收取公眾意見，2023 年又再收取一次意見，最後決定選 .internal 保留，然後 2024 年七月決議。
另外文件裡剛好提到「IANA-managed Reserved Domains」，看起來是由 IANA 管理的 reserved domains，可以看到很多 IDN...
堆了一陣子的消息，Google 將在 2025/08/25 停止 goo.gl 轉址服務：「Google URL Shortener links will no longer be available」。
2019 就已經停止新的網址了：「Transitioning Google URL Shortener to Firebase Dynamic Links」，要維持這個服務對 Google 來說不會花太多力氣 (以 Google 的規模來說)，但因為這對於賺錢 (尤其是 Ad) 沒有直接與間接幫助，還是被砍掉了...
看了一下 ArchiveTeam 的資料，應該是 URLTeam 這個計畫，看起來 2019 年就有人拉了一包了。
不過好像不太好找，他們應該是丟到 Internet Archive 上，不過 Internet Archive 上面找 goo-gl 看起來有點散？不確定丟上去的邏輯是什麼...
在「Engineering for Slow Internet (brr.fyi)」這邊看到的，這幾天還蠻紅的文章，在講網路受限的情況下要怎麼想辦法：「Engineering for Slow Internet」，作者是南極洲計畫 (USAP) 的 IT (目前已經回美國本土)。
主要的技術限制有幾個，第一個是對外網路的時間是有限的，因為受限於經過上空的衛星是有限的，這是 2023 年十月的一些資料：
可以看到主要是 DSCS (五顆服役中，但不是每科都有經過南極上空) 與 TDRS-6。
這個是物理限制，沒有 workaround 可以做，所以所有人都得照著對應的時段安排傳輸。不過應該有其他的衛星可以隨時聯絡 (emergency channel)，畢竟算是半個軍事計畫？
Hacker News 上也有人討論到 Starlink 好像還是有一些衛星會飛過南極洲，但不確定是否有 relay 的能力，如果有的話似乎也能考慮看看？(不過可能會需要客製天線，畢竟緯度的關係，設備需要的工作溫度區間不太一樣)
另外一個大問題是 latency，平均的 latency 是 750ms，而且 jitter 會到數秒：
Round-trip latency averaging around 750 milliseconds, with jitter between packets sometimes exceeding several seconds.
第三個是速度，一般使用者的平均網路速度大約是個位數的 kbps 到狀況好的時候大約是 2mbps，差不多是 1990 年代數據機的速度：
Available speeds, to the end-user device, that range from a couple kbps (yes, you read that right), up to 2 mbps on a really good day.
文章基本上就是圍繞這些問題在討論。
因為 latency 過高，而很多應用程式 (web 或是 app) 寫死 timeout，所以造成網路明明就有慢慢在傳輸資料，你放著慢慢傳遲早會傳完，但卻因為超時而失敗。
另外因為頻寬有限的問題，沒有提供續傳機制 (app 裡面沒做，或是沒有提供檔案直接讓有技術能力的人下載，像是 wget -c 這樣的工具) 就很容易因為失敗浪費頻寬。
另外是遇到軟體更新機制 (像是安全性更新) 無法下載檔案後直接安裝，都會有裝到一半中間要連網的事情。
另外一塊是現在太多工具太肥大，一個簡單的功能要先下載一包 20MB javascript 之類的 (然後換算一下前面提到的頻寬，在網路最好的情況下得花 80 秒下載這包 javascript)。
如果你的使用者族群包括了這類網路狀況不是很好的地區，這篇提到的蠻多東西都還蠻值得參考的。
在「The Internet Archive is under a DDoS attack (archive.org)」這邊看到 Internet Archive 被 DDoS 貓，原始連結在 https://mastodon.archive.org/@internetarchive/112513905401989149 這邊：
現在是有感覺到 loading 的速度不快 (不過以前就不快了)，然後 traceroute 看起來有輕微的 packet loss...
記得 Internet Archive 的頻寬一直都是滿的 (翻到 2020 年時有提到的「Internet Archive 的頻寬...」)，對於以灌流量的 DDoS 攻擊是沒什麼抵抗力的。
以他們家的情況來看，大概只能請上游幫忙擋？
2023 年的時候在北韓的 internet 上發現一台沒有設定好的伺服器，於是就有人 dump 下來分析裡面的內容，然後就發現看起來是中國的團隊轉包給北韓團隊用的 server：「What We Learned Inside a North Korean Internet Server: How Well Do You Know Your Partners?」。
像是這張圖，可以看到上面有「EKACHI EPILKA」，這查一下可以查到「株式会社エカチエピルカ」，另外也可以看到簡體中文以及韓文的說明：
雖然拼圖不夠完整，但應該是可以看出輪廓了：目前比較像的情況應該是中國拿到合約後轉包給北韓的團隊，這對於有在關注日本動畫產業的人來說應該也不算太意外，日本的動畫產業已經是高度分工，自己國家內二包三包本來就很常見，如果是先包到中國，再分包到北韓的話也不算太奇怪：
There is no evidence to suggest that the companies identified in the images had any knowledge that a part of their project had been subcontracted to North Korean animators. In fact, as the editing comments on all the files, including those related to US-based animations, were written in Chinese, it is likely that the contracting arrangement was several steps downstream from the major producers.
不過法律上就有些狀況了，北韓應該是被制裁對象...
在 Hacker News 上看到「The Wi-Fi only works when it's raining (predr.ag)」，原文是「The Wi-Fi only works when it's raining」，基於文章的發表日期，雖然作者宣稱是 true story，但我還是沒辦法確定... 但內容還蠻有趣的：
Happy April 1st! This post is part of April Cools Club: an April 1st effort to publish genuine essays on unexpected topics. Please enjoy this true story, and rest assured that the tech content will be back soon!
文章裡面提到作者的老爸是工程師，他老爸自己開的公司跟家距離算近，所以他老爸用指向性天線，把公司的商用 internet 橋接到家裡用，用了十年都沒什麼問題，但最近幾個禮拜開始只有下雨天才會通？
這聽起來蠻反常的，下雨應該只會讓訊號更差才對...
直接跳到最後的揭曉，原因是鄰居的樹在這十年內長高擋到訊號了，而下雨天會讓植物稍微垂下來，於是下雨天時訊號就通了...
作者的解法則是升級設備，把本來 802.11g 的設備換成 802.11n 的設備，抗干擾的能力更好 (這邊應該是指 coding & 5GHz)：
We replaced our old 802.11g devices with new 802.11n ones, which took advantage of new magic math and physics to make signals more resistant to interference.
另外作者文章用的子標題應該是與 Five stages of grief 相關，不過文章裡是 Denial-Bargaining-Determination-Debugging-Realization。
昨天的「What's that touchscreen in my room? (laplab.me)」這篇頗有趣的，原文「What's that touchscreen in my room?」是在租屋處看到牆上有一片平板，研究這到底是什麼的文章：
作者在一包文件裡找到手冊以後 (應該是屋主當初直接拿給他的一包文件？)，知道這是 NetThings 的設備 (看起來已經是歷史了，這邊留個 LinkedIn 上的連結...)：
然後連了半天發現連不上，到公共區域發現他還有一台主機要打開，但因為沒有保險絲，所以沒通電：
在裝了保險絲開機之後就是黑這台機器的過程...？
在各種嘗試中得知，port scan 過程發現有 tcf-agent 可以直接對檔案系統操作，首先是試著撈出 root 加密過的密碼來 john 但不順利，後來是發現可以修改 /etc/shadow 把 root 密碼清空，並且修改 /etc/ssh/sshd_config，就順利連上了這台機器...
這是一台 ARM9 的機器，有大約 118MB 的記憶體，而且 CPU 可以直接跑 Java bytecode (Jazelle)。
另外這台平板是 Android 5 的系統，透過 webview 從主機上拉狀態出來。
然後裡面有不少 (以現在來看) 古董：
Along with the Pulse app, there is the second part of the application. A Node.js app reads CSV files populated with energy usage data and displays them to the user in the web UI. It uses Node.js 0.10.26, Express.js 4.13.3 and Socket.io 1.3.6.
是個 2014/2015 年左右的產品...
llamafile 是昨天很紅的一個專案，由 Mozilla Internet Ecosystem (MIECO) 弄出來的專案，可以使用一個檔案直接跑起大型語言模型的 HTTP server，讓你可以在瀏覽器裡面直接使用。
直接看官方的 README.md 就可以蠻簡單的跑起來，不過 Simon Willison 也有寫一篇文章介紹一下，可以看看：「llamafile is the new best way to run a LLM on your own computer」。
這邊說的「一個檔案」是指同一個檔案同時可以在 Windows、macOS、Linux、FreeBSD、OpenBSD 以及 NetBSD 上面跑，而且這個檔案也把大型語言模型 (LLM) 的 model 檔案包進去，所以檔案會蠻大的，但畢竟就是方便讓人使用：
下載下來直接執行，預設就會在 port 8080 跑起來，可以直接連到 http://127.0.0.1:8080/ 連進去使用。
llamafile 用到的技術是 Cosmopolitan 專案，可以把多個平台的執行檔包在同一個檔案裡面使用。
另外用到的專案是 llama.cpp，這個蠻多人都用過了，可以很方便的用 CPU 或是 GPU 跑 LLM。
我在 Linux 上面跑剛好遇到幾個問題，都是在 README.md 上面有提到的。
第一個是 zsh 無法直接跑 llamafile (Ubuntu 22.04 內建 zsh 的是 5.8.1)，這邊官方的建議是用 sh -c ./llamafile 避開：
If you use zsh and have trouble running llamafile, try saying
sh -c ./llamafile. This is due to a bug that was fixed in zsh 5.9+. The same is the case for Pythonsubprocess, old versions of Fish, etc.
另外一個對是 GPU 的支援，這邊跟你說加上 --n-gpu-layers 35 就可以用，所以一開始先用 sh -c ./llamafile --n-gpu-layers 35 試著跑：
On Linux, Nvidia cuBLAS GPU support will be compiled on the fly if (1) you have the cc compiler installed, (2) you pass the
--n-gpu-layers 35flag (or whatever value is appropriate) to enable GPU, and (3) the CUDA developer toolkit is installed on your machine and the nvcc compiler is on your path.
但可以看到沒有被 offload 到 GPU 上面：
llm_load_tensors: ggml ctx size = 0.11 MB llm_load_tensors: using CUDA for GPU acceleration llm_load_tensors: mem required = 4165.47 MB llm_load_tensors: offloading 0 repeating layers to GPU llm_load_tensors: offloaded 0/35 layers to GPU llm_load_tensors: VRAM used: 0.00 MB
嘗試了不同的方法，發現要跑 sh -c "./llamafile --n-gpu-layers 35"，也就是把參數一起包進去，這樣就會出現對應的 offload 資訊，而且輸出也快很多：
llm_load_tensors: ggml ctx size = 0.11 MB llm_load_tensors: using CUDA for GPU acceleration llm_load_tensors: mem required = 70.42 MB llm_load_tensors: offloading 32 repeating layers to GPU llm_load_tensors: offloading non-repeating layers to GPU llm_load_tensors: offloaded 35/35 layers to GPU llm_load_tensors: VRAM used: 4095.05 MB
玩了一下像是這樣：
先前 Let's Encrypt 跟 IdenTrust 的 cross sign 會在 2024/10/01 到期，可以參考 3958242236 這邊的資訊，可以看到由 IdenTrust 的 DST Root CA X3 對 Let's Encrypt (ISRG) 的 ISRG Root X1 簽名，時間是到 2024/09/30 18:14:03 GMT (換算大概是台灣隔日的清晨兩點多)：
Issuer: (CA ID: 276)
commonName = DST Root CA X3
organizationName = Digital Signature Trust Co.
Validity
Not Before: Jan 20 19:14:03 2021 GMT
Not After : Sep 30 18:14:03 2024 GMT
Subject: (CA ID: 7394)
commonName = ISRG Root X1
organizationName = Internet Security Research Group
countryName = US
所以 Let's Encrypt 這邊也整理出了對應的落日計畫：「Shortening the Let's Encrypt Chain of Trust」。
第一波是 2024/02/08，從這個時間點開始 Let's Encrypt 的 ACME 服務預設組出來的 SSL certificate 將不會帶 IdenTrust 提供的 cross sign 憑證，但你還是可以自己另外設定取用：
On Thursday, Feb 8th, 2024, we will stop providing the cross-sign by default in requests made to our /acme/certificate API endpoint. For most Subscribers, this means that your ACME client will configure a chain which terminates at ISRG Root X1, and your webserver will begin providing this shorter chain in all TLS handshakes. The longer chain, terminating at the soon-to-expire cross-sign, will still be available as an alternate chain which you can configure your client to request.
再來是過期前的 90 天多一點的 2024/06/06，Let's Encrypt 的 ACME 服務將不會提供 cross sign 的憑證：
On Thursday, June 6th, 2024, we will stop providing the longer cross-signed chain entirely. This is just over 90 days (the lifetime of one certificate) before the cross-sign expires, and we need to make sure subscribers have had at least one full issuance cycle to migrate off of the cross-signed chain.
最後就是過期的日子 2024/09/30：
On Monday, September 30th, 2024, the cross-signed certificate will expire. This should be a non-event for most people, as any client breakages should have occurred over the preceding six months.
依照說明，應該是 Android 7.0 以及之前的版本會產生問題，照目前的數字看起來是 100% - 93.9% = 6.1%：
接下來一年應該會再低一些，但不確定會低多少，有機會 <5% 嗎？
前幾天在 Hacker News 上看到的討論，有人在問有沒有不需要連網，也不希望透過 app 連的 IP cam：「Ask HN: IP cameras that don't require an app or internet?」。會在意隱私性的人應該會有興趣。
討論裡面意外看到幾個台灣廠商，首先是翻到 GeoVision，奇偶科技：
Geovision cameras are low end and not expensive. They are Taiwanese in origin and are pretty easy to find.
這家的產品在台灣一般 C 端的 EC 通路沒找到，但蝦皮上有翻到一些資料；如果跑去美國的 Amazon 上面找可以看到不少商品，價錢似乎比較便宜？
另外一個是台達旗下的 VIVOTEK：
There's a Taiwanese brand Vivotek that makes some relatively affordable NDAA cameras. I'm hoping to try them out myself, but unfortunately haven't had time yet.
這家在 PChome 與 momo 上面都有擺一些商品，另外在蝦皮上就可以找到蠻多商品；在 Amazon 上面也不少商品。