雖然很久沒更新部落格了，但這段時間我偶爾還是會搜尋一下我先前寫過的文章，主要是裡面也放了一些重要的筆記。有一天我發現我再也無法在 Google 搜尋到了，才驚覺到我的網站居然被 Google 移出索引！？沒關係，順便來整理一下。
自從我知道 GDPR 這玩意以後，我對 Google Analytics 的使用就開始有了疑慮。雖然我也很想幫我的網站開營利，但我知道我這個小網站賺不到什麼錢。既然都無法賺錢，我希望我的網站本身對使用者隱私是非常友善的，不會有討人厭的廣告與追蹤行為，至此我開始搜尋一些 GA 的替代方案，最後我選擇了 Cloudflare Web Analytics。
現在這個部落格支援 Dark Mode 了！看看網站的右上角，應該會有個太陽或月亮的圖示，點擊就可以切換。我本身對前端並不熟悉，這次的 Dark Mode 全靠 Chatgpt 協助完成，前前後後也花了兩個多小時，過程中也有許多驚喜與反思，這篇文章就來記錄一下整個流程及一些心得。
fio 是一個好用的合成 IO (Synthetic IO Workload) 產生器，我們經常用他來測試例如檔案系統或是 Disk 的 IO 效能等等，他有非常多可調參數，很多時候我們只是複製了某測試的參數就打，這在大多數情況可能是夠用的，但身為一個優秀的效能分析者，我們還是必須要知道 …
kprobe 是一個輕量的 linux kernel 的除錯工具，他可以在不重新編譯核心的情況下追蹤一個函式的呼叫以及回傳，相當方便。kernel 內目前提供了三種類型的 probe，分別是 kprobe、kretprobe 以及 jprobe，三者都是基於類似的原理所實現的。
詳細的技術原理 … 我也沒弄得那麼清楚 😜，有興趣的可以去看核心的技術說明手冊，會比我介紹清楚得多，這邊只簡單介紹好用工具。
前一陣子有追蹤一個 ARM 平台發生 Kernel BUG_ON 的問題，在同事的協助下花了一點時間終於追出可能的原因。在我剛開始接觸 Linux Kernel 時，遇到這類 log 都很不知道該如何下手，累積了一些經驗以後才慢慢知道該如何切入、分析及找出原因。
這篇會分享實際分析 Kernel Oops log 的過程，以及相關工具的使用方式做為案例分析給各位參考。
相較於其他程式語言，C++ 的函數參數傳遞方式有很多種方法，如傳值(value)、傳址(address/pointer)，及傳參考(reference)等，再加上 const 修飾詞後又有不同的變化。
C++11 引入的 unique_ptr 及 shared_ptr 等智慧指標，也同樣有傳值或傳參考等方式。雖然很多手段都可以達到相同目的，但如果透過傳遞方式的不同，就可以表現出函數設計者想傳達的「語意」，那一定會是比較好的設計，同時好的設計也能借助編譯器的輔助來降低程式出錯的機會。
針對各種不同需求及使用情境，這篇整理我蒐集到的建議實作方式，主要源自於 C++ Core Guideline，提供給各位參考。