Threads 開放更多使用者進入 Fediverse

Meta 宣佈了讓更多 Threads 使用者進入 Fediverse:「Threads has entered the fediverse」。

目前是 beta 功能,然後有些限制條件:

Threads has entered the fediverse! As part of our beta experience, now available in a few countries, Threads users aged 18+ with public profiles can now choose to share their Threads posts to other ActivityPub-compliant servers.

直接丟 Threads 的 url 找 (像是 https://www.threads.net/@zuck 這樣) 在 Mastodon 上沒辦法找到,需要丟 @zuck@threads.net 這樣的 identifier 加。

另外文章裡面有提到支援了一些延伸的標準,像是 FEP-e232: Object Links 以及 _misskey_quote,這些「表態」應該也會對社群有重大影響,畢竟 Threads 就算是新加入 Federvise 的成員,但還是太大...

Tumblr 的 ActivityPub 進度

先前在「Threads 要放 ActivityPub 了?」這篇提到 Threads 要放行 ActivityPub,剛剛想到 Tumblr 這邊不知道在 re-org 後有什麼新消息,然後翻到 Matt Mullenweg 在 Tumblr 寫了 這篇

主要是交代有指派人做這件事情,但也先舖了一些理由... 所以看看 2024Q1 有沒有機會看到些東西?

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 有關。

目前最老的 BitTorrent 種子 20 年了:The Fanimatrix

The FanimatrixBitTorrent 種子是目前還活著的 BitTorrent 種子最老的,從 2003 年九月建立的種子,至今要 20 年了:「The World’s Oldest Active Torrent Turns 20 Years Old」。

在 2022 的報告裡面 BitTorrent 的流量大約是 2.91% (雖然這份報告本身有些地方很詭異,但就還是可以當個參考):「2022 Global Internet Phenomena Report」,在「BitTorrent is Still the King of Upstream Internet Traffic, But for How Long?」這邊也在討論 BitTorrent 的占比逐漸下降。

但這就是 open protocol 的特性,你沒辦法殺掉他,而且他在對應的領域還是活的很好...

Cloudflare 看 HTTP/3 的使用率

Cloudflare 利用自家平台分析過去一年 HTTP/3 的使用率:「Examining HTTP/3 usage one year on」。

首先是整體的使用率,看起來反而沒有什麼太大的變化?一上線就已經是巔峰的感覺?

然後各種 bot (像是搜尋引擎的 bot 或是 social media 的 bot) 看起來幾乎都沒有用 HTTP/3,少數的量應該都是實驗性質居多,唯一的例外是 LinkedIn 有試著在導入,可以看到慢慢的爬升:

看起來不算太順?

MariaDB 嘗試相容於 PostgreSQL 協定的產品

Twitter 上看到的消息,新聞在「MariaDB's Xpand offers PostgreSQL compatibility without the forking drama」這邊:

看起來是 SkySQL 的服務,這樣聽起來不像會 open source... 看起來賣點在於 globally distributed RDBMS 這個部分:

MariaDB is previewing a PostgreSQL-compatible front end in its SkySQL Database-as-a-Service which provides a globally distributed RDBMS on the back end.

再看看後續會不會有更多消息?

CPU Core 之間溝通的時間成本

Hacker News 上看到「Measuring CPU core-to-core latency (github.com/nviennot)」這篇,專案在「Measuring CPU core-to-core latency」這裡,看起來是個有趣的研究,測試許多不同 CPU 內,跨 core 之間溝通的時間花費。

依照專案的說明,測試的方式是利用 cache coherence 來來量測:

We measure the latency it takes for a CPU to send a message to another CPU via its cache coherence protocol.

By pinning two threads on two different CPU cores, we can get them to do a bunch of compare-exchange operation, and measure the latency.

裡面已經測了很多不同的 CPU,然後可以看到一些有趣的結果。

像是第一張圖片的「Intel Core i9-12900K @ 8+8 Cores (Alder Lake, 12th gen) 2021-Q4」這組,大家還蠻好奇 CPU #8 到底是怎麼一回事,跨 core 溝通的 latency 特別低,還特別找了 CPU 的 die 圖片看看:

另外一個是 AWS 上的 c6a.metal,機種是「AMD EPYC 7R13 @ 48 Cores (Milan, 3rd gen) 2021-Q1」,可以看到被分成了六個區塊:

接下來在 ARM 平台,在更多 CPU core 的 c7g.16xlarge 上,機種「AWS Graviton3 @ 64 Cores (Arm Neoverse, 3rd gen) 2021-Q4」,會看到更多不平均的現象:

早一點的 c6gd.metal 雖然也還是 ARM 的 64 cores 機種「AWS Graviton2 @ 64 Cores (Arm Neoverse, 2nd gen) 2020-Q1」,但可以看到很不一樣的 latency pattern:

大致上可以感覺到當 core 數愈多就會有很多技術上的瓶頸,導致不同 core 之間的溝通成本不一樣... 這個感覺跟當初學到 NUMA 的情況有點像。

TCP 標準被整理到 RFC 9293

看到「RFC 9293: Transmission Control Protocol (TCP)」這篇,主要是把本來分散在各個 RFC 的文件 (從 RFC 793 開始) 全部整理成一份,另外把一些已知的勘誤表放進來:

This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.

然後淘汰掉 (obselete) 一卡車 RFC 文件 XD

翻資料發現 2014 的時候 HTTP/1.1 被幹過一次類似的事情,不過是反過來被拆開:「HTTP/1.1 的更新」,這次把 RFC 2616 幹掉分成 RFC 7230RFC 7235

然後今年因為 HTTP 的關係又被幹了一次,這次 HTTP/1.1 又被整回來變成一份文件,但是把裡面的一些概念拆開:「HTTP 標準的翻新」。

其中 RFC 9110 定義 HTTP Semantics,RFC 9111 定義 HTTP Caching,然後 RFC 9112RFC 9113 拿來定義了 HTTP/1.1 與 HTTP/2,另外先把 HTTP/3 的號碼保留下來的 RFC 9114

不斷 refactor 以及加新功能的文件...

OxideDB:另外一套用 PostgreSQL 為底的 MongoDB 相容層

看到 OxideDB 這個專案:

OxideDB is a translation layer that works as a MongoDB database server while using PostgreSQL's JSON capabilities as the underlying data store.

跟之前提到的 MangoDB 有些淵源 (參考「MangoDB:拿 PostgreSQL 當作後端的 MongoDB 相容層」),順便提一下 MangoDB 後來被要求改名為 FerretDB:「MangoDB 改名為 FerretDB (雪貂)」。

主要的差異在於 OxideDB 只以 PostgreSQL 為底層,另外是用 Rust 寫的:

The project was heavily inspired by FerretDB and is on its early days. The main difference is that there is no intention to support any database other than PostgreSQL (FerretDB is also supporting Tigris) and it's written in Rust, as opposed to Go.

看起來大家都拿 PostgreSQL 在搞事,但這個專案裡面好像沒搜到 GIN 這個關鍵字,不知道是不是連 index 都沒下...