kanru's blog

Scoped Error in Rust

2026-05-22T00:00:00+00:00

I’ve never been fully satisfied with any error handling crate in Rust. I’ve tried many and even developed a few helpers. Here are the key issues I found with each. Theses are issues my scoped-error</code> crate tries to address.

The Inspiration</h2>
anyhow</code></strong> - good for a drop-in Error type that just works, but requires
adding .with_context()</code> everywhere. It’s verbose and repetitive. Error
reporting requires knowing how anyhow::Error</code> handles format strings. Error
propagation lacks location information; the alternative is backtrace,
which pulls in heavy std dependencies.</p>
thiserror</code></strong> - good for defining custom Error types. The #[from]</code> implementation
encourages a single Error type that encompasses all possible sources. But
the ergonomics stop there. Using these types is still tedious if you want
per-module errors with good context. The improvement over manually rolling
Error types seems small compared to the syn</code> and compile-time overhead.</p>
snafu</code></strong> - combines manual context attachment with anyhow</code> and thiserror</code>
patterns in one crate. However, I feel like I’m encoding all my error
branches into Snafu</code> contexts. Those implementation details don’t need
to be public, yet snafu</code> tightly couples the Error type to them. Maybe
I’m using it wrong.</p>
exn</code></strong> - a refreshing approach to error handling. I
actually started my crate based on the pattern from
the blog post Stop Forwarding Errors, Start Designing
Them</a>.
The minor issues with exn</code> 0.3 are: (1) you still need to remember
.or_raise(err)</code> for each fallible operation, and it’s easy to miss
for intra-module method calls; (2) the Exn</code> wrapper itself is not a
std Error</code>, so interop with other error types requires adapters like
exn-anyhow</code> or exn-stderr</code>.</p>
While switching between these error crates, I kept noticing a gap: with
anyhow</code>-like crates, you attach context at each call site, but the method
itself lacks it.</p>
Example:</p>
use</span> anyhow</span>::</span>Result</span>;</span></span>
</span>
fn</span> read_config</span>(</span>)</span> -></span> Result</span><</span>String</span>></span> {</span></span>
  let</span> raw</span> =</span> std</span>::</span>fs</span>::</span>read_to_string</span>(</span>"</span>config.toml</span>"</span>)</span>?</span>;</span></span>
  Ok</span>(</span>raw</span>)</span></span>
}</span></span>
</span>
fn</span> complex_method</span>(</span>)</span> -></span> Result</span><</span>(</span>)</span>></span> {</span></span>
  let</span> cfg</span> =</span> read_config</span>(</span>)</span>.</span>context</span>(</span>"</span>validate config file</span>"</span>)</span>?</span>;</span></span>
  parse</span>(</span>cfg</span>)</span>.</span>context</span>(</span>"</span>parse config file</span>"</span>)</span>?</span>;</span></span>
  Ok</span>(</span>(</span>)</span>)</span></span>
}</span></span></code></pre>
It’s easy to ?</code> away the context when all your methods return anyhow::Result</code>.</p>
With exn</code>-like crates, you define error context for each method and attach
it to all error branches. snafu</code> works similarly.</p>
Example:</p>
use</span> exn</span>::</span>{</span>Result</span>,</span> ResultExt</span>}</span>;</span></span>
use</span> thiserror</span>::</span>Error</span>;</span></span>
</span>
#</span>[</span>derive</span>(</span>Debug</span>,</span> Error</span>)</span>]</span></span>
#</span>[</span>error</span>(</span>"</span>MyError: </span>{</span>0</span>}</span>"</span>)</span>]</span></span>
struct</span> MyError</span>(</span>&</span>'</span>static</span> str</span>)</span>;</span></span>
</span>
fn</span> read_config</span>(</span>)</span> -></span> Result</span><</span>String</span>,</span> MyError</span>></span> {</span></span>
  let</span> err</span> =</span> |</span>|</span> MyError</span>(</span>"</span>read config file</span>"</span>)</span>;</span></span>
  let</span> raw</span> =</span> std</span>::</span>fs</span>::</span>read_to_string</span>(</span>"</span>config.toml</span>"</span>)</span>.</span>or_raise</span>(</span>err</span>)</span>?</span>;</span></span>
  Ok</span>(</span>raw</span>)</span></span>
}</span></span>
</span>
fn</span> complex_method</span>(</span>)</span> -></span> Result</span><</span>(</span>)</span>,</span> MyError</span>></span> {</span></span>
  let</span> err</span> =</span> |</span>|</span> MyError</span>(</span>"</span>complex method</span>"</span>)</span>;</span></span>
  let</span> cfg</span> =</span> read_config</span>(</span>)</span>.</span>or_raise</span>(</span>err</span>)</span>?</span>;</span></span>
  parse</span>(</span>cfg</span>)</span>.</span>or_raise</span>(</span>err</span>)</span>?</span>;</span></span>
  Ok</span>(</span>(</span>)</span>)</span></span>
}</span></span></code></pre>
The common issue: it’s easy to ?</code> away the context when all methods share the same Result</code> type.</p>
Enter Scoped Error</h2>
I really liked exn</code>’s approach: define an error closure to force conversion
to the module-scoped Error type. But the repeated .or_raise(err)?</code> gets
annoying fast.</p>
I started creating wrappers to mediate conversion from source errors to
module-scoped Errors. I soon realized this pattern solves several ergonomic
issues with other approaches, and checks the boxes I cared about.</p>
Example:</p>
use</span> scoped_error</span>::</span>{</span>Error</span>,</span> expect_error</span>}</span>;</span></span>
</span>
fn</span> read_config</span>(</span>)</span> -></span> Result</span><</span>String</span>,</span> Error</span>></span> {</span></span>
  expect_error</span>(</span>"</span>read config file</span>"</span>,</span> |</span>|</span> {</span></span>
    let</span> raw</span> =</span> std</span>::</span>fs</span>::</span>read_to_string</span>(</span>"</span>config.toml</span>"</span>)</span>?</span>;</span></span>
    Ok</span>(</span>raw</span>)</span></span>
  }</span>)</span></span>
}</span></span>
</span>
fn</span> complex_method</span>(</span>)</span> -></span> Result</span><</span>(</span>)</span>,</span> Error</span>></span> {</span></span>
  expect_error</span>(</span>"</span>failed to do complex thing</span>"</span>,</span> |</span>|</span> {</span></span>
    let</span> cfg</span> =</span> read_config</span>(</span>)</span>?</span>;</span></span>
    parse</span>(</span>cfg</span>)</span>?</span>;</span></span>
    Ok</span>(</span>(</span>)</span>)</span></span>
  }</span>)</span></span>
}</span></span></code></pre>
The core idea is simple: attach context exactly once. Not at every call
site, not at every failure point, just between caller and logic. I
want per-module Error types without manual conversion at every step.</p>
expect_error()</code> has three responsibilities: prepare context for future
errors, force inner errors into a boxed type to type-erase the inner error, and
wrap the outer error with the inner as its source.</p>
The result: a clean, readable declaration of fallible operations. A
default Error</code> type is provided, but any std Error</code> implementing WithContext</code>
works too.</p>
The core library is tiny. It’s small enough to vendor directly into your project1</a></sup>.</p>
The inner boxed error type Frame</code> takes its name from exn</code>. It converts any
error to Box<dyn Error></code> and captures file location via #[track_caller]</code>
for a lightweight stack trace.</p>
With the built-in Error</code> type or the ErrorExt::report()</code> helper, error
trees (yes, trees are supported) render like this:</p>
Error</span>:</span> failed</span> to</span> do</span> complex</span> thing</span>,</span> at</span> src</span>/</span>main</span>.</span>rs</span>:</span>12</span>:</span>19</span></span>
|</span>-</span>-</span> read</span> config</span> file</span>,</span> at</span> src</span>/</span>main</span>.</span>rs</span>:</span>5</span>:</span>19</span></span>
`</span>-</span>-</span> No</span> such</span> file</span> or</span> directory</span> (</span>os</span> error</span> 2</span>)</span></span></code></pre>
The scoped-error</code></a> crate also
packs a few extras: a macro_rules!</code> macro for creating common errors that
implement WithContext</code>, and a Many</code> error type for multi-cause errors.</p>
The crate is on crates.io,
source is on Codeberg</a>, and
docs</a> cover the details.  If you try it,
I’d love to hear your use cases. File an issue or drop me a note. I’m using
this in my own projects now and finally Rust error handling feels right.</p>
^{1</sup>
The core of the library is really tiny.</p>
</div>
//</span> Copyright (C) 2026 Kan-Ru Chen <kanru@kanru.info></span></span>
//</span> SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception</span></span>
</span>
use</span> std</span>::</span>any</span>::</span>Any</span>;</span></span>
use</span> std</span>::</span>borrow</span>::</span>Cow</span>;</span></span>
use</span> std</span>::</span>error</span>::</span>Error</span> as</span> StdError</span>;</span></span>
use</span> std</span>::</span>fmt</span>::</span>{</span>Debug</span>,</span> Display</span>}</span>;</span></span>
use</span> std</span>::</span>panic</span>::</span>Location</span>;</span></span>
</span>
///</span> A trait for error types that can carry context information.</span></span>
pub</span> trait</span> WithContext</span>:</span> StdError</span> +</span> Any</span> {</span></span>
    ///</span> Attach a context layer to this error.</span></span>
    fn</span> with_context</span>(</span>self</span>,</span> context</span>:</span> Frame</span>)</span> -></span> Self</span>;</span></span>
</span>
    ///</span> Get the location where this error was created or where context</span></span>
    ///</span> was attached.</span></span>
    fn</span> location</span>(</span>&</span>self</span>)</span> -></span> Option</span><</span>&</span>'</span>static</span> Location</span><</span>'</span>static</span>></span>></span>;</span></span>
}</span></span>
</span>
///</span> A single layer of error context.</span></span>
pub</span> struct</span> Frame</span> {</span></span>
    ///</span> The underlying error that caused this context.</span></span>
    pub</span> source</span>:</span> Box</span><</span>dyn</span> StdError</span> +</span> Send</span> +</span> Sync</span> +</span> '</span>static</span>></span>,</span></span>
    ///</span> The location where this context was attached.</span></span>
    pub</span> location</span>:</span> &</span>'</span>static</span> Location</span><</span>'</span>static</span>></span>,</span></span>
}</span></span>
</span>
impl</span><</span>T</span>></span> From</span><</span>T</span>></span> for</span> Frame</span></span>
where</span></span>
    T</span>:</span> Into</span><</span>Box</span><</span>dyn</span> StdError</span> +</span> Send</span> +</span> Sync</span> +</span> '</span>static</span>></span>></span>,</span></span>
{</span></span>
    ///</span> Creates a `Frame` from any error type, capturing the</span></span>
    ///</span> caller's location.</span></span>
    #</span>[</span>track_caller</span>]</span></span>
    fn</span> from</span>(</span>value</span>:</span> T</span>)</span> -></span> Self</span> {</span></span>
        let</span> source</span> =</span> value</span>.</span>into</span>(</span>)</span>;</span></span>
        let</span> location</span> =</span> Location</span>::</span>caller</span>(</span>)</span>;</span></span>
        Frame</span> {</span> source</span>,</span> location</span> }</span></span>
    }</span></span>
}</span></span>
</span>
///</span> Low-level function for adding context with a custom error constructor.</span></span>
#</span>[</span>inline</span>(</span>always</span>)</span>]</span></span>
pub</span> fn</span> expect_error_fn</span><</span>F</span>,</span> T</span>,</span> E</span>></span>(</span></span>
  err</span>:</span> F</span>,</span></span>
  body</span>:</span> impl</span> FnOnce</span>(</span>)</span> -></span> Result</span><</span>T</span>,</span> Frame</span>></span>,</span></span>
)</span> -></span> Result</span><</span>T</span>,</span> E</span>></span></span>
where</span></span>
    F</span>:</span> FnOnce</span>(</span>)</span> -></span> E</span>,</span></span>
    E</span>:</span> WithContext</span>,</span></span>
{</span></span>
    body</span>(</span>)</span>.</span>map_err</span>(</span>|</span>context</span>|</span> err</span>(</span>)</span>.</span>with_context</span>(</span>context</span>)</span>)</span></span>
}</span></span>
</span>
///</span> Add context to errors, returning a custom error type.</span></span>
#</span>[</span>inline</span>(</span>always</span>)</span>]</span></span>
pub</span> fn</span> expect_error</span><</span>T</span>,</span> E</span>></span>(</span></span>
    msg</span>:</span> impl</span> Into</span><</span>Cow</span><</span>'</span>static</span>,</span> str</span>></span>></span>,</span></span>
    body</span>:</span> impl</span> FnOnce</span>(</span>)</span> -></span> Result</span><</span>T</span>,</span> Frame</span>></span>,</span></span>
)</span> -></span> Result</span><</span>T</span>,</span> E</span>></span></span>
where</span></span>
    E</span>:</span> From</span><</span>(</span>Cow</span><</span>'</span>static</span>,</span> str</span>></span>,</span> Frame</span>)</span>></span>,</span></span>
{</span></span>
    body</span>(</span>)</span>.</span>map_err</span>(</span>|</span>context</span>|</span> (</span>msg</span>.</span>into</span>(</span>)</span>,</span> context</span>)</span>.</span>into</span>(</span>)</span>)</span></span>
}</span></span></code></pre>}

處理 Imm32 與 TSF 的相容性問題 2026-03-06T00:00:00+00:00 稍微紀錄一下這一次 Debug 的過程。 背景與問題描述</h3> Imm32 是 Windows 舊有的輸入法 API，一路沿用到 Windows XP 後被 TSF (Text Service Framework)</a> 取代。許多平台的輸入法支援在切換輸入法時自動送出組字區的文字，例如打字到一半按 Ctrl + Shift 切換英文，可同時完成「送出組字」與「切換輸入法」兩個動作，無需先按 Enter 再切換。這對需快速切換中英文的使用者來說非常方便。 然而，在新酷音 Windows TSF</a> 改用 TSF 實作後，此功能一直時好時壞。若使用者無法預期切換輸入法後未送出的字是「消失」還是「送出」，自然會選擇先按 Enter 再切換，失去便利性。我已多次嘗試修正此問題。 錯誤的修正方向</h3> 在 TSF API 中，未送出的文字稱為「組字區 (Composition)」，可設定「組字中止 (OnCompositionTerminated)」事件處理器。根據微軟文件</a>，此事件僅在組字被「強迫終止」時觸發，例如開關或切換輸入法。文件提及「輸入法可藉此機會修改組字、還原文字或清除組字」，讓我誤以為必須在此處理器中強制送出組字。雖然修改後看似有效，但在使用 Imm32 API 的軟體中仍無法自動送出。這些軟體依賴系統橋接器使用 TSF 輸入法，行為與原生 TSF 應用不同，我一度認為這是橋接器的限制。 使用除錯工具找出差異</h3> 一位使用者回報： 使用新酷音輸入法已選字但未按 Enter，若用 Ctrl + Shift 切換輸入法，候選字會消失；但用「Shift 快速切換中英文」時卻會送出。能否增加設定選項？ </blockquote> 剛好我正在測試日文輸入法，發現 Mozc 無論在哪個軟體都能在切換時自動送出組字。查看其 OnCompositionTerminated</code> 實作，與我的寫法無顯著差異。 於是使用 WinDbg 比較呼叫堆疊（backtrace），發現關鍵差異： Mozc 的 backtrace： OnCompositionTerminated CompComplete IMM32!NotifyIME</code></pre> 新酷音 TSF 的 backtrace： OnCompositionTerminated CompCancel IMM32!NotifyIME</code></pre> 兩者僅在 IMM32!NotifyIME</code> 後分別觸發「完成組字」與「取消組字」，顯示問題根源在系統層級，非輸入法內部可控制。 發現系統層級的設定差異</h3> 這讓我聯想到 ibus 可設定切換時「取消」或「送出」組字。查閱資料後，發現 Imm32 有 IME_PROP_COMPLETE_ON_UNSELECT</code> 屬性，若設定，輸入法在停用時會自動完成組字；否則取消。新酷音的 Imm32 版本有設定此值，但 TSF 橋接器無對應介面。 再拿出 WinDbg 來看看究竟 Mozc 是怎麼被設定的，行為會不一樣？因為這部份是 Windows 的系統函式庫，沒有原始碼可以參考，只好用機器碼單步執行，最後發現有一段機器碼跟 ReactOS 的這一段 TSF 橋接器的重新實做</a>非常相似。 進一步研究 ReactOS 原始碼發現，TSF 橋接器初始化時會靜態設定此屬性。日文、韓文輸入法預設包含 IME_PROP_COMPLETE_ON_UNSELECT</code>： IME_PROP_COMPLETE_ON_UNSELECT | IME_PROP_SPECIAL_UI | IME_PROP_AT_CARET | IME_PROP_NEED_ALTKEY | IME_PROP_KBD_CHAR_FIRST;</code></pre> 但中文輸入法未包含： IME_PROP_SPECIAL_UI | IME_PROP_AT_CARET | IME_PROP_NEED_ALTKEY | IME_PROP_KBD_CHAR_FIRST;</code></pre> 這解釋了為何 Mozc 可行而新酷音不行。由於屬性為靜態設定，似乎無標準方式自訂。 Hack 解法與未來改進方向</h3> 在 ReactOS 的 Imm32 實作中，我注意到 ImmLockImeDpi</code> 這個未公開（undocumented）函式，可用於取得 IMM32 內部結構體指標。假設微軟實作類似，便可在初始化後動態修改屬性。實驗後，提交以下變更： debug!("trying to override the default IMM32 property set by MSCTF.dll"); let hkl = unsafe { GetKeyboardLayout(0) }; let pimedpi = unsafe { ImmLockImeDpi(hkl) }; if let Some(imedpi) = unsafe { pimedpi.as_mut() } { imedpi.ime_info.fdw_property |= IME_PROP_COMPLETE_ON_UNSELECT; debug!("done adding IME_PROP_COMPLETE_ON_UNSELECT to IME property"); } else { debug!("unable to get the PIMEDPI pointer"); } self.pimedpi.set(pimedpi);</code></pre> 此 hack 目前測試可行。由於 ImmLockImeDpi</code> 是 MSCTF.dll</code> 內部使用的隱藏介面，未來可能變動。為避免執行期錯誤，應改以弱符號（weak symbol）方式動態載入此函式。 心得</h3> 這次除錯讓我體會到，問題有時不在應用層，而在系統與舊有 API 的相容性設計。透過逆向工程與底層探索，雖可突破限制，但也需承擔維護風險。期待未來能有公開 API 支援此類設定。▞ 開箱 Framework 13 吋 DIY 版筆電 2024-11-17T00:00:00+00:00 官網購入</h2> 由於 Framework</a> 還沒有在日本開賣，趁著今年回台灣前先預購了 DIY 版的 13 吋 AMD Ryzen™ 7040 系列。這次的 DIY 版本只有加購了記憶體而已，硬碟就用原本買給舊 System76 的 Lemp9</a> 用的 Samsung SSD 970 EVO Plus 2TB，直接繼續使用裡面安裝的 Fedora Workstation 41，所以也沒有另外選擇 OS。 原本想要用日本的信用卡付帳，結帳後卻收到需要人工審核的通知。搜尋論壇了之後發現 Framework 對於購買地區的把關非常嚴格，如果使用沒有支援的國家地區的信用卡有可能導致帳號被鎖定。最後只好先把訂單取消後重新用台灣的信用卡付款。 開箱組裝</h2> 結帳後五日內出貨，但是等到我回到台灣實際上多等了兩個星期才開箱。 組裝的過程還算順利，只有幾個步驟比較需要注意。第一個是安裝鍵盤模組的時候排線不容易對齊，很怕把插槽壓壞；第二是把鍵盤模組蓋上之後，右下角會微微翹起，看了文件才發現原來是故意這樣設計，讓你拆鍵盤模組時比較容易施力；最後第三點是螢幕轉軸部份的訊號線很容易卡到邊框，調整了好幾次才確定闔上螢幕的時候沒有任何凸起的地方。 組裝好之後順利開機。附上 Fastfetch 的螢幕快照一張： </picture> ▴ Fastfetch 螢幕快照 </figcaption> </figure> 測試與設定</h2> 實際使用了幾天都沒有什麼問題，所有的功能都是開箱就可以使用，不用任何微調，甚至連電源開關上面的指紋感應都可以用，這是我第一次在 Linux 筆電上面成功使用指紋解鎖。 以下會隨時更新紀錄後來有調整的地方。 休眠功能與電池最佳化</h3> 休眠以及使用時的耗電量是論壇上數一數二被討論的話題1</a>。有人分析到記憶體的容量大小會影響休眠時的耗電量，尤其是 48GB 的記憶體的耗電量是 8GB 的十倍2</a>。同一個討論串裡面也提到他可以休眠 7.82 天但是不甚滿意，因為他的其他筆電可以休眠到 14 天。我的目標只要可以達到 7 天左右就好，因為之前用的 Lemp9 只能休眠 1.2 天左右，我已經對長時間休眠沒有抱很大期望了。 用 AMD 工程師分享的 amd_s2idle.py</a> 這隻程式來分析休眠有沒有成功、可能的問題、實際的耗電量等等。第一次跑得時候發現只有 60% 的時間硬體是在低耗電模式，把所有的喚醒來源都關掉後成功讓 99% 休眠時間都是低耗電模式。懷疑是裝在左下跟右下的兩個 USB-A 的擴充卡造成的（論壇上也有不少人提到 USB-A 的問題），決定先全部換成 USB-C。 另外，Fedora 從 41 版之後就把控制節能模式的 power-profiles-daemon 換成 tuned-ppd，但是 power-profiles-daemon 有同一位 AMD 工程師 Mario Limonciello 的加持，感覺會有比較多深入的最佳化，所以我把 tuned-ppd 換回 power-profiles-daemon 了。 從 EFI 設定界面可以直接設定電池最多充到 80% 就自動停止充電，目前從 80% 放了一晚之後大約剩下 74%，換算大概可以休眠 4 到 5 天左右，算是很夠用了。不過我還是很好奇的持續在看有沒有可以繼續最佳化的方法3</a>。 螢幕調整最佳化</h3> 我選購的是新的 2.8K 霧面螢幕，更新率可達 120 Hz，但是我平常的使用情境都不是會有東西動來動去的，所以把更新頻率設定改回 60 Hz，省省電。希望之後 GNOME 的動態更新頻率功能可以自動最佳化這個部份。 這塊面板可以支援到接近 100% sRGB 的顏色範圍，可以從 notebookcheck</a> 下載他們的 ICM 檔案來套用螢幕顏色校正。套用後原本偏藍的畫面變成溫暖一點的色調。 設定 OpenCL</h3> AMD 的內建 GPU 還算不錯，雖然無法跑運算量大的遊戲，但是足夠我用在 Darktable 的 OpenCL 加速了，這也是我選擇 AMD 版本的原因之一。 Fedora 上要啟用 OpenCL 可以參考 Fedora HC SIG</a> 的 wiki： sudo usermod -a -G render,video $LOGNAME sudo dnf install rocm-opencl sudo dnf install clang18 # workaround 一個 clang path 的問題</code></pre> 重開機後就可以執行 darktable-cltest</code> 來看看 OpenCL 有沒有正確啟用。 接下來這台 Framework 就會是我的主力囉！▞ ^1https://community.frame.work/t/real-world-battery-life-experience-fw13-amd/39112/73</a> </div> ^2https://community.frame.work/t/impact-of-ram-density-on-suspend-power-consumption/57664</a> </div> ^3https://community.frame.work/t/is-framework-13-amd-s2idle-modern-standby-efficient-enough/46431</a> </div> 回顧用 Rust 重寫新酷音的經驗 2024-05-05T00:00:00+00:00 libchewing</a> 0.8.0 將是新酷音的重大里程碑。酷音原本是 XCIN 的一個模組，新酷音團隊在 2002 年把模組獨立出來變成一個共有函式庫 (shared library) 維護至今。從 2021 年開始我就斷斷續續的用 Rust 重寫 libchewing，現在終於要預設啟用 Rust 重寫的版本了！我現在一邊為釋出做最後的準備工作，一邊寫個文章紀錄一下整個重寫的經驗，順便最後測試實際使用的情境。這篇文章將會以紀錄發生了什麼事為主，不會解釋太多技術細節，如果有想要深入了解的部份，歡迎留言讓我知道。 2017 年的第一次嘗試</h2> 應該是在 2017 年八月的時候，那個時候剛剛接觸 Rust 沒有多久，就想著可以用新酷音練練功，試著把使用者詞庫的模組 (userphrase) 改用 Rust 的 HashMap 改寫。那個時候新酷音的建置環境還是用 autotools 以及 libtool，重寫的結果算是證明了可以把 C 跟 Rust 放在同一個程式碼庫內一起編譯使用。練習的結果在 COSCUP 給了一個經驗分享 (COSCUP 2017 – Porting C Library to Rust, 以 libchewing 為例</a>)。 2021 年底重新開始的契機</h2> 2021 年底的時候開始玩流行的寫程式解謎遊戲 Advent of Code</a>，依照我的慣例是用 Rust 寫 (adventofcode2021</a>)。寫著寫著不禁想，同樣是透過寫程式娛樂，我不如把時間花在寫一些對其他人有幫助的程式。同樣是 2021 年接觸了 QMK</a> 與 ZMK</a>，覺得好像可以把寫鍵盤 firmware 的經驗應用在酷音的鍵盤對應表上，於是又開始想要怎麼把新酷音用 Rust 改寫。 這時候只是開始隨便寫寫，驗證自己心裡所想的架構可以運作，並重新閱讀 libchewing 的程式碼，重拾對程式碼的了解。 2022 年黃金週確立基礎架構</h2> 4/29 為期一週的黃金週假期開始，在 Matrix</a> 上面開了新的聊天室，把聊天室的連結</a>加到 README 之後就開始先加入 CMake 的 FindRust 模組，讓 libchewing 可以連結 Rust 的程式碼，然後就陸續把許氏鍵盤、表準鍵盤、倚天26、大千鍵盤等等鍵盤模組實做出來並且替換 C 的內部 API，採取的是從最末端的程式碼一步一步的取代更大的 C 模組。(開發紀錄</a>) 此時要感謝 czchen 幫新酷音加了非常多的測試，我可以直接用原本的測試程式來確保大致功能是對的。要不是有這些測試程式，我的進度一定會要慢上好幾倍。而且這些測試很多都是整合測試 (integration test)，讓我可以不必理會原本 C 是怎麼實做的，只需要依照 API 界面實做即可跟原本的程式合在一起測試。 等所有的注音輸入模組都寫的差不多之後，我開始寫字典的讀取查找模組，這是酷音裡面重要又有一定複雜度的模組，但是又相對的獨立沒有其他的相依性，所以是很好的重構目標。首先我實做了一個新的 Trie 檔案格式以及字典建構工具，然後又寫了 SQLite 為底的使用者字典格式。此時很多時候都是在逆向工程原本字典模組 (tree.c) 的一些規則，像是排序的順序、詞頻的調整等等。原本的 tree.c 用的是記憶體映射 (mmap) 的方式把字典檔案直接當作記憶體位置操作，直接回傳一個唯讀的記憶體指標，我在重構的時候就直接分配新的記憶體然後不釋放，等到測試都過了之後再慢慢的修 valgrind 報的記憶體洩漏錯誤。(開發紀錄</a>) 此時我已經把新酷音內最沒有其他相依的兩大模組換成 Rust 了，我也漸漸有信心好像可以完成這個「小專案」。有了字典模組之後，接下來就是需要使用字典模組的注音分詞的酷音模組了，這邊的演算法我一直不是很有信心，加上工作變忙於是就慢慢的摸索</a>，直到 12 月又到了 Advent of Code 的時間才又開始有精力開發。把酷音的演算法移植到 Rust 之後很令人驚訝的是大部份的測試都過了，既開心有不錯的進展，卻又有點擔心已有的測試在分詞模組的覆蓋率有點不足。我要感謝聰明又可愛的老婆不厭其煩的跟我討論我最沒有信心的演算法。(開發紀錄</a>) 2023 年合併到主線開發</h2> 把詞庫跟分詞模組都重構完之後，就有機會把原本兩個模組之間黏合用的 C API 拿掉了。兩個模組之間用新設計的 Rust API 組合之後，整個新酷音除了使用者的輸入輸出的部份都已經是 Rust。我開始整理 commit history 然後把結果提交為 pull request</a>，並分享未來的開發計畫。此時也已經換成用 Corrosion-rs</a> 這個優秀的 CMake 專案來編譯 libchewing。採用的是 Rust staticlib + dummy C file + version script 的方式來產生共用函式庫。 提交 pull request 之後，感謝眾多的 reviewer 給予建議，我也開了許多 ticket 供想要參與的人可以幫忙或是尋求指導。Pull request 裡面的參考架構仍然接近現在所使用的架構： </picture> ▴ 架構圖 </figcaption> </figure> 接下來開始設計 Editor (input/output) 模組，這個模組跟其他模組不一樣的地方是它有著非常多的 API 以及內部資料狀態 (state)，沒有辦法像其他模組一樣漸進式的處理。原本 libchewing 的 chewingio.c 與 chewingutil.c 等，總共有約 119 個 API，全部都是透過操作內部狀態以及使用詞庫和分詞模組來實做新酷音的主要功能，這些 API 全部都共用同一組狀態，存在 ChewingContext 裡面，所以沒辦法單單只把一些功能搬到 Rust。 後來因為注意到在跑 test 的時候，Rust 的版本比純 C 的版本要慢上一個數量級，所以花了些時間用 samply</a> 來了解問題在哪裡〔很多時間是花在原本較沒效率的 syllable 設計，後來把內裝改成用 u16 之後改善不少〕。我從 7 月開始除了偶爾構思一下暫存編輯區 (preedit text)、候選字清單 (candidate window)、編輯區邏輯 (editor state machine) 的架構之外，都花時間在最佳化 Trie 字典的效能，逃避不想面對的複雜重構。 11 月參考 hoverbear</a> 的 blog</a> 設計了新的 state machine 架構，花了些時間把 C 的 119 個公開 API 用 Rust 重寫，把 API 跟 Editor 跟字典模組直接整合起來，得到一個只有用到 Rust 程式碼但是測試壞掉大半的狀態。接下來就是一個一個修 test-bopomofo.c 的錯誤。我幾乎都是把原本的 C 實做當作黑盒子做 TDD，因為如果依照原本的邏輯實做，會受到原本架構的影響。一旦有了可用的 state machine 架構之後，我就以還算穩定的速度在年底前就把所有的測試都通過了。(開發紀錄</a>) 2024 開始穩固基礎</h2> 等到測試都通過之後改用 genkeystroke 測試一般的使用情境，此時會發現雖然有很多小地方都還沒有處理〔例如選詞結果不會清除〕，已經可以通過所有的測試以及一般的使用情境都沒有問題。這證實我之前的猜測，現有的測試只能帶我到大約 80% 的地方，剩下的 20% 需要靠其他的方法測試才行。 所有的測試都通過之後，表示 Rust 版本的酷音已經可以用在基本的使用情境了，也可以編譯出只有使用 Rust 的 libchewing.so 共用函式庫。接下來需要更廣泛的測試，首先在 CI 上面在所有平台同時測試 C 跟 Rust 版本，以免有任何的退步。一月底的時候釋出 0.6.0</a> 為 2016 年以來的第一個維護版同時也是第一個 alpha 版的 Rust rewrite 版。 (開發紀錄</a>) 0.6.0 釋出之後就開始準備可以日常使用、抓蟲的 0.7.0 版，根據之前定義的路線圖這個版本有以下重點項目： 可以自動的搬遷使用者字典到新的格式</li> 穩定性優先，盡量不可以有嚴重錯誤或是毀壞使用者資料</li> 減少不必要的相依項目</li> </ul> 穩定性的部份，我從一開始就希望可以用 fuzzing 的方式幫我找到更多的 bug，最後我用 clang + afl.rs</a> 的方式編譯出有 instrument 的執行檔，讓 AFL++</a> 可以更有效率的執行。 </picture> ▴ AFL++ 跑了九天的截圖 </figcaption> </figure> 用了 AFL++ 之後很快就找到許多原本的測試沒有找到的問題，大多都是因為原本的 state machine 沒有阻擋把游標移動到超出編輯區的頭尾，或是選擇鍵超出頁面範圍。原本這些問題在 C 的版本會非常難偵測，但是因為 Rust 有邊界測試以及數值溢位的偵測，這些問題都可以很簡單的發現並修復。持續的跑 fuzzer 好幾天都沒有發現新的問題之後，我更有信心日常使用使用者不會遇到程式嚴重錯誤的問題，最多只是程式的輸出結果很奇怪。(開發紀錄</a>) ※ 一個用 fuzzer 找 bug 的小技巧，我在日常測試的時候出現一個問題，就是編輯區的詞有時候會消失，但是不知道要怎麼重現，我就在 fuzzer 裡面特別加了一個檢查，很快 fuzzer 就找到好幾個 testcase，原來是我根本就沒有處理選詞之後的重新整理，沒想到這樣也可以用到現在。 在準備 0.7.0 正式 release 之前，我決定替換字典的實做。一開始在設計架構的時候預留了可以有多種不同字典格式的設計，也實際實做了 SQLite, Trie</a>, CDB 三種不同的字典格式，其中 SQLite 是可以更新的，CDB 雖然是唯讀的格式，可是利用一個技巧把需要更新的內容先快取在記憶體內，然後定期的覆蓋硬碟上的字典檔，也可以達到更新的效果。後來在做效能測試</a>的時候發現建立 Trie 沒有比寫新的 CDB 檔案更花時間，所以如果用一樣的技巧就可以把 Trie 格式當作可更新的使用者字典來用，於是就有想法把系統字典與使用者字典全部統一成一個格式，這樣可以讓整體的相依更少。 最後，2024 年的黃金週現在準備釋出 0.8.0，把 Rust 重寫的版本變成預設選項。把 chewing-cli 開發成一個通用工具程式，包含原本用來建立系統辭典的 init-database 程式，並加上新的 info 與 dump 兩個命令，可以用來檢視字典的內容。這個版本還用了一個 K Shortest Path</a> 演算法 (Yen’s Algorithm</a>) 來加強搜尋候選斷詞清單的最差時間複雜度。(開發紀錄</a>) 最初採用卻沒有留下的設計</h2> Tracing. 原本用了 Tokio 的 tracing crate，可以很方便的幫 function 加上 tracing log，對於實做 Editor 的 state machine 幫助極大，可是後來的 log 需求比較簡單，於是就改回相依項目比較少的 log crate。 RIFF. 一開始設計的新 Trie 字典格式仿照了 WebP 的格式標準，用了 RIFF 容器格式作為可擴充的檔案格式基礎，把 index 與 data 封裝在同一個檔案內，後來在重新設計的時候因為需要更有彈性的儲存詞彙資料而改用 ASN.1 描述檔案格式，並用 DER 做為檔案的實做格式，就沒有用 RIFF 了。 CRC32. 原本的 Trie 字典格式裡面用了許多自訂的 TLV 封包，在做 fuzzing 的時候發現有很多邊界測試需要做，於是就在 index 跟 data 資料的最後面加上 CRC32 的檢查碼，然後就在程式裡面假設如果檢查碼通過的話就當作資料都是正確的，省掉許多的額外邊界測試，算是有點偷懶。後來因為 TLV 太麻煩不想處理，直接用標準的 TLV 格式，也就是 ASN.1 的 DER 格式，也就沒有一定要用 CRC32 檢查碼了。之後可能會加回來讓檔案更牢不可破。 CDB. 一開始設計來取代 uhash.dat 格式的，用了 DJB 的 CDB 格式，跟原本的 uhash 一樣把字典當作 key/value 存。如同前面提到的，因為把字典格式統一為 Trie 與 TrieBuf 之後就沒有用 CDB 了。 SQLite. 最新的 libchewing 是用 sqlite3 當作使用者字典的格式，好處是有支援多行程，ACID，然後其他的工具或是使用者可以直接操作 sqlite3 檔案。最一開始改寫的時候重新設計了 schema 讓 sqlite 更有效率，並且支援大於 10 個字元的詞彙詞。後來因為想要減少額外的相依項，重新設計讓 TrieBuf 格式也可以更新之後，就打算移除 SQLite 格式了，目前因為需要可以從舊有格式轉移，這部份的程式碼還留著。 Symbol versioning. 一開始在實做只用 Rust 編譯整個 libchewing 的時候，採用的是用 cmake 去呼叫 linker 來產生最後的 shared library，因為這樣可以更容易的控制哪一些 symbol 是 public 的，這時候我用了 version script 來控制 ELF library 的 symbol version，後來因為想用 cargo + rustc 直接產生 shared library，而 rustc 又不支援用 version script，所以就暫時放棄了 symbol version 的想法。 感謝</h2> 首先感謝我自己在 2004 年寫的 testchewing 與 genkeystroke 兩個小程式，可以在沒有 GUI 或是任何 IM wrapper 的情況下直接測試 libchewing，同時 genkeystroke 可以用來產生測資，而 testchewing 可以用來執行 genkeystroke 產生的測資。酷音的很多測試用的也是 testchewing 所使用的檔案格式。這兩個程式仍然是我測試 libchewing 時不可或缺的工具。 接下來要感謝 czchen，他替 libchewing 加了 cmake 的支援，以及大量的測試。若是沒有這兩者，我根本無法想像開始用 Rust 改寫的計畫。我的改寫基本上都是 TDD (Test Driven)，全部都歸功於這些測試。感謝我一開始的決定先把 GitHub Actions 的 CI 設定好同時跑 C 跟 Rust 的整合測試以及計算覆蓋率，我在重構的時候以及有人貢獻的時候都可以有明確的品質指標。目前整個程式庫大約有 88% 的測試覆蓋率。 感謝 Rust Taiwan</a> 的 wusyong 與 weihanglo 幫忙 review 最初的 pull request，以及其他夥伴在 Matrix/Telegram 上提供的各種建議。 感謝 rano 開發直接使用 chewing-rs Rust API 的實驗性 IM chewingwl</a> 並在 Matrix 上面給予回饋。 最後要感謝 yan12125 與 wengxt 幫忙實際測試 libchewing 0.8.0 並回報問題，jserv 幫忙更新 README 裡面新酷音的歷史以及現狀。▞ ※ 封面照片是 2022 年黃金週去東京野鳥園玩的時候拍的螃蟹 網站搬到 HostHatch 2024-02-11T00:00:00+00:00 TL;DR HostHatch</a> 便宜好用，想測試的話可以用我的連結 https://cloud.hosthatch.com/a/3823</a> 這樣我可以收到一點回饋 🙂 幾年前因為想要用 Vultr 的機器玩 BGP，就把網站從 AWS 搬到 Vultr 的東京機房。當初用的是稍微高一級的 1c1g，夠同時跑多個 container 沒有問題，於是就用一台當 blog + BGP router。 去年原本租了 Element 代管的 ElementOne 來玩 Matrix</a> 順便贊助開發。後來 Element 取消這個每月 $10 的方案不做一般消費者這塊了，剛好我也在考慮自己裝個 Synapse</a> 來自架 Matrix，就把這筆預算拿來用在新的 VM 上面。 考慮到 Synapse 跟大型的聊天室直接對接的時候好像還滿需要資源的，需要找一個可以跑 PostgreSQL 的規格。這樣整個 VM 就會有至少 caddy, php-fm, mariadb, synapse, postgresql 這幾個 container，感覺要至少 2c4g 才夠。Vultr 符合這個規格最便宜的就是 $20 的共用 CPU 方案。 因為種種原因我想要找有沒有可能加一點錢改用獨立主機，這樣可以把更多小網站集中起來，於是就用以下的條件開始找： 在東京</li> 便宜的獨立主機，大約 20 多美金</li> 有 BGP 可以用自己的 ASN</li> </ul> 說實在想要找到這種規格的在東京幾乎是沒有，倒是有不少 IP 假裝是在東京，其實機房是在美西的便宜方案想要魚目混珠，又或是機房看起來是在東京沒錯，但是 peer 的狀況實在有夠差，我家距離附近主要的 Equinix 機房都在一兩公里的距離而已，但是封包常常要先繞去大阪或是美西再回東京，130 ms 到 200 ms 的 latency 只好放棄。 HostHatch 後來尋覓到 HostHatch 最近剛好開始提供 BGP 的服務。雖然一開始需要設定費，但是他們提供的報價看起來非常的物超所值。$15 的價錢就可以買到 4c16g，其中還有 2c 是獨立的。空間與流量也算滿大方的，雖然東京的流量比其他地方少一半，以我的用量來說也還算夠用，算是很不錯的 trade off。 只是在 LowEndTalk 或是 LowEndSprit 討論區上面給 HostHatch 的評價都不是很好，不外乎回覆很慢，服務態度不好之類的。仔細觀察感覺很有可能是因為這些人都買促銷價的 VM 所以也得到最基本的客服而已。 總之先開了帳號，直接從網站上買了不是促銷的 $22 方案 6c24g, 100G, 6T 一個月來試用看看，然後開始設定。雖然 BGP 啟用的部份一開始有點小差錯，考慮到他們才剛開始做這塊也算是情有可原。整體而言服務的品質其實相當不錯，回訊息都很快，機器的規格也沒有灌水。從我家連到機器只需要 4 ms 的時間。 測試了幾天之後就把網站搬過來，然後也架好 Synapse，目前跑了快三個月都沒什麼問題，也測試了從台灣連過來的速度也不錯，走 GSL 只需要 34 ms 左右的時間。 如果有興趣想試試看的人可以用我的連結 https://cloud.hosthatch.com/a/3823</a> 這樣我可以收到一點回饋 🙂 IBus Chewing 更新 2024-02-05T00:00:00+00:00 上週末跟 Ding-Yi Chen 聯絡上，把 ibus-chewing 的 repository 搬到 Chewing Project 之後，就動手改一些東西。新的 repo 網址是 https://github.com/chewing/ibus-chewing</a> 。 首先著重在整理 code base，先把 CMake 環境整理一下，然後把原本手刻的 ibus-setup-chewing 用 GTK4 重寫，並引入 libadwaita 讓界面跟 gnome 統一。 之前的樣子： </picture> </figure> </picture> </figure> </picture> </figure> 現在的樣子： </picture> ▴ 新 ibus-chewing 設定界面 </figcaption> </figure> 主要的兩個 PR: https://github.com/chewing/ibus-chewing/pull/171</a></li> https://github.com/chewing/ibus-chewing/pull/172</a></li> </ul> 接下刪掉約三千多行的沒有在用的程式碼，拿掉 X11 的依賴，修掉一些小的 bug。接下來測試若是沒什麼大問題，就可以來準備出個新版。▞ 2024 年的專案計畫 2024-01-21T00:00:00+00:00 有太多想做的小專案，隨手紀錄一下以免要一直回想。 新酷音 Rust 版</h2> 0.7.0 – Rust 重寫的版本可以支援全部功能考慮一下最終要支援的資料庫格式們</li> Fuzzing</li> </ul> </li> 0.8.0 – 預設使用 Rust 版本</li> 0.9.0 – 第一版 Rust API 的半穩定版重新設計 Editor type</li> 重新設計 Error type</li> 重新設計 Keymap module</li> 更新文件</li> </ul> </li> </ul> 新酷音新功能</h2> 簡單注音模式</li> 只輸入聲符的模式</li> 不需要輸入音調的模式</li> 好用的詞庫編輯器，從自己文章產生詞庫等等</li> 多詞庫功能</li> </ul> cdb2-rs</h2> 把這個 fork 的 library 整理一下釋出新版本 ibus-z</h2> 用 zbus 寫一個 ibus 的 wrapper library ibus-chewing</h2> 更新 ibus-chewing 到 GTK4 推動 Fedora 把繁體中文的輸入法改回 ibus-chewing 用 Rust 重寫 ibus-chewing，需要 chewing 0.8.0 以及 ibus-z MuPDF</h2> Update the Debian package to build shared library by default. Fedora 上使用硬體加密的 SSH 與 PGP 2023-12-02T00:00:00+00:00 從一開始入手 Yubikey 4，後來換成 Yubikey 5 NFC，我已經很久沒有把 SSH 跟 PGP 的密鑰放在檔案系統裡過了。我最近新買了一隻 Yubikey 5 Nano，簡單設定後紀錄分享一下怎麼使用硬體加密的 SSH 和 PGP 簽章。 Yubikey 的原理是它有一個硬體的「安全元件 (secure element)」可以用來實做各種智慧卡 (smart card) 的功能，這裡我們關心的是它的 PIV (personal identity verification) 與 PGP 兩個智慧卡界面。 PIV 與 PKCS#11 與 PC/SC</h2> PIV 是一種智慧卡的標準，定義了智慧卡需要支援的金鑰格式，演算法等等。Yubikey 的 PIV 支援標準的 9a, 9c, 9d, 9e 金鑰儲區，還有額外的 10 個以上的過期金鑰儲存位置。這些標準的金鑰儲存區分別用來「認證」、「簽章」、「加密」、「驗證」。雖然沒有強制規定這些金鑰要怎麼使用，通常 SSH 會設定為使用 9a 的「認證」用金鑰區來儲存 SSH 的私鑰。 SSH 不是直接使用 PIV 來使用智慧卡，而是支援另外一個標準 PKCS#11，這個標準定義了統一的抽象軟體界面來提供硬體的加密演算法功能。Yubico 有提供自己的 libykcs11.so 這個函式庫可以直接使用 Yubikey 上的 PIV 功能，而 Fedora, Debian 等系統則預設使用 OpenSC 的 opensc-pkcs11.so 這個函式庫。OpenSC 則仰賴 pcscd-lite 這個程式透過標準的 PC/SC 界面和各種不同的智慧卡溝通。 因為同一個系統上可以同時有多個不同的 PKCS#11 函式庫，Fedora 便用 p11-kit 的 p11-kit-proxy 來更簡單的使用不同的 PKCS#11 提供元。 PKCS#11 相關的軟體生態相當複雜，簡化為一張圖的話大概繪像這樣： </picture> ▴ PKCS#11 生態練 </figcaption> </figure> 實際上因為用了 p11-kit 的關係，所以設定起來其實非常簡單。首先先用 ykman 產生私鑰(預設是 RSA 2048 bit)跟公鑰(包裝為 X.509 憑證格式)： $ sudo dnf install yubikey-manager $ ykman piv keys generate 9a public.pem $ ykman piv certificates generate -s CN=SSH 9a public.pem</code></pre> 然後就可以使用了，可以用 ssh-keygen 把公鑰弄出來，然後設定 ssh 預設用 p11-kit-proxy 來存取私鑰： $ ssh-keygen -D pkcs11: | tee ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0tEUNb5QGKlGW8wcv+WYZCN1xKZE7NLFeCqj8QUbsfuobudTp8fZYCwtF8UwkwXpVTTg5RLdFOanp0V3ZDDVanyZEzopfhghcmZAmNJ5UoBZx+hOerlTHBmZNBJY0T8MzogQO60UluVYqOwcRynQfdV+F2oNrhqNph0BHIOgPTtlc5WO6R6VXcFBaHQROBDvB7hAi1MrIqZ5AoX9bI7thYbmzQuK6PYbFQEcSXrxyvnb4Xus7hmk6Vw7itn65/7JMKhgAz3jRR0HHAyRBB2pjqPxdNFOMDB3IieviiYOGvMlfZ2HaimQB8c6EvC8i+G3/KV/w5C8zP0VE+lfGhyHn PIV AUTH pubkey pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH;manufacturer=piv_II?module-path=/usr/lib64/p11-kit-proxy.so $ echo 'IdentityFile "pkcs11:"' > ~/.ssh/config # 也可以把私鑰加到 ssh-agent 中 $ ssh-add -s pkcs11:</code></pre> 設定起來算是相當無腦(參考文章</a>)。 GnuPG 與 scdaemon</h2> 我一開始用 Yubikey 主要就是為了它的硬體 PGP 智慧卡，搭配 GnuPG</a> 可以實現簽章、加密、SSH 認證三個功能。這是一個常用的功能，而且網路上已經有許多的文件說明，這裡就不再重複。我想要紀錄的是如何讓 GnuPG 與 PIV 共存。 網路搜尋可以發現許多關於 gpg –card-status 不正常運作的問題： $ gpg --card-status gpg: selecting openpgp failed: No such device gpg: OpenPGP card not available: No such device</code></pre> 這是因為 GnuPG 跟 OpenSC / pcscd 都需要透過 CCID 這個 USB 通訊協定跟智慧卡溝通，但是 GnuPG 用來實現這個功能的工具程式 scdaemon 預設會開啟獨占模式，不允許其他的程式也使用系統上的智慧卡，理由是 scdaemon 會暫時快取一些狀態在記憶體裡面，如果其他程式也同時使用智慧卡的話，有可能會造成狀態不一致的錯誤。相關的討論中如 T6218</a> 和 T2440</a> 可以看到 GnuPG 的開發者並不願意改變這個預設行為。 網路上有許多很久以前的解法，甚至 pcsc-lite 的作者都有一篇 blog</a> 說明這個問題。我測試後現在可以暫時解決這個問題的方法是強制 scdaemon 以共享模式使用 pscsd 的資源： # $HOME/.gnupg/scdaemon.conf disable-ccid pcsc-shared</code></pre> 這樣就可以讓 gpg 幾乎都可以正常運作。如果還是有問題，跑指令 $ gpgconf --kill all</code></pre> 也幾乎都可以解決。 基於現在 Debian 還是只能用 PGP 來認證上傳的套件，希望 GnuPG 可以改善 scdaemon 的預設行為，跟其他軟體和平相處。▞ 用 podman-kube 來跑 WordPress 2023-11-18T00:00:00+00:00 上一篇寫了要怎麼用 podman 的 systemd generator</a> 來跑單一的 container，其實 podman 還有另外一個 pod 模式，也就是類似 Kubernetes 的 pod 一樣，可以把多個 container 跑在同一個 namespace 裡面。Podman 的 podman-kube-play(1)</a> 指令可以接受一個 Kubernetes 的 YAML 設定檔然後跑起單一個 container 或是一整個 pod 與多個 container。同樣的，systemd generator 也可以用來管理整個 pod，變成 systemd service unit。 </picture> ▴ 原本的架構圖 </figcaption> </figure> 這次我要做的是把單一的 WordPress container 改成用 PHP-fpm 和 Caddy 兩個 container 的方式佈署。原本單一的 WordPress container 用的是 apache2 prefork mpm，同時處理多個 HTTP request 效率比較不好，換成兩個獨立的 container 後，可以把 PHP 與靜態檔案分別交給不同的 process 處理，這樣各自效率都比較好。當然也不一定要用 Caddy，其他像是 nginx 或是 apache2 event mpm 也可以。 </picture> ▴ 新的架構圖 </figcaption> </figure> Podman 的改版還滿快的，新的版本常常都會新增許多功能。這次我使用的是 Podman 4.7.0 版。因為我記不住要怎麼寫 Kubernetes 的 YAML，所以我用比較簡單的方法：先用指令產生好 pod 跟 container 後，再用 podman kube generate 來產生 YAML. 首先創造一個空的 pod 來： podman pod create --network core --name wordpress-pod</code></pre> Network 可以隨意設定，之後可以再改。接下來可以創造 File Server container： podman create --pod wordpress-pod --name wordpress-php \ -v /var/srv/wordpress:/var/www/html:Z \ -e WORDPRESS_DB_HOST=wp-db \ wordpress:fpm</code></pre> 最後，用 podman-kube 來產生 Kubernetes 的 YAML 設定檔： podman kube generate wordpress-pod > wordpress-pod.yaml</code></pre> 產生出來的設定類似這樣： # Save the output of this file and use kubectl create -f to import # it into Kubernetes. # # Created with podman-4.7.0 apiVersion: v1 kind: Pod metadata: annotations: bind-mount-options: /var/srv/wordpress:Z bind-mount-options/wordpress-pod-wordpress-fs: /var/srv/wordpress:Z bind-mount-options/wordpress-pod-wordpress-php: /var/srv/wordpress:Z creationTimestamp: "2023-11-18T07:10:21Z" labels: app: wordpress-pod name: wordpress-pod spec: containers: - image: docker.io/library/caddy:latest name: wordpress-pod-wordpress-fs volumeMounts: - mountPath: /etc/caddy/Caddyfile name: etc-caddy-wordpress-fs-host-0 - mountPath: /var/www/html name: var-srv-wordpress-host-1 - mountPath: /data name: wordpress-fs-data-pvc - args: - php-fpm env: - name: WORDPRESS_DB_HOST value: wp-db image: docker.io/library/wordpress:fpm name: wordpresss-pod-wordpress-php volumeMounts: - mountPath: /var/www/html name: var-srv-wordpress-host-0 restartPolicy: Always volumes: - hostPath: path: /etc/caddy/wordpress-fs type: File name: etc-caddy-wordpress-fs-host-0 - hostPath: path: /var/srv/wordpress type: Directory name: var-srv-wordpress-host-1 - name: wordpress-fs-data-pvc persistentVolumeClaim: claimName: wordpreess-fs-data - hostPath: path: /var/srv/wordpress type: Directory name: var-srv-wordpress-host-0</code></pre> 最後就可以用 podman-kube-play 來測試： podman kube play --network core wordpress-pod.yaml</code></pre> 滿意了就可以把設定弄成 systemd unit # /etc/containers/systemd/wordpress-pod.kube [Unit] Description=WordPress website After=network-online.target Wants=network-online.target [Kube] Network=core Yaml=/etc/containers/systemd/wordpress-pod.yaml [Service] Restart=always TimeoutStartSec=900 [Install] WantedBy=multi-user.target</code></pre> 整體而言算是相當簡單就可以設定好一個 pod，再加一些設定還可以做動自動更新或是自動佈署最新的設定，也可以把同樣的設定檔改一改就拿去大型的 Kubernetes 叢集跑。▗ 參考文章： https://caddy.community/t/setting-up-wordpress-with-caddy-on-ubuntu/18448</a></li> https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html#name</a></li> https://docs.podman.io/en/latest/markdown/podman-kube-play.1.html</a></li> </ul> 用 systemd 管理 podman containers 2023-11-06T00:00:00+00:00 Podman 原本有提供指令可以產生 systemd service 的設定檔，但是產生出來的檔案內容感覺有很多改善的空間，例如要怎麼讓 podman 可以乖乖的把 log 送到 journald 就不是產生的範本有提供的。 podman generate systemd wordpress-container</code></pre> 在研究這個問題的時候發現這個指令已經被 Quadlet 取代了。Quadlet 是在 podman 4.4 的時候整合進去的，利用 systemd generator 的方式把類似於 systemd 的設定檔直接轉換為 systemd 可以使用的格式。 # cat /etc/containers/systemd/wordpress.container [Unit] Description=Wordpress Container After=network-online.target Wants=network-online.target [Container] Image=docker.io/library/wordpress:6 Volume=/var/srv/wordpress:/var/www/html:Z [Service] Restart=always TimeoutStartSec=900 [Install] WantedBy=multi-user.target</code></pre> 如此一來就可以簡單的設定 container 以及讓 container 自動更新了。詳細的設定可以參考 podman-systemd.unit(5)</a> 的內容。 把設定放到 /etc/containers/systemd 目錄下以後，記得要讓 systemd 重新讀取： # sudo systemctl daemon-reload # sudo systemctl start wordpress # systemctl status wordpress ● wordpress.service - WordPress Container Loaded: loaded (/etc/containers/systemd/wordpress.container; generated) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: active (running) since Sun 2023-11-05 03:07:06 UTC; 20h ago Main PID: 57888 (conmon) Tasks: 5 (limit: 2032) Memory: 212.2M CPU: 4min 34.751s CGroup: /system.slice/wordpress.service ├─libpod-payload-739aab67986c96c │ ├─57890 apache2 -DFOREGROUND │ ├─74394 apache2 -DFOREGROUND │ ├─74399 apache2 -DFOREGROUND │ └─74407 apache2 -DFOREGROUND └─runtime └─57888 /usr/bin/conmon --api-version 1 -c 739aab67986c96c</code></pre> 這一種設定方式比原本的 systemd 簡單太多了。▗ Fedora Silverblue 新增硬碟到 Btrfs 陣列 2023-05-16T00:00:00+00:00 我目前的主力電腦是一台 2020 年購入的 System76 的 Lemur Pro (lemp9)</a>，前陣子無線網路卡掛點，自己換了新的 Intel AX210 模組。 今天有感於最初設定的規格 500 GB 的 SSD 儲存空間有點不夠用了，想要加裝新的 SSD 來擴增容量。lemp9 內部有兩個 M.2 NVMe 的空間，所以我還有一個空位可以用。 原本內裝的是 Samsung 的 970 EVO Plus 500 GB，所以這次就添購了同樣是 Samsung 的 970 EVO Plus 2 TB，一次加好加滿。 我大約半年前把主力作業系統換成 Fedora 並且裝了 Fedora Silverblue</a> 這個版本，是一種新型的 immutable 作業系統安裝方式，安裝基底系統後，額外的軟體都是用 Flatpak 或是 container 的形式疊加上去的。 有如其他 Fedora Workstation 系統，Silverblue 已經預設使用 Btrfs 為主要檔案系統。這次我要新增一個 SSD 並且加到硬碟陣列中。主要的一個問題是我有用 LUKS 形式的全硬碟加密，增加了新的 SSD 之後要改些設定讓他在開機的時候會自動解鎖。 安裝新的 SSD</h2> 按照 System76 網站上的維修手冊</a>就可以輕鬆安裝。 格式化新的 SSD</h2> 使用 GNOME 內建的 Disks 工具軟體，幫新的 SSD 建立 GPT 分割表，然後產生一個分割區，不要建立檔案系統但是要加密。 </picture> ▴ Disks 管理工具 </figcaption> </figure> 新增到 Btrfs 陣列</h2> 參考這篇詳細的說明</a>，首先把解鎖後的裝置加入 sudo btrfs device add /dev/mapper/luks-d56dd585-059c-45b7-8eab-4e1df1e3d769 /mnt/btr_pool/</code></pre> 然後把 metadata 轉成 RAID1 sudo btrfs balance start -mconvert=raid1 /mnt/btr_pool/</code></pre> 接下來就可以確定新增完成： sudo btrfs fi usage / Overall: Device size: 2.27TiB Device allocated: 432.07GiB Device unallocated: 1.85TiB Device missing: 0.00B Device slack: 0.00B Used: 287.40GiB Free (estimated): 1.99TiB (min: 1.06TiB) Free (statfs, df): 1.99TiB Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: 512.00MiB (used: 0.00B) Multiple profiles: no Data,single: Size:416.01GiB, Used:274.19GiB (65.91%) /dev/mapper/luks-4845f8f9-cfdf-4488-9611-68a7789869dd 416.01GiB Metadata,RAID1: Size:8.00GiB, Used:6.60GiB (82.56%) /dev/mapper/luks-4845f8f9-cfdf-4488-9611-68a7789869dd 8.00GiB /dev/mapper/luks-d56dd585-059c-45b7-8eab-4e1df1e3d769 8.00GiB System,RAID1: Size:32.00MiB, Used:80.00KiB (0.24%) /dev/mapper/luks-4845f8f9-cfdf-4488-9611-68a7789869dd 32.00MiB /dev/mapper/luks-d56dd585-059c-45b7-8eab-4e1df1e3d769 32.00MiB Unallocated: /dev/mapper/luks-4845f8f9-cfdf-4488-9611-68a7789869dd 40.12GiB /dev/mapper/luks-d56dd585-059c-45b7-8eab-4e1df1e3d769 1.81TiB</code></pre>修改開機參數</h2> 為了要在開機的時候自動解鎖兩個 SSD 一定要記得修改開機參數，不然開機後只有一個硬碟解鎖，會卡在開機掛載系統分割區。 在 Silverblue 可以用 rpm-ostree 指令管理開機參數： rpm-ostree kargs --append=rd.luks.uuid=luks-d56dd585-059c-45b7-8eab-4e1df1e3d769</code></pre> 重新開機後就可以驗證宜一切都設定好了！▗ 2022 十月箱根旅行 2023-02-05T00:00:00+00:00 試著發表一些旅行時拍的照片！ 相機 Fujifilm X-Pro2，鏡頭 XF35mmF1.4R，後製 Darktable 4.0 </picture> ▴ 在小田原駅等車前往箱根湯本 </figcaption> </figure> </picture> ▴ 搭乘登山小火車 </figcaption> </figure> </picture> ▴ 搭乘空中纜車到大湧谷 </figcaption> </figure> </picture> </figure> </picture> </figure> </picture> ▴ 大湧谷的火山地形 </figcaption> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> ▴ 經由蘆之湖坐巴士到仙石原すすき高原 </figcaption> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> ▴ 箱根湿生花園 </figcaption> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> </figure> </picture> ▴ 箱根神社 </figcaption> </figure> </picture> </figure> 加入 Fediverse 聯邦宇宙 2022-11-04T00:00:00+00:00 最近因為 Twitter 被收購，許多人開始找替代的服務，所以 Mastodon 又開始有很多新人加入。和一般社交網路不一樣，Mastodon 是建立在一個無單一主站的架構上面。而上一篇我換回到 WordPress 其實跟這個還有點關係 😉 這個由架構所建立起來的社交網路又稱作 Fediverse</a>，裡面並不只是 Mastodon</a>，只要是使用 ActivityPub</a> 這個協議的網站都有機會串接起來！現在已經有各種類似 Twitter 的微型部落格，或是類似 Instagram 的照片分享平台，都可以互相串連。而 WriteFreely 則是介於傳統部落格與微型部落格之間。 </picture> ▴ <a href="https://axbom.com/fediverse/">世界樹</a> </figcaption> </figure> 而 WordPress 上有人做了一個 ActivityPub 的 plugin</a> 可以把部落格網站直接變成一個 Fediverse 上面的節點，可以直接被 Mastodon 或是其他網站跟隨。比如說可以在 Mastodon 裡面搜尋 @kanru 就會找到我！更有趣的是回文會變成網站上面的留言，所以互動是雙向的。 讓我覺得，如果說 Web2.0 是創作者與讀者互動網站，早期部落格的 RSS 訂閱，跨網站的引用通知 (Ping back & Trackbacks) 是長篇文章的互動的話，ActivityPub 所促成的正是短篇文章 (microblog) 的互動，可不可以算是 Web3.0？最少也是 Web2.0 的文藝復興了。▗ 回頭用 WordPress 寫部落格 2022-11-03T00:00:00+00:00 網路上有一個笑話：有在寫部落格的工程師，都至少有寫過一次自己的靜態網頁編譯軟體，而且比起真正寫部落格，會花更多時間在重構這個軟體或是調整模板。回頭看看我自己網站上面的文章，自從發出 Blog Redesigned</a> 這篇文章之後，文章數量從每年幾篇，直接掉到每三年一篇。為什麼呢？ </picture> ▴ 2010 年之後就幾乎沒有幾個月有新文章 </figcaption> </figure> 這幾年我換過好幾次靜態網頁產生軟體，調整過好幾次網站設計，換過各種服務平台（雲端虛擬主機、Vercel、Cloudflare、Cloudfront+S3、Lambda、雲端虛擬主機），但是文章數量總共增加了兩篇，免強加上翻譯為英文跟日文，也才只有五篇。 去年初幫老婆的姊姊架了一個新的 WordPress 網站，主要讓她寫一些小品心得文章還有讓她有可以宣傳她自己的產品的網站。過程中還開發了一個使用 Cloudflare Zero Trust 的外掛，架了幾個測試站，才發現 WordPress 已經改變進步了很多。 之後我又陸續測試了 Ghost 跟 WriteFreely ，了解到重點不在於靜態編譯的網頁可以有多快的速度、多省資源，而是一個環境會不會讓你有可以維持繼續的寫下去的動力。 WordPress 有兩個我覺得很有用的功能，第一個是最新的古騰堡編全站輯器有區塊的概念，可以很簡單的加入圖片並且調整圖片的樣式是滿版還是中間對齊，也可以針對不同文章給予不同的排版，第二點是可以把文章存到草稿，然後很快的打開就可以繼續編輯。這兩個功能讓「寫文章」這件事的阻力變小，也就比較沒有心裡負擔可以輕鬆的寫。以前換到靜態網頁編譯器之後，光是要開始寫一篇新文章，就要先花點時間研究文章標題等等後設資料(front matter)要怎麼設定，等到搞定之後，已經沒有力氣寫本文了。 趁著這週 WordPress 6.1 釋出，把所有文章都搬過來了，希望這次搬回 WordPress 之後可以多發表一些技術還有隨手拍的文章！▗ 桔梗種植的第二年更新 2021-07-16T00:00:00+00:00 桔梗的葉子在冬天會枯萎，但是地下長的像人蔘的根部則是會進入休眠狀態。等到春天白天氣溫約 17 度的時候，就會重新萌發出新芽。 我種在陽台的桔梗在去年過冬前就已經枯的七七八八，完全枯死那種。剩下的最後一棵頑強的桔梗，在氣溫進入 10 度以下後也似乎漸漸進入休眠，只是實在難以判斷是否還有機會重新萌發。就這樣半信半疑，每隔一段時間仍然給盆栽水分，讓土壤保持微微溼潤。 今年春天，三月初的時候，從桔梗開始休眠已經過了三、四個月。有一天我仍然例行檢查盆栽，驚喜的發現桔梗的枯莖旁邊冒出了一個小小的像筍子的東西，隔幾天又多冒出兩個筍子。根據它們的位置看起來，它們應該都是去年最後一棵桔梗重新萌發的。 </picture> ▴ 2021-03-17 桔梗新芽冒出 </figcaption> </figure> 第二年重新長出來的桔梗和新芽很不一樣，粗壯好幾倍，生長速度也快非常多。每天可以長高一兩公分，等到三月底的時候已經可以看出來是三棵強壯的桔梗了。 </picture> ▴ 2021-03-20 桔梗新芽越長越高 </figcaption> </figure> </picture> ▴ 2021-03-23 桔梗新芽有如蘆筍 </figcaption> </figure> </picture> ▴ 2021-03-31 桔梗新芽的葉子開始展開 </figcaption> </figure> 四月中，所有的葉子都已經展開，長到大約 15 公分左右。之後，因為我臨時必須回台灣一趟，所以給它們設置了自動澆水的裝置，中間約有一個月多的時間無法紀錄，只能希望它們可以撐到我回來。 </picture> ▴ 2021-04-06 桔梗新芽已經有 15 公分高 </figcaption> </figure> </picture> ▴ 2021-04-11 桔梗新芽出國前的樣子 </figcaption> </figure> 等到我從台灣回來之後看到的是雖然沒有枯掉，但是長的東倒西歪的桔梗，真是哭笑不得。原本以為粗壯幾倍的桔梗應該可以長的比較挺，不會像第一年一樣伏在地上，結果可能因為沒有修剪加上今年春天陽光比較不夠，最後還是長到歪了。 </picture> ▴ 2021-05-25 東倒西歪的桔梗 </figcaption> </figure> 其中有有一棵看起來是被強風吹斷了，已經半枯，就乾脆剪到底座。其他兩棵也因為長的不是很好，被第一年就有的真菌感染，葉子上許多白點。 </picture> ▴ 2021-06-05 桔梗生病的葉子 </figcaption> </figure> 六月中，雖然葉子還是不健康，花苞還是陸續結出來了。和第一年不一樣的是，花苞非常的多，最後最高紀錄同時開了九朵呢！ </picture> ▴ 2021-06-09 桔梗的花苞 </figcaption> </figure> </picture> ▴ 2021-06-13 桔梗開花 </figcaption> </figure> </picture> ▴ 2021-06-22 桔梗開滿花 </figcaption> </figure> 桔梗花的種植與照顧 2020-08-08T00:00:00+00:00 桔梗（學名：Platycodon grandiflorus），别名包袱花、鈴鐺花，擁有可愛的小花，帶有獨特的紙張質地和可見的花脈。我所在地區（日本東京）的常見品種有紫色和白色的花朵。這種植物的一個顯著特徵是它的花苞在完全打開之前像氣球一樣膨脹。 在超市或是居家賣場不難發現它們的身影。當我第一次發現它們之後我就決定要在我的陽台花園種個幾朵。 我在日本亞馬遜買了花的種子以後，用了我原本計畫要種些蔬菜的花盆來種。之後發現這種花盆不是最好的選擇，因為很難控制澆水的水量。之後會詳細解釋。 網路上有許多關於桔梗的資訊，但是關於它們在各個生長期的照片，還有如何照顧它們的文章非常的少。希望我的經驗分享可以對其他想要種桔梗的人有幫助！ 桔梗在生長的初期長的非常緩慢</h2> 作為參考，東京的柯本氣候分類法分類裡面是「Cfa」，意思是溫暖帶濕地型夏季炎熱氣候。夏天最熱的時候可以高於 34 攝氏度。冬天的時候溫度最低可以低於零度，甚至有可能下雪。我買到的品種是較嬌小的「桔梗五月雨混和」，原生於北海道，所以極端的氣候對它們應該不構成問題。理論上冬天的時候它們會休眠然後隔年春天再重新長芽。根據種子包裝的說明，最好的播種季節是四月或是九月。 </picture> ▴ 一百顆桔梗五月雨混和種子都種下了, 2019-09-15 </figcaption> </figure> 我第一次試圖種桔梗是在 2019 年九月。因為它們的發芽需要光照，所以最好把它們放在室外半日照或是有遮蔭的地方。我原本不知道它們在初期長的如此緩慢。大約在播種的二十天之後，種子們慢慢陸續發芽，然後用無比緩慢的速度生長它們的真葉。 </picture> ▴ 播種二十天後的桔梗, 2019-10-05 </figcaption> </figure> 在這個階段我面臨了另外一個問題，也就是要如何幫幼苗澆水。桔梗喜歡排水通暢的帶砂質土壤，所以我必須要維持土讓的濕度又不過度潮濕。問題是它們生長緩慢因此並不太消耗盆栽裡面的水。我所使用的盆栽是設計來保留較多水分的，所以反而是幫倒忙。很難估計多久要澆一次水，每次要澆多少。 </picture> ▴ 接近生長季節的尾聲, 2019-10-27 </figcaption> </figure> 另外一個問題是它們的生長季節不夠長。我猜測它們要儲存足夠的養分長出肥大的肉質根，才有機會在冬天嚴酷的休眠期存活。我懷疑它們一開始葉子會長的如此慢是因為都在長看不到的根部。結果在溫度變低之前，這一批桔梗來不及長到足夠的大小過冬。 冬天的時候桔梗高於地面的部份會枯死。維持耐心的等待，保持土壤溼潤，大約隔年的四月它們就會重新長出嫩芽。是的，大約就在我快要放棄並開始重新播種的時候。 </picture> ▴ 唯一活過冬天重新長芽的桔梗, 2020-05-02 </figcaption> </figure> 春天開始播種讓事情簡單許多</h2> 我現在知道了，如果我一開始就等到四月才播種，結果也許不會改變太多。儘管它們一開始還是生長的非常緩慢，最終它們會爆發性的開始長葉子。 這次我把它們先種在雞蛋盒裡面，因為這樣子比較容易澆水。我建議使用底部澆水法，因為從上面澆水有可能移動幼苗，干擾它們的根部穩定。 </picture> ▴ 重新開始，這次先種雞蛋盒裡, 2020-04-21 </figcaption> </figure> 春天相對溫暖的氣候似乎有促進幼苗的發展，但是跟隔壁的羅勒比起還是完全不在同一個層次。 它們的根毛開始從盒子的底部冒出，所以是時候把它們換到較大的盆子了。它們不喜歡根部被打擾，所以換盆的時候要小心操作，最好在幼苗長的太大之前進行。 </picture> ▴ 這些桔梗幼苗已經可以換盆了, 2020-05-29 </figcaption> </figure> 換盆之後又過了兩週，它們開始有明顯的成長。原本換盆前就有的兩對真葉長的更大了，全部也都開始長第三對真葉。 </picture> ▴ 換盆後的桔梗長出第三對真葉, 2020-06-14 </figcaption> </figure> 大盆栽的另外一側是空的，因為我原本計畫要再種幾顆幼苗。為什麼呢？因為我本來以為要多種一點才會有足夠的花。畢竟你看，它們看起來就是只會有單一植株，單一朵花的模樣。很多網路上的圖片看起來它們都是叢生的樣子。我錯了！ </picture> ▴ 僅僅五天它們就長成這樣了, 2020-06-20 </figcaption> </figure> 桔梗單體可以長出多個側芽</h2> 換盆的一個月後，它們開始展現它們的主幹會橫臥的傾向。一開始這些主幹會垂直的生長，然後突然開始傾倒往旁邊發展，最後再垂直生長。 它們會朝四面八方生長，如果有人只看每一支幼苗的莖，是很難找到基部在哪裡的。 </picture> ▴ 有些桔梗會長出橫臥的莖, 2020-07-11 </figcaption> </figure> 隨著它們越長越大，它們也開始從莖的節點或是基部長出新的分支。我開始理解很多圖片裡面看起來叢生的桔梗，其實很有可能都是同樣的一兩顆桔梗而已。 </picture> ▴ 從桔梗基部長出的新分支, 2020-07-12 </figcaption> </figure> 如果你仔細觀察的話，你可能會發現上面照片裡的葉子有一些小白點。我懷疑這些白點是一種真菌感染的疾病。幸運的是它們似乎沒有造成太大的影響。 桔梗第一年就有可能開花</h2> 我原本有點擔心我今年可能不會有任何的花，因為它們一開始長的好慢。結果，大約七月底的時候開始陸續有花苞長出來了。每天看著這些「氣球」越長越大我就感到興奮。 </picture> ▴ 多個桔梗的花苞開始出現, 2020-08-01 </figcaption> </figure> 有一天，最大的那一個花苞開始出現些許的紫色。我知道它就快要開花了，但是是什麼時候呢？順帶一提，桔梗對日本人來說是秋天的象徵，看起來這些花還挺準時的。 </picture> ▴ 這個桔梗花苞隨時都會開花, 2020-08-02 </figcaption> </figure> 隔天早上，這朵花就在我還在幫其他植物澆水的時候開了！ </picture> ▴ 完全展開的桔梗花, 2020-08-02 </figcaption> </figure> 還有更多的花苞跟桔梗們繼續在生長。希望我今年春天會有更多的桔梗花可以欣賞！ </picture> ▴ 另外一個隨時會成熟的花苞, 2020-08-08 </figcaption> </figure> 你也種過桔梗嗎？你有沒有任何訣竅想要分享？歡迎寄電子郵件或是在底下留言 :) JSON Web Tokens 研究筆記 2020-02-01T00:00:00+00:00 JSON Web Tokens 是什麼？它真的可以用來取代傳統的 session cookies 嗎？本篇為研究 JWT 時所做的筆記。 什麼是 JSON Web Tokens ？</h2> JSON Web Token 縮寫為 JWT，唸作 jot，是一個 IETF 標準(RFC 7519</a>)，定義了不同的群體間可以精簡且安全的方式交換資訊的方法，這些資訊是包裝在一個 JSON Object 裡面，因而得名。這些資訊因為經過數位簽章所以可以被驗證是否為可信任的內容，簽章的方式可以是單一密文(HMAC)或是公鑰私鑰系統(RSA)。 JSON Web Tokens 要怎麼用？</h2> 當使用者跟伺服器登錄之後，伺服器可以傳回一個 JSON Web Token，此 Token 可以存在瀏覽器的 local storage 或是 cookie。 當使用者想要再次存取某些需要認證的資訊的時候，他們需要把這個 JWT 送回伺服器，通常以 Authorization header 的形式，例如： Authorization: Bearer <token></code></pre> 這個方式對於伺服器來說相較於 session cookie 的方式輕量(stateless)，因為伺服器不需要保有相關 session 的訊息，只需要 JWT 內的資訊就可以確認該使用者是否可以取用相關資源。 使用 JSON Web Tokens 的好處</h2> 可以容易的橫向 scale</li> 維護更容易(沒有需要長期儲存的資料)</li> 跨 Domain RESTful API (不需要 CORS cookie)</li> 可以設定 Token 的有效期限</li> 單一 Token 即包含所有認證需要的資訊</li> </ol> 傳統的 Session</h2> 使用者認證後伺服器傳回一個 session ID，之後伺服器可以用此ID查訊使用者資訊 常見問題</h3> 需要資料庫統一儲存登錄資訊</li> 如何登出使用者？</li> </ol> JSON Web Token 的潛在問題</h2> XSS, CSRF, Replay attack, MITM</li> JWT 透過數位簽章跟加密來防止竄改或是竊取裡面的資料，但是 JWT 被儲存在 local storage 或是 cookies 裡面的時候，同一個 domain 的 JavaScript 同樣都可以存取這些 JWT，因此有潛在的 XSS 或是 CSRF 攻擊的風險。</li> JWT 的大小比單純的 session ID 大的多</li> 保護簽章用的密文或是私鑰變得非常重要</li> </ol> 如何應對重播攻擊</h3> 使用較短的有效期限</li> 客戶端定期更新Token</li> 伺服器端使用黑名單阻擋有問題的客戶</li> </ol> 把 JWT 或是 session ID 存在 cookie 的好處</h2> Browser 會自動把 cookie 包含在 header 裡面所以適合用來保護網頁的存取 結論</h2> Don’t use JWT for persistent, long-lived data. 參考文獻</h2> https://ponyfoo.com/articles/json-web-tokens-vs-session-cookies</a></li> http://by.jtl.xyz/2016/06/the-unspoken-vulnerability-of-jwts.html</a></li> https://stackoverflow.com/questions/37582444/jwt-vs-cookies-for-token-based-authentication</a></li> https://dzone.com/articles/jwtjson-web-tokens-are-better-than-session-cookies</a></li> http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/</a></li> https://jwt.io/</a></li> </ol> 簡單把 CSS 變成非同步讀取 2019-07-28T00:00:00+00:00 在 Smashing Newsletter</a> 看到的，只要 <link></code> 標籤就可以簡單把 CSS 變成非同步讀取： <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'"></code></pre> 有用過 Google PageSpeed Insight</a> 分析網站的，應該都有看過如下的結果： </picture> 原因是因為瀏覽器在處理 CSS 與 JavaScript 檔案的時候會阻擋其他資源的載入。解決的方法裡，JavaScript 類型的資源可以標示 defer</code> 或是 async</code> 屬性讓瀏覽器知道我們希望可以非同步的載入執行此 JavaScript 檔案，可惜 CSS 並沒有類似的屬性可以使用。 一般處理 CSS 的載入有兩個策略： 盡量把最重要的樣式內嵌(inline)在 HTML 內，</li> 用 JavaScript 動態的插入 <link></code> 標籤。</li> </ol> 策略 1. 應該不難理解，因為都已經要下載 HTML 了，不如把少部份最重要的樣式直接也寫在裡面，可以省下一次網路請求。策略 2. 則是把其他剩餘的樣式集中在一起，用 JavaScript 在網頁讀取完畢後再動態的插入 <link></code> 標籤讓瀏覽器套用。LoadCSS</a> 似乎是個常用的 library 但是我沒有用過，因為我不喜歡這種需要很多 JavaScript 的解法。 這次看到的這個方法非常簡單，原本的 CSS 標籤如下： <link rel="stylesheet" href="/path/to/my.css"></code></pre> 只要再加上 media="print"</code> 以及 onload="this.media='all'"</code> 就可以讓瀏覽器非同步載入 CSS 了！ 原理是，瀏覽器在遇到非使用中的 media</code> 時，只會下載但是不會套用樣式，所以設定 media</code> 為 print</code> 可以避免套用 CSS 的時候延遲其他的資源的載入，而 onload</code> 的部份則是在等到其他資源都載入完畢後，才把 media</code> 切回 all</code> 或是 screen</code> 讓瀏覽器套用樣式。雖然還是需要一點點 CSS，整體看起來清爽許多，也不需要額外的 library！ 如果需要支援沒有開啟 JavaScript 的瀏覽器，記得加上 fallback： <noscript><link rel="stylesheet" href="/path/to/my.css"></noscript></code></pre> 完整的範例如下： <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'"> <noscript><link rel="stylesheet" href="/path/to/my.css"></noscript></code></pre> 我迫不及待的立刻試用了😊 ∎ CSS Text 3: Segment Break Transformation Rules 2017-07-08T18:36:54-07:00 At the end of last year, I used my free time1</a> to fix Firefox Implementation of Segment Break Transformation Rules</a> (Bug 1081858</a>). Starting from Firefox 52, the line breaks between Chinese and Chinese in HTML will not be displayed as blank in the browser. Source</figcaption> </figure> Chromium 59</figcaption> </figure> Firefox 56</figcaption> </figure> </div> When using a plain text editor to compose a document, for the comfort of reading, we often set the line width to wrap at 80 characters. This width can accommodate forty Chinese characters, which is also comfortable for reading Chinese. With the advancement of software and hardware, the display content is no longer limited to a fixed width. Many typesetting software can reformat the content and display it in a different environment. In the process of formatting from the original document to the content displayed on the screen, these software will reorganize the text of the same paragraph into a text stream, remove or insert new line breaks, and retype it in the new container width; the problem is that many latin scripts use white space as the separation between words, and the algorithm of typesetting software also assumes this. As a result, the line breaks removed in the original document are replaced with white space by default. Nowadays, many content on the Internet is written in Markdown format, and most of the Markdown translation programs retain the line breaks of the original text2</a>, so many Chinese content on the Internet will find such problems. If you don’t read it carefully, you may not notice it, but once you notice it, it’s hard to ignore this typographic flaw, especially if the web page uses justified layout. This problem appears not only on web pages, but also in many applications that automatically reformat the text stream. For example, the Chinese package XeCJK of XeLaTeX also deals with similar problems. In the past, I used to modify the back-end of the program to solve this problem, but I have been looking for a way to fix it once and for all, directly in the browser. Later I found that CSS Text 3 has specifications in this regard. 4.1.2. Segment Break Transformation Rules When white-space is pre, pre-wrap, or pre-line, segment breaks are not collapsible and are instead transformed into a preserved line feed (U+000A). For other values of white-space, segment breaks are collapsible. As with spaces, any collapsible segment break immediately following another collapsible segment break is removed. Then the remaining segment breaks are either transformed into a space (U+0020) or removed depending on the context before and after the break: If the character immediately before or immediately after the segment break is the zero-width space character (U+200B), then the break is removed, leaving behind the zero-width space.</li> Otherwise, if the East Asian Width property [UAX11] of both the character before and after the segment break is F, W, or H (not A), and neither side is Hangul, then the segment break is removed.</li> Otherwise, the segment break is converted to a space (U+0020).</li> </ul> </blockquote> After actually starting to implement it, I found that Firefox had done some processing for Chinese early on, but this code incorrectly judged the boundaries of Chinese characters, making this code doing nothing after it was written. The original writing of this program is rather difficult to understand (using negative array index), and the lack of relevant tests has led to no one to find this error3</a>, and even after I fixed this code, some bugs</a> in the original layout engine were exposed. My colleague Jeremy later further modified</a> Gecko’s algorithm to make it conform to the current spec behavior. For other browsers, IE already has partial support. Now if the same spec is implemented in Blink/Webkit, most web pages will have no problems. Servo currently only has a simple algorithm in this part, which is also an opportunity to contribute! ^{1 This bug has been in my “If I have time” list before, and usually I don’t have time to do it. 😆 </div> ^{2 The original Markdown is just simple text substitution with perl </div> ^{3 That’s why test coverage is very important! </div>}}} CSS 文字級別 3：段落分隔變換規則 2017-07-08T18:36:54-07:00 去年年底，我利用閒暇時間1</a>修好了 Firefox 的 Segment Break Transformation Rules</a> 實做 (Bug 1081858</a>)。從 Firefox 52 開始，HTML 裡面中文與中文之間的換行，瀏覽器排版時不會顯示為空白。 Source</figcaption> </figure> Chromium 59</figcaption> </figure> Firefox 56</figcaption> </figure> </div> 使用純文字編輯器撰寫文檔時，為了閱讀的舒適性，常常我們會在行寬 80 個字元的時候換行，這個寬度可以容納四十個中文字，剛好也是可以舒適閱讀中文的寬度。隨著軟體硬體的進步，顯示內容不再侷限於固定的寬度，很多排版軟體都可以把內文重新排版後顯示在不一樣的環境。 從原始文檔轉換為螢幕顯示內容的排版過程，這些軟體會把同一段落的文字重組為文字流，移除換行或是插入新的換行，重新排版於新的容器寬度內；問題在於很多拼音文字使用空白作為字與字之間的分隔，排版軟體的演算法也如此假設，結果原本文檔內被移除的換行就預設被取代為空白。 現在很多網路上的內容都是用 Markdown 語法編寫的，大部分的 Markdown 轉譯程式都會保留原本內文的換行2</a>，所以很多網路上的中文內容都會發現這樣的問題。不仔細看的話也許不會注意到，但是一旦注意到了就很難忽略這個排版的瑕疵，如果網頁使用齊頭齊尾排版的話尤其明顯。 這個問題不只出現在網頁上，也出現在很多會自動重新排版文字流的應用程式中，例如 XeLaTeX 的中文套件 XeCJK 也要處理類似的問題。過去我經常修改程式後端來解決這個問題，但是也一直在尋找一勞永逸的，直接在瀏覽器裡面修正的方法。 後來找到 CSS Text 3 有這方面的規範。實際開始修改後我發現其實 Firefox 在很早就有針對中文做些處理，但是這段程式碼錯誤判斷中文字的邊界，使得這段程式碼從寫完開始就沒有任何作用。這段程式原本的寫法就比較難懂(使用負的陣列索引)，缺乏相關的測試導致一直沒有人發現這個錯誤3</a>，結果甚至在我修好這段程式碼之後還暴露了原本排版引擎的一些 bug</a>。 同事 Jeremy 後來進一步修改</a>了 Gecko 的演算法，符合目前 spec 規範的行為。 4.1.2. Segment Break Transformation Rules When white-space is pre, pre-wrap, or pre-line, segment breaks are not collapsible and are instead transformed into a preserved line feed (U+000A). For other values of white-space, segment breaks are collapsible. As with spaces, any collapsible segment break immediately following another collapsible segment break is removed. Then the remaining segment breaks are either transformed into a space (U+0020) or removed depending on the context before and after the break: If the character immediately before or immediately after the segment break is the zero-width space character (U+200B), then the break is removed, leaving behind the zero-width space.</li> Otherwise, if the East Asian Width property [UAX11] of both the character before and after the segment break is F, W, or H (not A), and neither side is Hangul, then the segment break is removed.</li> Otherwise, the segment break is converted to a space (U+0020).</li> </ul> </blockquote> 其他瀏覽器的話，IE 原本就有部份支援，只要在 Blink/Webkit 也實做同樣的 spec，這樣大部分的網頁就都不會有問題了。Servo 目前在這部份也是只有簡單的演算法，也是貢獻的機會！ ^{1 之前這個 Bug 一直在我的「如果我有時間」清單裡，通常就是不會有時間做啦 😆 </div> ^{2 原本的 Markdown 是用 perl 做簡單的文字取代 </div> ^{3 所以說 test coverage 很重要！ </div>}}}

`心得</h3> 這次除錯讓我體會到，問題有時不在應用層，而在系統與舊有 API 的相容性設計。透過逆向工程與底層探索，雖可突破限制，但也需承擔維護風險。期待未來能有公開 API 支援此類設定。▞</p>`

安裝新的 SSD</h2>
按照 System76 網站上的 維修手冊</a>就可以輕鬆安裝。</p>

傳統的 Session</h2>
</p>
使用者認證後伺服器傳回一個 session ID，之後伺服器可以用此ID查訊使用者資訊</p>

結論</h2>
Don’t use JWT for persistent, long-lived data.</p>

kanru's blog

Scoped Error in Rust

處理 Imm32 與 TSF 的相容性問題

開箱 Framework 13 吋 DIY 版筆電

回顧用 Rust 重寫新酷音的經驗

網站搬到 HostHatch

IBus Chewing 更新

2024 年的專案計畫

cdb2-rs</h2>
把這個 fork 的 library 整理一下釋出新版本</p>

ibus-z</h2>
用 zbus 寫一個 ibus 的 wrapper library</p>

ibus-chewing</h2>
更新 ibus-chewing 到 GTK4</p>
推動 Fedora 把繁體中文的輸入法改回 ibus-chewing</p>
用 Rust 重寫 ibus-chewing，需要 chewing 0.8.0 以及 ibus-z</p>

MuPDF</h2>
Update the Debian package to build shared library by default.</p>

Fedora 上使用硬體加密的 SSH 與 PGP

用 podman-kube 來跑 WordPress

用 systemd 管理 podman containers

Fedora Silverblue 新增硬碟到 Btrfs 陣列

2022 十月箱根旅行

加入 Fediverse 聯邦宇宙

回頭用 WordPress 寫部落格

桔梗種植的第二年更新

桔梗花的種植與照顧

JSON Web Tokens 研究筆記

簡單把 CSS 變成非同步讀取

CSS Text 3: Segment Break Transformation Rules

CSS 文字級別 3：段落分隔變換規則

kanru's blog

Scoped Error in Rust

處理 Imm32 與 TSF 的相容性問題

心得</h3> 這次除錯讓我體會到，問題有時不在應用層，而在系統與舊有 API 的相容性設計。透過逆向工程與底層探索，雖可突破限制，但也需承擔維護風險。期待未來能有公開 API 支援此類設定。▞</p>

開箱 Framework 13 吋 DIY 版筆電

回顧用 Rust 重寫新酷音的經驗

網站搬到 HostHatch

IBus Chewing 更新

2024 年的專案計畫

cdb2-rs</h2> 把這個 fork 的 library 整理一下釋出新版本</p>

ibus-z</h2> 用 zbus 寫一個 ibus 的 wrapper library</p>

ibus-chewing</h2> 更新 ibus-chewing 到 GTK4</p> 推動 Fedora 把繁體中文的輸入法改回 ibus-chewing</p> 用 Rust 重寫 ibus-chewing，需要 chewing 0.8.0 以及 ibus-z</p>

MuPDF</h2> Update the Debian package to build shared library by default.</p>

Fedora 上使用硬體加密的 SSH 與 PGP

用 podman-kube 來跑 WordPress

用 systemd 管理 podman containers

Fedora Silverblue 新增硬碟到 Btrfs 陣列

2022 十月箱根旅行

加入 Fediverse 聯邦宇宙

回頭用 WordPress 寫部落格

桔梗種植的第二年更新

桔梗花的種植與照顧

JSON Web Tokens 研究筆記

使用 JSON Web Tokens 的好處</h2> 可以容易的橫向 scale</li> 維護更容易(沒有需要長期儲存的資料)</li> 跨 Domain RESTful API (不需要 CORS cookie)</li> 可以設定 Token 的有效期限</li>

傳統的 Session</h2> </p> 使用者認證後伺服器傳回一個 session ID，之後伺服器可以用此ID查訊使用者資訊</p>

常見問題</h3> 需要資料庫統一儲存登錄資訊</li>

把 JWT 或是 session ID 存在 cookie 的好處</h2> Browser 會自動把 cookie 包含在 header 裡面所以適合用來保護網頁的存取</p>

結論</h2> Don’t use JWT for persistent, long-lived data.</p>

簡單把 CSS 變成非同步讀取

CSS Text 3: Segment Break Transformation Rules

CSS 文字級別 3：段落分隔變換規則

`心得</h3> 這次除錯讓我體會到，問題有時不在應用層，而在系統與舊有 API 的相容性設計。透過逆向工程與底層探索，雖可突破限制，但也需承擔維護風險。期待未來能有公開 API 支援此類設定。▞</p>`

cdb2-rs</h2>
把這個 fork 的 library 整理一下釋出新版本</p>

ibus-z</h2>
用 zbus 寫一個 ibus 的 wrapper library</p>

ibus-chewing</h2>
更新 ibus-chewing 到 GTK4</p>
推動 Fedora 把繁體中文的輸入法改回 ibus-chewing</p>
用 Rust 重寫 ibus-chewing，需要 chewing 0.8.0 以及 ibus-z</p>

MuPDF</h2>
Update the Debian package to build shared library by default.</p>

傳統的 Session</h2>
</p>
使用者認證後伺服器傳回一個 session ID，之後伺服器可以用此ID查訊使用者資訊</p>

把 JWT 或是 session ID 存在 cookie 的好處</h2>
Browser 會自動把 cookie 包含在 header 裡面所以適合用來保護網頁的存取</p>

結論</h2>
Don’t use JWT for persistent, long-lived data.</p>