把 terminal 軟體從 xfce4-terminal 換成 wezterm

我自從換到 Xubuntu 後一直都是用 xfce4-terminal,直到三月中的時候換成 wezterm 了,記得當時是在 Fediverse 上看到 gugod 說他用這套,測了一下覺得比 xfce4-terminal 好用,可以微調不少 xfce4-terminal 做不到的東西,就換過去了。

前陣子看到「Just How Much Faster Are the GNOME 46 Terminals?」這篇 (via),在 Hacker News 的討論裡面有提到另外一篇文章有測試 terminal latency 的問題:「Terminal Latency」,看了一下 wezterm 的速度不算快,不過 terminal 的速度目前不是我的痛點,所以還好:

(話說 xterm 居然是最快的...)

翻了一下之前在 2021 的時候有提到過 wezterm,不過當時是在講 vttest:「用 vttest 測試 terminal 程式實做的相容性」。

wezterm 是透過一個 Lua 檔案 (~/.wezterm.lua) 在管理設定的,而且預設支援 hot reload,所以不用太擔心會需要一直調整後重啟。

我的設定檔在 config repository 裡面有,不過我是建議自己花些時間調整,如果你是 terminal-heavy user 的話...

Wikimedia 新計畫:WikiFunctions

Wikimedia 的新計畫 WikiFunctions:「Introducing Wikifunctions: first Wikimedia project to launch in a decade creates new forms of knowledge」。

官方的說明中提到 WikiFunctions 是提供給 Wikimedia 其他的計畫用的程式碼:

Wikifunctions is a Wikimedia project for everyone to collaboratively create and maintain a library of code functions to support the Wikimedia projects and beyond, in the world's natural and programming languages.

這樣有點抽象,看「Wikifunctions:Catalogue」這邊的範例會比較具體一點,可以看到都是實作很基本的功能,像是「Function: To Uppercase」。

Hacker News 上也有討論:「Wikifunctions (wikimediafoundation.org)」,在 id=38549081 這邊有人比較清楚的說明了要解決的問題:

A lot of Wikipedia sites have scripts embedded in the wikitext which automatically generate or transform information on a page, e.g. automatically performing unit conversions to generate text like "I would walk 500 miles (804.67 km)", performing date math to automatically generate and update a person's age based on their birthdate, or querying structured data from Wikidata [1] to display in an infobox. One example of these scripts is the {{convert}} [2] template on the English Wikipedia.

Initially, these scripts were written in MediaWiki template logic [3], and were maintained individually on each wiki. This quickly proved unmaintainable, and some of those scripts were rewritten in Lua using the Scribunto extension [4], but these were still per-wiki, and there were frequently issues where different wikis would copy scripts from each other and introduce their own incompatible features.

The WikiFunctions project is an attempt to centralize development of these scripts, much like how Wikimedia Commons [5] centralizes hosting of freely licensed images and other media.

MediaWiki 本身的 template engine 還是有極限,所以很多的需求會希望使用程式語言開發,一方面是比較好維護,另外一方面是效率也比 template engine 硬幹來的好。

先前大家在 MediaWiki 上比較常用的方案是透過 Extension:ScribuntoLua script,而這個 extension 後來變得太重要 (好用),直接包進 MediaWiki 了。

拿個例子來說,常見的引用功能 Template:Citation 裡面直接是透過模組實作:

<includeonly>{{#invoke:citation/CS1|citation
|CitationClass=citation
}}</includeonly><noinclude>
{{Documentation}}
</noinclude>

而這邊的 #invoke 就是去使用「Module:Citation/CS1」這邊的 Lua 程式。

目前的架構上面,每個語言的 Wikipedia 都需要使用 Lua 維護自己的 Module:*,而 WikiFunctions 計畫則是希望能夠整合起來,算是重新打造基礎建設的工程。

目前看了一些 WikiFunctions 的實作,主要是以 PythonJavaScript 為主。

這樣看起來,技術上是蠻有機會讓 Scribunto 退役,但實際上要不要這樣推還沒查到討論,在 Wikifunctions:FAQ 這邊則是沒提到 Scribunto,不確定是不是想雙軌跑...

HAProxy 1.6 的兩個大功能:Quote 以及 Lua

HAProxy 1.6.0 出版的公告文章:「[ANNOUNCE] HAProxy 1.6.0 released」。

兩個大功能,第一個是「It’s 2015, let’s use QUOTE in configuration file」,可以用引號了... 另外一個是「Lua Scripting」,需要 Lua 5.3+。

還有提到一些改進,像是支援 SNI,以及對 HTTP/2 的計畫。

支援多 CPU 的 ab:wrk

在「wrk」這邊看到 wrk 這個工具:「Modern HTTP benchmarking tool」。

利用 multi-threading 與 epoll/kqueue 撐出效能:

wrk is a modern HTTP benchmarking tool capable of generating significant load when run on a single multi-core CPU. It combines a multithreaded design with scalable event notification systems such as epoll and kqueue.