syllazh:拿同音字硬顯示到 Linux TTY 的 console 上面

翻資料的時候翻到用 Python 寫的 syllazh 這個東西,可以在 Linux TTY console 上面直接顯示中文,我本來以為是類似 big5con 的東西,看了一下完全不是,syllazh 是直接透過 Linux TTY 搞,所以會受限於 512 字的限制,而 big5con 是切進圖形模式自己處理,所以可以完整顯示 big5 上面的字:

Linux TTY 上的字体可以由一般位于kbd软件包里的setfont工具更换。它最多支持512个字形(glyph),但每个字形可以被映射到多个 Unicode 码位。 所以为了支持显示中文,我必须把成千上万个汉字挤进这个狭小的空间。 幸运的是,现代汉语普通话大约只有400个不同的音节(忽略声调)。于是我针对每个音节,挑选了一个最常用的汉字来代表那最多上百个读音近似的汉字。 这样再加上96个可见的ASCII字符和几个符号,它们就正好装进512字符的限制内了!

然後這邊因為不可能將所有的中文字都塞進去,syllazh 的作法就是找同音字塞,效果就會變成這樣:

這主要還是好玩為主,作者自己也有提到這點:

老实讲,盯着这些同音错字并通过句子来费劲猜测它是什么意思,并不是很愉快的体验。因此我也不期待任何人日常使用它。 现在都2024年了,你应该去用你喜欢的 Wayland 或 X 桌面,而不是TTY。所有主要的图形界面库对中文(以及所有其他语言)的支持都比我这奇技淫巧高到不知哪里去了。

從 VirtualBox 換到 virt-manager

為了可以使用 KVM,把桌機 Ubuntu (Xubuntu) 上的 VM 都從 VirtualBox 換到 virt-manager 了...

不得不說 VirtualBox 包的很好,很多事情就不用自己繞半天... 在 virt-manager 上面有蠻多東西得自己設定繞開,把 2024 年會遇到的問題整理下來。

首先是權限的部分,裝完 virt-manager 後馬上打開會遇到 virt-manager 說連不到 libvirtd 的問題:「virt-manager can't connect to libvirt」,而最簡單的解法就是重開機,原因是安裝過程中在 /etc/group 增加了 libvirt 的權限,現有的 session 因為權限不夠無法連上 libvirtd。

接下來就是操作介面上的順暢度問題了,預設「Automatically detect from the installation media / source」是勾起來的,但你丟 Windows 的 ISO 進去不一定會偵測到是 Windows 的 ISO,需要把勾勾拿掉,然後自己輸入 win 後才會出現可以選的選項,而不是直接選單選擇... 這邊的 UX 在第一次用的時候還蠻卡的。

另外裡面設定也是有問題的,選擇 Windows XP 會發現網路的設定居然還是用 e1000,導致 Windows XP 抓不到網路卡,需要另外再改成 rtl8139 (不過速度只有 100Mbps)。

最後在 Network selection 的部分,NAT 算是最常用的,不過如果要自己架設 lab 的話 (像是我弄了三台 Ubuntu VM 測各種服務),直覺會設定成 Bridge device,但這邊的 Bridge device 是需要先自己設定好 bridge interface 後再讓 virt-manager 設定掛進去。

所以比較「簡單」的方式 (當時以為比較簡單) 是選擇 Macvtap,然後選擇要用的介面,這樣設定後主機的確可以透過指定的介面連到 Internet 上,但就像設定 Macvtap 時出現的警告,guest 與 host 本機之間是無法溝通的:「In most configuration, macvtap does not work for host to guest network communication.」。

解決的方法還是自己搞 bridge interface,這邊由於 Ubuntu 現在網路都是透過 Netplan 在管理,我是透過「[Wishlist] Support macvlan/macvtap interfaces」這邊提供的 workaround 來解決。

以前是直接在 enps0f0 上面設定 IP address,現在是在 networkd 跑起來就先建立 macvlan0,然後在上面設定 IP address。然後 virt-manager 就可以用 macvtap 到 macvlan0 了,實際測試 guest 與 host 之間也通了...

折騰了一會算是搬過來了,這樣總算是可以在桌機上面跑 android emulator 了,先前硬關掉 KVM 跑了兩次,速度實在是受不了,就跑去 Mac 上開發了,現在這樣好多了...

Ubuntu 上 PPPoE 自動重撥的設定

tl;dr:在設定檔裡面除了 persist 外,還要加上 maxfail 0

中華 HiNet 家用方案有提供固一動七的 IPv4 address 可以用,我自己因為玩 DevOps/SRE 的項目,有個固定 IPv4 address 弄一台便當盒小主機跑個 Ubuntu 系統當 jump server (跳板機) 總是對於防火牆的設定比較友善。

家用方案的固定 IP 在網站上申請完以後,透過 PPPoE 撥號指定另外一組 username 拿到。

我遇到的問題時大多數斷線後會自己重連,但偶而就是不會,這次難得在土城家裡的主機發生,看 log 發現是 pppd 自己 exit 了:(時間是 UTC,大約是 2024/02/22 的早上三點多)

Feb 21 19:09:15 kennel pppd[716]: No response to 4 echo-requests                                                      
Feb 21 19:09:15 kennel pppd[716]: Serial link appears to be disconnected.                                             
Feb 21 19:09:15 kennel pppd[716]: Connect time 7434.5 minutes.                                                        
Feb 21 19:09:15 kennel pppd[716]: Sent 1240056869 bytes, received 1018762497 bytes.                                   
Feb 21 19:09:21 kennel pppd[716]: Connection terminated.                                                              
Feb 21 19:09:21 kennel pppd[716]: Connect time 7434.5 minutes.                                                        
Feb 21 19:09:21 kennel pppd[716]: Sent 1240056869 bytes, received 1018762497 bytes.                                   
Feb 21 19:09:21 kennel pppd[716]: Modem hangup                                                                        
Feb 21 19:10:27 kennel pppd[716]: Timeout waiting for PADO packets                                                    
Feb 21 19:10:27 kennel pppd[716]: Unable to complete PPPoE Discovery                                                  
Feb 21 19:11:32 kennel pppd[716]: Timeout waiting for PADO packets                                                    
Feb 21 19:11:32 kennel pppd[716]: Unable to complete PPPoE Discovery                                                  
Feb 21 19:12:37 kennel pppd[716]: Timeout waiting for PADO packets                                                    
Feb 21 19:12:37 kennel pppd[716]: Unable to complete PPPoE Discovery                                                  
Feb 21 19:13:42 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:13:42 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:14:47 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:14:47 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:15:52 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:15:52 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:16:57 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:16:57 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:18:02 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:18:02 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:19:07 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:19:07 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:20:12 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:20:12 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:20:12 kennel pppd[716]: Exit.

這邊算了一下「Unable to complete PPPoE Discovery」出現了十次,這種數字看起來就蠻可疑的,回頭去 pppd 的說明找 10 可以看到這段:

Terminate after n consecutive failed connection attempts. A value of 0 means no limit. The default value is 10.

接著網路上翻,在「How do I set a PPPoE connection to redial?」這邊看到有人也提到了這點:除了 persist 以外,也要記得改 maxfail...

Ubuntu 的 Phased Update

Ubuntu 22.04 上面常常會遇到跑 apt upgrade 時系統跟你說有些 package 不打算升級:

$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  python3-distupgrade ubuntu-release-upgrader-core ubuntu-release-upgrader-gtk
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

以往遇到這種情況,如果確定要裝就是開 dist-upgrade 下去,但會發現也還是不為所動:

$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  python3-distupgrade ubuntu-release-upgrader-core ubuntu-release-upgrader-gtk
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

這個可能是遇到 PhasedUpdates,這個設計是在最後一關推出去的階段,一次不要更新 100% 的機器。

可以從 apt policy 看到現在的比率是 20%:(這是我已經升級上去的樣子)

$ apt policy python3-distupgrade
python3-distupgrade:
  Installed: 1:22.04.18
  Candidate: 1:22.04.18
  Version table:
 *** 1:22.04.18 500 (phased 20%)
        500 http://tw.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://tw.archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
        100 /var/lib/dpkg/status
     1:22.04.10 500
        500 http://tw.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        500 http://tw.archive.ubuntu.com/ubuntu jammy/main i386 Packages

而對於 LTS 的使用者,這個功能在 APT 的支援是從 Ubuntu 22.04 開始,以前只有桌面的 Update Manager 才有支援,所以不太會遇到:

Up to Focal (20.04), Update Manager is the only package manager that supports phased updates (reference). Any other update mechanism installs all updates regardless of the Phased-Update-Percentage.

(話說 wiki 頁上面可以看到有「User stories」這段,用 User story 的格式把這個功能的目的描述出來了)

所以一般人可以忽略掉,而對於有意願想要幫忙測試的人,也可以透過設定蓋過 Phased Updates 的比例設定...

VirtualBox 內的 Windows 上傳速度很慢的問題

因為我電腦有兩張網卡,兩條線分別接到自己拉的 HiNet 以及社區網路 (不過出去也是 HiNet,這是另外一回事了)。

我桌機的預設 routing 是走自己拉的 HiNet,但我希望 VM 是走社區網路,所以用 bridge mode 設定到網卡上,用 DHCP 取得分享器給的 private IP。

之前一直都沒注意到,前幾天用 Line 傳照片的時候很慢 (之前就有發生了,一直忘記去追問題),花了點時間追問題的時候發現是 VM 裡面的 Windows 10 上傳很慢,這點可以從 Speedtest 的測試結果看到:

先講最後的結論,在交叉測了很多組合後,我發現遇到的問題是把網卡裡的 Large Send Offload (IPv4) (也就是 LSO) 從 Enabled 改成 Disabled

回到當時抓問題的情況,當時先用筆電與 host 測試都沒看到問題,所以看起來應該是 VM 裡面的狀況,但不確定是什麼情況,畢竟不是斷掉...

由於下載速度正常,只有上傳速度卡住,一開始想到的是跟 MTU 相關的問題,所以找了指令降到 1400 後測試,還是一樣...

後來先把 VM 的網路改成 NAT,再測試上傳速度就正常了...

接著想要換個網路卡類型看看,結果卡在找不到 driver。

本來已經想拿 tcpdump 出來追了,但想說先去看看 Windows 10 網卡設定裡面的設定,結果看到 LSO... 就先關看看 (算是以前在 FreeBSD 以及 Linux 下的經驗?)。

然後一關就正常了,交叉再開關兩次確認這個參數有影響,就肯定這個 workaround 應該是有效了...

另外在自己找完問題後,在「Virtualbox 7.0.12 slow upload speed in any Guest OS」這邊看到了類似的問題以及同樣的 workaround。

LSO 過了十幾年還是...

VirtualBox 的 KVM backend 版本

看到「VirtualBox KVM Public Release (cyberus-technology.de)」這邊的討論,原文是「VirtualBox KVM public release」,專案則是在 GitHub 上的 cyberus-technology/virtualbox-kvm 這邊。

這個算是解決了 VirtualBoxLinux 上常遇到的問題:當使用 VirtualBox 時無法同時使用 KVM,像是 qemu-kvm 這樣的工具。

不過看起來是直接大改 VirtualBox,而不是補一個 extension 或是 plugin 的感覺,雖然說明現有的 guest OS 可以直接套用。

沒有 pre-compiled binary,需要自己編,而且目前的版本得用 Ubuntu 22.04 內的 GCC 11 編譯,裝了新版的 GCC 12 會有狀況:

Newer GCC versions (>= 12) might cause build issues.

另外目前的主要測試的平台還是以 Intel 為主,AMD 這邊是「會動」但沒有詳細測過:

Currently, Intel x86_64 is the only supported host platform.
AMD will most likely work too but is considered experimental at the moment.

然後在比較新的 Intel 平台上,Linux kernel 有些東西要開機參數調:

Starting with Intel Tiger Lake (11th Gen Core processors) or newer, split lock detection must be turned off in the host system. This can be achieved using the Linux kernel command line parameter split_lock_detect=off or using the split_lock_mitigate sysctl.

看到編譯參數裡面的 --disable-hardening,hmmm... 先繼續放著看看?

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.

是個懷舊的討論串...

Gentoo 宣佈支援 binary package

Hacker News 上看到「Gentoo goes Binary (gentoo.org)」這篇,原文在「Gentoo goes Binary!」這。

Gentooportage 知名,這點在維基百科條目開頭就有提出來:

Gentoo Linux (pronounced /ˈdʒɛntuː/ JEN-too[3]) is a Linux distribution built using the Portage package management system. Unlike a binary software distribution, the source code is compiled locally according to the user's preferences and is often optimized for the specific type of computer.

這算是 Gentoo 的特色,不過即使 Gentoo 超愛 source package,也還是支援 binary package 安裝,但以前只提供重點套件,這包括了像是 Linux kernel 以及 gcc 這種套件,總是要有這些東西才能開始編軟體。

而這次公告宣佈要全面支援 binary package 算是個大轉變:

To speed up working with slow hardware and for overall convenience, we’re now also offering binary packages for download and direct installation!

目前 binary package 的主力會在 amd64 與 arm64 平台,然後提到這會對 mirror site 有額外的空間需求:

For most architectures, this is limited to the core system and weekly updates - not so for amd64 and arm64 however. There we’ve got a stunning >20 GByte of packages on our mirrors, from LibreOffice to KDE Plasma and from Gnome to Docker. Gentoo stable, updated daily.

從文末的圖也可以看到「the amount of binary package data in GByte for each architecture」得資訊:

想得到的客群大概是兩種,第一類是對於想用 Gentoo 看看的人來說會更好入手,尤其是手上是 Raspberry Pi 這些 CPU 不快的 SBC 會方便不少...

另外一種是不太在意效能,但是對某些 package 來說有高度客製化需求的人,會希望自己編這些 package 的人,透過 portage 自己調整。

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 層級了:

差不多就這些...

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 都有非常巨大的改善。