最近在清理我放在瀏覽器裡面的書籤，搭配最近架設的 Homelab ，以下是我的 SOP：
RSS feeds for your Github releases, tags and activity. Retrieved 2025-04-28 from https://medium.com/@vilcins/cbda2c51373 ↩
最近在自架 RSS 訂閱器，目前是使用 Tiny Tiny RSS，不過這裡還是把當時查資料時的其他候選方案簡單列一下。
最近在建置自己的 Homelab，入口網站或儀表板 (Dashboard) 的方案其實不少，我自己目前是使用 Dashy，不過這裡還是把當時查資料時的其他候選方案簡單列一下。
選擇 Dashy 沒有什麼特別的理由，就是星星數夠高、畫面簡單以及仍然保有擴充的潛力，這裡是它支援的資訊欄 (Widget)。
最近在自架專案管理的工具，目前是使用 Vikunja，不過這裡還是把當時查資料時的其他候選方案簡單列一下。
Planka 明眼人都看得出來它是衝著 Trello 去的，因此作為一個「Kanban 本位主義」的專案管理軟體，使用案例著重在看板本身，對於卡片 (Ticket/Issue) 的管理就稍微薄弱，比如沒有人類友善的流水號可以辨別卡片。
OpenProject 則是側重卡片管理，可以堆疊巢狀結構也可以建立關聯，但是 UI 顯得比較老氣一點。
Wekan 和 Planka 一樣屬於「Kanban 本位主義」，可以從設定啟用人類友善流水號，不過對於卡片管理的功能比較缺乏，巢狀堆疊的設計不是很理想，而且沒辦法建立其他卡片關聯。
今年 SITCON 之後又多了兩條掛繩：
突然想到我的睡褲前一陣子洗衣機幫我打死結只好剪掉，所以剛好少一條繩子，心動不如馬上行動。
因為一條的長度不夠，只好把兩條接在一起當一條用：
畢竟很少縫東西，縫得很爛：
噹啷～多出來的繩子困擾跟少一條繩子的需求互相湮滅了～
週末買了 RPG Maker MV，然後不出意外的出意外了（Linux 使用者日常）：
Check failed: InitDefaultFont(). Could not find the default font
先講結論 RPG Maker MV 不管目標平台是什麼，都是輸出成 NW.js 程式，而 RPG Maker MV 內建的 NW.js 樣板版本太舊：
./nw --version
nwjs 65.0.3325.146
這個當下 (2025-03-26) 最新的 NW.js 是 0.97.0，照著網路上查到的資料1，從 http://nwjs.io 下載 Normal 和 SDK 並且放到 ~/.steam/steam/steamapps/common/RPG Maker MV/ 之類的路徑下就能解決了：
/nwjs-lnx
/nwjs-lnx-test
兩者的差別是在編輯器按「測試」執行跟「發布」執行。
NW.js 一個類似於 Electron 用「寫網 頁的方式製作桌面應用程式」的工具，不過兩者實做的方式不太一樣，我先不在這邊做比較。
NW.js 專案提供了一個 nw.exe 執行檔（和一些動態函式庫），而這個執行檔就像是 Chromium 和 Node.js 的奇美拉，只是 Node.js 會去找 app,js 而 nw 會去找 index.html 來執行，看似跑在 Chromium 瀏覽器上卻又能解析 Commonjs 的 require() 和 Node.js 的核心模組。發布應用程式的時候就是把 nw.exe 和 Javascript 以及其他網頁 assets 打包給使用者。
另我驚訝的是當輸出專案時，所有在編輯器完成的調整都會變成 JSON 組態，遊戲程式則是 Javascript 明碼，連混淆都沒有！我甚至可以直接看到它繪圖的基礎是使用 PixiJS 完成的。雖然程式碼裡面充滿了 prototype 之類的古早味語法就是了。
[LINUX/MV 1.6.2] Fresh Install with new project and play test button doesn’t work :: RPG Maker MV Tech Support. Retrieved 2025-03-26 from https://steamcommunity.com/app/363890/discussions/1/2653116024334677568/#c2653116235598796183 ↩
網站減少的原因之一是，網站存檔舊內容在技術上很困難，成本也很高，這個問題不僅僅是在中國才有。
上個週末整理書籤，發現大概死了 25% 的連結，另一方面發現有一些看起來比較「傳統」的網站雖然還活著，可是反過來說，我現在 Google 也很少搜尋到這種網站，感覺老網站死掉是一回事，然後被 SEO 過濾掉是另外一個問題。 P.S. 有些書籤是 10 年前左右加的
本文可能觸及敏感的社會議題或現象，目的是提出一種看事情的角度，並無針對特定族群冒犯之意。
作為一個理工死宅男，我想做機器人妹抖 (Maid)。
事後整理了一下思緒，我想一切的起因來自這則貼文：
https://t.co/QcYEAUBqBV pic.twitter.com/kLkziAlPVj
— jet (@natwjeq) February 20, 2025
這個貼文包含了兩個實體：Clone 和足立レイ，等等我會稍做解釋。
關於足立レイ的具體資訊可以從萌娘百科了解，簡單來說它是一個 ACG 圈的原創角色，然後作者有愛到造了一個等身大小的機器人。可以在作者的 Twitter 帳號 (@missile_39)看到各種關於足立レイ的貼文，並且機器人看起來被安置在一個像是電子實驗室的空間中。
另外一件事則是前幾天 (2025-02-20) Clone 發布了一支影片：
Protoclone, the world's first bipedal, musculoskeletal android. pic.twitter.com/oIV1yaMSyE
— Clone (@clonerobotics) February 19, 2025
內容就是一個神似 Westworld 中的機器人被吊著抽搐（？）的畫面。
對於 Clone 不熟悉的讀者，我這邊稍微介紹一下，Clone 在研發"仿生機器人"的方向與主流機器人公司不同的地方在於它們是在基於人類骨骼的骨架上附上基於液壓的仿生肌肉來製作機器人的肢體，而不是直接「把基於電機的機器關節打造成人形」的形式，後者是包含波士頓動力和 Tesla Optimus 等知名公司製造人形機器人的方式。
對於 Clone 的貼文，大部分留言的反應是感到不安，一來是 Clone 的配樂有意的製造驚悚的氣氛，而「像人一樣的肢體抽搐」更是命中了不少人的恐怖谷，更有人批評「開發團隊甚至不能讓它做出有意義的動作，只是讓特定的組件做動而已，這裡沒有新聞」。
事實是，足立レイ的貼文出現在我的 Twitter 動態牆上時，大部分都是坐在椅子上的擺拍，它的本質就像一個二次元角色的巨大手辦而已，對於這些貼文我的心態大部分是嗤之以鼻的。
另一方面，一些 Clone 更早的影片中，那栩栩如生的手臂確實 讓不少人感到驚豔，不過背景的噪音透漏的是旁邊有一組體積異常龐大的驅動裝置在做動1：
因此不論 Clone 在鏡頭前呈現多少東西，只要開發者沒有辦法微縮化那坨液壓驅動系統，就不可能實現真正意義的實用化人形機器人。
不過話說回來，挑別人毛病容易，我呢？作為一個想開發類似的東西後進者有沒有因此學到什麼？
讓我們來想像，起點是空無一物；終點是實用化的人形機器人，那麼中間的過度狀態是什麼？我該如何設定階段性目標 (milestone)?
實用化人形機器人理論上應該具備自然人的大部分能力，因此如果我把問題反過來思考會發生什麼事？起點是自然人；終點是死物。
我們會發現這是一個失能 (Disable) 的過程：從一個功能完全正常的人，經歷輕度、中度、重度、極重度殘疾直到不再被承認為活物。
採用這個視角看待問題會有一個好處，那就是殘疾這件事是已經被經過系統化討論與歸納的主題，各國對於殘疾等級都有一定的規範與定義，作為開發者在這個問題上就不太需要重複造輪子去定義中間的過度狀態了。
接著我們再把這個人類失能的過程反過來看，變成賦能 (Enable)，從死物、極重度、重度、中度、輕度殘疾到正常人，就是一個實用化人形機器人的開發路徑了：
Strongest Biomimetic Hand in the World - Clone (V16) - YouTube, https://www.youtube.com/watch?v=lGnSQbEzI9s ↩
說到人形機器人，不少人或許會想到波士頓動力或是 Tesla 的 Optimus，不過我這邊想聚焦在「自製」這一個範疇。想要自製人形機器人的人，我不是第一個，也不會是最後一個，例如：
這些創作者往往較著重於頭部與手部，或是由外而內的方式去模仿人類的外貌，不過對此我有不一樣的看法，分別從幾個角度切入。
.gif)
皮質小人是以大腦皮質層功能區對應的比例來繪製的人類，並且分成運動小人（motor homunculus）與感官小人（sensory homunculus）兩種。
私以為這是一種對於「實做人類複雜度」的暗示與視覺化，在皮質小人中比重越大的器官代表需要更多、更複雜的運算能力，因此在有限的預算內，應該優先迴避這些可能需要高研發成本的部位，又或是對這些部位做謹慎的預算控制。
Mimic 是一部 1997 年上映的科幻驚悚電影。
下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透 ，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。 下方可能有劇透，請讀者斟酌瀏覽。
在這部電影中，基因改造的蟑螂發生了變異，可以長到 2 公尺高，並且成為了人類的狩獵者，而且演化出透過外殼模仿人臉的擬態能力：
對我而言使用硬質材料作為外殼（框架）的人形機器人，都像是模仿人類外型的外骨骼偽物。
作為工程師，想要建造一個東西的時候第一件事情是什麼？絕對不是閉門造車，而是先看看競品長怎樣，然後能抄多少就抄多少。
那麼人形機器人的競品是什麼？當然就是人類本身。畢竟這個「設計」可是經過萬年迭代演化而來的，每一吋規格都得有個幾分道理。
所以我認為「研究人形機器人的競品」這一件事情應該是走向醫學系學生走過得路：學習解剖學。接著才考慮「在不丟失現有 Feature 的情況把設計從有機的 techstack 遷移到基於電機的 techstack 去」。
上下文 (Context) 在軟體工程是一個很常見的概念，它所代表的是：
某個詞（變數）在當下在當下的語境（區塊）代表什麼意思？
比如說，當我們在日常對話提到「蘋果」，可能指的水果的蘋果，也可能是科技公司的那個蘋果。電腦的呆板促成程式碼的嚴謹性造成我們在程式碼使用某個變數的時候，必須明確的告訴電腦這個詞對應的是什麼具體的東西，沒有模糊空間。
然而自然語言對話卻不是這樣運作的，兩個工學院學生談論「傑森」的時候，可能是指 JSON (JavaScript Object Notation) 也可能是指 NVIDIA Jetson，對話有時候能奇妙的繼續下去，直到有人察覺哪裡怪怪的。
又或是雙方對於同一個詞有不同 的見解，讓對話陷入鬼打牆，因為每個人都想用自己的詮釋描述，這種情況我認為最好的解決方式是向程式語言取經：建立命名空間，用「小明::蘋果」和「小美::蘋果」分離兩種定義，在不否定任何人的「蘋果」的前提下，讓對話繼續下去。
接著來到我昨天 (2024-11-02) 花了一天溫吞的學習骨骼名稱的過程，讓我想到我們在義務教育的歷程中，有著不少的「背科」。以我正在學習的解剖學來說，每一個骨頭都有自己麼名字：
如果每個人能夠以自己的方式理解每一個物件，其實根本不需要背這些東西，但是事實是在社會之中人與人需要互相合作，就需要透過語言或文字來傳達概念，而這些被定義的名稱能夠在溝通的時候精準定位特定的物件。
工程師在面對問題的時候往往也沒有太多的模糊空間，M4 螺絲就是 M4 螺絲，CLK 跟 VCC 就是不同的接腳；在這一點上，醫學和工程或許沒有太多差別。而這些教科書 (Textbook) 本質上的作用就是幫人們同步上下文 (Context)。
（看著西方的 Woke 運動）當一個社會的 Context 沒辦法達到一定程度的共識，那又是另外一個話題了。