FreeBSD 14.0 釋出

FreeBSD 14.0-RELEASE 的公告也出來了:「FreeBSD 14.0-RELEASE Announcement」,比較完整的 release notes 在「FreeBSD 14.0-RELEASE Release Notes」。

先從官方列的 highlight 來看,首先比較重要的是 GENERIC kernel 支援 1024 cores:

FreeBSD supports up to 1024 cores on the amd64 and arm64 platforms.

看了一下 commit log 是從 256 變成 1024

先就 x86-64 這邊來看,目前「家用」最多的應該是 AMD7995WX (96 cores),舊版的 256 限制應該也還能撐住,但看 commit log 有提到,主要是預期這幾年應該會有更暴力的機器出現。

另外一塊是伺服器端,Intel 這邊有 8 sockets 的版本 (參考「Intel Xeon Sapphire Rapids to Scale to 4 and 8 Sockets」),如果都是接 8490H 的話就是 480 cores 了。

ARM 的話好像也可以堆,但不熟...

另外一個提到的重點是 TCP 預設的 congestion control 改成 CUBIC

The default congestion control mechanism for TCP is now CUBIC.

翻 commit log 可以看到是從 NewReno 換成 CUBIC 的,這樣就跟 Linux kernel 預設值一樣了。

再來比較重要的是在 release notes 裡面提到的,FreeBSD 15.0 將會拔光 32-bit 環境的支援,只留 armv7,這代表 Raspberry Pi 第一代的 armv6 也被淘汰掉了:

FreeBSD 15.0 is not expected to include support for 32-bit platforms other than armv7. The armv6, i386, and powerpc platforms are deprecated and will be removed. 64-bit systems will still be able to run older 32-bit binaries.


首先是看到 non-root 的 chroot

The chroot facility supports unprivileged operation, and the chroot(8) program has a -n option to enable its use. a40cf4175c90 (Sponsored by EPSRC)

然後把 OpenSSH 內對 FIDO/U2F 的支援開起來了:

The use of FIDO/U2F hardware authenticators has been enabled in ssh, using the new public key types ecdsa-sk and ed25519-sk, along with corresponding certificate types. FIDO/U2F support is described in e9a994639b2a (Sponsored by The FreeBSD Foundation)

ASLR 預設開啟:

Address Space Layout Randomization (ASLR) is enabled for 64-bit executables by default. It can be disabled as needed if applications fail unexpectedly, for example with segmentation faults. To disable for a single invocation, use the proccontrol(1) command: proccontrol -m aslr -s disable command. To disable ASLR for all invocations of a binary, use the elfctl(1) command: elfctl -e +noaslr file. Problems should be reported via the problem reporting system,, or posting to the mailing list. b014e0f15bc7 (Sponsored by Stormshield)

然後先前被罵臭頭的 WireGuard 支援也放回來了:(「FreeBSD & pfSense 上的 WireGuard 問題」)

The kernel wg(4) WireGuard driver has been reintegrated; it provides Virtual Private Network (VPN) interfaces using the WireGuard protocol. 744bfb213144 (Sponsored by Rubicon Communications, LLC ("Netgate") and The FreeBSD Foundation)

然後看到 Netflix 贊助的 kTLS 支援 TLS 1.3:

KTLS (the kernel TLS implementation) has added receive offload support for TLS 1.3. Receive offload is now supported for TLS 1.1 through 1.3; send offload is supported for TLS 1.0 through 1.3. 05a1d0f5d7ac (Sponsored by Netflix)

然後 FreeBSD 長久以來 root 預設用的 /bin/csh 改成 /bin/sh 了:

The default shell for the root user is now sh(1), which has many new features for interactive use. d410b585b6f0

預設的 MTA 變成 dma (Dragonfly Mail Agent),看名字加上翻了一下 manpage,確認是從 Dragonfly BSD 移植過來的:

The default mail transport agent (MTA) is now the Dragonfly Mail Agent (dma(8)) rather than sendmail(8). Configuration of the MTA is done via mailer.conf(5). sendmail(8) and its configuration remain available. a67b925ff3e5

然後 portsnap 被拔掉了,現在就建議直接用 git 拉了,算是功成身退了:

The portsnap(8) utility has been removed. Users are encouraged to fetch the ports tree by using pkg install git and then git clone /usr/ports. df53ae0fdd98

而 mergemaster 也被換成 etcupdate 了:

mergemaster(8) has been deprecated. Its replacement is etcupdate(8). 398b12691b4f (Sponsored by The FreeBSD Foundation)

然後支援 tarfs,而且可以用 zstd

The tarfs(5) file system has been added, which is backed by POSIX tar archives optionally compressed with zstd(1). 69d94f4c7608 (Sponsored by Juniper Networks, Inc.) (Sponsored by Klara, Inc.)

好久沒看 FreeBSD 的 release notes...

微軟出手直接讓 Sam Altman 與 Greg Brockman 成立新團隊

不算太意外的一步,Satya Nadella (微軟的 CEO) 直接宣佈讓 Sam AltmanGreg Brockman 加入微軟,包含了其他的 team member,另外還特別講了一句會儘快提供需要的資源:

X (Twitter) 上的全文:

We remain committed to our partnership with OpenAI and have confidence in our product roadmap, our ability to continue to innovate with everything we announced at Microsoft Ignite, and in continuing to support our customers and partners. We look forward to getting to know Emmett Shear and OAI's new leadership team and working with them. And we’re extremely excited to share the news that Sam Altman and Greg Brockman, together with colleagues, will be joining Microsoft to lead a new advanced AI research team. We look forward to moving quickly to provide them with the resources needed for their success.

微軟與 Satya Nadella 在這次爆炸後,災難處理接近最完美的劇本了?

讓 Sam Altman 回去 OpenAI 大概不是好方案,很明顯已經有嫌隙了,尤其是直接被 Greg Brockman 點名過的 Ilya Sutskever

把 Sam Altman 與 Greg Brockman 放出去找 VC 開新的公司,不如還是讓直接微軟吃下來。


這個方法 Satya Nadella 完全可以對董事會交代,也能對微軟自家內部合作的團隊交代。

另外推文裡有提到 Emmett Shear 接手 Interim CEO,這樣看起來 Mira Murati 應該也是會過去 Sam Altman 那邊了。

後續應該就是看團隊元氣大傷後可以恢復多快了,少掉的 Ilya Sutskever 這塊要怎麼補?

PostgreSQL 的 Logical Replication 還有很多限制...

雖然之前提過很多次 PostgreSQL 的 logical replication,但最近總算是有空實際架設起來測試,發現目前的 logical replication 還在進化的過程,只能算是階段性的產品。

PostgreSQL 16 的「31.6. Restrictions」裡面有列出了目前 logical replication 的限制。

第一條其實是最痛的,不支援各種 DDL 操作,所以像是 CREATE TABLE 或是 ALTER TABLE 都不會同步,這牽扯到 DBOps 的動作需要配合,DB schema 的改變會變得很詭異,需要 case by case 處理,甚至 application 端可能也會需要配合。

The database schema and DDL commands are not replicated.

另外一個頭痛的點是 sequence 資料居然不會同步,這個工具常被用到 SERIAL 類的設計 (雖然 SERIAL 被 deprecated 了),這代表當偵測到 master 掛掉時無法直接 failover,除非有另外處理 sequence 的資料:

Sequence data is not replicated.

翻了資料發現官方 wiki 上有「Logical replication of DDLs」,裡面有今年六月的投影片:「Logical Replication of DDLs」,看起來 DDL 的部分有已經 patch 丟出來 (對 PostgreSQL 15 的 patch),但看了 PostgreSQL 16 的 release notes 裡面還沒看到,看起來還要等...

所以 logical replication 看起來還在演進的過程,目前的限制使得 logical replication 還不到能用的成熟度。


AWS 的 VPC 開放自訂 IPv6 CIDR 了,但還是有 4 的倍數的限制...

AWS 的公告,VPC 裡的 IPv6 可以自訂 CIDR 了:「VPCs and subnets now support more sizes for IPv6 CIDRs」。

不過還是有限制,首先是 VPC 的大小必須是 /44/60 中 4 的倍數,也就是只有 /44/48/52/56 以及 /60 這五個可以用,而 subnet 也有類似的限制,但從 /44/64,所以剛好就是多了 /64 可以用:

Amazon VPC allows customers to create VPCs and subnets of different sizes using IPv6 CIDRs. With this capability, customers can now create VPCs in sizes between /44 and /60, and subnets in sizes between /44 and /64, in increments of /4.

先前的限制是 VPC 只能給 /56 以及 subnet 只能給 /64 的搭配,是個「可以動」但總是覺得「...」的設計:

Before today, AWS supported one standard IPv6 CIDR block size of /56 for VPC and /64 for subnet, whereas IPv4 CIDR block size were flexible for both VPCs and subnets.

不過我實際在 ap-northeast-1 上測試,發現如果是 AWS 發的 IPv6 address,固定就是 /56 的大小,然後 subnet 在選擇的時候可以選 /56/60/64

這邊提到 VPC 可以選擇大小,應該是其他方式帶進來的 IPv6 address?

另外這次的 /4 的遞增限制,我猜是 AWS 裡面 SDN 上面的限制?IPv4 的 CIDR 有 33 個大小 (/0/32),IPv6 上面如果也處理 33 個的話,反過來設計剛好是 /4 遞增的 workaround?

不過話說回來,我記得前陣子 AWS 公佈要收 Public IPv4 address 的費用時 (參考「AWS 將開始收取 IPv4 的 Public IP 費用」),Hacker News 上有人抱怨還是有很多 AWS 的服務是 IPv4 only,在純 IPv6 network 上面是不太會動的;把這些服務的 IPv6 endpoint 生出來應該要趕快放到 roadmap 上...

Greg Brockman (OpenAI 的 President) 宣佈離職

OpenAI 的 President,Greg Brockman 宣佈離職:

不過更重要的是後續的說明,看起來是與 Sam Altman 聯合起來整理情況,算是另外一邊第一手的資料?

目前主要是一些時間線的呈現,分別被解任與拔除 President。

這邊講的 Ilya 是 Ilya Sutskever,在 Sam Altman 被幹掉後有些八卦傳言有提到他,不過目前 Cofounders 這邊還沒直接開火,沒辦法驗證更多資訊,再繼續等看看有沒有什麼資訊還會冒出來...

Sam Altman (OpenAI 的 CEO) 被幹掉

Hacker News 首頁變得超卡,通常代表有大事... 看了一下 top 1 的文章,oh 幹這件事情很大條:「OpenAI's board has fired Sam Altman (」。

OpenAI 的公告在「OpenAI announces leadership transition」這邊。


Mr. Altman’s departure follows a deliberative review process by the board, which concluded that he was not consistently candid in his communications with the board, hindering its ability to exercise its responsibilities. The board no longer has confidence in his ability to continue leading OpenAI.

In a statement, the board of directors said: “OpenAI was deliberately structured to advance our mission: to ensure that artificial general intelligence benefits all humanity. The board remains fully committed to serving this mission. We are grateful for Sam’s many contributions to the founding and growth of OpenAI. At the same time, we believe new leadership is necessary as we move forward. As the leader of the company’s research, product, and safety functions, Mira is exceptionally qualified to step into the role of interim CEO. We have the utmost confidence in her ability to lead OpenAI during this transition period.”

這邊就用 ChatGPT 來翻譯好了:



現在 X (Twitter) 上面也有不少人在討論 (八卦),但看起來只能先讓子彈飛一下...

AWS 東京區的機器有 μs 等級的 Amazon Time Sync Service 可以用

AWS 宣佈 μs 等級的 Amazon Time Sync Service,也就是比 ms 再多三個零的等級:「Amazon Time Sync Service now supports microsecond-accurate time」。

一般的 Time Sync Service 服務大多是 ms 等級,也就是 10-3 秒這個等級,μs 則是到了 10-6...

但這其實有點詭異,目前只有 AWS 東京區有這個服務,而且限制在 r7g 的機器上才能用:

Amazon Time Sync with microsecond-accurate time is available starting today in the Asia Pacific (Tokyo) Region on all R7g instances, and we will be expanding support to additional AWS Regions and EC2 Instance types.

也就是說 us-east-1us-west-2 這些第一線熱門的區域沒有,另外只有特別的 ARM 機種,而且是 memory-intensive 的 r7g 才能用?

先放著看看 XDDD

從 e-mail 取得電話號碼

Hacker News 上看到 2019 年的文章:「From email to phone number, a new OSINT approach (2019) (」,原文在「From email to phone number, a new OSINT approach」。

用的原理是每一家在 recovery 時都會透漏電話號碼的不同部位,從截圖可以看到像是 PayPal 給的是區碼地一碼加上後三碼:


Leaks first three and last two digits:

Leaks first and last four digits:

Leaks first and last two digits:

Leaks last four digits:

Leaks last two digits:

接著文章裡面介紹了其他的方法再縮小可能性,然後再反過來利用電話號碼查 e-mail,像是 Amazon



Signal 的簡訊花費在 $6m/year

Signal 的「Privacy is Priceless, but Signal is Expensive」這篇 PR 稿裡面提到了各項支出,Hacker News 上的討論在「Privacy is priceless, but Signal is expensive (」這邊可以翻到。

裡面可以看到目前的數字 (以 2023 年十一月推算):

Storage: $1.3 million dollars per year.
Servers: $2.9 million dollars per year.
Registration Fees: $6 million dollars per year.
Total Bandwidth: $2.8 million dollars per year.
Additional Services: $700,000 dollars per year.

Current Infrastructure Costs (as of November 2023): Approximately $14 million dollars per year.

我比較感興趣的有幾塊,一個是標題提到的簡訊,在「Registration Fees」這個段落的說明裡可以看到列了兩個項目,一個是下載 Signal 的費用,另外一個是簡訊 SMS 認證的費用:

Signal incurs expenses when people download Signal and sign up for an account, or when they re-register on a new device. We use third-party services to send a registration code via SMS or voice call in order to verify that the person in possession of a given phone number actually intended to sign up for a Signal account.

這邊有些要確認的,下載軟體的頻寬應該是包括在 Total Bandwidth... 而且推敲起來,金額應該不算大:

  • 手機上的應用應該是由 AppleApp StoreGooglePlay 平台提供,不需要 Signal 提供頻寬下載。
  • 桌面應用端的部分,無論是 Windows、Mac 還是 Linux 的平台,看起來是透過 下載,這個名稱目前是指到 Cloudflare 上面,透過 traceroute 看起來不是 premium account (HiNet 用戶是導去美西的 SFO 機房),也許是 Cloudflare 的贊助帳號?

所以我會先假設這邊 $6m/year 的費用應該都是 SMS,在後面這段看起來也有提出來:

The cost of these registration services for verifying phone numbers when people first install Signal, or when they re-register on a new device, currently averages around $6 million dollars per year.

另外會這麼高也是因為現在 SMS pumping 很流行,也就是攻擊者與電信商合作 (或是同一組人),透過假造大量的認證需求,讓 app 後面的公司需要付大量的簡訊費用:

另外一個感興趣的是頻寬的部分,裡面有提到有一個比較吃頻寬的項目,是處理不在通訊錄上面的通話或是視訊。這邊 Signal 為了避免 IP address 的洩漏,會避免直接讓兩邊接通,而是透過 relay 接通:

To take one example, Signal always routes end-to-end encrypted calls from people who aren’t in your contacts through a relay server that obscures IP address information.

光這部份大約是 20PB/year 的量,費用約 $1.7m/year (上面有提到整個頻寬費用約 $2.8m/year):

At current traffic levels, the amount of outbound bandwidth that is required to support Signal voice and video calls is around 20 petabytes per year (that’s 20 million gigabytes) which costs around $1.7 million dollars per year in bandwidth fees just for calling[.]

而最大的費用還是各種人事支出的部分 (i.e. 經濟規模還沒有大到反過來),佔 $19m/year:

In total, around 50 full-time employees currently work on Signal[.]

To sustain our ongoing development efforts, about half of Signal’s overall operating budget goes towards recruiting, compensating, and retaining the people who build and care for Signal. When benefits, HR services, taxes, recruiting, and salaries are included, this translates to around $19 million dollars per year.

在 Hacker News 上有人貼了「Signal Technology Foundation - Nonprofit Explorer - ProPublica」這個,這邊有申報資料可以翻,比 PR 稿上面細。

Amazon EBS 在 Compliance mode 下的 Snapshot Lock

Jeff Barr 寫了「New – Amazon EBS Snapshot Lock」這篇,介紹 Amazon EBS 的新功能 Snapshot Lock。

從名字就知道是鎖住 snapshot 不讓人刪除,比較特別的是有兩個模式,第一個是 Governance,這個模式下就只是防止誤刪除的情況:

This mode protects snapshots from deletions by all users. However, with the proper IAM permissions, the lock duration can be extended or shortened, the lock can be deleted, and the mode can be changed from Governance mode to Compliance mode.

比較重要的是第二個模式 Compliance,在超過猶豫期 (cooling-off period) 後就不能動了,就算你有最大的權限 (我猜是連 root account 也不能動),唯一能操作的只有延長 lock 時間:

This mode protects snapshots from actions by the root user and all IAM users. After a cooling-off period of up to 72 hours, neither the snapshot nor the lock can be deleted until the lock duration expires, and the mode cannot be changed. With the proper IAM permissions the lock duration can be extended, but it cannot be shortened.