2025年9月14日 星期日

橋接 UEFI 虛擬機, 2025 network manager 版

現在很少開虛擬機, 如果有, 也都是用 kvm -pflash ... 指令簡單用一下我的 UEFI 隨身碟。 今天需要讓區網裡的機器看見虛擬機, 所以必須開 virt-manager。 太久沒用, 都快忘記怎麼用了。 花了一小時挖出自己散落在好幾篇的舊設定, 終於慢慢想起來, 趕快記錄下來:

2025年9月11日 星期四

NotebookLM: 「太長太多了,讀不完」 的好幫手

某個主題的文件 TL;DR (太長太多了,讀不完) 嗎? 那就讓 NotebookLM (<==請先讀簡介文) 來幫忙吧! 這裡分享我的一個粗淺心得範例: 微軟強推 edge , 採用了哪些暗黑模式?

首先確認 「設定」=>「輸出語言」 是中文 (或是你要的語言)。

2025年7月25日 星期五

共筆維護試算表、地圖自動更新 - 大尺寸版

前一陣子跑去看 「國有器官」 認識 雄獅影視的管弄雲先生。 我主動建議幫他製作, 並且已經完成了: 「國有器官」放映地圖。 他們忙著更重要的事, 當然不可能請他們自己學會用 umap。 要讓他們能夠自己維護後續的新資料, 最簡單的方法就是: 我建一張 國有器官播放紀錄試算表 分享給他們, 然後我用程式把試算表的資料拉過去地圖上。 原本以為先前的 「共筆維護試算表、地圖自動更新」 可以直接拿來用, 後來才發現試算表太大 (大約超過 100 列?) 時會失敗。

2025年7月3日 星期四

終極通訊網路韌性: meshtastic

meshtastic 畫面與設定 日常生活中絕大多數通訊網路架構屬於 『star network』; 曾經火紅一時的 OLPC 以及今天要介紹的 meshtastic, 它們的架構則屬於 mesh network。 (請分別用這兩組關鍵詞做圖片搜尋。) 前者是中心化的架構: 有一些特別重要的節點 (例如各種伺服器) 如果停擺, 整個網路就跟著停擺; 後者則是去中心化的架構, 所以具有較高的通訊網路韌性。 可以用中共的統治架構 vs 香港「無大台」抗爭 的聯絡架構去理解兩者的差異。 (民主社會的 「國-州省-縣市-鄉鎮-村里」 架構幾乎也就是 star network, 但另外加上民意代表等等機制弱弱地稍微降低各層級中心的單點失敗風險。)

手上持有 meshtastic 裝置 (以下簡稱 M 機) 的人, 完全不需要靠現有的電信網路 (家中的有線網路、 手機或 SIM 卡分享器) 就可以直接跟鄰近的 M 友傳文字訊息。 從使用者的角度來看, 你可以把它想成是手機的硬體外掛裝置, 讓手機新增一個類似藍芽的功能, 但是它的連線速度超慢 (所以只能傳文字不能傳圖/影/音)、 距離超遠 (數公里到數十公里)、 沒有主從關係只有鄰居關係。

2025年6月23日 星期一

免註冊、尊重隱私、去中心化的即時通/語音/影像通話軟體: SimpleX Chat

設定個人暱稱 初次啟動 強化通訊韌性, 從 SimpleX Chat 開始! 我沒有辦法忍受 line 強烈的控制慾; 開放的 xmpp 一直很難推廣; 聯邦宇宙通訊協定 matrix 的 apps 用起來卡卡 (可能我沒有找到最好的 app; 但我覺得更像是因為 matrix 的帳號管理太嚴格) 於是我又做了一些研究, 包含詢問 ChatGPT, 最後找到這個目前心目中最理想的聊天軟體: SimpleX chat。 "It's FOSS" 網站上的 這篇文章 的作者覺得 SimpleX 比 Signal更棒 "SimpleX Chat is everything Signal should have been and more." 我完全認同。

2025年3月11日 星期二

共筆維護試算表、地圖自動更新 - 小尺寸版

想像一個團隊, 每位成員分頭去收集一些 (不涉及隱私或機密、 可以公開的) 地址, 要放到一張共同的地圖上面。 除了地址之外, 還有一些需要經常更動的欄位, 例如各地點的開放時間、 注意事項、 臨時公告等等。 什麼樣的工作流程會比較有效率呢? 我會開一張共筆的試算表, 例如 ethercalc 或是 google sheet, 裡面含有名稱、地址、經緯度、備註以及其他文字資訊等等欄位, 並且分享給所有成員, 然後把這張試算表餵給 umap 吃。 於是每當任何成員修改 [地址經緯度以外的] 其他任何欄位, 地圖瀏覽者只要重新整理網頁, 就會看到最新最及時的資訊。 至於經緯度, 可以透過 TGOS 手動批次更新。 編輯 google 試算表的門檻比編輯地圖低很多, 這樣的安排便於讓任何人都可以參與。

如果你的試算表較大 (超過100列?), 本篇可能不適用。 請跳到第三節見新版連結。

2025年2月13日 星期四

防止 gmail 信件誤入 「封存」 (archive) 黑洞

gmail 處處鼓勵你使用 「封存」 功能 gmail 處處鼓勵你使用 「封存」 功能 Gmail 的 「封存」 (archive) "功能" 令人困惑 (很棒的抱怨文), 例如: 你無法單獨列出「所有已封存信件」; google 也 堅持 不讓你很輕易地處理 「所有已封存」 的信件。

我自己呢, 因為覺得它很難用, 所以從來不會想要把信件封存。 可是很奇怪地, 每年整理信件時, 都會發現有好多信件莫名奇妙地被丟去「封存」, 包含一些早就應該刪掉的不重要郵件, 自己卻完全沒有印象。 但是就如前面所說, 我無法很簡單地列出所有已封存郵件, 只能從 「所有郵件」 裡面毫無線索、 一封一封費力地去判斷這到底是不是我真的想留下的信件。

2025年2月3日 星期一

把所有帳號的信件都接收到自己的伺服器上 (四): 郵件標籤/搜尋工具 notmuch

假設你已經 用 mbsync 之類的把郵件下載到自己的 linux 機器, 以 maildir 的形式儲存。 今天要介紹 debian 的 notmuch 套件, 它可以跟 neomutt 等等 MUA 搭配使用; 不過今天先只介紹在命令列上獨立使用 notmuch。

2025年1月10日 星期五

把所有帳號的信件都接收到自己的伺服器上 (三): 從 zimbra 匯出 csv 格式的通訊錄; 匯入 neomutt 與 posteo

延續 mbsync + neomutt + msmtp 這一篇, 接下來我想把 zimbra (使用多年下來系統自動建立) 的 「姓名 email」 通訊錄搬到 neomutt 跟 posteo。 先講心得: 過程當中用 csv 檔比較方便處理; 處理 vcf 檔的工具太少了。 反正最後要轉 vcf 很簡單。

2025年1月1日 星期三

2024年12月17日 星期二

把所有帳號的信件都接收到自己的伺服器上 (二): mbsync + neomutt + msmtp

為了維護資料自主權, 上一篇 我們測試 MS o365 的 xoauth2 登入。 我覺得那是最困難的部分。 接下來的部分有點囉嗦, 但並不困難, 如果遇到問題, 都很容易看著錯誤訊息, 搜尋或問 chatgpt 解決。 (困難的部分我已經幫你撞過牆壁,把心得寫進本文裡了。) 我們要用 mbsync 把所有的 emails 都抓到自己的伺服器裡, 採用 Maildir 格式儲存, 以利將來搜尋/用AI分析/存檔。 並且設好以後, 就可以用 ssh 登入自己的伺服器、 在文字模式底下採用 neomutt 跟 msmtp 閱讀與發送信件。

2024年11月23日 星期六

把所有帳號的信件都接收到自己的伺服器上 (一): oauth2

學校通知 zimbra mail server 要退役了; 寒假起要改用微軟 outlook。 一如 以往, 微軟的服務暗藏高昂的 下賊船的代價, 未來如果郵件都留在微軟的伺服器裡, 想要匯出的時候, 必須使用桌面版 outlook, 而且匯出的是微軟的專屬格式, 到時候你就會逐步地被吸入微軟黑洞。 我必須趕快學會定時用 IMAP 把所有的郵件抓回自己的伺服器上。 找到兩篇很棒的文章: Neomutt + isync / mbsync for Office365Local email from Office365 using OAUTH2 with mbsync。 這幾天先做一半: 學會用命令列進行 oauth2 授權。