各家首頁 JavaScript 的大小

看到「JavaScript Bloat in 2024 (tonsky.me)」這篇在講各家首頁 JavaScript 的大小,原文在「JavaScript Bloat in 2024」這邊。

作者 Nikita Prokopov 創造了很多 open source project,我比較有印象的是 Fira Code,這篇比較像是他在抱怨現在的網站...

裡面站台一堆都是 10MB+ 的 JavaScript 在跑的,突然提到 P 站只有 1.4MB 的時候笑了出來 (在 Hacker News 的 comment 裡面也有人提到這個):

Compare it to people who really care about performance — Pornhub, 1.4 MB:

另外 Jira 也被拿出來鞭:

Here, Jira, a task management software. Almost 50 MB!

但趨勢看起來不可逆?現在開發網站一堆都搞前後端分離,用 JavaScript 產生出所有頁面,然後再想辦法補 SEO...

Martti Malmi 與 Satoshi Nakamoto 一些早期關於 Bitcoin 的信件

Martti Malmi 把早年與 Satoshi Nakamoto 的信件公佈出來:「Satoshi - Sirius emails 2009-2011」。

主要是因為作證而整理出來的:

I did not feel comfortable sharing private correspondence earlier, but decided to do so for an important trial in the UK in 2024 where I was a witness. Also, a long time has passed now since the emails were sent.

另外這些是有備份到的部分,在改成 @aalto.fi 的部分就沒備份到了:

The archive is incomplete and contains only emails from my address @cc.hut.fi. My university email addresses changed to @aalto.fi in early 2011, and I don't have backups of those emails.

這次公開的看起來共 260 封,從 2009 到 2011 的信件,算是新出土的史料... (?)

CloudFront 端出 Embedded Points of Presence

看到 CloudFront 的產品新聞稿:「Amazon CloudFront announces availability of Embedded Points of Presence」,AWS 在 CloudFront 上端出了 Embedded Points of Presence 服務,看名字就是更彈性的 CDN PoP,不過想知道更細節的東西得去看 FAQs 的部分...

從這段可以看到應該是 AWS 的 appliance,然後放到實體機房裡面提供服務:

These embedded POPs are owned and operated by Amazon and deployed in the last mile of the ISP/MNO networks to avoid capacity bottlenecks in congested networks that connect end viewers to content sources, improving performance.

比較特別的消息是,這個不會額外收費:

Q. Is there a separate charge for using embedded POPs?
No, there is no additional charge for using CloudFront embedded POPs.

另外這個服務會是 opt-in 選擇加入,但不需要額外設定 distribution,而且 CloudFront 會針對有 opt-in 的 distribution 自動混搭:

Embedded POPs are an opt-in capability intended for the delivery of large scale cacheable traffic. Please contact your AWS sales representative to evaluate if embedded POPs are suitable for your workloads.

No, you do not need to create a new distribution specifically for embedded POPs. If your workload is eligible, CloudFront will enable embedded POPs for your existing distribution upon request.

You don't have to choose between CloudFront embedded POPs or CloudFront POPs for content delivery. Once your CloudFront distribution is enabled for embedded POPs, CloudFront's routing system dynamically utilizes both CloudFront POPs and embedded POPs to deliver content, ensuring optimal performance for end users.

下一章「Compliance」的部分有提到 embedded POPs 是不包括在 PCI DSSHIPAA 以及 SOC 這些 compliance 的,所以也可以回頭看到在提到推薦掛上來的內容,有避開掉敏感服務,主要是以大家都會看到一樣的內容的東西為主:

Embedded POPs are custom built to deliver large scale live-streaming events, video-on-demand (VOD), and game downloads.

看起來有點像是 NetflixOpen Connect 或是 GoogleGGC,讓 ISP 或是 MNO 可以放 cache service 降低對外消耗的流量。

這應該會回到老問題,ISP/MNO 當然是希望 CloudFront 花錢放機器進來,不會是 ISP/MNO 自己申請放,這不是技術問題而是商業問題...

Google Groups 脫離 Usenet 系統

先前在「Google Groups 將在 2024/02/22 斷開與 Usenet 的連接」這邊提到的,Google Groups 在 2024/02/22 會斷開與 Usenet 的 NNTP peering,日子到了...

在 Google Groups 上官方更新 banner 訊息了:

從我自己架的 News Server 上也可以從 innreport 中 incoming feed 的各個指標看到差異了:

可以再觀察幾個月看看後續的量,原先使用 Google Groups 的人會跑來 Usenet 上面嗎?或是 Usenet 就繼續萎縮下去...?

Ubuntu 上 PPPoE 自動重撥的設定

tl;dr:在設定檔裡面除了 persist 外,還要加上 maxfail 0

中華 HiNet 家用方案有提供固一動七的 IPv4 address 可以用,我自己因為玩 DevOps/SRE 的項目,有個固定 IPv4 address 弄一台便當盒小主機跑個 Ubuntu 系統當 jump server (跳板機) 總是對於防火牆的設定比較友善。

家用方案的固定 IP 在網站上申請完以後,透過 PPPoE 撥號指定另外一組 username 拿到。

我遇到的問題時大多數斷線後會自己重連,但偶而就是不會,這次難得在土城家裡的主機發生,看 log 發現是 pppd 自己 exit 了:(時間是 UTC,大約是 2024/02/22 的早上三點多)

Feb 21 19:09:15 kennel pppd[716]: No response to 4 echo-requests                                                      
Feb 21 19:09:15 kennel pppd[716]: Serial link appears to be disconnected.                                             
Feb 21 19:09:15 kennel pppd[716]: Connect time 7434.5 minutes.                                                        
Feb 21 19:09:15 kennel pppd[716]: Sent 1240056869 bytes, received 1018762497 bytes.                                   
Feb 21 19:09:21 kennel pppd[716]: Connection terminated.                                                              
Feb 21 19:09:21 kennel pppd[716]: Connect time 7434.5 minutes.                                                        
Feb 21 19:09:21 kennel pppd[716]: Sent 1240056869 bytes, received 1018762497 bytes.                                   
Feb 21 19:09:21 kennel pppd[716]: Modem hangup                                                                        
Feb 21 19:10:27 kennel pppd[716]: Timeout waiting for PADO packets                                                    
Feb 21 19:10:27 kennel pppd[716]: Unable to complete PPPoE Discovery                                                  
Feb 21 19:11:32 kennel pppd[716]: Timeout waiting for PADO packets                                                    
Feb 21 19:11:32 kennel pppd[716]: Unable to complete PPPoE Discovery                                                  
Feb 21 19:12:37 kennel pppd[716]: Timeout waiting for PADO packets                                                    
Feb 21 19:12:37 kennel pppd[716]: Unable to complete PPPoE Discovery                                                  
Feb 21 19:13:42 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:13:42 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:14:47 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:14:47 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:15:52 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:15:52 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:16:57 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:16:57 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:18:02 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:18:02 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:19:07 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:19:07 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:20:12 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:20:12 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:20:12 kennel pppd[716]: Exit.

這邊算了一下「Unable to complete PPPoE Discovery」出現了十次,這種數字看起來就蠻可疑的,回頭去 pppd 的說明找 10 可以看到這段:

Terminate after n consecutive failed connection attempts. A value of 0 means no limit. The default value is 10.

接著網路上翻,在「How do I set a PPPoE connection to redial?」這邊看到有人也提到了這點:除了 persist 以外,也要記得改 maxfail...

RFC 9512:application/yaml

看到「RFC 9512: YAML Media Type」這個,原來還沒有註冊 application/yaml 啊...

另外在 media type 的文件裡面,意外的給出了安全性的建議:

Code execution in deserializers should be disabled by default and only be enabled explicitly. In the latter case, the implementation should ensure (for example, via specific functions) that the code execution results in strictly bounded time/memory limits.

這邊用的是 should 不是 SHOULD,所以當一般的英文句子在讀,而非具有規範性的敘述。

但還是給了預設關閉 code execution 的建議...

從 Backblaze 的年度報告裡看 HGST 的 4K 盤的問題

Backblaze 照慣例放出了年度報告,這次是 2023 年整年的回顧:「Backblaze Drive Stats for 2023」。

樣本數量少的跳過,這次比較特別的是可以發現 HGST 這邊 HUH721212ALN604 這顆樣本數破萬,而且 AFR 高到 3.69% 了:

他上面那顆 HUH721212ALE604 只差了一個字母 (N -> E),AFR 只有 0.95%,這個差距有點大。

拉了 datasheet 來確認:「Data Sheet: Ultrastar DC HC520 (He12)」,可以看到兩顆的規格幾乎一模一樣,唯一的差別是:

Format: Sector size (bytes)
4Kn: 4096
512e: 512

另外可以從「How to Read the Ultrastar Model Number」這邊看到 4Kn 與 512e 的說明:

E6 = 512e SATA 6Gb/s,
N6 = 4Kn SATA 6Gb/s

文章裡面沒有看到討論到這點,但好像很值得研究一下...?

測 IPv4 NAT VPS,以及架設 HTTPS Proxy

因為 AWS 開始收 Public IPv4 address 費用的關係 (而且頗貴,參考「AWS 將開始收取 IPv4 的 Public IP 費用」),我把其中一台主機改成只有 IPv6 address 後遇到不少問題 (在「把 AWS 上的 EC2 instance 改成 IPv6-only」這邊)。

由於有 proxy 的需求,剛好找機會玩一下 IPv4 NAT VPS... 這種 VPS 最基本的大概就是會給一個 IPv4 address 上 non-standard port 當作 SSH port,讓你可以連進去管理;另外通常會給 port forwarding 的功能,而且是固定不能換的,讓你可以開一些 port 出來用。

我的用途是 IPv6 address 的 proxy,所以要找有給固定的 IPv6 address 的,另外希望跑在日本,這樣其他用途也比較方便。

過年期間翻了一下找到 NAT VPS,有 256MB 跑個 proxy 類的應用應該還 OK,實際上是 256MB RAM + 64MB swap 的 OpenVZ 類環境,kernel 有到 5.2.0 還算堪用,上面可以選 Ubuntu 22.04 安裝。

費用的部分 US$7/year 還行,網路上是有看到 128MB RAM 的 機器,但這樣連裝東西都綁手綁腳的,太容易 OOM。

(剛拿到機器的時候還試著裝 Percona Server for MySQL,結果就 OOM 跑不完 setup 的流程,看起來得自己改設定混過去,但只是想確認 256MB RAM + 64MB swap 可以弄到什麼程度,就反安裝了...)

在上面把想測的東西測試完後,實際的 proxy 設定比較簡單... 先設定一個只有 IPv6 address 的 domain 申請 Let's Encrypt 的 SSL certificate,然後掛給 Squid 用。

然後在 IPv6-only 的機器上用 curl -v --proxy https://username:password@proxy-jp.example.com:12345/ https://home.gslin.org/robots.txt 確認沒問題後就可以把服務都掛過去。

有些服務會吃環境變數 HTTP_PROXYHTTPS_PROXY,有些是在設定檔內設定,基本上都是照著文件設就可以了。

我遇到的 application & library 都可以吃 HTTPS Proxy 協定,就沒什麼大問題... 如果有遇到不行的,也可以考慮在 Squid 裡面直接放行特定的 IPv6 address。

Go 的 net/http 在 1.22 的 routing 新功能

Gonet/http 在 1.22 引入了更方便的 pattern matching:「Routing Enhancements for Go 1.22」。

用官方的範例,現在可以處理路徑裡的參數了:

http.Handle("GET /posts/{id}", handlePost2)

後續可以透過 PathValue() 取出來:

idString := req.PathValue("id")

而優先順序則是依照吻合度定義:

The precedence rule is simple: the most specific pattern wins. This rule matches our intuition that posts/latests should be preferred to posts/{id}, and /users/{u}/posts/latest should be preferred to /users/{u}/posts/{id}. It also makes sense for methods. For example, GET /posts/{id} takes precedence over /posts/{id} because the first only matches GET and HEAD requests, while the second matches requests with any method.

但是當有重疊卻無法判斷相對吻合度的 rule 被加進去時,會直接 panic()

What if two patterns overlap but neither is more specific? For example, /posts/{id} and /{resource}/latest both match /posts/latest. There is no obvious answer to which takes precedence, so we consider these patterns to conflict with each other. Registering both of them (in either order!) will panic.

這的確是種方法啦... 而且留有之後處理的空間,真的有好的方法就可以把 panic() 的邏輯改成新的共識。

透過無線 WiFi 的監視器的問題

在「Wi-Fi jamming to knock out cameras suspected in nine Minnesota burglaries (tomshardware.com)」這邊看到的,原報導在「Wi-Fi jamming to knock out cameras suspected in nine Minnesota burglaries -- smart security systems vulnerable as tech becomes cheaper and easier to acquire」。

這個手法是把無線網路的頻寬塞爆 (或是放出干擾),這樣 security camera 就算拍到東西也不會有記錄:

這個應該是已知的問題?從以前 security camera 都是建議走有線 (以及 isolated VLAN),無線的主要還是娛樂用途,而不是 security camera...

以前還有印象有看過防 EMP 的型號,不過那個是軍用...