Broadcom 買下 VMware

看到「Broadcom announces successful acquisition of VMware」這則公告,想要找 VMware 發的新聞稿但沒找到,反倒是 Broadcom 這邊還有一篇「Broadcom Completes Acquisition of VMware」。

不知道要說什麼... 有種當年 Intel 買下 McAfee 的感覺?到底會有什麼想法?

Hacker News 上的討論蠻有趣的:「VMware is now part of Broadcom (broadcom.com)」。

[...] Broadcom will get blood from the stone, rest assured. They will continue to raise maintenance and licensing fees until they very last customer turns off their last ESXi box. If you think IBM and mainframe is bad, you've never lived with a technology that Broadcom has acquired.

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 https://www.openssh.com/txt/release-8.2. 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, https://bugs.freebsd.org, or posting to the freebsd-stable@FreeBSD.org 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 https://git.FreeBSD.org/ports.git /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...

用 inxi 列出系統資訊,在回報問題時提供環境

在「GPU Survival Toolkit for the AI age: The bare minimum every developer must know」這篇看到的工具,雖然裡面是講 GPU 相關的事情,但看到這段:

inxi -G

This command provides information about the graphics subsystem, including details about the GPU and the display.

inxi 這個工具是用 Perl 寫的,在 manpage 的說明是:

inxi - Command line system information script for console and IRC

提供一些資訊給使用者,方便使用者在問問題時順便複製貼上到 IRC 或是論壇。

看了一下系統的 dependency,我的桌機是因為 xubuntu-desktop 這個套件相依裝進去的,這是 XFCE 桌面環境的套件。

Ubuntu 的預設環境沒有包這個套件進去,會需要額外安裝。

Raspberry Pi 5 在 shutdown 狀態時的電力消耗過高問題

在「Reducing Raspberry Pi 5's power consumption by 140x」這邊看到的,講 Raspberry Pi 5 在 shutdown 狀態下電力消耗過高的問題。

依據 Jeff Geerling 提到,在 shutdown 狀態下仍然會消耗 1.2W~1.6W:

Because of this, a Pi 5 will still sit there consuming 1.2-1.6W when completely shut down, even without anything plugged in except power.

也有提到解決方法是把 POWER_OFF_ON_HALT 改成 1,他給的範例另外有多一些設定,但跟這次的功耗問題無關:

[all]
BOOT_UART=1
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1

依照文章裡面的說明設定好,重開再 shutdown 測試就可以看到整個降下來了:

Save that configuration and reboot, then next time you shut down, you should see power consumption go down from 1-2W to 0.01W or even less:

應該算是某種 bug 或是 regression,後續預設值應該會修正?

Cloudflare 前幾天 API 與 Dashboard 出事的 Post Mortem 記錄

前幾天 Cloudflare 的 API 與 dashboard 掛了一天多,少見的讓 Matthew Prince (CEO) 自己出來發 post mortem 記錄了:「Post Mortem on Cloudflare Control Plane and Analytics Outage」,在 Hacker News 上面也有蠻多討論的:「Post Mortem on Cloudflare Control Plane and Analytics Outage (cloudflare.com)」,這邊是整理我自己讀完後的感想。

從「Matthew Prince - The Cloudflare Blog」這邊可以看出來 Matthew Prince 上次是 2023/09/27 的公關文「Cloudflare’s 2023 Annual Founders’ Letter」,還有對應的多國翻譯,像是繁體中文的「Cloudflare 2023 年度創始人來信」,再往前的 2022/12/11 也是公關文「Welcome to Cloudflare’s Impact Week」(以及對應的繁體中文版本:「歡迎來到 Cloudflare 的 Impact Week」)。

這次的事情算是 Cloudflare 在 post-IPO 後很少見的長時間出事,就難得看到 Matthew Prince 自己出來坦了。為了重新建立信任,加上因為層級的關係,可以看到透漏出很多架構細節,算是這次可以窺視 Cloudflare 架構的一些資訊。

先大概提一下官方文章的著墨點:他們花了非常多的篇幅在機房服務商 Flexential 在處理 PDX-04 (這是 Cloudflare 訂的名稱) 機房電力問題的失職 (要注意這邊是 Cloudflare 的觀點,認為 Flexential 的失職,目前沒有從 Flexential 這邊的消息出來解釋),淡化掉了 Cloudflare 自己的設計問題,這邊在 Hacker News 上有蠻多人都有指出來的。

這次事件一切的起因是 Flexential 的 PDX-04 機房整個電力系統斷線 offline 導致的,屬於標準的 data center failure 的情況,像是 2013 年二月時是方機房的火災 (可以參考 iThome 的整理),或是 2021 年 OVH 的機房火災 (「去年 OVH 機房大火的部份情形最近被揭露」),是個在設計架構時一定會規劃進去的項目。

所以 Matthew Prince 先是解釋 Cloudflare 的 HA 作法,是直接在 Hillsboro, Oregon 租三個機房建立起 low-latency network:

Cloudflare's control plane and analytics systems run primarily on servers in three data centers around Hillsboro, Oregon. The three data centers are independent of one another, each have multiple utility power feeds, and each have multiple redundant and independent network connections.

但大家看到這計馬上就會去查,這個城市也才 66.9km2 的土地,大約是 1/4 個台北市 (約 291.8km2) 再小一些,拉了一下城市內的直線最遠距離,大約是 12km?

呃,這不是一個地震 (就在聖安地列斯斷層區域?) 或是一個核攻擊就把 Cloudflare 最核心的部分給擺平了嗎?

其中 analytics systems 就算了:整個 Hillsboro 掛了進入 gracefully degrading,我可以理解這個設計的考量,但 control plane 看起來不太妙?

雞蛋放在同一個籃子的問題裡先放著,雖然這個問題真的很...。

後續提到了有些重要的產品對沒有 HA 能力的服務上有相依性:

Unfortunately, we discovered that a subset of services that were supposed to be on the high availability cluster had dependencies on services exclusively running in PDX-04.

這邊沒有講是哪些服務的相依性,但文章其他地方有提到有些基礎服務是沒有跨機房 HA 架構的,只有在 PDX-04 有跑,包括了 KafkaClickHouse

In particular, two critical services that process logs and power our analytics — Kafka and ClickHouse — were only available in PDX-04 but had services that depended on them that were running in the high availability cluster.

這點讓人頗意外的,Kafka 因為自己架設 & 維護過,知道他的架構本身就很容易設計到跨機房的 case,而且這算是很基礎建設的東西,居然沒有跨機房 HA?

而 ClickHouse 只有研究過,沒有實際把 production 量丟上去跑,但從文件看到的東西,應該至少能做到 shared-everything 的架構,也居然沒有跨機房 HA?

這接基礎建設的問題,導致了雖然只是單一機房 PDX-04 掛掉,但在有重要基礎建設消失的情況下 (應該就是上面提到的 Kafka 與 ClickHouse),加上 Flexential 沒有給出恢復的時間,決定直接跑災難重建的 SOP (也就是 Hillsboro 的三個機房都回不來的情境)。

而這也可以看到恢復時間比較久,從決定切到歐洲的 DR site 到整個切過去花了四個多小時:

Because more services were offline than we expected, and because Flexential could not give us a time for restoration of our services, we made the call at 13:40 UTC to fail over to Cloudflare's disaster recovery sites located in Europe.

By 17:57 UTC, the services that had been successfully moved to the disaster recovery site were stable and most customers were no longer directly impacted.

因為 Kafka 與 ClickHouse 在 Hillsboro 只有單一機房有服務,那就不確定歐洲 DR site 平常有沒有建起來,也許這邊的四個多小時有不少是在歐洲 DR site 把 Kafka 與 ClickHouse 建起來?(這個就只能猜測了)

回到 Flexential 這邊,在恢復供電的過程發現 Cloudflare 這邊迴路用的 breaker 掛了,直到十個小時後才供電,但也因為大家都忙了一整天,Matthew Prince 決定讓大家先回去休息,隔天早上再從歐洲的 DR site 切回 Hillsboro,也因此拉長了恢復的時間:

At 12:48 UTC, Flexential was able to get the generators restarted. [...] When Flexential attempted to power back up Cloudflare's circuits, the circuit breakers were discovered to be faulty.

Flexential replaced our failed circuit breakers, restored both utility feeds, and confirmed clean power at 22:48 UTC. Our team was all-hands-on-deck and had worked all day on the emergency, so I made the call that most of us should get some rest and start the move back to PDX-04 in the morning. That decision delayed our full recovery, but I believe made it less likely that we’d compound this situation with additional mistakes.

要注意報告慣例是用 UTC 時間 (這又是另外一個主題了,先前 HN 上也有其他文章討論過...),而 Hillsboro 在美西,要減八個小時,所以 22:48 UTC 是下午兩點多左右,美東與歐洲的團隊時間則會更晚。

目前看起來 Cloudflare 的設計與流程有很大的改善空間?之後看看有沒有其他的八卦消息出來?

Raspberry Pi 5 拿掉硬體的 H.264 encoding

HN 上看到「Raspberry Pi 5 has no hardware video encoding and only HEVC decoding (raspberrypi.com)」,原文指到 Gordon Hollingworth 的回覆這邊,可以看到這是上個月的消息了。

Raspberry Pi 一直都有硬體 H.264 encoding 的能力,不過這個在 Raspberry Pi 5 上被拿掉了,所以得用軟體壓。

官方有提到 Raspberry Pi 5 的 CPU 因為比之前快很多,單顆就有辦法做到 1080p60 (而 RPi5 有 4 CPU),所以除了 power consumption 以外應該不是大問題:

Obviously, the bad thing is the power consumption, but actually it only takes around 1 processor to encode 1080p60 with our default settings (which is still better quality than the PI 4 hardware encoder).

不過 HN 上猜是授權費用之類的問題,我在想是不是新的晶片組的 encoding license 都綁在一起,H.264 + H.265 得一包一起買,而 H.265 的授權費是眾所皆知的貴...

當 desktop 應該是還好,但就心裡有個底...

USB PD 的誘騙器

先在 HN 上看到「USB Power Delivery for Hobby Projects (flameeyes.blog)」這則,原文是「USB Power Delivery For Hobby Projects」,裡面提到了很多想要從 USB-PD 裡面取出電流的搞法,不過在 HN 的 id=38057797 裡面有提到這搞的有點複雜,可以直接買 USB-PD 的誘騙器輸出對應的電壓:

Most of the rest seems to be over-engineering. You can get a ready-made "PD Trigger" board for literally $1 [0], which will allow you to select the desired voltage using jumpers. It even has support for the non-standard (although still common) 12V profile. Or, if you really want to do it using software, grab a $6 one from Adafruit [1] which comes with a tutorial and Arduino library.

其中的 [0] 是「PD/QC/AFC fast charge decoy trigger support 5V 9V 12V 15V 20V fixed voltage output」這個,可以直接調整 switch S1 S2 S3 選擇輸出的電壓:

不過不知道遇到沒有支援的電壓輸出時會怎麼樣 (像是有些變壓器只支援 5V 與 9V),我猜就是輸出 5V 而且不足電流,然後導致後面的設備不會動?另外比較大的問題就是不知道最大的電流與保護 XDDD

而 [1] 則是「Adafruit USB Type C Power Delivery Dummy Breakout - I2C or Fixed - HUSB238」,除了可以自己改線路設定電壓與最大電流外 (看起來直接一坨錫連過去,或是劃開預設的 5V 1A 的設定導線),也可以用 I²C 動態設定 decoy trigger:

這個看起來至少有個上限擋著?

X (Twitter) 的工程團隊列出了最近做的事情

Hacker News 上看到的討論,在 Elon Musk 接手後的 X (Twitter),工程團隊做了什麼事情:「X Engineering Year Retrospective (twitter.com/xeng)」,原推在:

其中裡面有些蠻有趣的,出現了一些平常不太會出現的數字資訊。

我比較有興趣的關掉了加州 Sacramento DC 的這個部分,而光是這個 DC 就有 148k 台 server (是 server,不是 VM 或是 container),而且也提到電力少了 48MW,看起來是把這些 server 廢掉,而不是轉到其他機房?

- Shutdown the Sacramento data center and re-provisioned the 5,200 racks and 148,000 servers, which generated more than $100M in annual savings. In total, we freed up 48 MW of capacity and tore down 60k lbs. of network ladder rack before re-provisioning it to other data centers.

話說一個 Twitter 機房用 48MW... 查了一下台電網站,核三的一個機組的供電量也才 951MW:

而且 Twitter 服務要用到 148k server,hmmm...

Oxide 推出的 Oxide Cloud Computer

Hacker News 上看到「The Cloud Computer」這篇行銷新聞稿被衝了很高,翻了一下討論「Oxide: The Cloud Computer (oxide.computer)」,裡面看到不少有趣的東西。

行銷新聞稿裡面包裝的很「行銷」,如果看完後可以理解 Oxide Cloud Computer 其實就是賣機櫃,裡面包好一個 mini AWS 需要的硬體與軟體。

這個機櫃裡的硬體部分可以在「Specifications」這邊看到,裡面有主機、網路與電供這些東西,而且照他提到的 60cm * 106cm 的佔地面積需要 1145kg,一般辦公建築物沒辦法直接放,需要用架高地板的方式把重量打散掉,而且放好幾台的時候應該需要找結構工程師重新計算安全性;如果是機房的話應該是有機會直接塞進去 (因為前面的事情都先考慮過了)。

軟體的部分則是在 id=38024259 裡面看到的,上面是用 Illumos 當作 hypervisor,這是 OpenSolaris 的 fork,這個選擇還蠻特別的,不是選 Linux-based 的系統來包,不確定是不是考慮到 license 的問題:

The hypervisor OS is based on Illumos, which was forked from OpenSolaris, and it uses Bhyve from FreeBSD for virtualization.

另外在 id=38026273 這邊也有一些解讀,可以了解 Oxide 在 Illumos 上面重新實作了 OpenStack 的功能 (也可以看做 mini AWS):

Oh. I get what this is. It's a "cloud" mainframe. They're trying to be the Apple of mainframes.

Reinvent OpenStack, slap it on some 8Us and storage arrays, shove it in a rack, and ship it to a colo with a professional installer. So basically one of the larger server vendors but with integrated "cloud" software, minus the 2-hour service turnaround and spare parts.

The fact that they're writing the software from scratch is going to add years of lead time until they reach parity with other solutions. My guess is they're hoping they can get sticker price or TCO low enough that it outweighs the lack of functionality and uncertainty of a brand new everything. If you just need some VMs in a lab in the office closet, might work.

可以想到的 TA... 馬上可以想到的是,需要把資料都控制在自家的公司 (像是金融法規/軍方/TSMC/...),這些公司在這之前的路線會是買硬體後上 VMwareCitrix 或是 OpenStack 之類的方案,這些方案除了可以自己養人,應該也都有 SI 可以付費代操。而 Oxide 這次給出來的方案則是都包掉?不過 SI 也可以去包 bare-metal server 來賣就是了...

其他的暫時想不到,畢竟 ecosystem 還是很重要,Oxide 推出的東西沒有特別吸引人的地方,也許看看還能怎麼包裝跟想像?

Starlink 宣佈了 LTE 服務

Starlink 宣佈了直接從衛星提供 LTE 的服務:「Home - Starlink - Direct to Cell」。

在網站上的副標題寫的比較清楚:

Seamless access to text, voice, and data for LTE phones across the globe

另外官網的這張圖片也有說明到,可以直接用原始的手機連上去,這點比起當初蘋果需要用 iPhone 14 跟衛星通訊又更進一步:

依照目前的規劃是 2024 年上 Text 服務 (應該就是 SMS 簡訊服務),2025 年上 Voice & Data 以及讓 IoT 也能上。

而目前列出來的 Global Partner 有這六家,可以看到涵蓋了北美洲、歐洲、亞洲與大洋洲,如果後續再多找一些的話應該就更完整了:

T-MOBILE (USA)
OPTUS (AUSTRALIA)
ROGERS (CANADA)
ONE NZ (NEW ZEALAND)
KDDI (JAPAN)
SALT (SWITZERLAND)

這對於完全沒有 mobile coverage 的地區來說會有很不一樣的情況,馬上有想到的是登山時緊急求救的設備,目前有 Garmin InReach 這種專用設備,之後如果真的弄起來的話應該都會逐漸退場...

另外北美的沙漠公路裡面也是有不少區域沒有訊號,這個 coverage 看起來會有很大的幫助?