文章列表

Bandai小比列高達模型的危機
手機‧電玩
MacauYeah・2026-02-27

筆者去年就分享了一系列自己機械人模型的制作經驗,大部份都被Bandai的小比例高達所主導。其中一個原因,是因為動畫的加持,令到每台高達在筆者心中,都有一個神聖的地位。 而其有一兩款國模原創系列,品質是好的,就只是少了一份共鳴。這令筆者覺得,其實中國的開模技術及制作誠意,是不是已經超越了Bandai?所以筆者買一台外型是高達模型的高仿拼裝產品回來做個對比,在拼完之後,實在令筆者覺得Bandai是有意放任做好小比例模型的市場。 結論講在前頭 筆者反對盜版,盜版是需要付上版權責任的。如果Bandai肯借出舊的高達IP,讓有實力的第三方開模,那怕賣貴一點,Bandai單純抽成,都是可以接受的。這樣Bandai不需要考慮開模成本,就可以把舊模持續更新,那就Bandai 、玩家、第三方都可以win win win。 Bandai小比列高達模型的現況 雖然1/144的分支裏面,Bandai已經有EG/HG/RG三種選擇,但對於玩家來講,都不太有誠意。EG可動差,易斷,HG其實水口外露很嚴重,在不打磨的情況下,很多地方都有白刺刺的水口,RG就是件太細,一有不慎就發生悲劇。RG的外型最修長,但有時比人的感覺會是細節密集得過火了。 在筆者最近購入的那一台國產高仿中,讓筆者看到了不一樣的設計。它雖然沒有RG的細節,但分件做得比HG好。分色也比HG多,而且更多的分件,亦可以通過嵌套的方式去相互遮蓋水口。 隱水口現在基本是國模的標準配置,不論原創還是高仿。就那麼一點小事,其實HG也可以有,Bandai就偏偏不用在HG上。國模也不是全部隱水口,只在有需要的部份使用。筆者過去一年的Seed Freedom劇場版HG模型,就是總在手、大腿當眼處來個大大水口,看著有夠難受。 看著看著,筆者就會想,有些開模技術的事,不是Bandai不能做,而是不想升級舊模。新模雖有很大發揮空間,但它都選擇去挑戰新動畫設定(例如Gquuuuuux),為求衝一波人氣,就生產一堆新模出來。HG就是比例失衝的產物,夠快就好,反觀晚個半年推出的MR魂系列,比例都有所調整,基本都會好看些。 老實說,Bandai MR魂都能設計出來,其實也可以下放技術給HG用。那我們就不用受那些水口的拆磨了(筆者亦有想過,其實那些品質特別好的高仿,是不是就是把MR逆向工程,改為拼裝的?) 還是那個總結 筆者明白在商業上,需要衡量風險,Bandai延期的話,可能會錯失熱度,做得多好,也只會少賺了。但正如之前所說,把舊IP借給第三方廠,由它們是再重塑外觀、批裝結構、生產模具,Bandai只在抽成,應該大家都開心。現在即使沒有IP授權,高仿依然存在,如果只是因為IP問題,令到一些更優質的產品消失,實在是玩家的遺憾。 因為IP問題,封面圖是筆者今年制作的Bandai HG 新生命運,而非高仿。如果大家想知道是哪一台超越了它,可以再自行搜一搜相關關鍵事。

AI 寫Code,可以真的讓我們解放雙手嗎?
科技新知
MacauYeah・2026-02-27

用過AI查資料寫Code後,筆者的確覺得是比傳統自己Google更有生產力。但長期使用下去,我們又該如何看待AI的生成物?理想地,以Copilot的方式,靠著AI寫出人都能看得懂,當然很好。但如果AI 什麼都懂,就讓AI自己維護自己就好。 重點應該是實現持續發展 傳統上, 能動能讀,通常就代表可以持續發展。但如果只以AI來編寫,是不是可以AI自己維護自己的程式了? 現階段看來是不可能的,一來是因為現時AI的精準度未夠高,我們只少要介入讓AI知道正向或逆向反饋。只有我們才能了解自己的需求,我們才能好好地驗收。 二來,就是當一件事越來越複雜的時候,不可能三言兩語就可以精準地描述我們想要的功能。雖然可能大部份人會認為,我們可以很簡單地描述出需求,並讓AI通過自我修正,直到找到結果。但寫過需求管理的朋友都知道,好好表達需求並不容易,如果可以很詳盡地寫出規則,其實pseudo code都完成了。就像人類社會的管理層一樣,上司很簡單地提出一個概念,下屬去思考再執行。除非下屬就是上司本人,否則不可能對同一個概念有完全一樣的理解。用一個更極端的例子來講,我們不可能將資訊無限量壓縮,最後就只會得0和1這個二元分類,也就是一些概念不可能無限地精簡。 所以不論AI可以如何代工,都不會讓我們可以完全省力,特別是在寫程式這一塊。它是減少我們重新發明車輪的工具,讓我們可以更早地面對未解決的問題。 所以筆者認為,可以人腦好好地理解AI寫出來的程式,一定會比只讓AI自己閱讀自己寫出來的程式走得更遠。像以前查書一樣,千鿋年變成Google後,查找快了,資訊流動快了,但人始終要理解資訊。而現在經過AI後,一些重複的工作,可以變得更有效率了,可以迭代的速度,道理上可以更快了,但人始終要知道自己為了什麼目標而迭代。

架設 Squid proxy,作為國産 Linux RPM 安裝包更新的 RPM proxy
科技新知
MacauYeah・2026-02-26

前編我們介紹了 Qemu 運行國産OS做快速測試。應該基本使用大家都可以實驗到。 在投産環境上,我們通常還要控制它的kernel或lib版本更新,但這麼多的不同OS版本,想一次過做rpm mirror,並不太實際。 若以監管為目標,那些不同種類的OS,限制互聯網存取,統一經過某個http proxy的取得RPM更新,應該是一個最低成本的做法。 本文就來介紹一下,使用Ubuntu 24建設 Squid http proxy,達到rpm proxy的結果。 ubuntu 24.04 squid settings apt-get update && apt-get install squid vim /etc/squid/squid.conf 約在1404行,指定一個新的acl(access control list)名字,fixip, 它的允許來源IP是你的rpm base OS # around line 1404, add acl fixip src xxx.xxx.xxx.xxx 約在1627行, 放行新的acl # around line 1627, add http_access allow fixip rpm os settings 在rpm base的OS上,通常在 /etc/yum.repos.d/ 低下就找到它們的 rpm 包來源為置,在每個來源上加上 proxy 設定,就可以了。 Anolis OS 8 因為rpm來源眾多,我們只想讓其中兩個經proxy更新,例如 /etc/yum.repos.d/AnolisOS-AppStream.repo, /etc/yum.repos.d/AnolisOS-BaseOS.repo, 最在後加入 proxy=http://yyy.yyy.yyy.yyy:3128。 yyy.yyy.yyy.yyy 就是設了 Squid的機器 [AppStream] name=AnolisOS-$releasever - AppStream baseurl=http://mirrors.openanolis.cn/anolis/$releasever/AppStream/$basearch/os enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ANOLIS gpgcheck=1 proxy=http://yyy.yyy.yyy.yyy:3128 [BaseOS] name=AnolisOS-$releasever - BaseOS baseurl=http://mirrors.openanolis.cn/anolis/$releasever/BaseOS/$basearch/os enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ANOLIS gpgcheck=1 proxy=http://yyy.yyy.yyy.yyy:3128 OpenEuler 22 來源檔只有一個,/etc/yum.repos.d/openEuler.repo, 但內存多個section, 需要在每個section的尾段,加入 proxy=http://yyy.yyy.yyy.yyy:3128 [OS] name=OS baseurl=http://repo.openeuler.org/openEuler-22.03-LTS-SP4/OS/$basearch/ metalink=https://mirrors.openeuler.org/metalink?repo=$releasever/OS&arch=$basearch metadata_expire=1h enabled=1 gpgcheck=1 gpgkey=http://repo.openeuler.org/openEuler-22.03-LTS-SP4/OS/$basearch/RPM-GPG-KEY-openEuler proxy=http://yyy.yyy.yyy.yyy:3128 [everything] name=everything baseurl=http://repo.openeuler.org/openEuler-22.03-LTS-SP4/everything/$basearch/ metalink=https://mirrors.openeuler.org/metalink?repo=$releasever/everything&arch=$basearch metadata_expire=1h enabled=1 gpgcheck=1 gpgkey=http://repo.openeuler.org/openEuler-22.03-LTS-SP4/everything/$basearch/RPM-GPG-KEY-openEuler proxy=http://yyy.yyy.yyy.yyy:3128 ... ... [update] name=update baseurl=http://repo.openeuler.org/openEuler-22.03-LTS-SP4/update/$basearch/ metalink=https://mirrors.openeuler.org/metalink?repo=$releasever/update&arch=$basearch metadata_expire=1h enabled=1 gpgcheck=1 gpgkey=http://repo.openeuler.org/openEuler-22.03-LTS-SP4/OS/$basearch/RPM-GPG-KEY-openEuler proxy=http://yyy.yyy.yyy.yyy:3128 ... ... 指令 我們可以先用curl,來測試一下最基本的連線。請確保指令是在最初定義的xxx.xxx.xxx.xxx範圍內。 curl -v -x http://yyy.yyy.yyy.yyy:3128 http://mirrors.openanolis.cn/anolis/8.10/ 部份更新指令 由於我們前述 rpm 包並不是所有都加了proxy,我們只限定某些進行更新,所以我們使用--disablerepo --enablerepo來限制指定的更新來源。 # anolis dnf install --disablerepo='*' --enablerepo='BaseOS' 'tmux' dnf upgrade --disablerepo='*' --enablerepo='kernel-5.10' 'kernel*' # openeuler dnf install --disablerepo='*' --enablerepo='everything' tmux dnf upgrade --disablerepo='*' --enablerepo='update' 'kernel*' 參考連結 squid tutorial https://www.digitalocean.com/community/tutorials/how-to-set-up-squid-proxy-on-ubuntu-20-04 yum proxy tutorial https://www.baeldung.com/linux/yum-dnf-repositories-set-proxy

Steam OS 3.7 桌面模式下的中文輸入法 fcitx5+RIME
科技新知
MacauYeah・2026-02-21

上一篇我們提到,SteamOS的原生鍵盤不知為何失效,我們在桌面模式上的另一個選擇就是flatpak中的 Fcitx5。 因為Fcitx5是基於flapak安裝的,預設只在flapak下通用,後半部份,亦會介紹如何打破這個限制。 安裝Fcitx5 及倉頡五 我們可以在 Discovery App,輸入關鍵字 Fcitx5, 找到相關的套件。為更精準地安裝指定套件,可以直接在terminal 使用以下指令。 首次啟動時,需在start menu中,搜尋fcitx5,它就會長註在右下角的系統列中,選該icon→右鍵→input method settings,把「RIME」加入到fcitx5中,就可以使用了。 在此時,你可以打開Firefox,經control+space的方式轉換輸入法試試。但之後你會發現,原生的Kate文字軟件,都無辦法輸入中文。因為只有Dsicovery / flatpak 的 app 才能正常使用fcitx5。 大範圍套用Fcitx5 如果你找網上或AI的資訊,大部都會提示你修改系統設定檔,把fcitx5加到其中,但筆者就不成功。好在有[Bilibili強者的筆記](https://www.bilibili.com/opus/1139601518269300768](https://www.bilibili.com/opus/1139601518269300768)),原來SteamOS自帶的是ibus,但ibus又不讓設定(因為要換rootfs)。我們通過flatpak中安裝fcitx5,其實是可以通過ibus存到系統的。步驟如下: 如果你還未為當前的deck user配上密碼,你可以在terminal中使用 有密碼後,就可以使用 把所有module加為ibus 你沒有看錯,真的是那樣。基在上所有原生的桌面app及terminal,也可以切為到中文輸入法了。還有一個特例就是經 distrobox 生成的環境,依然無法存入ibus。 Reference https://www.bilibili.com/opus/1139601518269300768

2026看Steam Machine | Steam OS 是不是一個出路?
科技新知
MacauYeah・2026-02-20

在這幾年,筆者都一直分享一些coding anywhere的主題。原本的出發點,其實是因為雲資源及container的出現,是不是讓個人電腦的採購可以越來越不受限?是不是相對選擇會更多,亦應該可以更便宜的選擇? 適逢SteamDeck Linux興起,使用Steam OS道理上會比windows更適配雲資源的開發,而且SteamDeck 可以同步作為手提遊戲機,買台低配的SteamDeck回來,可謂一石多鳥。筆者用著用著,也來了兩年多。現在再來聊它,主要因為Valve未來又有新的硬件Steam Machine推出。這台新硬件,道理上也是跟Steam OS,官方亦宣傳它可以作為PC用。但就這一賣點,筆者很想分享一下它的Steam Deck的使用心得,供各位參考Steam Machine的軟功能是否適合。 https://store.steampowered.com/sale/steammachine 首先,作為遊戲方面,Steam Deck是手提遊戲,硬件比較弱,不能與同世代的PS5或Xbox Series X或PC去對比。我們不應該拿畫面和效能跟其他平台比。但它的OS 層功能,就很直接看得出它有沒有價值。 遊戲模式-Gaming mode 有即時待機功能,但不是所有遊戲都百分百適配。Steam OS的待機,來回玩,再待機,玩過兩三天,總會crash一次。相對之下,Switch就做得很好,就算玩一週也沒問題。Steam OS 也不能說很差,因為PS5等沒有真試過來回待機玩個一週。這裏要表達的,就是遊戲未必為Steam OS而做優化,開發商的目標還是傳統的PC遊戲模式,傳統PC Notebook也有待命,但又有多少遊戲會認真對待?所以Steam OS可以待個兩天,就已經很好 手柄連接算是順利,一般大版的手柄,都可以簡單連接。但它也有做得不好的地方。每次待機換地點,基本上都涉及切換手柄問題。即使內置就有只一個實體手柄,系統並不會自動為你更換第一順位。例如,我原本使用PS5 無線手柄,在家遊玩,這時PS5手柄是第一順位,實體手柄是第二順位。很多遊戲只認第一順位是很正常的。不過在我待機,切換環境,原本的PS5手柄已不存在,但SteamOS並不會把實體手柄順移到第一順位,必需要手動調節。好在,也不需要退遊戲就可以切換。這個對比PC來講,SteamOS已經是做出了改進,但對於Switch和PS4/5,這些根本就是待機一啟動時就要為用戶的問題。可能這是因為SteamOS要考慮Desktop Mode的原因吧,不過筆者就沒有試過在Desktop Mode開遊戲,因為突然要待機外出會更麻煩。 桌面模式-Desktop Mode 這個模式,筆者就專注在取待PC的日常操作上 中日韓輸入法問題,這是大大地阻礙大家入這坑的很重要原因。如果大家都是純英文人,就不需要顧慮這一塊。但筆者就不是一個英文很強的人,多多少少需要直接打中文去找問題。原本SteamOS在Gaming Mode下可以通過 Steam Key + X,叫出虛擬鍵盤,安裝中文倉頡是很易的事。原本這一功能,在Desktop Mode也是可以的。但在寫稿的今天,Gaming Mode / Desktop Mode的中文虛擬鍵盤都一起報廢了,原因未明。筆者只好走回最早期為大家介絡的 flatpak fcitx5+RIME大法。fcitx5可以用,但限制也多。之後筆者再寫一期教學,解決它的限制問題。 辦公室套件。最基本就LibreOffice, OnlyOffice,大家可以在Desktop Mode中的Discovery裏找到。大家想知自己常用的套件是否有對應的版本,可以在https://flathub.org/en 裏找找看。有的話基本可以放心一半,至少經Discovery下載的app,都可以經fcitx5+RIME輸入中文。但這並不代表你可以真的當自己在辦公室工作,那些printer / scanner ,筆者實在沒有太多想法。道理上今年今日普通列印功能,應該通過指定driver就可以做到,但無耐真的不太簡單。日後筆者了解好制式問題後,再來填這個坑。 瀏覽器-就用Firefox吧。 其他瀏覽器有是有的,但最好只用Firefox。Discovery是有筆者最常用的google chrome瀏覽器,但在網安原因下,筆者不敢推薦。Flathub上 Firefox是官方認證的程式,但Google Chrome和Chromium也是沒有認證。如果想使用管方認證的Google Chrome,頂多只能在Distrobox下自行安裝。同樣,如果你是IT人也是英文人,Distrobox再安裝chrome,應該很簡單。但如果你像筆者一樣,還是依賴中文輸入法,你就會很失望,Distrobox經X-server出來的程式,沒法使用前文所講的fcitx5。所以簡單一點的選擇,就是直接使用Firefox。 寫Code,那就得在Distrobox上弄了 Flathub上是有非管方的VSCode,但同樣問題,這個版本你敢用嗎?同樣地,在Distrobox 下安裝 VSCode,是取得官方版本的好方式。只要大家不強求在vscode中輸入中文就可以了(貼上中文是可以的)。使用Dsitrobox做開發類的IT工作,在Contianer範圍內,都算可行的,在Container內安裝java,總比在SteamOS上簡易。但如果你需做一些低層的開發,還是在VM下操作吧。 總結: 如果你很想一石多鳥,你能接受新事物,Steam OS可以一試。 如果你有一些深度的操作或要求,即是是遊戲層面還是工作層面,現時Steam OS都不是一個很好的選擇,除非你的Steam OS不更新,把它硬改回ArchLinux,但這就失去了Gaming Mode的意義。

雲系統的持續更新,大家的選擇是什麼?
科技新知
MacauYeah・2026-01-30

在開始之前,筆者先解釋一下自己對Linux發佈策略的理解。筆者之前以為自己都尚算了解,但到了兩難問題時,才開始反思。所以都不禁懷疑自己的基本觀念有沒有問題,如果大家覺得筆者多少有些理解上的錯誤,請留言糾正。 普通軟件的發佈 主要分為穩定(Stable / GA), 測試(Edge / Alpha / Beta),特定版本。穩定、測試版本也可能有多個不同的分支,但它們主要是指不同環境下的選擇。通常安裝時,都會安裝最後的穩定、測試,除非最後版本有明顯Bug,我們需要回覆到再去的一個穩定版本。 當我們每次都更新到最後的穩定版本,我們稱之為rolling release. 以docker 官方建議的方式,我們在ubuntu底下,可以看到它的有很多結果回傳。 apt list --all-versions docker-ce Listing... Done docker-ce/noble,now 5:29.1.4-1~ubuntu.24.04~noble amd64 [installed] docker-ce/noble 5:29.1.3-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.1.2-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.1.1-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.1.0-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.4-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.3-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.2-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.1-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.0-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.5.2-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.5.1-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.5.0-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.4.0-1~ubuntu.24.04~noble amd64 ... 我們可以選擇過去某個版本,但通常無腦update,就會去到最後一個版本。 Ubuntu的發佈策略 我們換個package看看,如果只看重要軟件的話,例如kernel,我們沒有什麼可以選擇 apt list --all-versions linux-image-generic Listing... Done linux-image-generic/noble-updates,noble-security,now 6.8.0-90.91 amd64 [installed] linux-image-generic/noble 6.8.0-31.31 amd64 apt list --all-versions linux-image-virtual Listing... Done linux-image-virtual/noble-updates,noble-security,now 6.8.0-90.91 amd64 [installed,automatic] linux-image-virtual/noble 6.8.0-31.31 amd64 除了可選擇數量外,另一個最大的不同是,kernel的自身版本其實固定在 6.8.0,就算更新,都是同一個版本的ubuntu補丁版,並不是官方kernel的bug fix版。筆者認為,這應該就是所謂的point release的策略。 (如果大家安裝物理機的話,kernel可能會是6.14,筆者大部份都是VM,還是比較舊的版本。筆者保證,6.8.0-90.91與 6.8.0-31.31之間,曾經是有多個不同版本的。但現在沒法下載回來,除非之前大家有安裝過。) 但相同情況,我們找另一個package看看,由 ubuntu 自己打包的docker 版本,雖然可以選擇的數量是有限的,但它們的版本是不斷更新的,而且不是hotfix版,還有大版本更新。 apt list --all-versions docker.io Listing... Done docker.io/noble-updates,now 28.2.2-0ubuntu1~24.04.1 amd64 [installed] docker.io/noble-security 27.5.1-0ubuntu3~24.04.2 amd64 docker.io/noble 24.0.7-0ubuntu4 amd64 雖然版本是跟著官方docker最新版本,但也有持續跳級更新。如果真的要分類,筆者應該會把它歸類為 rolling release。 Rolling release vs Point release 花了一些時間看例子之後,終於開始討論我們自己的更新策略了。rolling release,最主要的原因是,舊版本無人再免費維護了,有什麼bug,都在最新版本中修復,但也因此有機會出現不相容的情況。point release,最主要的原因是為了維持極強的穩定和兼容版本,這亦代表,除官方專家出手,否則很難有舊版本的bug fix。 那麼我們有什麼選擇? 有point release,當然跟point release,因為程式不可能天天做調整。除非大家想要新功能再升級版本。 沒有point release,就手動自己選擇hotfix版或小版本升級。在升級大版本前,一定要做整合測試。若追求極致的穩定,升級大版本時就不要原機升級,要另起爐灶,似兩個相對獨立的環境並行過渡。如果有container版本,就用container隔離,一般java等都可以這樣建獨立環境。 沒有point release,也沒有可隔離的並行環境:其實 docker 接近這類。對它應的OS層的存取,雖然可以用VM隔離,但通常都不實際。因為重新安裝OS, 設定外部環境,成本很高。docker 在中 lab 並行升級是可以,但投産環境並行真的不實際。沒有辦法之下,筆者還是原機升級。頂多是lab中實現更多的整合測試。

Coding中的AI輔能3 | AI 探索新領域
科技新知
MacauYeah・2026-01-26

繼之前筆者介紹使用AI Chat問一些技術固有問題後,筆者亦試著繼續用AI做一些其他功能探索。 也是先講結論 目前筆者針對自己不熟悉的技術,而且認為已存在,不太可能不存在的技術,叫AI幫忙做事。跟過去一期最大的差別,就是筆者無法快速判斷AI的答案是對還是錯,只能跟著AI一句一句的地執行Code再去找問題。但即使是這樣的情況下,AI還是能提供到有參考價值的答案。 Jasper report studio 參數引用 在預設的情況下,Jasper report studio 的某些參數只可以反映在 SQL Data Source中,其他Data Source並不適合。但即使這樣,筆者還是希望AI找尋一下過去的人有什麼解決辦法。原本的問題,筆者在Google上,並不能找到合適的參考案例,但在問Claude Sonnet 後,反而有案例。實測下,也是有效的。 與搜尋引擎關鍵字不同,在Claude Sonnet中,筆者花了較長的字句去描述問題。也有可能是因為「生成式」的關係,Claude Sonnet 可以生成更多我沒有見過的關鍵字,從而得到答案。而這個答案,非常大機會並不是出自官方的使用說明中。這種就像坊間的用法,可能升級後會突然無法使用。但至少目前可以解決問題。 QEMU 的教學 筆者一直被逼著試用一些新的cloud image,並非筆者認知的傳統VM使用方法。qemu筆者之前有看過官方教學,但實在太長、太複雜,故筆者就把自己的問題拋給DeepSeek-V3,看看它能不能提供一個可行的指令。 結果是可行的。不過要重提的是,筆者雖然對QEMU不太懂,但至少對Cloud image有些認識,知道Cloud image是如何運作,某些image又可能缺了些什麼。針對性地問DeepSeek-V3一些具體問題,結果還可以接受。也幫忙解決了筆者誤會抄下來的指令。 總結 總括來講,這種方法係加大了筆者可以搜索的範圍,AI亦可以做一些自己的嘗試。省卻了自己閱讀大量文章之後再組合的過程。對於一些自己太熟悉,但是穩定的技術,應該會有可行解。 但如果針對一些很肯定資料來源的問題,筆者還是會選擇使用傳統搜索的方式或以AI找出官方來源,自行到官網查證。Fact Check 資料可信性,原本就是這麼做,也會繼續這樣做。AI會有幻覺,傳統的搜尋答案有部份也是來Stack Overflow等討論區,也是需要進一步自行了解。

想試國産Linux Cloud Image ? 無問題Qemu快速幫到你
科技新知
MacauYeah・2026-01-21

不知道大家最近有沒有在考慮使用國産OS,如果有,大家又是怎樣做初步測試的呢? 筆者之前一直都笨笨的從ISO開始安裝,所以每試不同的版本,都要從零開始。不但重複,OS安裝階段的複制過程也是很耗時的。但其實國産OS,大部份都有qcow2的格式,我們若只是本地測試的話,其實可以利用qcow2來做快速VM生成。 阿里aliyun 之前筆者有介紹過ubuntu的multipass,若你想試用的國産OS就是阿里aliyun,只要你有ubuntu,就可以快速跑起來。 但如果沒有ubuntu,只要有qemu(多平台),也是可以的。 qemu-system-x86_64 \\ -cpu host -machine type=q35,accel=kvm -m 2048 \\ -nographic \\ -snapshot \\ -netdev id=net00,type=user,hostfwd=tcp::2222-:22 \\ -device virtio-net-pci,netdev=net00 \\ -drive if=virtio,format=qcow2,file=aliyun_3_x64_20G_nocloud_alibase_20251215.qcow2 \\ -drive if=virtio,format=raw,file=seed.img 上述指令中的qcow2和seed.img,階為官方網站可以下載的。預設帳號 alinux 密碼 aliyun。 seed.img是用於cloud-init的,就是初始化VM所用。第二次開機時,就不需要再使用seed.img qemu-system-x86_64 \\ -cpu host -machine type=q35,accel=kvm -m 2048 \\ -nographic \\ -snapshot \\ -netdev id=net00,type=user,hostfwd=tcp::2222-:22 \\ -device virtio-net-pci,netdev=net00 \\ -drive if=virtio,format=qcow2,file=aliyun_3_x64_20G_nocloud_alibase_20251215.qcow2 華為OpenEuler 同樣地,我們也是用qemu可以跑起OpenEuler,只是它沒有seed.img(不支持cloud init),所以直接跑起就好。 qemu-system-x86_64 \\ -cpu host -machine type=q35,accel=kvm -m 2048 \\ -nographic \\ -netdev id=net00,type=user,hostfwd=tcp::2222-:22 \\ -device virtio-net-pci,netdev=net00 \\ -drive if=virtio,format=qcow2,file=openEuler-24.03-LTS-SP3-x86_64.qcow2 預設帳號 root 密碼 openEuler12#$ 第二次開機,指令也是一樣。 龙蜥AnolisOS 方式也一樣。 qemu-system-x86_64 \\ -cpu host -machine type=q35,accel=kvm -m 2048 \\ -nographic \\ -netdev id=net00,type=user,hostfwd=tcp::2222-:22 \\ -device virtio-net-pci,netdev=net00 \\ -drive if=virtio,format=qcow2,file=AnolisOS-8.10-x86_64-ANCK.qcow2 預設帳號 anuser 密碼 anolisos 總結 如果只是要體驗一下國産OS,Qemu快速起VM就足夠。但Qemu本身只有NAT網絡,想要做VM之間的通訊,需要大量的學習成本。

Coding中的AI輔能2 | Ai 寫測試用例
科技新知
MacauYeah・2026-01-21

繼之前筆者介紹使用AI Chat問一些技術問題後,筆者亦試著用AI直接參考code的改動。 先講結論 目前筆者只針對自己熟悉的技術,叫AI幫忙做事。那怕它做錯,我也有條件驗證及修正。而結果是,。 優點:它的確有幫上忙,省了我一些時間。省時不多,但有省得不多。總比全人力Google來得舒服。 缺點:很慢,有點鈍。它的答案也可能很直觀,需要手動再調整。 寫測試 為免一下子挑戰太大,筆者先從寫測試開始。使用一個現有的專案,去掉secret等敏感資訊,然後針對新做的function,叫GitHub Copilot 幫忙寫Test Case。Copilot Agent就會開始檢驗你現有的測試,學著你之前的風格,為新的function寫測試。Copilot會結合你現有的程式,也了解一些框架的知識,例如Hibernate Entity, Repository之間的關係,試著寫一個符合你剛才文字表述的邏輯。就是因為這也是一個整體掃瞄和學習的過程,筆者覺得不論付費還是免費的AI額度,可能都會一樣慢。 為什麼要在這個地方上使用AI幫忙呢? 因為Test Case中,通常因應不同的情況,有不同的預設值。很多時,Test Case相似,又無法直接覆用預設值。所以找AI幫忙起草,後期自己再修正一些,總比全力自己設計要省心一點。 Maven pom依賴升級 筆者亦都有試過找GitHub Copilot 解決一些因版本升級帶來的依賴不相容的問題。同樣地,筆者對於這些問題,有一定的了解,只是不想每個版本逐個比較。筆者想靠 Agent 找到相近或相容的版本,結果算做得不錯。這些問題本身沒有難到需要大量Google去做資料搜集,但至少Troubleshoot時,要回憶幾個不同的maven指令。平常pom 版本分析的指令很少機會會用,一時三刻要重新好好理解一下,也是費神。這個場境,似乎AI也勝任,自己最後驗證也簡單。就像解一元多次方程式一樣,找解很費神,但驗證就很簡單。那怕驗證時真要追蹤 pom file,也有IDE幫忙。 總括來講,筆者沒有叫AI大量創作,在控制問題範圍的情況下,免費額度的GitHub Copilot也能找到一些幫助。

2025 個人年度模型總結(下)|唔上唔落,特別有愛再入手系列
手機‧電玩
MacauYeah・2025-12-25

SDEX 巴巴托斯天狼座 / SDEX 命運 不過這一兩個模的問題,而是整個SDEX都需要大量補色。雖然外型不錯,強行把玩還是可以的。但因為工作量問題,沒有時間或者耐性,就盡量不要碰。想要練手嘅朋友反而可以多買。 EG Nu 主體套件是沒有問題的,問題就是官方一直沒有推出配件包。筆者試過買Fake Nu 背包,能安裝,但會有重量不平問題。正式配件包,據說下年是會推出的。有愛可以考慮先團主體,然後等配件包,避免事後加價。不想等的話,可以買副廠配件包也可以。那為何筆者會買它呢?主要是初期練手刻線為主。EG的特點是造型可以,但板件數不多,可以快速到實驗你想試的事。 HG EXIA 舊模,純情懷向,需要補色。第三方水貼亦唔見有,真係要靠自己。可動唔算好好,但得益於輕裝甲的設計,裝甲干涉唔多。能做完還是很有吸引力的,但真的要花功夫。 RG Wing Zero EW 天使翼有一個很特別嘅吸引力,上支架可以做出好多華麗嘅造型。因為呢款係舊款RG模型,所以有軟骨問題,好在佢唔係走Seed 系路線,靠一雙翼都可以有好多變化。硬要走手持巨炮的路線,就要考慮使用多支架。 HG Mighty freedom 去年劇場版模型,雖然係新設計,拼裝體驗是很好的。但外型對比MR魂,榮耀防衛者有一些決定性的缺陷,翼的張開角度沒能完好配合身體。除非大家識自行改造,如果唔係背包會有少少奇怪。平時亦需要支架支撐。 原本還有兩隻想介紹的模型,不過因為真係純粹吐槽,就不介紹了。今年嘅分享就到呢一度,新嘅一年,祝大家心想事成,事事順利。

2025 個人年度模型總結(中)
手機‧電玩
MacauYeah・2025-12-24

續上編分享,繼續曬一下筆者推薦的模型 HG 炮型脈衝 呢一款係筆者第一款買嘅PB 模型。因為算係新生系列中比較舊嘅款,所以若要效果好,就要大量補色。而且因為係PB,所以說明書說上沒有官方作例,筆者只可以參考RG模型作補色。 另外,筆者都做咗一個嘗試,就係加入花紋貼紙(RG 借來的),整體即刻提升咗一個層次。所以若果唔想做太多功夫嘅朋友,都可以搵搵有冇第三方水貼。 HG 命運 呢款係模型圈裏面唔少人推介嘅模型,有些玩家都話可以直接平噴,唔需要做複雜嘅遮蓋上色。筆者就理解為,對於素組玩家嚟講應該更友善,唔需要自己補色。筆者製作之後,覺得翅膀還是有點素,如果唔買水貼嘅話,要喺翅膀補色落返啲功夫。 整體可動性唔錯,但唔可以同MR魂比,翅膀比較受限,大刀同大炮亦冇MR嗰種局部放大的設計,如果你按照MR官圖去拍攝,你可能會覺得HG 少咗一份氣勢。除此之外都算正常發揮。 HG 維爾達 便宜好物,只要你識補色就可以。呢款模型有一啲白色或者奶白色嘅補色貼紙,真係要落筆補色要考慮遮蓋力問題。想偷懶嘅話,用返貼紙亦都OK。其他部份都係深灰色補色,遮蓋力,一般都冇問題。因為肩甲上邊有花紋,前裙甲亦係特殊造型,唔需要特別買水貼去提升線條感。 HG GQuuuuuux 今年嘅新作品,結構真係好特別,冇進行補色,亦冇滲線,整體顏色已經好鮮艷。 唯一比較難接受嘅,就係佢嘅頭部造型。如果你接受到造型嘅話,只要唔係價錢出現溢價,都可以買。最近(年底)亦見到有價格回落嘅情況,所以係一個好好嘅出手時機。 和模線 塔斯提爾 上年發售嘅國模產品,筆者今年先正式完成。和模線唔算係一個內卷廠商,無合金骨架,但係佢嘅設計嘅産品都仿人形,比例做得唔錯,構造有心思,體驗好過魔動核好多。唔洗補色,亦唔使靠水貼去提升細節。部份地方有蝕刻貼,只限於眼睛部份。 值得推薦的部份已經講得差不多了,下一期就介紹一下筆者踩過的坑。

2025 個人年度高達模型總結(上)
手機‧電玩
MacauYeah・2025-12-23

筆者呢一年都不斷分享製作模擬經驗,但就好少分享自己嘅作品。其實筆者今年都砌咗相當數量嘅中小比例模型,主要都係集中喺 1/144嘅比例。 因為大部份都係過去嘅商品,所以筆者就唔做年度最佳的評比。就係針對筆者個人嘅收藏目標,推薦一啲筆者認為有質素嘅商品。筆者同大眾嘅審美不太一樣,最主要因為筆者考量自主站立嘅關係,例如好多大背包機體,對澳門土地資源短缺環境,長期保存嚟講都係唔合適,所以呢類都唔係筆者收藏的首選。最後入圍筆者嘅名單,通常係一啲輕型機、人型機。 HG 新生紅渣古 UC 元祖呢個系列,代表住最原始嘅設計,對於玩慣後期系列嘅朋友嚟講,紅渣古真係好樸素,就係因為呢種樸素令佢身上面嘅線條設計比較獨特,再加上佢係圓面裝甲比較多,佢所需要嘅製作加工工序唔多,簡單加深刻線,唔需要補色都已經有好高完成度。 HG 不朽正義 上一年嘅劇場版機體,如果你依家買嘅話價錢應該係回落到一個好合適嘅價錢,佢同其他主角機唔太一樣,因為佢背包係得兩片細細嘅翼,想要站立係好容易。加上佢係匕首格鬥機,玩法比較特別。而且係新嘅設計,補色亦無rising freedom 咁多,好適合爽砌爽玩。 HG 無限正義二式 如果背包嘅規則嚟講,呢台機應該係唔符合筆者嘅標準。但因為呢部機嘅背包,係一台小飛機,可以單獨拆出作為展示。就展示+可玩性,一齊考量,整體都算唔錯。(除咗價錢比較硬之外。) 原本mighty strike freedom 都想列入其中,但最尾還係除名。考慮榮耀防衛者,對於整台機體的展示方式,收納時候好臃腫,分開展示,主體機又顯得好肥,而且背翼展開,對於MR魂,的確差咗一個等級,所以呢台機就冇推薦。 EG Build Strike Exceed Galaxy 簡單粗暴特別。 因為筆者喺素組嘅途中整壞咗頭部,所以用咗其他棄件代替。亦因為咁,意外地創造咗一種新感覺。因為呢個系列係鼓勵自由組合,整出嚟效果唔會太差。不過就係EG嘅關節容易損壞,所以把玩要很小心 EG Perfect strike 不過不失。背包雖然重,但係因為有大件同埋大炮可以作為支撐,收納情況下,可以自主站立(當然上支架可以更挺),對比筆者過去舊有嘅RG, EG呢一款雖然細節比較少,但比較硬淨。RG 多年之後好多件都要落膠水黐死,EG 相對冇咁容易鬆脫。站屍一流。 本年度筆者還有其他推薦的模型,不過需要時間慢慢找出來拍一拍。有興趣的朋友記得留意筆者的更新。

Coding中的AI輔能
手機‧電玩
MacauYeah・2025-12-20

早排跟一位外國的朋友聊天,發現對方公司大力地推動開發工作與AI結合,而且實務上亦幫到忙,可以解放生産力。 既然大家在AI上有得益,筆者亦試用一下。就礙於安全性問題,目前筆者暫時都經過chatbot的發散問題的方式,問AI取得方向性的建議。以下,筆者就分享一下自己的使用心得。 Github Copilot Chat 道理上可以直接安裝VSCode上,但不知道是否不版本更新問題。筆者的Ubuntu 24.04 VSCode 無法運行。反而匯出vsix 後,筆者的codeserver (open source VSCode) 可以運行。 有相同問題的朋友,可以留言找codeserver的詳細安裝方式。 初次使用下,GPT-5 mini 的性能不錯。作為發散問題,可以幫筆者快速地梳理筆者想要了解的技術。(前題是這個技術很成熟,只是筆者不太了解) 例如:筆者會問它關於一些 builder pattern 的必要性。與原本的做法有什麼差異。通過一輪來回對答,筆者對於使用情境也有一個更全面的了解。相對於傳統,筆者要多輪Google,之後再在腦海中梳理再追問,的確快好多。 GitHub Copilot Chat 唯一的問題是,免費的額度需要每個月才會補充。長期用需要付上月費,而且它內置的Model並不包括 DeepSeeks 和 Claude。 我們可以經API KEY隨時加的外部的Model,不過這就等於我們需要多頭付費,GitHub 充一份錢,外部算力也是。 Poe.com 因為筆者暫時也只是使用開放式問題,做一些思維上的整理。筆者還試過 Poe 的第三方Claude Bot。除了策略問題外,範例寫Code效果也行。(當然是限制在筆者未了解,但其實已面世很久的技術。如果好像現在問它一個spring boot 4的問題,就不太推薦) 由於不是直接由Bot改Code,所以算力消耗不高,Poe也每日補充免費額度,可以更方便用來試水看看。 還想用AI嗎? 筆者直接給答案,想,很想。不過這並不代表我們就輕鬆很多。 對於傳統開發框架,我們還是要先理解、學習。就算未來筆者試用Bot生成Code,筆者還是要負責驗證的部份。驗證的能力,其實就是基於過去的理解和學習。面對一些新問題,筆者還是需要去官方網站找實際的資料、範例,以判斷AI生成的結論是否合理。也依靠這些資訊去修正AI的結果。 對於筆者已知的問題,若筆者過去的專案已有答案,筆者還是寧願自行複制貼上,去做一些手動修改,去適配新的場景,因為這需要的驗證工作量還更少,風險更低。

Ubuntu 的簡易日常更新
科技新知
MacauYeah・2025-12-17

早陣子跟新認識的朋友聊天,聽到他們因為要轉伺服器平台,煩惱如何做作業系統層面的定期更新。筆者亦都分享一下自己是如何做 Ubuntu OS 層面的定期維護。 沒錢,就用最原始的方式解決 因為Ubuntu也算是常見的linux品牌,所以基本有有商用軟件可以偵測OS的狀態,並針對它推送更新。不過如果你像筆者一樣,是個貧窮的革命家,那就只有土炮一點自己做鏡像點及做測試。 建立一個 ubuntu 的 deb 包 mirror。手動單次地用步 mirror,確保自己其他 server 同一個時間段都只會取得同一個更新。 停了 ubuntu 的 kernal 自動更新。不然的話,mirror 有更新,ubuntu 亦會偷偷地自動安裝了新的kernal,只是等待你的重啟。 使用一個測試機,先經 mirror 更新到最新的狀態。運行一段日子後,其他機再陸續更新。如果你投産環境有多於一種配置,就考慮要多個不同的測試機。更新指令直接做成 script,方便在其他機器中重複。 輪流 ssh 登入各台機,執行相同的更新指令。更新指令經 git 同步到其他機器。為確保不受 ssh 斷線的風除,必要時還需加入 tmux 。 多機器的煩惱 上述的做法雖然可行,不過當你有十台以上的機器,重複做 ssh, tmux, git checkout, script 互動,也是很累人。考慮一次性地全自動化執行,還是有必要的。筆者對上述的第四步驟,作出一些取捨,以確保更新速度足夠快,可以順暢地執行。 什麼是必需要更新的? 筆者觀察到,在 container 技術出現後,其實很多時安裝應用都不會直接在 OS 層安裝 deb / rpm 包,都是直接經 docker image 去做。所以OS層面,或者很多服務都不會被啟動。筆者亦發現,至少在ubuntu下,只更新kernel,對比無腦全更新所有 deb 包,會快很多很多。 如果可以,我們只更新kernel,再加對應的 container runtime,是不是更新對令相對地穩定,而且可以經外部統一管理。也就是不用在每一台機中進行 tmux + git checkout ,全數在外部推送 ssh 指令? 筆者就用 multipass VM + ssh key,表達一下執行概念。 ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get autoremove -y ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get update ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get install -y linux-generic linux-headers-generic linux-image-generic ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- reboot 上述最大的假設,是第一、三步,更新 kernel 時不會因為網絡問題導致 ssh 斷線,因為它們都是系統級別的改寫,中斷後並不能確保可以重來。第二步就很安全,隨時重來也沒有問題。 這樣,我們就可以在任一台管理機,經過一個 shell script for loop,更新所有其他機器。 如果我們對於網絡還是有些疑慮,我們也可以試用一次性排程式的方式去做。 ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 echo '/your/script/location' | at 08:00 PM 17.12.2025 這樣的好處是,我們可以連 tmux 的開啟也省略,git checkout 也可以經固定的 script 執行(只是很煩鎖)。但這也會有壞處,就是看不到執行的情況,只能事後檢查系統狀態,是否已更新過。 當然前述 ssh key 的方法也可以加入 git checkout 更加深化不同的更新 script,但這又會增大斷線可能。ssh key 還是以快速完成指令更實際。 註:因為網安原因,筆者把上述 script 中的 S U D O 關鍵字去掉,這樣 blog 才能發出。