南極洲使用 Internet 的痛點

在「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)。

如果你的使用者族群包括了這類網路狀況不是很好的地區,這篇提到的蠻多東西都還蠻值得參考的。

Internet Archive 被 DDoS 攻擊

在「The Internet Archive is under a DDoS attack (archive.org)」這邊看到 Internet ArchiveDDoS 貓,原始連結在 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。

2014/2015 年的 Smart Home & IoT 裝置?

昨天的「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/shadowroot 密碼清空,並且修改 /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

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」。

這邊說的「一個檔案」是指同一個檔案同時可以在 WindowsmacOSLinuxFreeBSDOpenBSD 以及 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 Python subprocess, 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 35 flag (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 要結束了

先前 Let's EncryptIdenTrust 的 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% 嗎?

無 Internet 也能使用的 IP cam

前幾天在 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.

這家在 PChomemomo 上面都有擺一些商品,另外在蝦皮上就可以找到蠻多商品;在 Amazon 上面也不少商品。

Internet Archive 被打

Internet Archive 更新一篇文章,說明前幾天被打掛的事情:「Let us serve you, but don’t bring us down」。

有 64 台機器 (或是 64 個 IP) 從 AWS 打了幾萬 rps 進 Internet Archive:

Tens of thousands of requests per second for our public domain OCR files were launched from 64 virtual hosts on amazon’s AWS services. (Even by web standards,10’s of thousands of requests per second is a lot.)

然後擋掉這些 IP 後恢復正常,但過了幾個小時後又換 IP 被打了:

But, another 64 addresses started the same type of activity a couple of hours later.

找了一下之前有寫過「限制流量的方式 (rate limit)」這篇,裡面提到 Figma 怎麼處理,另外以前自己搞 apache module 後面接 memcached 達到跨機器統計的作法。

就 Internet Archive 的服務來說,是應該要搞個類似的東西來擋,不然可以預期會不斷發生?

備份 Xuite Blog 的公開文章

中華的 Xuite 前陣子宣佈了服務中止的公告:「Xuite隨意窩平台服務終止公告」(這邊就先拉 Internet Archive 的連結了,看起來之後會消失...)。

Blog 的部份,除了作者本身可以拉資料下來放到其他平台以外,外人也可以把這些歷史遺跡保留下來,像是丟到 Internet Archive 的 Wayback Machine 上面。

所以用 Perl 寫了一隻 script,把 url 掃出來後,後續就可以用其他工具 submit 到 Wayback Machine 上面:「xuite-urldump」。

當年有不少 ACG 相關的 blog 在上面,先來備份起來...