• 經過 12 年多,EPGrab 再度更新

    前情提要:〈EPGrab,把 DVB 數位電視的 EPG 電子節目表輸出成 XMLTV 格式

    因為經濟上的困境,自己開個小公司,做什麼都不成,最近還蠻常陷入重鬱狀態的。為了緩解,就把一些過去累積的,想做而未做、做到一半只求驗證概念可行的專案與想法,拿出來整理。

    EPGrab 是其中之一。

    這次改版,以 Rust 重寫,借助 Rust 語言本身的語彙與表現力,把整套程式翻新過:

    • 內建 Zap 格式的頻道設定檔掃描機能(`scan-channels`)。能夠獲取其他類似程式所無法正常處理的頻道名稱文字編碼 (character encoding) 的 channels.conf。
    • 修掉了控制字元沒妥善濾掉的老問題。
    • 內建一個微型的 HTTP server,可以把擷取到的 EPG 資料檔直接上網,並用 XSLT 轉換為 HTML,便利直接瀏覽。順道一提,行文當下,Google Chrome 正策劃要因噎廢食地移除 XSLT 支援,看了只想說:「這就是市場一家獨大後的樣子,大家高興了吧?」
    我是一份看起來像 HTML 的 XML 文件呦!是 XSLT,我用了 XSLT。

    雖然在 12 年多之前,認識的人就已經很少人在收視無線數位電視了,然而這段時間以來,無線數位電視網也變了不少,除了廣為眾人所知的中視被旺旺買了,台視被非凡傳播買了這些已知的民營化;公視多了台語台、兒少台「小公視」;原住民族電視台在無線數位電視播送;然後多了兩台國會頻道,還有主要以英語製播節目的 TaiwanPlus 頻道。整體來說,有量變,有質變,算是很兼顧多元聲音的組成。

    與此同時,有線電視隨著頻道商經營不易,一個個搞消失,轉向自有的網路串流服務,也變得愈來愈難找到好節目收看了。

    身為一個電視兒童、電視少年、電視青年、電視阿伯,小時候的我,讀世新時的我,從沒想過電視這種媒體會變得 doesn’t matter。

    那為什麼還要在意這個程式專案呢?因為我還是相信,無線數位電視裡仍有不少好節目值得「更早」被發現,而不是到了每年金鐘獎,看了入圍與得獎名單,才知道原來有一個這麼好的節目。且因為傳媒生態的變化,廣告預算下給電視的比例,呈現一路在變少的趨勢,進而造成節目製作預算與成本回收狀況愈來愈窘迫,有些節目就算得了獎,也只此一季,難以為繼。於是故,我覺得好的節目在首播當下,愈多人收看,總的來說,是件好事。

    🔭聯邦宇宙對此表示:

  • 樸實注音鍵盤 3.6.9 版釋出

    自從 3.4.5 版後,改了一些地方:

    • rustup 去讀 rust-toolchain.toml 自動安裝所需的 Rust toolchains。
    • 精簡模式(使用硬體鍵盤模式)會顯示目前的全形、半形狀態。
    • 更改切換至其他輸入法編輯器的組合鍵,從長按 Alt 改為 Alt+I。
    • 把使用硬體鍵盤模式的選項整個幹掉,改成自動偵測。
    • 從 Google Play 下架。
    • 修正〈deGoogle – 替換鍵盤〉一文作者指出的逗號鍵功能失效問題。
    • 把「Dvorak 許氏」軟鍵盤整個拔掉,只保留支援硬體鍵盤,連帶將新酷音函式庫支援的各式鍵盤,都順便實作到硬體鍵盤支援列表裡。軟鍵盤現在只支援傳統大千、(QWERTY) 許氏、倚天 26 鍵、倚天 41 鍵。
    • 支援 Unihertz Titan 2 這款內建硬體鍵盤,但是又不是那麼完整的排列的機種。讓 QWERTYUIOP 列入候選字詞選擇鍵組,並讓音量增減鍵用於切換候選字詞前後頁。

    🔭聯邦宇宙對此表示:

  • 解決 rtkit-daemon 一直吐 “Supervising m threads of n processes of o users.” 的 logs

    剛剛把 journalctl -f 掛著觀察系統有沒有什麼地方需要維護的,發現 rtkit-daemon 一直吐 Supervising m threads of n processes of o users. 的 logs 洗版面,有點惱人,找了一下解法:

    1. sudo systemctl edit rtkit-daemon.service
    2. 覆寫 [Service] 段,新增一條設定 LogLevelMax=2。記得要寫在 ### Edits below this comment will be discarded 這行的上方,不然是不會存入變更的,我犯了這個蠢。
    3. sudo systemctl daemon-reload
    4. sudo systemctl restart rtkit-daemon.service

    這樣 log level 小於 2 (critical) 的就不會輸出。

  • 接上 Sony Xperia Z3 Compact (D5833) 的 Serial Console

    之前試著將這台 Xperia Z3 Compact (D5833) 刷寫 postmarketOS,刷機過程雖然順利,然而當 postmarketOS 開機畫面閃過之後,便是無消無息的黑色螢幕。我大概可以猜到這是很典型的卡在 initrd 或 kernel 某個地方,但是確切是什麼地方,還是得想辦法查得,不然我原本想要有一台 postmarketOS 的實機以方便開發上面的應用,就無法如願了。

    還好某段時期的 Sony Xperia 對開發者很友善,該提供的技術文件、bootloader 解鎖服務、UART 接點都公開給開發者利用(撰文當下的 2025 年,Sony Xperia 似乎已經不再這麼積極推動這項 Open Devices 專案了),我的 Xperia Z3 Compact 就在這段時期的產品線裡,可以輕易獲知如何透過 UART 接上 serial console,取得非常早期的開機時資料。

    Xperia Z3 Compact 的 UART 接點,取自 https://developer.sony.com/open-source/aosp-on-xperia-open-devices/guides/access-uart-ports

    GND 是還好,但是 Rx 與 Tx 的焊點真的很小,不使用 OK 線的話很難焊上去。

    此外,板子提供的 UART 邏輯電源電壓是 1.8V,所以還要找支援 1.8V 的 USB-UART 轉接介面。

    現在已經確定能夠在原裝的 Android 系統、從 serial console 獲取非常早期(從 S1 BOOT 開始)的開機時資料,接著要再度刷成 postmarketOS 看看當初是卡死在什麼地方。

    🔭聯邦宇宙對此表示:

  • 裝了一張 RTX3060 GPU

    雖然已經是隔了兩代的舊產品,但是我因此勉強能負擔(除了 GPU 我還得連帶買一顆足瓦的 PSU);且 12GB VRAM 雖然比上不足,比下仍多了些餘裕。

    原本我覺得租用 Google Colab 比較省事,但是以我的資料量,Google Colab 不但 GPU/TPU 額度消耗的快,那種在遠距操作下不夠順暢的體驗也不甚好,於是我還是想要回到自己的機器上設置一套機器學習的環境。

    硬體裝好後,開機卻沒辦法進 display manager(我使用 SDDM),原本以為 nouveau 應該是至少基本能用。無奈只好重開機進 single user mode (aka recovery mode),然後參考 Debian Wiki 安裝 Nvidia 釋出、但由 Debian 打包 dpkg 的驅動程式。

    裝好之後 SDDM 終於能正常顯示了,然而進 KDE Plasma Wayland session 會有嚴重的遲頓現象,唉,只好再退一步,捨 Wayland 回去使用 X11。

    接著又發現 TensorFlow 與 PyTorch 找不到 GPU/CUDA 裝置,原本以為是 CUDA 版本過舊,但是折騰了一個晚上後,才發現是 nvidia_uvm kernel module 沒有載入的關係。

    執行 nvidia-smi 查看 NVIDIA System Management Interface 資料後,會發現 nvidia_uvm 被載入了,TensorFlow 與 PyTorch 也因此能找到 GPU/CUDA 裝置。

    但是每次都要手動執行 nvidia-smi 也太惱人,於是新增 /etc/modules-load.d/nvidia-uvm.conf 把 nvidia_uvm 列入,讓它能自動於開機時載入。

    2025.11.23 更新:因為執行 apt upgrade 時更新了 kermel 版本 6.17.8+deb14-amd64,結果 linux-headers-amd64 與 nvidia-open-kernel-dkms 不知怎麼地爛了,DKMS 無法編出給這個版本的 kernel modules,乾脆改用 NVIDIA installer 安裝驅動程式 580.105.08。

    🔭聯邦宇宙對此表示:

  • 說說我對 Google 此次處理 Android App 要求「全境實名驗證開發者身分」政策的不滿

    Google Play Protect

    在這個 AI 大瘋潮時代,Google 大可使用更好的威脅偵測模型去處理惡意程式的問題,去加強他們現有的 Google Play Protect 防禦能力。

    這在古早古早 DOS 時代的防毒軟體像是 ZLock, Tracer+ 就已經採行「偵測異常行為,而不只是單純掃描病毒程式 pattern」了。

    當時礙於硬體能力,這些軟體大概也只能正面表列一些有限的異常行為態樣,但是表現就已不俗;如今即使一台入門級的手機,CPU 運算能力也遠遠超過那些老 PC,還加上可以透過網路協助處理。但是 Google 他們在此處不用人工智慧,而用工人智慧,企圖把技術責任轉移為法律責任。

    這難道不諷刺嗎?

    要上架 Google Play,你原本就要註冊、繳費、驗證開發者帳戶,這像是進駐市集、百貨公司做生意,合理。

    但是現在這個「全境實名驗證開發者身分」卻要求你即使不在 Google Play 上架,你還是要註冊、繳費、驗證開發者帳戶(把你的官方身分證明、法定地址證明都交出來,視情況還會公開揭露),然後你 build 出來的 APK 還得要用 Google 發出的憑證簽署,不然就無法在用戶的手機上安裝。

    Google 聲稱這樣以身分驗證要求可以減少惡意程式散布、危害使用者;但是誰來跟我說明一下,我身為開發者,誰來保護我不被瘋狂用戶騷擾、威脅?

    且你相信赫赫有名的大公司(姑且想成更注重商譽),就不會在其 App 產品裡作惡?

    或是你覺得在 App 裡不慎用了一隻懷有惡意的第三方套件,出了包,是 App 作者存心如此?

    再說一次,把技術責任轉移為法律責任,這樣真的很荒謬。

    🔭聯邦宇宙對此表示: