YAPC::Fukuoka 2025 研討會的日期是 2025/11/14 與 2025/11/15 兩天。場地在福岡工業大學。這次只有參加，沒有發表。在徵稿階段時有投，但沒有被選上，只好先把那個題目冷藏起來之後再拿出來溫看看。
從議程表看來，這次的「Perl 濃度」似乎很高。可能是近年的 YAPC Japan 的內容內 Perl 濃度最高的一次。雖然 YAPC 這個名字原本就是 Perl 社群在扮研討會時所用的名字，但近年來有難免有不少並不直接與 Perl 相關的議程。這也是近七、八年來以 yapcjapan 名義在日本辦的，首次有兩日議程的 YAPC 研討會。
以下稍微記錄一下自己參與的課程
k1LoW/deck 指的是由 [k1Low][] 所做的 deck 這個投影片製做軟體。在 YAPC 必定會有某個演講是關於自作的投影片製做軟體的啊。高速化的部分主要是在於把內部一些呼叫 Google Slides API 的部分批次化。減少呼叫次數。讓執行快速的好處所附帶來的好處就是 e2e 測試能夠比較快結束，省下等待時間。
use v5.42 後源碼檔案的內容會被強制定在 ASCII。如果混入了 ASCII 範圍外的字，perl 會在編譯過程中報錯。這個設計主要是用來避免 unicode confusables 所帶來的麻煩事吧。以前我試著在多個程式語中，讓變數名稱內混入 HALFWIDTH HANGUL FILLER (U+FFA0)，讓原始碼在人眼看來莫名其妙，基本上是大成功(?): gugod/xxx。限制讓源碼檔案內的字必須在 ASCII 範圍內的話就可以避免這一整類的問題了。
場地是大學校園，主辦單位借了好幾間教室。場地整體的感覺跟 COSCUP 2025 所在的台科大很像。有基本的教室跟有個大演講廳。可能也由於是教學大樓的關係，走廊的空間相對小。但好在，就算要「翹課」在外混時間，教室外面 20 公尺出就有很棒的室外桌椅，可以在風景優美的湖邊稍微休息一下。我在湖邊坐了 30 分鐘，稍微加強了 perlbrew 的 e2e 測試。
逛這次的贊助商攤位，可看到幾乎每一間都把自家軟體服務的架構畫出來給大家看。然後基本上每一件都是使用 AWS 生態系內的產品。看來 AWS 真是 YAPC 場外的最大贏家。 :-)
明年 YAPC Japan 將會在 Tokyo Big Sight 舉辦。相關時間表將有兩日三夜。想必是很值得期待的了。
Perl 的數值，在其內部十進位來表示。若要將十進位數字轉成其他進位數字，可用以下的 to_base($base, $n) 函式。其處理對象 $n 是十位數字數值的純量變數。其傳回值也是一個純量變數。
use v5.40;
sub to_base ($base, $n) {
state @digits = ('0'..'9', 'A'..'Z');
die 'base argument is out of rage. Is: $base, should be 2..36'
unless 2 <= $base <= 36;
# Recursive calls on an inner-sub to avoid doing redundant
# param-validations.
return sub ($base, $n) {
my $lsd = $digits[ $n % $base ];
my $high = int($n / $base);
return ($high > 0 ? __SUB__->($high, $base) : "") . $lsd;
}->($n, $base);
}而要將某個底數不是 10 的數字轉換成十進位的方式，可用以下的 from_base($base, $n) 函式。
use v5.40;
sub from_base ($base, $n) {
state @digits = ('0'..'9', 'A'..'Z');
state %decOf = map { $digits[$_] => $_ } (0..$#digits);
die 'base argument is out of rage. Is: $base, should be 2..36'
unless 2 <= $base <= 36;
# Recursive calls on an inner-sub to avoid doing redundant
# param-validations.
return sub ($base, $n) {
return 0 if $n eq "";
my $lsd = substr($n, -1);
my $high = substr($n, 0, -1);
return $base * __SUB__->($base, $high) + $decOf{$lsd};
}->($base, $n);
}這兩個函式都是以遞迴演算法寫成的。同時，為了避免多次地對不會變動的 $base 做格式上的檢查，實際上遞迴的函式並非它們本體，而是其內部一個較小的無名函式。在 Perl 中可以使用 __SUB__ 來表示「目前這個函式」，所以無名函式也可以遞迴呼叫自己。
先給專案連接： TwoStackWM.kwinscript
在 macOS 上作業時透過 TwoStackWM.spoon 將視窗的格局管理做到最簡化。而最近在使用 KDE Plasma 是也覺得應該要有一樣的簡化方式，能讓我只用一組熱鍵就決定目前焦點視窗的寬高與位置。就不必老是花時間在調整視窗位置。
於是就有了使用 KWin Script 來延伸 KDE Plasma 既有的視窗管理的方法。
在 KDE Plasma 環境中既有的 tiling window manager 不少，例如：
每個都很通用，都有不同的操作模式。但對我這記不住複雜規則的人來說，還是只要一坐一右兩邊並排就好。在 KDE Plasma 中預設的 tiiling 是左右同寬，但我比較想要左小右大，沒什麼熱鍵需要記憶的管理方法。所以還是覺得自己寫一個 WM 好了，於是就再花點時間學了一下 KWin 的寫法與 API，而做了： TwoStackWM.kwinscript
根據摸索大半天下來的經驗，目前這個初版大概只能支援 KDE6，不支援 KDE5。因爲正好有個與舊版不相容的，關於修改視窗寬高方式的變更在 KDE6 出現了。也有可能只支援 Wayland 而不支援 X11。但還好，反正我沒有那麼多就舊系統需要照顧。
雖然 KWin API 沒有代客處理跨環境的相容性問題，得要寫程式的人自行想辦法處理，但基本上 KWin Script 算是其實頂簡單的。這次是直接寫 Javascript。如果有需要多多延伸發展的話再來看看要不要改成 QML 好了。
我平時使用的外接鍵盤都是在韌體層就改爲 Dvorak 佈局，但，帶筆電外出時有可能無法再帶一個鍵盤，所以希望能夠調整作業系統界面，讓我能夠在使用筆電鍵盤於外接鍵盤是都能使用 Dvorak 佈局來打字。這邊主要的需求是
最後摸索出的方法是直接用 Fcitx5 內建的方式來做到。
修改 Fcitx5 設定。開 KDE 的「設定」App，進入「輸入法」那一區調整 Fcitx5 的設定內容。
~/.config/kxkbrc 便會在 fcitx5 起動時自動依照前述設定內容重新產生出來。
在套用這段設定之後，以滑鼠右鍵點擊 Fcitx5 於系統工具列上的按鈕後，應可 看到切換兩群組的選單。選了其中之一個群組後，在輸入法沒有啓用的狀態下， 便會對應到該群組內的系統佈局。切換到 Rime 或 Mozc 後，也會自動對應到各 自的系統佈局。
最後重新開機後確認一下結果就好。
最近花了一些時間在試用一些於 macOS 上提供所謂 tiling window management 的軟體。
比較有名的是這三家：
綜合來說，Amythest 算是夠好用，也很好裝（相對於其他兩者而言）。但是對於我而言總是有一些不夠，或是很難搞的地方。
我花了點時間稍微定義了一下於我而言必要的「視窗管理機能」，大約是以下這幾項：
「主要區」與「側邊區」的這種區分概念主要是在用過 xmonad 與 dwm 後帶過來的，比起要經常決定「要把目前這個視窗放在螢幕上的哪個區象限」，以「把目前這個視窗移動去主要區或是側邊區」這種方式來簡化管理難度，對我而言更加合適。
在釐清了自己的需求之後，很容易就可以發現到之前試過的幾個 tiling window manager 都不夠用了。於是只好自己找工具湊合看看了。
在定義快速鍵方面，有找到 Keyboard Cowboy 這個能讓人自定自動化工作流程，並將工作流程綁在快速鍵上的工具。能滿足我上述需求列表中的第一點及第二點。
在視窗管理方面，雖然沒有找到能直接滿足我需求的軟體，但找到了 Hammerspoon 這個工具。這個工具能讓人以 lua 程式語言來自己寫一套 tiling window manager 出來。於是我立刻就自己寫了一套試試。名爲 TwoStackWM。
這個 TwoStackWM 只提供六個能將目前焦點視窗移動到別處的函數：
moveFocusedWindowToMainStack() -- 移動到主要區
moveFocusedWindowToSideStack() -- 移動到側邊區
maximizeFocusedWindow() -- 最大化
toggleFocusedWindowToMainOrSide() -- 在主要區與側邊區兩狀態間切換
toggleFocusedWindowToMaxOrMainOrSide() -- 在最大、主要區與側邊區三中狀態中切換
moveFocusedWindowToNextScreen() -- 移動到下一個螢幕
而主要區與側邊區的大小比例，則是在設定當中一次性寫好的。無法動態調整。也就是說我可花一次時間將其調整到大致順眼的比例，然後就再也不必管了。
TwoStackWM 並不會把所有視窗一次顯示出來。而是最多只會顯示兩個，一主一側。要切換焦點就使用 macOS 原生、改不掉的 Cmd-Tab 快速鍵，使其成爲視窗堆疊中最上層的就好。
Hammerspoon 提供的函數十分直覺好用。並且，它也提供了一個 Console 可以讓人立刻執行一段 lua 程式碼。十分便於開發。能過讓我以不到 100 行的程式碼就定義出能符合自己需求的 Window Manager出來。
目前還沒摸索出如何以 Hammerspoon 取代 Keyboard Cowbody 提供的工作流程功能。但想必一定程度上也是做得到的。
Monty Hall Problem （蒙提霍爾問題）是個奇妙而有趣的數學遊戲問題。維基百科上提供的問題本文為：
假設你正在參加一個遊戲節目，你被要求在三扇門中選擇一扇：其中一扇後面有一輛車；其餘兩扇後面則是山羊。你選擇了一道門，假設是一號門，然後知道門後面有什麼的主持人，開啟了另一扇後面有山羊的門，假設是三號門。他然後問你：「你想選擇二號門嗎？」轉換你的選擇對你來說是一種優勢嗎？
此問題的解答是「會」，也就是換答案後會比較容易得到汽車的意思。
但，這答案是以列舉出幾種狀況的機率來比較而得的。以機率而論，如果我能玩這遊戲 1000 次，那麼每一局都依主持人提供的資訊來更換答案後，我能在這 1000 局內獲勝的總次數較多。期望值約為 1000 2/3，也就是約為 666 次。而如果我每一局都不換答案，那我在這 1000 局內的獲勝期望值則為 1000 1/3，也就是約為 333 次。
既然如此，那就必須寫個程式來模擬看看了。以下是 play-monty-hall.pl ，以 perlclass 提供的新語法寫成的一個模擬程式，可模擬兩種策略玩家在玩了多局之後的勝率。雖然沒有註解，但應該還算是能夠望文生義的程度。
#!/usr/bin/env perl
use v5.38;
use feature 'class';
no warnings 'experimental::class';
class Game {
field $doors :param;
field $winningDoor = 1 + int rand($doors);
method doors { $doors }
method winningDoor { $winningDoor }
method loosingDoors {
grep { $_ != $winningDoor } (1..$doors);
}
};
class FirstChoicePlayer {
field $doors :param;
field $firstChoice = 1 + int rand($doors);
field @loosingDoors;
method doors { $doors }
method addLoosingDoors ($n) { push @loosingDoors, $n }
method loosingDoors () { @loosingDoors }
method firstChoice () { $firstChoice }
method finalChoice () { $firstChoice }
};
class ChangeChoicePlayer :isa(FirstChoicePlayer) {
method finalChoice () {
my %isLoosing = map { $_ => 1 } $self->loosingDoors();
my @choices = grep { $_ != $self->firstChoice() } grep { ! $isLoosing{$_} } 1..$self->doors();
die "Illegal state" if @choices != 1;
return $choices[0];
}
};
class GameMaster {
field $doors :param;
method playWith ($player) {
die "No player ?" unless defined $player;
my $game = Game->new( doors => $doors );
my %untold = map { $_ => 1 } ($game->winningDoor, $player->firstChoice);
while ((keys %untold) == 1) {
my $door = 1 + int rand($doors);
$untold{$door} = 1;
}
my @revealLoosingDoors = grep { ! $untold{$_} } (1..$doors);
for my $door (@revealLoosingDoors) {
$player->addLoosingDoors($door)
}
my $finalChoice = $player->finalChoice();
return $finalChoice == $game->winningDoor;
}
};
sub playOneRound($playerClass) {
my $doors = 3;
my $gm = GameMaster->new( doors => $doors );
my $player = $playerClass->new( doors => $doors );
return $gm->playWith( $player );
}
sub play ($rounds, $playerClass) {
my $wins = 0;
for (1 .. $rounds) {
my $win = playOneRound($playerClass);
$wins++ if $win;
}
return $wins;
}
sub sim ($rounds) {
for my $playerClass ("FirstChoicePlayer", "ChangeChoicePlayer") {
my $wins = play($rounds, $playerClass);
my $pWin = $wins / $rounds;
say "$playerClass wins $wins / $rounds. p(win) = $pWin";
}
}
sim(shift // 1000);
可以提供一個參數，表示要模擬幾局。預設為 1000 局。執行起來如下：
# play-monty-hall.pl
FirstChoicePlayer wins 323 / 1000. p(win) = 0.323
ChangeChoicePlayer wins 665 / 1000. p(win) = 0.665
# play-monty-hall.pl 1000000
FirstChoicePlayer wins 333606 / 1000000. p(win) = 0.333606
ChangeChoicePlayer wins 666348 / 1000000. p(win) = 0.666348這程式內主要幾個互相作用的 class:
FirstChoicePlayer: 以不變為其策略的玩家
ChangeChoicePlayer: 以改變為其策略的玩家
GameMaster: 與玩家互動的遊戲主持人。
Game: 維護單一一局的遊戲初始資訊。基本上只有記住哪號門是贏門 ($winnigDoor)，並提供列舉出所有輸門的方法 loosingDoors
Game 物件在建構、初始完畢後計基本上是個常數了，沒有什麼特別的地方。 FirstChoicePlayer 也差不多，只是會有個 @loosingDoors 內部狀態來記著那些由 GameMaster 提供的輸門號碼。
而此處我讓 ChangeChoicePlayer 為 FirstChoicePlayer 的延伸，依照 $self->firstChoice 與 $self->loosingDoors 的內容來推算出 finalChoice。這邊我原本以為透過繼承機制，FirstChoicePlayer 的兩個 field 變數都可以直接在 ChangeChoicePlayer 內來使用。但結果是不行，必須在透過 FirstChoicePlayer 內定義的 getter method 才行。這表示由 field 所定義出來的便是是私有於該類別而已。
在所有類別中有一項共同參數 $doors，也就是這遊戲的門的數量。Game 類別是依 $doors 來隨機生成出贏門的號碼。兩個玩家類別內則是以數字去隨機產生 firstChoice。GameMaster 類別則是以此資訊來建構先的 Game 物件，還有推算出能告訴玩家哪些門是輸門。這邊我用了 :param 這個添在 field 變數上的屬性 (field $doors :param;)，來代表說這 field 的值必須被提供給類別的建構函式 new。這用法尚算直覺。而其他依賴 $doors 的值所計算出來的各 field 都似乎是正確地在物件建構時期被計算完畢了。無須另外調整。
目前幾個有需要用到的 getter method 都是我自己手動補上的，讓程式碼看來量很多。但依 perlclass 文件中 TODO 一節 內的說明，看來以後能寫個 :reader 來讓 perl 自動生成出 getter method。就能省下不少打字的力氣。
雖然 perlclass 語法跟類別機能十分基本，比不上其他以物件導向為核心設計的語言。但以這個小程式的用途用起來沒意外，很夠用。等以後改版之後再來看看有沒有什麼更有意思的地方。
最近發現 GNU Stow 這個軟體，其主要提供的功能是以 symlink 來做到軟體安裝。其自我介紹文中第一段話為：
GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place.
意思就是說：你可以用 GNU Stow 把本來裝在四處的資料或程式，以 symlink，讓它們看來好像是全裝在同一個目錄下。
乍看之下好像怪怪的沒有什麼用處（為何不一開始就裝在一起？）但轉念一想：這不就是 homebrew 的做法嗎？
看來 GNU Stow 所做的工作，就類似於 brew link 這個階段，把本來安奘在 A 處的各個檔案，逐一在 B 處建立相對應的 symlink。由於 B 處都是 symlink，要移除也相對簡單。並且，能以 symlink 內容作為某種安裝證明，不怕失誤刪到了不在管轄範圍內的物件。
這做法對於管理 $HOME 底下的 dotfile 十分有用。由於 dotfile 都是必須要放在 $HOME 底下指定位置的檔案，如果要以版本控制系統來管理，那就還要另外有一套方式去把那些檔案自版本控制系統中拷貝出來放在 $HOME 底下，如果還想要有簡單的同步或刪除機制的話，用 GNU Stow / symlink 似乎就很適合了。
以下用幾個簡單的範例來示範一下。首先是建一個 dotfiles/ 目錄，並在底下依照軟體名建立出若干子目錄。子目錄底下則是放置該軟體的 dotfile。並且，使其中 dotfile 路徑有保留住 $HOME 之後的部分。例如，如果某 abc 軟體的 dotfile 為 $HOME/.config/abc/abc.conf，那就把其 $HOME 的部分換為 dotfiles/abc/。也就是要建出 dotfiles/abc/.config/abc/abc.conf。
如果是從既有的檔案移管，準備起來大致上像這樣：
mkdir -p dotfiles/zsh
cp ~/.zshrc ~/.zshenv dotfiles/zsh/
mkdir -p dotfiles/emacs/.emacs.d
cp ~/.emacs.d/init.el dotfiles/emacs/.emacs.d
mkdir -p dotfiles/sway/.config/sway/
cp ~/.config/sway/* dotfiles/sway/.config/sway/
mkdir -p dotfiles/wezterm/.config/wezterm/
cp ~/.config/wezterm/* dotfiles/wezterm/.config/wezterm/將 dotfiles/ 準備完畢之後，就執行 stow
cd dotfiles
stow --target=$HOME zsh/
stow --target=$HOME emacs/
stow --target=$HOME sway/
stow --target=$HOME wezterm/這麼一做完之後，原本 $HOME 底下的 dotfile 就會被 stow 改成是連到 dotfiles/ 目錄底下某個檔案的 symlink 了。
而 dotfiles/ 目錄本身就可以再透過 git init 等步驟來納入版本控制系統中，並且，其內容是依照各個軟體名分類放好了的。就算實際在 $HOME 底下會出現在很多子目錄，但在版本控制系統中是很一致的。
特別是在刪除的時候。有時候試用軟體要寫幾個 dotfile，一陣子沒用後，把軟體刪除了，但 dotfile 卻沒有一起清。久而久之就忘了那些在 $HOME 底下的 .abcrc、.xyz.conf 倒底是有用還是已經沒用的了。變得想清理又會怕弄錯。
透過本文所述的管理方式，如果哪天想把軟體 abc 的 dotfile 全丟了，也不必再花心力去找出它的 dotfile 是 .abcrc、.abc.conf、config/abc/abc.conf 還是什麼其他冷門的命名慣例，只要以 stow 指令：
stow --target=$HOME --delete abc/就可以把當初安裝上的所有檔案一次清光了。
如果發現不小心刪錯了，再重跑一次 stow 就可以救回來。
GNU Stow 的機制簡單又合理。看來應該能讓管理個人的 dotfile 的過程變得更有條理一些。
這一次的 YAPC Japan 是辦在廣島國際會議中心，位於和平紀念公園內，離原爆圓頂館很近。雖然離市中心區有一小段距離，但走起來並不算遠。
比起去年的 YAPC::Kyoto，這次的活動規模似乎擴大了。贊助商數竟然超過 50 家，而且有八間是廣島當地的中小企業。這還真是令人驚訝。
不過這次的議程，在內容方面與 Perl 直接相關的已經減少到一半左右了，可能算是有些偏離主體？但儘管如此，技術方面的主題仍然挺吸引人，並且技術知識的共享方面是共通的。似乎可以不必計較。
贊助商的攤位方面，有十來間到場設攤宣傳的廠商。另我印象比較深刻的是 chocoZAP 這個主打用零碎時間來運動的輕度健身的品牌，竟然也是贊助商（其公司為 RIZAP）。而且也在現場招募。從宣傳單上看來，伺服器端是 Ruby，iOS App 為 Swift，Android 為 Kotlin 這樣的組合吧。宣傳單的背面則是拉人加入健身房會員的廣告了(附折扣碼)（笑）。
另一間另我印象深刻的是 Findy。其主產品是協助軟體團隊能理解開發現況的視覺化輔助工具。跟我在碩士班期間做的題目很像。能給一個團隊一些簡明的圖表來迅速看出目前專案開發的狀態，瓶頸之有無，人員協作的連結度等等。應該比較偏向是給管理階級的人員看的圖資工具。
議程本體方面，總共分成三軌，自然也是等日後看有沒有錄影可以補完。在此先大致上摘要了一些我現場聽到覺得有意思的內容。
〈VISAカードの裏側と “手が掛かる” 決済システムの育て方 by 三谷〉。講者是在 VISA 發卡公司員工。這演講算是業界甘苦談吧。難度核心部份在於要能夠「寬鬆而有彈性地」去處理由 VISA API 呼過來的各種不太合理的內容。講者宣稱在聽完後，大家之後必定會在拿到刷卡對帳單時好好看一下在那張小單據印上的各欄資訊。這是真的。
〈rakulangで実装する! RubyVM by 八雲アナグラ〉。講者探索了如何以 rakulang 製作一個簡單的 Ruby VM，並分享了其摘要。嚴格說起來他做的程式不算是 Ruby VM，因為不能吃 bytecode，只能吃文字格式的組語。但要做出 YARV bytecode 似乎不那麼容易，所以就退而求其次了。是深入淺出，內容豐富的演講。
〈PerlでつくるフルスクラッチWebAuthn/パスキー認証 by macopy〉。講者用 live coding 形式說明了 WebAuthn 協定。概要清晰，有把 WebAuthn 中幾個重點都解釋出來。live coding 最後也成功了。但看來有 80% 左右的程式碼是 Copilot 寫的啊。 （結果 ok 就好）
Keynote 由「とほほのWWW入門」這個網站的作者「杜甫々」來登台。看來是位人人皆知的名人，這網站上所有文件似乎都是他自己編寫的，種類眾多，從軟體技術細節到所得稅法都有著墨。真是不得由衷讓人欽佩：怎麼會有人這麼會寫文件？
伴隨研討會的舉行，同時這次由面白法人主催了個 perlgolf 活動。很久沒玩了，還是頂懷念這種看似胡搞，但卻又能確實達成目的且節節變難的重構過程啊。同時也有種：「這才是 Perl 研討會啊！」的一種爽快感。雖然實務上不會有要把程式碼節節縮短的需要，但對同一個問題反覆進行重構、不斷得出不同風格的解法，不也是一種解決問題所必備的基礎能力嗎？
最近注意到有三個新版連發：
但是內容都一樣，看來是專門為了處理以下兩個 CVE 而發的新版本：
CVE-2023-47038 的影響範圍是自 5.30.0 (釋出日為 2019/05/22) 到 5.38.0 （釋出日為 2023/07/02）。這範圍不小，得來升級一下。
在 Fedora Linux 上，要裝設 Sway 的方式是裝 Sway Desktop 這一組套件：
dnf group install 'Sway Desktop'
這麼做完之後，在 GDM 登入畫面內某個不起眼的選單內底就可以選擇使用 Sway。
但只是這樣的話，有一些需要在 sway 啟動前就設定好的環境變數似乎就無法可設。主要是這些：
MOZ_ENABLE_WAYLAND=1
INPUT_METHOD=fcitx
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
稍微找了一下，發現透過 gdm 開的 sway，似乎是叫做 start-sway
# pgrep -lfa gdm
1208 /usr/sbin/gdm
2011 gdm-session-worker [pam/gdm-password]
2151 /usr/libexec/gdm-wayland-session --register-session start-sway
在 /usr/share/wayland-sessions/sway.desktop 中也可看到這行：
Exec=start-sway
在 /etc 搜尋 start-sway 這個字串的話，可看到 /usr/bin/start-sway 這檔名出現在 /etc/sway/environment 內。
# sudo rg start-sway /etc/
/etc/sway/environment
2:# from /usr/bin/start-sway script for all users of the system.
/usr/bin/start-sway 這個檔案是個 shell script，讀其程式碼後發現它的主要作用是去讀取 /etc/sway/environment 及 ${HOME}/.config/sway/environment 的內容，吃進這兩檔案內所設好的變數之後，再啟動 sway。
看來正好能滿足我的需要。於是將一干變數塞入 ${HOME}/.config/sway/environment 後，登出、重新登入。就管用了。
我猜 start-sway 這 shell scrett 是 Fedora Linux 方面對設定環境變數這需求所實做出的一個變通方法。
目前使用 Sway 主要的問題之一，是在只支援 Wayland 的幾個應用程式視窗內進行打字時，雖可看到輸入的「預編輯」有正確地內嵌在應用程式中，但是選字窗則是完全消失，毫無蹤影。
不少通 Wayland 協定的終端機類程式，如 foot、WezTerm 等等，皆是能打字，但選字窗看不到。反而，那些需透過 XWayland 才能執行的程式，像是 lxterminal 跟 Emacs 就能打字，能看到選字窗：
依 @wengxt 在 Fcitx5 專案中所留之言，不見選字窗，是因為 Sway 卻乏幾項關於 input_panel 協定之實作，而讓 fcitx5 無法得知該將選字窗繪製在何處。
依照 fcitx5 wiki Using_Fcitx_5_on_Wayland#Sway 這一頁中簡短的說明看來，似乎已經有一解 Sway PR 7226 待併入 Sway 之中。雖然仍需等待，但總之，各類程式都有替代方案，因此都算可用。
https://www.fastmail.help/hc/en-us/articles/4406536368911-Masked-Email
基本上是把多個自動生成的 email 地址對應自己的信箱的轉寄服務。這自動生成的 email 地址通常看來就像是串不好唸的咒文。
賣點就是匿名性。如果有什麼網站資料被竊盜的問題發生時，可以立刻把流出去的那個 email 地址給撤銷掉，讓它變成無效的。（從這點看來，自動生成的演算法必 須要類似 UUID 那樣，既不太容易列舉、又絕對不會生出重複的字串。）
原則上是每個站都給不同的 email 地址會比較好管理。
像在 Usenet group 這種公開場所，基本上必須在 From 欄位內給出自己的 email 給所有人看。顯然也很適合來使用這種 email 地址。
現在有一些 Usenet group 上的人會故意在 From 內的 Email 地址處提供像 `john@ex{amp]le.com' 這種不合規格的字串，也算是個方法。由於 hostname 部分 解不出來，至少能防到一些爬資料的機器人。但有智慧的物種則有機會看穿這種 email 地址的用意而在必要時手動修正一下。只是或許有被 NNTP 伺服器擋掉，或 是造成處理失誤等可能性。
另外想到有 https://simplelogin.io/ 這個服務。基本上是一樣的，但 simplelogin 只有提供轉寄，而 fastmail 主要是提供 email 信箱。
還有 https://duckduckgo.com/email/ Duckduckgo 那裡也有提供類似的，他們叫做 "Private Duck Address"。似乎可以一直產生新的。但是必須先去申請一個 @duck.com 的 email 地址下來，然後這個 email 地址也只是轉寄到現有信箱。
proton mail 那邊好像還沒有這做到這種地步，不知是否有機會跟進。
ibus mozc 的預設輸入模式叫做 "Direct Input"，也就是「不是日文輸入」的意思。依照預設熱鍵設定看來，似乎是為了能讓人使用鍵盤上的「變換」鍵來快速於「英數」與「平假名」兩種輸入模式間切換。但對於使用多種輸入法的人來說，變成要在切換到 mozc 後還要再多按一次變換鍵才能開始打平假名，反而礙事。
要讓 ibus mozc 的預設模式為平假名的辦法，是去修改 .config/mozc/ibus_config.textproto，讓 active_on_launch 為 True：
active_on_launch: True改完後重新開機。
順帶附上整個檔內容如下，以供參考：
# `ibus write-cache; ibus restart` might be necessary to apply changes.
engines {
name : "mozc-jp"
longname : "Mozc"
layout : "default"
layout_variant : ""
layout_option : ""
rank : 80
symbol : "あ"
}
engines {
name : "mozc-on"
longname : "Mozc:あ"
layout : "default"
layout_variant : ""
layout_option : ""
rank : 99
symbol : "あ"
composition_mode : HIRAGANA
}
engines {
name : "mozc-off"
longname : "Mozc:A_"
layout : "default"
layout_variant : ""
layout_option : ""
rank : 99
symbol : "A"
composition_mode : DIRECT
}
active_on_launch: Trueperl-5.38.0 變更說明： https://metacpan.org/release/RJBS/perl-5.38.0/changes
摘要：
class, field, method 三個定義類別的關鍵字。（實驗性機能。須以 use feature 'class'; 打開。）
PERL_RAND_SEED 環境變數為程式開跑時的亂數種子值。相當於去呼叫 srand() 。
package 或 class 的 .pm 檔案) 最後補上 true
' 分隔符號。
這應該是這是兩三年來著力最多的部份吧。比起多數提供在 CPAN 上的 OO 框架，perlclass 相對來說很好懂。有三個新的關鍵字與其帶來的新語意，但是幾乎沒有新的語法規則，至少目前沒有。
參考：perlclass 文件。
三個新關鍵字是：class、method、field。class 用來定義類別。method 用來定義 instance method，field 用來宣告 instance variable。
以 class 定義出來的類別會自動以 new 為其 constructor 函式，並且，所有 instance method 體內皆能以 $self 表示目前物件。class 體內的 instance method 的 signature 則不可包含 $self。
而 class 體內的 sub 可用來定義 class method， class 體內的 my 則可用來宣告 private class variable。 class 體內的 our 則可用來宣告 public class variable。
在同一 class 體內以 my、our、field 宣告出來的諸變數是共用同一個名稱空間的。名稱有衝突的話，只有最後一個變數會被留下。
在同一 class 體內以 sub 與 method 宣告出來的各函式也是共用同一個名稱空間的。名稱有衝突的話，只有最後一個函式會被留下。
以 field 宣告出來的變數為 instance variable，只能被用於 instance method 體內。
以 method 定義出來的函式為 instance method，體內可使用 instance variable，同時亦會自動有 $self 可用來代表目前物件。要呼叫其他同一 class 內的 class method 的寫法與普通函式呼叫相同。要呼叫 instance method 時則是需要對 $self 呼叫。
當做範例，以下是一個描述了五段變速電風扇的簡易類別。
use v5.38;
use feature 'class';
use builtin 'true', 'false';
class Fan {
use List::Util qw(min max);
my $__id = 1;
my $RPM_MAX = 600;
my $RPM_MIN = 100;
my $RPM_STEP = 100;
sub vendor { "Cool Company" }
sub speeds { ($RPM_MAX - $RPM_MIN ) / $RPM_STEP }
field $id = $__id++;
field $rpm = 3600;
field $on = false;
method id { $id }
method speed { $rpm / $RPM_STEP }
method turn_on { $on = true }
method turn_off { $on = false }
method faster { $rpm = min($rpm + $RPM_STEP, $RPM_MAX) }
method slower { $rpm = max($rpm - $RPM_STEP, $RPM_MIN) }
method TO_JSON {
+{
# instance method / variable
id => $self->id(),
speed => $self->speed(),
on => $on,
# class method / variable
vendor => vendor(),
speeds => speeds(),
rpm_max => $RPM_MAX,
rpm_min => $RPM_MIN,
}
}
}前述以 sub 定義出來的 class method，其實也可以被當成是 instance method 來呼叫。例如 Fan 類別的 vendor ，有兩種呼叫方式：
my $fan = Fan->new;
say $fan->vendor(); # (1)
say Fan->vendor(); # (2)(1) 與 (2) 兩處對應到的函式是同一個。
以 class 所附的 new 函式所做出來物件，字串形式上會有個 OBJECT 字樣：
my $fan = Fan->new;
say "$fan";
#=> Fan=OBJECT(0x19477b0);如果是以常見的 blessed HashRef 做法 (即：bless {}, 'Fan') 所造出來的物件，其字串形式是這樣：
Fan=HASH(0x1b3a5e8)由此可窺知在 perl 內部多了一種以 OBJECT 為表記的值。
true
以往都要在 .pm 檔案最後補個 1;，然後還得向人說明這行看似無作用的程式碼的用途。以後在開頭加上 use v5.38; 後就不必在檔尾補 1 了。
# Foo.pm
use v5.38;
package Foo {
sub foo() { "Bar" }
}附帶一提，就算在最後在 Foo.pm 最後故意加上 0;，也不會讓 use Foo; 失敗。
Recently on reddit.com/r/perl, pmz posted a question like this:
XML::Twig, get value (or not) without dying
Currently I do:
if (defined $elt->first_child('addr')->first_child('postalCode')) { $patient{patient_postal_code} = $elt->first_child('addr')->first_child('postalCode')->text ; }because if I don't check for "defined" and the resulting value is null , it dies.
Link to the original post: https://www.reddit.com/r/perl/comments/1492sc1/xmltwig_get_value_or_not_without_dying/
While on one hand the question is about how to use XML::Twig, on the other hand the obvious inconvenience here is when first_child('addr') returns undef, which means there are no <addr> element underneath, the following call of first_child('postalCode') would make the programm die. Generally speaking: in a chain of calls we expect objects to be present in all positions, but sometimes there are undef. Given that, is there a way to avoid the program from dying and let the entire call chain return undef if undef is encountered in the calling chain ?
To formalize the question a bit more generically: assume a class with instance methods a(), b(), and c(). These methods may return an instance of same class, or ocassionally, undef. Consider the following chain of calls originally from $o:
$res = $o->a()->b()->c();
In case any of a(), b(), or c() returns undef, the program dies with messages like this:
Can't call method "c" on an undefined value
Which suggests b() returns undef and since undef is not an object, we cannot call methods on it.
Now, could we rewrite the same program to prevent the abovementioned error from happening, while making $res be undef if any of a(), b(), c() returns undef, or otherwise, the return value of c() ?
In some other programming languages, such purpose could be satisfied by using the safe-navigation operator, such as ?. in javascript or kotlin:
res = o.a()?.b()?.c();
Or in raku, .?
$res = $o.a().?b().?c();
However, we haven't seen anything similar up until perl 5.38 just yet.
A rather intuitive way to rewrite would be something like this:
$res_a = $o->a();
$res_b = $res_a && $res_a->b();
$res = $res_b && $res_b->c();
However, besides making the program much longer and less easier to grasp, the rewrite is not generic. It'll be different for similar statements with different method names. Not a good strategy.
Meanwhile, here's a super simple and generic way:
$res = eval { $o->a()->b()->c() };
However, with the powerful side-effect of eval, all exceptions would be ignored while we are only interested in ignoring undefined values. That is a lot more than what we want. Even though it looks simple, it is probably not applicable.
Here is a solution with Monad design pattern.
The rewritten version looks like this:
$res = SafeNav->wrap($o) ->a()->b()->c() ->unwrap();
The SafeNav is defined as the folowing.
use v5.36;
package SafeNav {
sub wrap ($class, $o) { bless \$o, $class }
sub unwrap ($self) { $$self }
sub AUTOLOAD {
our $AUTOLOAD;
my $method = substr $AUTOLOAD, 2 + rindex($AUTOLOAD, '::');
my ($self, @args) = @_;
# [a]
(defined $$self) ?
__PACKAGE__->wrap( $$self -> $method(@args) ) : # [a.1]
$self; # [a.2]
}
sub DESTROY {}
};SafeNav is a class that wraps all scalar values and equips with AUTOLOAD for responding to all method calls.
Inside AUTOLOAD there is the core part of our logic in [a]: If we are not wrapping an undef value, we call the original method on it, then re-wrap the return value ([a.1]). Or if we are wrapping an undef, we ignore the method call and just lay down and keep being ourselves ([a.2]).
Thanks to the mechanism of AUTOLOAD, the original form of ->a()->b()->c() is kept exactly the same after the rewrite. Let's put both versions side-by-side for a quick comparison:
$res = $o ->a()->b()->c();
$res = SafeNav->wrap($o) ->a()->b()->c() ->unwrap();
The wrap() at the front, together with unwrap() at the back, form a clear boundary in which SafeNav is effective. Method calls after unwrap() are not not guarded by SafeNav.
With that, we properly ignore undef values, nothing more. If other kinds of exceptions are thrown from method a, b, c, the program would correctly abort. In the 3 proposed ways to rewrite the program in this article, the SafeNav monad is both generic and not adding too much verbosity to the original program.
在 reddit.com/r/perl 板上看到 pmz 問了這樣子的一個問題：
XML::Twig, get value (or not) without dying
Currently I do:
if (defined $elt->first_child('addr')->first_child('postalCode')) { $patient{patient_postal_code} = $elt->first_child('addr')->first_child('postalCode')->text ; }because if I don't check for "defined" and the resulting value is null , it dies.
原文連結： https://www.reddit.com/r/perl/comments/1492sc1/xmltwig_get_value_or_not_without_dying/
這一方面是在針對 XML::Twig 模組的用法提問，另一方面是在問：當 first_child('addr') 傳回 undef 時，表示在目前 XML 文件樹中沒有 addr 元素，而後o方的連環呼叫 first_child('postalCode') 之處就會讓程式執行中斷，因為原本預期是物件的地方，也有可能是 undef。那有沒有能讓連環呼叫不會使程式失敗，並且在遇到 undef 時，讓整串算式的結果成為 undef 的辦法？
如果把題目重新描述得較抽象一些的話，就是：假設有一類別，其下有方法 a()、b()、c()。這三個方法可能會傳回 undef 或同一類別的物件。今有一物件 $o 屬此類別，考慮此連環呼叫式：
$res = $o->a()->b()->c();
此式在 a() 或 b() 傳回 undef 時，就會讓程式中斷，並會出現像這樣的錯誤訊息：
Can't call method "c" on an undefined value
亦即：無法對 undef (undefined value) 呼叫 "c" 這個方法。這是當然的，因為 undef 並非物件。
試問：有何手段能改寫此式，能避免前述錯誤之發生，使 $res 在 a()、b()、c() 任一者傳回 undef 時就算得 undef，且在全無 undef 情況下，又能正確算得 c() 的傳回值？
在一些語言中，這可輕易得透過使用 safe-navigation operator 或 optional chaining operator 來解決。例如 javascript 或 kotlin 中的 ?.：
res = o.a()?.b()?.c();
又例如 raku 語中的 .?:
$res = $o.a().?b().?c();
但直到目前 perl 5.38 為止，在 perl 語言中尚未出現同等作用的算符。
有個直觀的改寫方式是像這樣：
$res_a = $o->a();
$res_b = $res_a && $res_a->b();
$res = $res_b && $res_b->c();
但在讓程式變長、用了多個臨時變數而讓程式碼變得稍微不好讀之外，這改寫法還不通用，碰到類似結構、名稱不同的式子就得手動從頭改寫。實在算不上是好辦法。
此外，有個超間單的改寫方法：
$res = eval { $o->a()->b()->c() };
但是，這個寫法的副作用，就是所有例外事件通通都會被忽略，雖然簡單好改，但其副作用很強。不見得在各種情境都適合。
在此提供一個以 Monad Design Pattern 來達成得的一個解法。
改寫方法如下：
$res = SafeNav->wrap($o) ->a()->b()->c() ->unwrap();
其中 SafeNav 的定義為：
use v5.36;
package SafeNav {
sub wrap ($class, $o) { bless \$o, $class }
sub unwrap ($self) { $$self }
sub AUTOLOAD {
our $AUTOLOAD;
my $method = substr $AUTOLOAD, 2 + rindex($AUTOLOAD, '::');
my ($self, @args) = @_;
# [a]
(defined $$self) ?
__PACKAGE__->wrap( $$self -> $method(@args) ) : # [a.1]
$self; # [a.2]
}
sub DESTROY {}
};這類別基本上是把所有純量值都包裝成物件。SafeNav 類別定義有 AUTOLOAD 這個特殊用途的函式，使其物件可接受所有方法呼叫。就算包著的值是 undef 方法呼叫也都不會失敗，而是會進入 AUTOLOAD 函式中。
於是在 [a] 處就可進行核心處理：若自己包著的值不是 undef，就對其呼叫原方法（[a.1] 處）。倘若自己包著的值已經是 undef 了，那繼續躺平做自己(?)就可以了（[a.2] 處）。
多虧有 AUTOLOAD 機制，原連環呼叫 ->a()->b()->c() 的部份是原樣保留著的。在此並列、比較一下：
$res = $o ->a()->b()->c();
$res = SafeNav->wrap($o) ->a()->b()->c() ->unwrap();
前後的 wrap() 與 unwrap() 算是明確界定了 SafeNav 類別在此式中的作用範圍。過了 unwrap() 之後如果還繼續串著更多方法呼叫，就一定不是被包在 SafeNav 裡面的。
這麼一來，會被「妥善忽略」的，就只有在碰到 undef 這個值的時候。若在 a、b、c 三個方法內發生了任何例外事件，程式還是能正確地被中止。並不會有太多副作用。在本文內提到的三種改寫辦法裡面，算是既通用，又不太囉唆的一種。
最近開始看到 Perl Toolchain Summit 的結果了。稍微讀了一下，以此篇文章綜合摘要一下今年在 Perl Toolchain 那裡的幾項決定（Lyon Amendment）：
如果有經常性在升級 perl 的話應該是不會因此受到甚麼影響。主要會被影響到的應該是一些因故無法升級的老系統，最糟有可能會變成不能使用 cpan 指令來安裝模組、或是有某些重要的模組在某版之後變成無法編譯、要使用的話就必須固定使用某個舊版。在老系統上安裝新模組的需求一般來說通常倒是安全性更新。考慮到作業系統本身也需要被更新，讓 Perl / CPAN 相關工具以類似作業系統更新的步調去「與時俱進」似乎還算是合理的。
註：
參考：
(注意： http 網址。其實用 https 也可以連，但是站長沒有把 cert domain 弄對。看來是同一台機器上架了多個網站，然後就「順便」多了一個錯誤的 https 進入點。)
一陣子之前在 HN 上紅了一陣子的這個網站是個搜尋引擎兼 web proxy。作者要在爲了要讓他蒐集的三十年前的老電腦也可以看各網頁而做了這個特殊的 web proxy。
實際上看來是把搜尋丟去 duckduckgo，並且把搜尋結果中的每個網址都換成他的 read.php，而 read.php 中實做 Readability 演算法，把原網頁中能內容極度精簡化再送回給 browser。 也因此有可能會碰到無法處理的網頁。但，在 Readability 演算法管用時的瀏覽體驗非常的好。
因此，給記憶體比較不足的機器（如 Raspberry Pi）來配合 w3m / lynx / eww 等純文字瀏覽器來用也是非常合的。
簡單筆記一下。以 Debian 爲例。
在安裝 DBD::mysql 時需要 mysql_config 這個指令，但如果要使用 MariaDB Client 而不能安裝 MySQL Client 時，也可以讓 DBD::mysql 去使用 mariadb_config，使其改與 libmariadb 連結。由於 MariaDB Client 也可以用來與 MySQL Server 溝通，在不想額外加入 mysql 套件的時候也可以使用這招來省點事。
首先需要裝好開發與編譯用的函式庫：
sudo apt-get install libmariadb-dev
然後是在安裝 DBD::mysql 時，透過指定環境變數的方式，讓其在編譯過程去使用 MariaDB 的編譯設定：
以 cpm 指令來裝
DBD_MYSQL_CONFIG=/usr/bin/mariadb_config cpm install -g DBD::mysql
以 cpanm 指令來裝
DBD_MYSQL_CONFIG=/usr/bin/mariadb_config cpanm DBD::mysql
以 cpan 指令來裝
DBD_MYSQL_CONFIG=/usr/bin/mariadb_config cpan -i DBD::mysql
以上。
https://metacpan.org/release/GUGOD/PerlX-ScopeFunction-0.03
好幾年前我擅自開始把 PerlX:: 這個 namespace 當成是「Perl 語言的延伸」的 意義在使用，並且做了一些有的沒的新語法。最近這星期做了 PerlX::ScopeFunction。
這個模組提供兩個新的語法關鍵字: let 與 with。
先看範例，就能大致上掌握這兩個關鍵字的用法：
use v5.36;
use List::Util qw( sum0 );
use List::MoreUtils qw( part minmax );
use PerlX::ScopeFunction qw(let with);
my @input = (3,1,3,3,7);
let ( ($min,$max) = minmax(@input); $mean = sum0(@input)/@input ) {
say "$min <= $mean <= $max";
}
with ( part { $_ % 2 } @input ) {
my ($evens, $odds) = @_;
say "There are " . scalar(@$evens) . " even numbers: " . join(" ", @$evens);
say "There are " . scalar(@$odds) . " odd numbers: " . join(" ", @$odds);
}
這兩個關鍵字提供了一種可以將幾個指定變數的語義範圍縮限起來的方式。前述範 例中 let 語句所造出的 $min、$max、$mean 三個變數的語義範圍是在後方的區塊 之內。with 語句則是能將一個算式取值，並把結果裝入 @_ ，使其能在後方的區塊內使 用。
這兩種語法結構都是從其他語言借過來的，在 Perl5 目前的語法中，最類似的是
sub closure 與 do：
sub {
my ($evens, $odds) = @_;
...
}->(part { $_ % 2 } @input);
do {
my ($min,$max) = minmax(@input);
my $mean = sum0(@input)/@input;
...
};
而 PerlX::ScopeFunction 所做的就是提供一些新關鍵字，讓這種特殊片語寫起來 更加明瞭一些，也利於解讀。
Steam Deck 的桌面模式基本上就是個 KDE Plasma 界面，拿來做不少工作很是夠用。
本文描述的幾項重點爲：
work。
work 身份而安裝 distrobox 並開設虛擬機。
基本上直接使用 Steam OS 的「桌面模式」。在不做大幅度修改的前提之下，就可以完成不少工作事項。
在切換到桌面模式之後，右搖桿可當滑鼠來使用。R2 對應到滑鼠左鍵，L2 對應到滑鼠右鍵（注意：左右相反）。外出時接個好打的鍵盤，就可以進行不少文字工作。只是，一直低頭看小螢幕實在傷頸酸肩，最好還是準備個能將機器墊高一些的支架或站台，
這 Steam OS 提供的桌面模式有以下幾點不那麼容易克服的限制：
deck 這個帳號，並且不必輸入密碼就可以登入。
deck 帳號是 wheel 管理員群組的一員，而且 無法 爲其設定登入密碼。
由於我還是會把 Steam Deck 拿來玩遊戲，所以基本上不會去試着突破以上這幾個限制，也不會嘗試去重新安裝成慣用的 Linux。附帶一提， 有人成功在 Steam Deck 上裝了 Windows，姑且算是個選項。
在不破壞前述幾項限制的前提之下，基本上能有的選項是：
以軟體開發爲目的話，大致上會需要
flathub 上的軟體能提供文字編輯器，但要安裝其他三項都不那麼容易。因此必須使用虛擬機。
目前爲止試過能較快上手的是 distrobox -- 這基本上是依賴 podman，以及現有的 container 生態系統去快速做出新的 Linux 環境。
使用 podman 的主要原因它有提供特殊版本。讓 podman 本身可以裝在 $HOME 底下，所有執行時需要的資料等等也都放在 $HOME 底下。對於 Steam Deck 這種特殊的系統而言是十分有利的。只要能裝在 $HOME 底下，就可以活過系統更新，不必重新安裝。
以 distrobox 所準備出來的虛擬機有個不錯的特性：可以將任意目錄指定爲虛擬機內的家目錄，並且以 bind mount 方式讓內外的檔案系統直接互通。也就是說，在桌面環境下其啓動的文字編輯器也可以直接去修改 distrobox 內部的家目錄內容，只讓編譯與測試在虛擬機內完成。這需要對指令有一定的熟練度，似乎對 IDE 不太友善。但至少是個不錯的辦法。真的需要 IDE 的話，也可在虛擬機內全套裝好。
建立工作用帳號的主要目的是便於區分家目錄底下的內容。讓 deck 帳號底下的內容全都是與遊戲相關的，並讓工作用帳號底下的內容全都是與工作相關的。
雖然根目錄是唯讀的，但是仍然可以透過指令或 KDE Plasma GUI 來建立其他使用者帳號，並且也能夠活過系統更新。只是，自遊戲模式切換到桌面模式時，固定是登入為 deck 帳號，無法 爲其設定登入密碼，也無法切換成其他使用者。只能開終端機出來用 su 變身成其他帳號。但這樣也就夠了。
假設工作用帳號爲 work ，那便以 deck 身份執行以下幾行指令來建立這個新帳號：
useradd -U -m work建好之後可用 sudo 或 su 來變身：
sudo su - work變身成爲 work 之後，首先是安裝 distrobox。依照 distrobox README.md 內的安裝說明，執行以下指令可將 distrobox 安裝到 ~/.local 底下：
curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/install | sh -s -- --prefix ~/.local安裝好後 distrobox 這個執行檔就會被放在 ~/.local/bin 底下。
再來是安裝 podman -- 同樣也是要安裝到 ~/.local 底下去。依照 distrbox 文件 ，使用他們提供的 install-podman 腳本就可以：
curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/extras/install-podman | sh -s -- --prefix ~/.local如此一來 podman 全體會被放在 ~/.local/podman/，而 podman 這個執行檔則是會被放在 ~/.local/podman/bin。
最後是調整 PATH 變數內以便日後執行。慣例是在 ~/.profile 裡加入類似以下這一行的指令：
export PATH=~/.local/bin:~/.local/podman/bin:$PATH最後就是實際上建出工作用虛擬機。假設要使用 alpine:latest 這個 container image，並將虛擬機命名爲 workstation，且將虛擬機內的家目錄指定爲 ~/distrobox/workstation/home 的話，就是這行指令：
distrobox create --image alpine:latest --name workstation --home ~/distrobox/workstation/home如果不指定的話，預設家目錄就是跟 $HOME 一樣。但這樣一來虛擬機內所有程式的設定檔路徑都會跟機主 (Steam Deck) 的路徑相同。如果要開設多個虛擬機，可能會遇到設定檔或暫存檔互相衝突的問題。建議是給每個虛擬機自己一個專用的家目錄。機主家目錄 $HOME 會以 bind mount 的方式直接與虛擬機內互通。所以也不至於造成太多不便。
建好之後就可以進入虛擬機內逛逛了：
distrobox enter workstation目前 Steam Deck 桌面環境是 Xorg，也就是說，其實也能加入一些調整，讓 distrobox 虛擬機內的 GUI 程式（如 Firefox）直接顯示在桌面環境上。
桌面環境：需要以 xhost 指令去讓跑在其他地方的 X client 可以在本機開視窗出來。以我的設定方式，所謂的「其他地方」是本機上的其他使用者。包括由虛擬機內開出來的 GUI 程式。
假設工作用帳號是 work ，那便在 /home/deck/.bash_profile 內加入以下幾行指令：
xhost +SI:localuser:work
alias work='sudo --preserve-env=DISPLAY su -w DISPLAY - work依照這兩個月的使用經驗，DISPLAY 有時是 :0 有時是 :2，不是很確定爲何改變。但總之只要讓所有地方的 DISPLAY 都有正確地設定好就好。方法就是在以 sudo 變身時把目前的 DISPLAY 保留下來。
如此一來便能夠在 WezTerm 內以 work 爲切換到工作用帳號的指令。切換過去後，進入虛擬機：
distrobox enter workstation並在虛擬機內直接執行 GUI 程式指令，例如 Firefox:
firefox &過幾秒鐘後便可以看到 Firefox 視窗開出來了。
附帶一提，由此方法開出來的 GUI 視窗也是可以配合桌面環境上的 Fcitx 輸入法框架來輸入漢字。如果有程式對輸入法切換熱鍵沒反應，那就檢查看看 LANG 環境變數是否有設定爲 zh_TW.UTF-8。有些程式不一定需要 LANG 爲 zh_TW.UTF-8，只要是某個有效的值（有對應到存在於系統上的 locale 資料），設定爲 en_US.UTF-8 或許也可以。
Steam Deck 桌面模式就是 KDE Plasma 圖形化介面。但出廠附上的輸入法設定是 ibus 框架的，其內附的漢語拼音等輸入法對我個人而言不太合用。
於是，參考 BrLi 的方法 後裝了 fcitx 框架，並且修改了相關設定，讓進入桌面模式後，就能直接起動 fcitx 而且不會起動 ibus。重點步驟如下：
~/.config/plasma-workspace/env/input.sh 這個檔案，貼入如後內容。
讓 fcitx5 自動起動的方式是把其起動腳本複製一份到 ~/.config/autostart 這個路徑底下去：
cp /home/.steamos/offload/var/lib/flatpak/exports/share/applications/org.fcitx.Fcitx5.desktop ~/.config/autostart/而 ~/.config/plasma-workspace/env/input.sh 內容為：
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
export XIM=fcitx如此一來在進入桌面模式後，於右下角工具列上會出現一個 Fcitx 的圖示。會顯示目前輸入法的狀態，並且可以透過點擊此圖示來設定各項細節。
核心的輸入法方面，為了配合手邊的 40% 鍵盤，我目前主要是使用 RIME 中的朙月拼音來滿足輸入漢字的需求。但想必也能接上其他種類的輸入法。