蘋果出手幹掉 Beeper Mini 了

前幾天在「Android 上與 Apple 生態系 iMessage 互通的 app」這篇提到的 Beeper Mini 被蘋果幹掉了：「Apple cuts off Beeper Mini’s access after launch of service that brought iMessage to Android」。

目前的 update 看起來要想辦法繞？

所以看起來蘋果的態度沒有要放，然後接下來應該會貓捉老鼠？不過蘋果的機器上面有硬體可以認證，真的把 iMessage 接上資料庫驗證的話應該就繞不過了...

Twitch 宣佈退出韓國市場

Twitch 宣佈 2024/02/27 (星期二) 退出韓國市場：「An Update on Twitch in Korea」。日期不知道是怎麼選的，可能跟某些合約有關？

Twitch 目前的公告會有繁體中文，也可以看這份：「Twitch 韓國現況更新」。

另外今天早上找了一下，Hacker News 也有討論了：「An update on Twitch in Korea (twitch.tv)」。

目前官方給出來的理由是虧本，而且找不到方法克服虧本的問題：

Ultimately, the cost to operate Twitch in Korea is prohibitively expensive and we have spent significant effort working to reduce these costs so that we could find a way for the Twitch business to remain in Korea.

這邊提到的包括了 p2p model 以及降到 720p，但即使如此網路費用 (應該就是頻寬費用) 是其他區域的十倍以上：

First, we experimented with a peer-to-peer model for source quality. Then, we adjusted source quality to a maximum of 720p. While we have lowered costs from these efforts, our network fees in Korea are still 10 times more expensive than in most other countries. Twitch has been operating in Korea at a significant loss, and unfortunately there is no pathway forward for our business to run more sustainably in that country.

在 Cloudflare 這邊，2016 年還叫做 CloudFlare 的時候也有抱怨過：「CloudFlare 對 HiNet 成本的抱怨 (還有其他 ISP...)」。

當年是這樣寫 HiNet 與 KT，成本大約是歐美區的 15 倍：

Two Asian locations stand out as being especially expensive: Seoul and Taipei. In these markets, with powerful incumbents (Korea Telecom and HiNet), transit costs 15x as much as in Europe or North America, or 150 units.

而尤其是韓國的部分，政府介入讓降價的速度比全世界慢，所以時間拉長後成本相較於其他地區就貴很多：

South Korea is perhaps the only country in the world where bandwidth costs are going up. This may be driven by new regulations from the Ministry of Science, ICT and Future Planning, which mandate the commercial terms of domestic interconnection, based on predetermined “Tiers” of participating networks. This is contrary to the model in most parts of the world, where networks self-regulate, and often peer without settlement. The government even prescribes the rate at which prices should decrease per year (-7.5%), which is significantly slower than the annual drop in unit bandwidth costs elsewhere in the world. We are only able to peer 2% of our traffic in South Korea.

不過不確定現在的情況，2016 年的 CloudFlare 跟 2023 年的 Cloudflare 已經差了七年了...

WFH 在美國的比重，以及舊金山辦公室的空屋問題

先講結論：COVID-19 前美國的 WFH (Work from home，或是 Remote work) 的比率大約在 5% 上下徘徊，在疫情開始暴增超過 60%，但到現在後疫情時期已經是常態性高過 25% 了。

報導是從「'Return to Office' declared dead」這邊看到的，裡面提到了今年九月發的 paper (可以免費下載)：「The Evolution of Work from Home」。

paper 的作者之一 Nick Bloom 在 X (Twitter) 上提到了目前看起來不同來源的結果是一致的：

先從他在九月時發的 paper 抓這張圖出來，裡面提到的 Census Household Pulse Survey 看起來是美國政府的「Measuring Household Experiences during the Coronavirus Pandemic」這份資料，時間是從疫情開始爆發後蒐集的 (2020/04/23)：

裡面有兩張圖，先看大的圖，可以看到 2000 年以後 WFH 是有緩慢上升，但也就是 5% 上下。而在疫情開始直接飆升，然後開始降回來。

接下來看小的圖，這是疫情開始的資料，疫情一開始非常高，到 60%+，但可以看到的確從 2021 年開始美國的 WFH 就平穩下來了，大約在 25%～35% 這邊，而且已經平緩下來了。

另外一篇要提的是從房地產的角度看的，報導是「San Francisco now at 35% office vacancy rate, highest ever recorded: data」這篇，提到舊金山辦公室的空房率達到歷史新高的 35%。

在加州的官網上有比較舊的資料 (資料來源不同，所以主要是看趨勢)，上面目前最新的資料可以看到 2023 年三月辦公室的空房率是 26% (這份資料裡面有提到最新資料大約晚一季到兩季)：「San Francisco Office Space Vacancy」。

算是不同方向的指標交叉看，看起來算一致。

Android 上與 Apple 生態系 iMessage 互通的 app

Hacker News 上兩篇相關的可以一起看，首先是 Beeper Mini，一套在 Android 上直接與 Apple 生態系 iMessage 相通的 app，而且不需要另外的 Apple 設備當作 Proxy：「Show HN: Beeper Mini – iMessage Client for Android (beeper.com)」。

另外先提一下，這是一套付費軟體 ($1.99/mo)，考慮到這算是 reverse engineering 後的產品，不確定 Apple 會不會反制，要付錢使用的人心裡先有個底：

We currently offer a 7 day free trial, afterwards there is a $1.99 per month subscription.

另外一篇相關的是「iMessage, explained (jjtech.dev)」，原文是今年八月的文章，應該就是 Beeper Mini 那篇而被貼出來的關係，在「iMessage, explained」這裡。

裡面解釋了他自己實作 pypush 時怎麼處理 iMessage 的部分：

This blog post is going to be a cursory overview of the internals iMessage, as I’ve discovered during my work on pypush, an open source project that reimplements iMessage.

專案裡面有提到 Apple 在這邊有段 obfuscated code，由於只有註冊階段需要用到，他選擇直接跑環境起來執行，產生出對應的 data 後就不用再跑，也就省掉 reverse engineering 這塊功夫：

pypush currently uses the Unicorn CPU emulator and a custom MachO loader to load a framework from an old version of macOS, in order to call some obfuscated functions.

This is only necessary during initial registration, so theoretically you can register on one device, and then copy the config.json to another device that doesn't support the Unicorn emulator. Or you could switch out the emulator for another x86 emulator if you really wanted to.

另外一個先前的消息是 Apple 說要支援 RCS：「Apple announces that RCS support is coming to iPhone next year」，目前大家的猜測是跟歐盟一直在要求 Apple 開放 iMessage 有關。

MySQL 5.7 已經 EoL

查資料發現忘記這件事情了... 先前就有寫過 MySQL 5.7 到今年十月就 EoL 了：「MySQL 5.7 的支援只到今年十月 (Oct 2023)」。

最後一版是 2023/10/25 釋出的 5.7.44：「Changes in MySQL 5.7.44 (2023-10-25, General Availability)」。

MySQL 5.7.44 is the final release of the MySQL 5.7 series.

然後 MySQL 8.1 也是十月 EoL。

雖然目前已經有 MySQL 8.2 了，但 MySQL 8.0 是 LTS，目前預定支援到 2026 年四月 (大約還有兩年多)，所以除非有需要用到 MySQL 8.2 的新功能或是特性，不然應該還是會先繼續用 MySQL 8.0...

然後翻了一下 Percona Server for MySQL，看起來還是沒有提供 ARM 的 binary 可以裝，所以在 ARM 上面的機器比較方便的還是裝 MariaDB 了...

Django 5.0

Django 5.0 的消息出來了：「Django 5.0 released」，比較完整的 release notes 則是在這邊：「Django 5.0 release notes」。

對應的 Django 4.2 因為是 LTS，會支援到 2026/04：

With the release of Django 5.0, Django 4.2 has reached the end of mainstream support. The final minor bug fix release, 4.2.8, was issued today. Django 4.2 is an LTS release and will receive security and data loss fixes until April 2026. All users are encouraged to upgrade before then to continue receiving fixes for security issues.

Django 5.0 比較大的 incompatibility 會是 Python 版本的要求：

Django 5.0 supports Python 3.10, 3.11, and 3.12. We highly recommend and only officially support the latest release of each series.

The Django 4.2.x series is the last to support Python 3.8 and 3.9.

關於 Python 版本的部分，交叉參考「Status of Python versions」這邊的說明，可以看到目前還在提供安全性更新 (狀態是 security) 的 3.8 (到 2024/10) 與 3.9 (到 2025/10) 在 Django 5.0 被放掉了...

現在 Django 的大版號更新比較像是常態性把有破壞相容性的更新整理起來出新版，倒不是動到什麼大結構...

Trino Gateway

先前一直有在追蹤 Trino 的 HA 方案：「High Availability #391」，昨天看到有人更新消息，提到 Trino Gateway 這個專案，以及九月底的時候的公告：「Trino Gateway has arrived」。

主要是從 Presto Gateway 整理出來的：

The release is the result of many, many months of effort to move the legacy Presto Gateway to Trino, start a refactor of the project, and add numerous new features.

原始的 Presto Gateway 專案上面也已經標示後續請大家去看 Trino Gateway：

NOTE: This is a legacy version of Trino Gateway. Please refer to https://github.com/trinodb/trino-gateway for active development and updates moving forward.

然後 Release notes 這邊可以看到前幾天又出一個新版了，看起來是有能量在專案上的。

從「Design」這頁可以看到軟體本身分成 BaseApp、ProxyServer 與 Gateway 三個部分，架構面上可以看得出來是 Proxy 架構。

從「References」這頁可以看到一些組織使用前身 Presto Gateway 的心得：

目前應該會需要一些時間，把積在 backlog 的功能開發出來。之後如果還有遇到 Trino 的話可以拿出來重新研究發展到什麼地方...

AMD Zen 3 與 Zen 4 上 FSRM (Fast Short REP MOV) 的效能問題

前幾天 Hacker News 上討論到的一篇：「Rust std fs slower than Python? No, it's hardware (xuanwo.io)」，原文則是在「Rust std fs slower than Python!? No, it's hardware!」。

原因是作者收到回報，提到一段 Rust 寫的 code (在文章裡面的 read_file_with_opendal()，透過 OpenDAL 去讀) 比 Python 的 code 還慢 (在文章裡面的 read_file_with_normal()，直接用 Python 的 open() 開然後讀取)。

先講最後發現問題是 Zen 3 (桌機版 5 系列的 CPU) 與 Zen 4 (桌機版 7 系列的 CPU) 這兩個架構上 REP MOV 系列的指令在某些情境下 (與 offset 有關) 有效能上的問題。

FSRM 類的指令被用在 memcpy() 與 memmove() 類的地方，算是很常見備用到的功能，這次追蹤的問題發現在 glibc 裡面用到導致效能異常。

另外也可以查到在 Linux kernel 裡面也有用到：「Linux 5.6 To Make Use Of Intel Ice Lake's Fast Short REP MOV For Faster memmove()」，所以後續應該也會有些改善的討論...

在 Ubuntu 這邊的 issue ticket 開在「Terrible memcpy performance on Zen 3 when using rep movsb」這，上游的 glibc 也有對應的追蹤：「30995 – Zen 4: sub-optimal memcpy on very large copies」。

從作者私下得知的消息，因為 patch space 的大小限制，AMD 可能無法提供 CPU microcode 上的 patch，直接解決問題：

However, unverified sources suggest that a fix via amd-ucode is unlikely (at least for Zen 3) due to limited patch space. If you have more information on this matter, please reach out to me.

所以目前比較可行的作法是在 glibc 裡面使用到 FSRM 的地方針對 Zen 3 與 Zen 4 放 workaround，回到原來沒有 FSRM 的方式處理：

Our only hope is to address this issue in glibc by disabling FSRM as necessary. Progress has been made on the glibc front: x86: Improve ERMS usage on Zen3. Stay tuned for updates.

另外在追蹤問題的過程遇到不同的情境，得拿出不同的 profiling 工具出來用，所以也還蠻值得看過一次有個印象：

一開始的 timeit 算是 Python 裡面簡單的 benchmark library：

接著的比較是用 command line 的工具 hyperfine 產生出來的 (給兩個 command 讓他跑)，查了一下發現在 Ubuntu 官方的 apt repository 裡面有包進去 (22.04+)：

再來是用 strace 追問題，這個算是經典工具了，可以拿來看 syscall 被呼叫的時間點：

到後面出現了 perf 可以拿來看更底層的資訊，像是 CPU 內 cache 的情況：

接續提到的「hotspot ASM」應該也還是 perf 輸出的格式，不過不是那麼確定... 在「perf Examples」這邊可以看到 function 的分析：

而文章裡的則是可以看到已經到 assembly 層級了：

差不多就這些...

蘋果的衛星 SOS 服務對 iPhone 14 用戶免費延長一年

去年十二月蘋果對 iPhone 14 開通了衛星 SOS 服務：「iPhone 14 的 Emergency SOS via satellite (衛星求救服務) 在北美開通」，然後蘋果決定延長一年：「Apple extends Emergency SOS via satellite for an additional free year for existing iPhone 14 users」。

而且看起來已經開放到十六個區域了：

Now also available on the iPhone 15 lineup in 16 countries and regions, this innovative technology — which enables users to text with emergency services while outside of cellular and Wi-Fi coverage — has already made a significant impact, contributing to many lives being saved. Apple today announced it is extending free access to Emergency SOS via satellite for an additional year for existing iPhone 14 users.

在「Use Emergency SOS via satellite on your iPhone」這邊有找到目前開放的地區，算了一下的確是十六個：

Emergency SOS via satellite is available in Australia, Austria, Belgium, Canada, France, Germany, Ireland, Italy, Luxembourg, the Netherlands, New Zealand, Portugal, Spain, Switzerland, the U.K., and the U.S.

北美洲 (美加) 與大西洋洲 (紐澳) 沒什麼問題，不過歐洲那些區域看起來偏西歐，有點像是衛星訊號的涵蓋性，另外可能還有當地法規的問題？不然以義大利與奧地利的涵蓋範圍，摩納哥與斯洛維尼亞看起來應該也是可以被涵蓋的...

jq 的開發狀況

在 Hacker News 上看到「Jaq – A jq clone focused on correctness, speed, and simplicity (github.com/01mf02)」這篇的時候，倒不是 jaq 本身如何，而是在 id=38465712 裡面提到了 jq 的發展停滯了五年左右，但最近又恢復了：

Well, taking into account that jq development has been halted for 5 years and only recently revived again, it's no wonder that bug reports have been sitting there for that time, both well known and new ones. I bet they'll get up to speed and slowly but surely clear the backlog that has built up all this time.

然後下面有提到 https://github.com/jqlang/jq/issues/2305#issuecomment-1572634869 這個，今年六月的時候開始重整團隊改善 bus factor，加入更多新的 maintainer 進來。

算是個好消息，朝向 community 的方式來發展...