把 MIT license 當歌詞寫歌...?

在「AI-generated sad girl with piano performs the text of the MIT License (twitter.com/goodside)」這邊看到的推,把 MIT License 的條文當歌詞丟進去寫歌 (應該是最近很紅的 Suno.ai?):

WTF...

下雨天才會通的網路

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。

台灣 3G 網路的停用:2024/06/30

iThome 上面看到的消息,三大電信業者都將在 2024/06/30 停止 3G 網路:「中華電信、遠傳、台灣大將在6/30前關閉3G網路,手機不支援VoLTE將無法通話」。

翻了一下 iPhone 的部分,從 2014 年九月推出的 iPhone 6 就支援 VoLTE 了,差不多快十年了;這樣 Android 陣營應該也是差不多的時間才對...

到時候可以看看 iPhone 5s 的訊號會是怎麼樣... (應該會是完全沒訊號?)

拿 WireGuard 當作 SOCKS5 Proxy 的用戶端

pufferffish/wireproxyHacker News 上看到「Wireproxy: WireGuard client that exposes itself as a HTTP/SOCKS5 proxy (github.com/pufferffish)」這個有趣的東西,GitHub 上的專案頁在 pufferffish/wireproxy 這邊:

A wireguard client that exposes itself as a socks5/http proxy or tunnels.

不需要連上完整版本的 WireGuard VPN,而是透過 proxy 協定讓使用者可以使用,這樣配合瀏覽器的工具 (像是 SwitchyOmega) 可以很方便的設定各種變化,像是針對日本限定的網站走日本的 VPS instance 出去。

另外值得一提的是,這是一個 userland 而且不需要 root 權限的實作;這點蠻容易可以理解的,只是聽一個 TCP port 然後用 WireGuard protocol 跟遠端溝通,的確是不需要 root 權限。

另外在 Hacker News 的留言裡面還看到了 aramperes/onetun 這個工具,看起來是 server 端的實作,支援 TCP 與 UDP:

A cross-platform, user-space WireGuard port-forwarder that requires no root-access or system network configurations.

這兩個看起來剛好可以搭在一起...?

Gitea 預定淘汰掉 jQuery + Fomantic-UI + Semantic-UI,改用 Tailwind CSS

在「So long jQuery, and thanks for all the fish」這邊宣佈了 jQuery 的退役計畫,會改用 Tailwind CSS

We would like to celebrate the significant work done to remove a significant portion of jQuery in our codebase and the start of the switch to using Tailwind CSS.

We would also like to thank the creators and maintainers of jQuery, Fomantic-UI, and Semantic-UI which we have used for many years, and while the usage of these projects in Gitea will be going away, they have powered Gitea's interface for almost an entire decade.

不確定是不是一個好的方向,因為在這十年前端的「蓬勃發展」後,jQuery 其實比較起來變得非常輕量 (87KB,如果是 gzipped 後則是 30KB),而且從一開始 John Resig 就很在意執行速度,不像現在各種 framework 都是抽象再抽象,沒在管效能的...

目前應該會在 Gitea 1.22 亮相,到時候可以看看改出來的結果...

Cloudflare Workers 支援 Python (是 open beta)

Cloudflare 宣佈 Cloudflare Workers 支援 Python:「Bringing Python to Workers using Pyodide and WebAssembly」。

不過比較特別的是,並不是原生支援 Python 環境,而是透過轉譯成 WebAssembly 丟進 V8 engine 執行,就如同文章標題提到的。

另外是套件的部分,照這個文字的說明,應該不是所有的套件都可以丟進去用 (can import a subnet of popular Python packages),支援的套件看起來是預先 compile 好:

All bindings, including bindings to Vectorize, Workers AI, R2, Durable Objects, and more are supported on day one. Python Workers can import a subset of popular Python packages including FastAPI, Langchain, Numpy and more. There are no extra build steps or external toolchains.

看起來是打算全部都用 javascript 當作基礎?

UI Event 的順序

othree 寫了一篇「UI Event Order」在講滑鼠 (或是更廣廣義的 pointer 類) 以及鍵盤 (包括輸入法) 在瀏覽器上會產生的 event。

裡面有些是歷史 (提到 IE 上的實作方式),現在都不太會碰到了,可以直接看目前的幾份標準就好,然後蠻多標準都還是在 draft 階段,各家瀏覽器更新的速度不一樣,所以會有不同的行為冒出來。

我決定先把文章保留起來,等遇到的時候再回來看 XD

Redis 的眾多 fork

從「Redis 改變授權,變成非開源軟體」差不多過去一個禮拜了,瞬間冒出一卡車 Redis fork:「The race to replace Redis」。

文章裡提到的第一個是 Valkey,在 Redis 宣佈改變授權後幾天 fork 出來的。

第二個則是 KeyDB,是很久前就 fork 出來實作 multi-threading 的公司,後來公司被 Snap 買走後 open source,但因為 fork 的很早,後續 Redis 增加的功能就沒有跟上了...

第三個則是 Redict,這是 SourceHut 這邊的 fork 版本。

第四個不算是 fork,是微軟前幾天公開的 Garnet,用 C# 寫的,也因為不是 fork,相容性當然比不上前面幾個。

另外一個文章帶出來的重要資訊,是目前 Redis 的 contributor 分佈,可以看到其實 Redis 本家不算多,這樣 Redis 決定硬幹 BSL + SSPL 的決定就頗值得玩味了:

可以看看 Redis 接下來會不會有什麼重量級的功能要推出?

Proxmox 的 VMware 轉移方案

Hacker News 上看到「Proxmox VE: Import Wizard for Migrating VMware ESXi VMs (proxmox.com)」這篇,原文在「New Import Wizard Available for Migrating VMware ESXi Based Virtual Machines」這邊。

算是有比較簡單的方式 (在這邊是提供 wizard) 可以把現有跑在 VMware 上面的 VM 轉出來,就不用自己在 command line 下 export (dump) & convert & import (restore),光是把 storage 轉過去就弄半天,這對於不熟悉 CLI & script 的人方便不少。

話說二月時傳出 Broadcom 打算把買來的 VMware 的 C 端產品拆開來賣:「VMware's end-user compute unit reportedly headed to private equity firm KKR」,後續好像沒有看到新消息?不過 C 端目前的領頭者應該還是 VirtualBox?這樣看起來賣掉也不算太意外就是了...

AWS Lambda 的 cache 架構

Lobsters 上看到的老文章:「[Cache Architecture for] Container Loading in AWS Lambda」,原文從 url 看起來是去年五月發表的資訊了:「Container Loading in AWS Lambda」。

主要是在講 container 怎麼 load 才會儘快執行,首先是提到了大家常用的 layer cache,在 AWS Lambda 上則是改用了 block level cache:

Most of the existing systems do this at the layer or file level, but we chose to do it at the block level.

然後每一塊 512KB:

We unpack a snapshot (deterministically, which turns out to be tricky) into a single flat filesystem, then break that filesystem up into 512KiB chunks.

接著是提到 lazy load 的方式:「Slacker: Fast Distribution with Lazy Docker Containers」:

Our analysis shows that pulling packages accounts for 76% of container start time, but only 6.4% of that data is read.

Slacker speeds up the median container development cycle by 20x and deployment cycle by 5x.

而這個技巧也被用在 AWS Lambda 上,而且是透過 FUSE 實作:

In Lambda, we did this by taking advantage of the layer of abstraction that Firecracker provides us. Linux has a useful feature called FUSE provides an interface that allows writing filesystems in userspace (instead of kernel space, which is harder to work in).

另外一個 AWS Lambda 有實作的是 tiered caching,分成三層,包括了 worker 的 local cache (L1)、同一個 AZ 上的 cache (L2) 以及 S3 上的資料 (L3):

Despite our local on-worker (L1) cache being several orders of magnitude smaller than the AZ-level cache (L2) and that being much smaller than the full data set in S3 (L3), we still get 67% of chunks from the local cache, 32% from the AZ level, and less than 0.1% from S3.

也因為 L3 cache 是 S3 的關係,他們在 L1 與 L2 上就不用擔心 durability 的問題 (反正不見了就往後面找):

The whole set of chunks are stored in S3, meaning the cache doesn’t need to provide durability, just low latency.

但還是用了 Erasure code,儘量維持每個 cache tier 在自己 tier 裡面就可以找到資料的機率,這樣可以盡量降低 peak latency (於是造成 99.9%/99.95%/99.99% 的 SLO 不好看?):

Think about what happens in a classic consistent hashed cache with 20 nodes when a node failure happens. Five percent of the data is lost. The hit rate drops to a maximum of 95%, which is a more than 5x increase in misses given that our normal hit rate is over 99%. At large scale machines fail all the time, and we don’t want big changes in behavior when that happens.

So we use a technique called erasure coding to completely avoid the impact. In erasure coding, we break each chunk up into M parts in a way that it can be recreated from any k. As long as M - k >= 1 we can survive the failure of any node with zero hit rate impact (because the other k nodes will pick up the slack).

大概是本來比較簡單的三層架構在 benchmark 後發現無法達成對應的 SLO,所以就「補上」erasure code 拉高 SLO,從這邊就可以感覺到老闆的要求對於架構設計上的影響...

話說難得看到一些細節被丟出來...