Linux 上應用程式利用使用者資料夾的標準

整個 Linux 作業系統怎麼安排檔案系統，有 Filesystem Hierarchy Standard (FHS) 作為參考標準，在使用者資料夾 (Home directory; ~/) 的部分，目前主要應該都是參考 XDG Base Directory 來放。

使用者設定: $XDG_CONFIG_HOME (~/.config/)

使用者為應用程式做的偏好設定。

使用者資料: $XDG_DATA_HOME (~/.local/share/)

存放類似書籤、憑證、郵件、金鑰等使用者操作應用程式所得到或產生的資料，期待資料格式應具備一定程度的可攜性，使用者可能會想要備份這些資料。

應用程式狀態: $XDG_STATE_HOME (~/.local/state/)

存放像是執行紀錄 (log) 檔、最近存取資料的紀錄、視窗最後位置等，可以用在應用程式啟動時初始狀態的資料，使用者備份這些資料可能沒有太多意義。

使用者自行安裝的程式: ~/.local/bin/

各 distribution 應該自動的在這個資料夾存在時，把他加到使用者的 $PATH 環境變數中。

雖然沒有那麼常見，但最好可以考慮使用者資料夾可能會在不同處理器架構的主機間共用的情形。

規格中另外有定義一些環境變數，用來指定搜尋資料的順序。

在 WSL 2 上掛載 USB disk

如果要在 WSL 2 (Windows Subsystem for Linux) 掛載在 Linux 格式 (EXT4, XFS ... etc.) 的 USB 外接磁碟，可以先試試看這篇 Mount a Linux disk in WSL 2 說的方法，萬一不行再去試 Connect USB devices 的方式。

雖然第一篇說該方法針對的是內部儲存裝置，外接式裝置無法支援，但我自己在 Windows 11 (23H2; build 22631) 試是可以的。反而透過 USBIPD 的方式，因為 WSL 提供的 kernel 沒有包含 USB mass storage 的驅動程式，雖然 lsusb 看得到裝置，但是沒辦法掛載起來使用。

Markdown

目前都是基於 CommonMark 上面再去增加語法或限制，疊在 CommonMark 上面新增的規格稱為 extension。

Extension 在函式庫看起來作法大概是這樣:

1. 解析部份目前都是產生 AST 再去生成輸出，大概有兩種讓 extension 介入解析的方式:
   1. 讓 extension 實作註冊關注的字元，再去觸發解析與 AST 加工。
   2. 掃出來的 AST 整個讓 extension 實作再去解析與加工。
2. 完成 AST 之後再進行 render 來產生輸出，看起來多半是讓 extension 註冊處理所屬 token 型別的輸出函式，在 render 時呼叫來處理生成輸出的作業。

直接從 Markdown 產生 HTML 的方式因為比較難擴充的關係，即使有機會比較快，但現在看起來比較不流行了。

Ref:

• GitHub (GFM) 的規格: https://github.github.com/gfm/
• Visual Studio Code 用的引擎: https://github.com/markdown-it/markdown-it
• CommonMark: https://spec.commonmark.org/
• Go: https://github.com/gomarkdown/markdown
• Go: https://gitlab.com/golang-commonmark/markdown
• 規格的範例本身可以當成 test suite: https://github.com/commonmark/commonmark-spec
• 在 CommonMark.org 首頁提到的 test suite: https://github.com/michelf/mdtest
• Markdown Guide 有一些最佳建議實踐與常見的 extension 使用說明: https://www.markdownguide.org/
• GFM 規格發表公告，有說明所謂「移轉到 CommonMark 上」的背景: https://github.blog/2017-03-14-a-formal-spec-for-github-markdown/

Linux 上的 load average 怎麼解釋？

在 Linux 或是大多數的 UNIX-like 的系統上，系統核心 (kernel) 會提供一組稱為 load average 的值，用來反應系統負載狀態。

這組值原則上是基於工作佇列中的工作數量與工作特性權重去計算出來，可以說是在等待資源中的工作數量，系統會提供 1, 5, 15 分鐘的平均值。

以 Linux 來說，納入考量的資源包含了處理器、被分頁置換的記憶體、儲存設備、網路介面等等，因此在 Linux 上 load average 可以說是一個綜合性的指標，可以相當程度的反映出程式分享設備資源的狀況。

舉例來說，如果這個值是 2.00 的話，可以想像成有兩個工作正在等待資源，換句話說，這些等待中的工作所需要的資源目前是完全使用中的。

系統中多半會有許多程式在運行，他們會因為程式本身設計的目的使用不同的資源，因此 load average 也一定程度可以反映出工作組合在特定主機設備上的狀況。

比如說，如果主機上的工作是類似資料庫或是需要大量存取檔案的應用程式，由於儲存設備相對處理器與記憶體多半是相對慢的，工作勢必是需要做一些等待來得到資料，所以在偏高的 load average 下整體而言還是可以有不錯的處理能力 (throughput) 表現。

但如果是使用處理器為主的應用程式，那麼偏高的 load average 就意味著有工作在進行單純的等待，在這個情況下如果處理能力不符合需求的話，可以考慮是不是做一些硬體資源的調整來提升處理能力。

利用這樣的特性，我們也可以透過監視 load average 來偵測到系統的工作組合是不是發生了變化。比如要是遭到了勒索軟體的入侵，由於勒索軟體會進行大量的儲存裝置操作，那麼 load average 就會衝到比平常還高的數值上。

Ref:

• Wikipedia: Load (computing)
• Monitoring CPU Utilization on Red Hat Enterprise Linux
• Linux Load Averages: Solving the Mystery
• Linux 核心設計: Load average

Visual Studio Code 無法識別 PATH_MAX 或 realpath

利用 Visual Studio Code 寫 C/C++ 程式時，發現一些系統定義或是函數被畫了無法識別的紅色波浪 (red squiggly line) 在下面，但是真的編譯程式又會過。

原因是那些定義被放在 feature test macros (FTM) 的後面，當沒有特別給像是 -ansi, -std=c17 之類的參數時 gcc 預設會定義 _DEFAULT_SOURCE 巨集，因此編譯可以順利進行。但是 vscode 的解析器似乎是比照給了 -std=c17 之類的參數，因此這些 Linux 上特有的常數或函數定義就不會被抓到。

解決方法就是在 .vscode/c_cpp_properties.json 的 defines 區塊中，加上 _DEFAULT_SOURCE=1 或是 _XOPEN_SOURCE=700 來把 Linux 上的常數或函數定義納入。或是，為求慎重的話，也可以看函數的 man page 裡面所描述的 feature test macros 需求，來決定要怎麼設定。

Ref:

• vscode: c_cpp_properties.json reference
• glibc: Feature test macros (GNU C Library)
• man7: feature_test_macros(7)

Apache 的 name-based virtual host

在 Apache 上面 name-based virtual host 是指: 利用 Host: 這個 HTTP Header (標頭) 決定要用哪個網站組態設定來回應來自瀏覽器的請求。

從 Name-based Virtual Host Support 這篇文章看起來，現在 Apache 建議無論如何就設定 <VirtualHost> 就對了。

搜尋 request 要用哪個 <VirtualHost> 處理時，會先看 request 所連線的目標 IP:Port 組合，先把有 match 到的部份最精確 (exact match) 的設定挑出來，當有多個設定相符時，會進去看 ServerName 來比對。

用 Host header 比對 ServerName 時，雖然 Host header 可以攜帶 Port，但是比對時會被忽略，只會使用瀏覽器連線時的目標 Port 進行比對。

Ref:

1. Name-based Virtual Host Support
2. VirtualHost Examples
3. An In-Depth Discussion of Virtual Host Matching

Podman 清除建置失敗的殘餘容器資料

使用 podman build 建置容器時，建置失敗的中間容器會被留下來，而且不會被 podman system prune -a 清除。

$ podman system prune -a
WARNING! This command removes:
	- all stopped containers
	- all networks not used by at least one container
	- all images without at least one container associated with them
	- all build cache

Are you sure you want to continue? [y/N] y
Error: Image used by fbcfbb...7e8: image is in use by a container

這個原因看起來是因為 podman system prune 清除的對象是 Podman 本身產生的資料，而 podman build 背後是透過 Buildah 來進行建置，而這部份就不被認為是 Podman 的直接行為。細節可以參考在 #7889 Failed to remove image, image is in use by container 這個 Issue 裡的描述。

處理的方式就是手動刪除，先執行 podman ps --all --storage 把所有的容器列出來，再用 podman rm 刪掉。

$ podman ps --all --storage
CONTAINER ID  IMAGE                                      COMMAND     CREATED      STATUS      PORTS       NAMES
b396d84310a4  docker.io/library/ubuntu:16.04             buildah     10 days ago  storage                 ubuntu-working-container
fbcfbbc3c233  docker.io/library/bd7139...bed-tmp:latest  buildah     10 days ago  storage                 793b78...79a-working-container
$ podman rm b396d84310a4 fbcfbbc3c233