MS-DOS v4.0 的程式碼以 MIT license 釋出

Hacker News 上的消息「Open Sourcing DOS 4 (hanselman.com)」,原文在「Open Sourcing DOS 4」。

Hacker News 裡面的討論有拉出一些有趣的 source code 註解,不過我比較好奇為什麼是挑 v4.0 而不是其他版本,看說明應該是剛好遇到對的人與對的團體?

A young English researcher named Connor "Starfrost" Hyde recently corresponded with former Microsoft Chief Technical Officer Ray Ozzie about some of the software in his collection. Amongst the floppies, Ray found unreleased beta binaries of DOS 4.0 that he was sent while he was at Lotus. Starfrost reached out to the Microsoft Open Source Programs Office (OSPO) to explore releasing DOS 4 source, as he is working on documenting the relationship between DOS 4, MT-DOS, and what would eventually become OS/2. Some later versions of these Multitasking DOS binaries can be found around the internet, but these new Ozzie beta binaries appear to be much earlier, unreleased, and also include the ibmbio.com source.

這些程式碼主要都是考古分析用了,不知道什麼時候 MS-DOS 6.22 的 code 會冒出來...

FreeBSD 4 到 FreeBSD 5/6/7/8 年代的事情...

在「FreeBSD 4 Bug may be present in Playstation 4/5 (wololo.net)」這邊看到一堆考古的討論... 原文是在講 FreeBSD 4 的 bug 可能會是 PS4PS5 的 jailbreak 切入點,不過討論裡面倒是看到了很多考古...

當年 FreeBSD 4.11 在 kernel 裡還是 single thread,然後是對 multi-core architecture 的理念不合分家了,另外一派變成 Dragonfly BSD,兩邊都花了不少時間實作多核心的架構。

印象中 FreeBSD 剛推出 5.x 的時候很不穩定,然後一路到 7.x 才算整個穩定下來,查了一下維基百科上的版本日期資訊:

After almost three years of development, the first 5.0-RELEASE in January 2003 was widely anticipated, featuring support for advanced multiprocessor and application threading, and for the UltraSPARC and IA-64 platforms.

FreeBSD 7.0 was released on 27 February 2008.

是個懷舊的討論串...

FreeBSD 14.0 對比於 13.2 有顯著的效能提升

Hacker News 上看到「FreeBSD 14.0 Delivering Great Performance Uplift (phoronix.com)」這篇,原文在「FreeBSD 14.0 Is Delivering Great Performance Uplift & Running Well In Early Tests」這邊。

測試平台是 AMD EPYC™ 8534P (64 cores & 128 threads),是個今年九月才推出的 CPU,另外底層 filesystem 是跑 ZFS

翻了一輪測試的資訊,幾乎是所有的項目都有提升 (少數幾樣有些微退步),但以 Phoronix 的測試計算,整體計算起來有 18% 的提升,對於 OS 升級帶來的提升算是蠻巨大的:

Across the span of five dozen benchmarks carried out on this AMD EPYC 8534P server of FreeBSD 13.2 vs. FreeBSD 14.0, the newly-released FreeBSD 14 was on average 18% faster than its predecessor. Not bad for a simple OS upgrade. I've been seeing very healthy gains on other x86_64 servers tested so far while due to hardware availability haven't yet tried any AArch64 servers.

依照他的說明,後續會有跟其他 Linux distribution 的比較,到時候可以回來再看看:

I'll be running more FreeBSD 14.0 server benchmarks shortly along with following that up by looking at the FreeBSD 14.0 performance against the latest leading Linux distributions. In any event I'm quite happy thus far with the performance and experience in my FreeBSD 14.0 testing.

回頭看報告裡面比較特別的部分,一個是 OpenSSL 的部分有下滑一些,這點應該跟版本更新有關,在 FreeBSD 14.0 的 Release Notes 裡面有提到大版本升級:

OpenSSL has been upgraded to version 3.0.12. This is a major upgrade from version 1.1.1, which has reached its end of life. Many components of the base system use a backward-compatible API, but will be migrated later. aa7957345732 930cec16d9ee b077aed33b7b (Sponsored by The FreeBSD Foundation)

另外一點是在 Page 4 裡面,可以看到 PostgreSQL 16 的效能提升非常明顯,無論是 TPS 還是 latency 都有非常巨大的改善。

FreeBSD 的 Firecracker 支援

Colin PercivalFreeBSD 能夠支援 Firecrack:「Announcing the FreeBSD/Firecracker platform」,成為 LinuxOSv 以外的第三個支援的作業系統。對應的 patch 在「amd64: Add FIRECRACKER kernel configuration」這邊可以看到。

接下來是反過來,要送一些 patch 進去 Firecracker,讓他支援 FreeBSD:

Now that FreeBSD supported Firecracker, there was one more thing to do: Make Firecracker support FreeBSD.

看起來是基於之前在 2020 年的 patch (但當時沒被整進去) 再修改:

Alejandro Jimenez contributed patches two years ago, but they were never merged. Some of his code ended up in the linux-loader project (which Firecracker uses); but I spent a few weeks digging through his thousand lines of changes to figure out which went into linux-loader, which still applied cleanly to Firecracker, and which I had to rewrite from scratch — a task made more difficult by the fact that Firecracker is written in Rust, and I had never used Rust before! Nevertheless, I was eventually successful, and opened a PR with updated patches which I hope to see merged into mainline Firecracker in the upcoming weeks.

看起來兩邊都有 patch 要做才能支援,目前看起來 Firecracker 這邊沒動作了,大概是沒什麼動力...

Mac 上 sprintf 的 scalability 問題

Hacker News 上看到個有趣的 scalability 問題,在 Mac 上的 sprintf() 因為有 lock 造成的 scalability 問題:「Curious lack of sprintf scaling (aras-p.info)」。

作者注意到 Mac 在多 CPU 下 sprintf() 會有 scalability 的問題,要注意到這邊的 Y 軸是對數比例:

用了 std::stringstream << 反而更慢 (作者還酸了一句「Zero cost abstractions」):

然後用了 Instruments 跑 profiling 找問題,可以看到看起來跟 locale 有關:

一般的情況下應該不會是問題,但如果是需要大量 sprintf() 組字串的人就會比較要注意了。

在「What else can we do?」這段有提到一些解法,包括了 stb_sprintf 當作替代品,以及 {fmt} 作為 iostreams 的替代品,然後另外是利用 to_chars 來解決,如果只是要把數字轉成字串。

算是蠻有趣的 bug hunting 過程,對於開發者來說,一般性的重點還是在 profiling,找到對的問題然後再往下提出解法...

Raspberry Pi OS 64-bit 與 32-bit 的效能差異

前幾天提過「Raspberry Pi OS 64-bit 版本正式推出」,而 Phoronix 實際拿正式版測試 64-bit 與 32-bit 的系統差異了,在「Raspberry Pi OS 32-bit vs. 64-bit Performance」這邊可以看到每一個測試項目的結果。

測試的硬體是 Raspberry Pi 400,這台機器基本上就是 4GB 版本的 Raspberry Pi 4 加上週邊配件:

Using a Raspberry Pi 400 keyboard computer with 4GB of RAM, I ran some fresh benchmarks of Raspberry Pi OS in its default 32-bit build and then again with the new 64-bit build.

先講結果,在 Phoronix 的 33 個測試裡面,64-bit 全部都比 32-bit 好,而且是很明顯的差異:

Across the few dozen different workloads tested, switching Raspberry Pi OS 11 for the 64-bit version improved the performance on average by about 48%. See all the 32-bit vs. 64-bit Raspberry Pi benchmarks over on OpenBenchmarking.org.

之前 64-bit OS 還在 beta 的時候就已經知道這個情況了,所以不會覺得太意外。當時提出的解釋是指令集的差異,aarch64 提供的指令集比 armv6 有效率多了,這點在 2016 年的文章「64-bit ARM (Aarch64) Instructions Boost Performance by 15 to 30% Compared to 32-bit ARM (Aarch32) Instructions」這邊可以看到說明。

所以正式版出來以後,只要硬體有支援,基本上都建議裝 64-bit OS 了...

Raspberry Pi OS 64-bit 版本正式推出

Twitter 上看到前同事貼了 Raspberry Pi 官方放出 Raspberry Pi OS 64-bit 版本的公告:「Raspberry Pi OS (64-bit)」。

我是在 beta 時就已經跑一陣子了,依照官方的說明可以看到 Raspberry Pi 3 或是 Raspberry Pi Zero 2 以上的版本才支援 64-bit OS。

我是在 Raspberry Pi 3 上面跑,主要是現在大多數支援 ARM 指令集的 package 都是包 arm64,換到 64-bit OS 能裝的東西會比較多。

另外有提到目前 64-bit 版本的 Chromium 還沒有 Widevine 支援,無法看 Netflix 或是 Disney+,需要裝 32-bit 版本才能看:

The 64-bit version of Chromium, installed by default, has no version of the WidevineCDM library and therefore, it is not possible to play streaming media such as Netflix or Disney+.

不過應該過一陣子就會有了...

不使用 Google 服務的 Android 手機

一樣是在 Lobsters Daily 上翻到的,去 Google 服務的 Android 系統搞法:「Lineage with microG on a Sony XA2」。

主要是看關鍵字的部份,TWRP 換掉 recovery image,然後 LineageOS 是系統底,microG 是 open source 版本的 Google 專屬 API 的相容層,Magisk 則是負責 root 相關的事情,F-Droid 是 open source 軟體的 app store,可以用他來裝 Aurora Store,就可以裝 Play Store 裡的 app。

會這樣搞的人主要還是考慮到 privacy,可以預期有不少應用程式是不會動的...

在 Linux (Ubuntu) 上跑透過 QEMU 跑 Windows/Mac/Linux 的工具

Hacker News Daily 上看到的工具:「Quickly create and run optimised Windows, macOS and Linux desktop virtual machines.」,對應的討論在「Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux (github.com/wimpysworld)」這邊可以看到,可以減少自己要設定一堆 QEMU 參數。

雖然專案是支援多系統,但其實 Microsoft WindowsLinux 的部份在其他虛擬軟體都很簡單 (像是用 VirtaulBox),大家馬上會注意到的重點還是 macOS 的部份,如果有自己弄過就會知道這東西有夠難裝的,而且跨版本有不同的安裝方式...

目前 Quickemu 支援四個版本:

Supported macOS releases:

  • High Sierra
  • Mojave
  • Catalina (Recommended)
  • Big Sur

然後可以看到幾乎所有目前能支援的功能都有設定上去了,包括 VirtIO 與 USB 的部份。

然後一些經典的問題,像是 Big Sur 的音源問題還是沒解:

Full Duplex audio works on macOS High Sierra, Mojave and Catalina.

  • macOS Big Sur has no audio at all.

在 Hacker News 的討論串裡面有提到有很多地方沒有檢查,這會是風險:

While I appreciate the effort, and the code is very readable. I just want to give a friendly warning that these shell scripts just download random stuff from the internet and run this random stuff without checking any integrity/signature.

下面的討論另外看到個冷知識,關於蘋果故意走 HTTP 下載 recovery image 是因為 HTTPS 太複雜,在 UEFI firmware 裡面實做容易產生被攻擊的點,所以決定自己透過其他機制確認正確性:

Apple Internet recoveryOS images are served over plain http, on purpose. The macrecovery.py script used by Quickemu uses http¹, though the server supports https.

https://support.apple.com/guide/security/recoveryos-and-diagnostics-environments-sec2512a0c09/web

> When the internet recovery and diagnostic modes were added to Mac computers in 2011, it was decided that it would be better to use the simpler HTTP transport, and handle content authentication using the chunklist mechanism, rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmwareʼs attack surface.

¹https://github.com/acidanthera/OpenCorePkg/blob/4a740c3f256e285c66ca3b65e42b60af6826d343/Utilities/macrecovery/macrecovery.py#L123

[edit] Added macrecovery.py info

另外為了避免直接在 shell script 裡面出現「神秘字串」,可以看到特別的寫法 XDDD

Took a little while to find the magic words in there: https://github.com/wimpysworld/quickemu/blob/af26f41440d63a069045660fad860c797011310a/quickemu#L351

可以想到一些用途,像是在機房裡面跑 CI 的 worker,但要注意這個搞法不符合蘋果的 EULA,現在不抓不代表以後也不會有事,請自己謹慎評估...

然後往 ARM-based 架構後應該門檻就更高了,現在還有 Intel-based 的環境可以用加減用...