搜尋

搜尋結果

緬甸。曼德勒 | 還是逃不了狗奴的命運。
走遍世界
原來世界這樣大・2019-04-29

在緬甸的最後一個早上,我放棄了Hostel免費提供的早餐,到附近的茶室吃緬甸式早餐,因為我知道在香港想吃到緬甸菜確實是有點難度。 早點把行李收拾好,向茶室出發去感受一下緬甸的地道。 早餐太大份我吃不完,店員好心地幫我把剩下的食物放進外賣盒,讓我之後可以翻熱再吃,但其實我正準備要坐十小時的巴士,把外賣盒帶著卻無法翻熱,實在有點不方便。但店員的好意我無法拒絕,只好拿著外賣盒離開茶室。 我沿路回Hostel的途中,發現有隻流浪狗一直跟著我,大概是盒子內散發著食物的香味吸引了牠吧。緬甸的物價指數低可以説是貧窮,一般的家庭都沒有飼養家犬。但因為是人狗共諧共存的國家,緬甸街上都不難看到流浪狗。牠們跟隨著人類,不會主動的攻擊,只是用那可憐又無辜的眼神乞求食物。即使在餐廳內偶爾也會有流浪狗在身邊經過人。 看著早餐剩下的食物,考慮著即使我回到hostel,食物還是會被我棄掉。我把外賣盒放到地上,把膠蓋打開,跟隨著我的流浪狗有點退縮,我指著地上的食物,示意叫牠去吃 牠大概聽不懂我説什麼,然後我後退一步,牠好像理解,然後靠近食物盒,開始吃盒內的食物。 這微不足道的小事對其他人是不值一提,但對流浪狗來説一餐溫飽已經相當的滿足。覺得自己做了一件有意義的事,心裡有點溫暖。而我發現自己一輩子還是逃不出當一個狗奴的命運。

坐長榮航空經台北飛關島來回連稅MOP2,959!仲以中停台北!
激安優惠
OHChance 旅遊誌・2016-03-23

長榮航空新推出了爆抵澳門出發的關島優惠,來回連稅低至MOP2,959! 唔係講笑,搵過連12月17日出發、25號返都有呢口價!順便去埋塞班島都得啊!回歸聖誕未有plan ge,唔使等,出手! 坐長榮澳門飛台北轉關島絕對是首選,來回程在台北轉機都可做到最短55分鐘(可以自己選長少少時間的)!全程包埋轉機都係6至7個鐘,香港直飛都要5粒鐘架! 然後台北來回關島是Hello Kitty 機喔!小燦2014年聖誕去關島都係坐長榮,個陣要成五千銀,現在這個價真係超值到爆! 台北飛關島逢星期二、六;關島飛台北就逢星期三、日有航班。想玩埋台北的,不妨利用 ldquo;多航段中途停留不同點進出rdquo;,將其中一程機拆成 ldquo;澳門-台北rdquo;、rdquo;台北-關島rdquo; 2段機來飛,就可以自制中停台北玩多個地方!(票量可能會貴幾十蚊) 澳門特區護照前往關島需要申請美國簽證,而葡國護照同香港特區護照則只需上網申請ESTA即可。 【促銷公司】長榮航空(Eva Air)【搭乘日期】3月23日至12月31日【開賣時間】已開賣,至6月30日【最長停留】17天【航班限制】3月24日至31日      4月28日至5月3日      7月14日至8月25日      12月20日至29日      以上日子出發不適用【預訂網址】httpohchance.inforefevaair 價錢 Sample ndash; 澳門經台北飛關島來回連稅HKD2,959

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 varsnapmultipasscommondatamultipassdsshkeysid_rsa ubuntu@10.115.189.200 aptget autoremove y ssh i varsnapmultipasscommondatamultipassdsshkeysid_rsa ubuntu@10.115.189.200 aptget update ssh i varsnapmultipasscommondatamultipassdsshkeysid_rsa ubuntu@10.115.189.200 aptget install y linuxgeneric linuxheadersgeneric linuximagegeneric ssh i varsnapmultipasscommondatamultipassdsshkeysid_rsa ubuntu@10.115.189.200 reboot 上述最大的假設,是第一、三步,更新 kernel 時不會因為網絡問題導致 ssh 斷線,因為它們都是系統級別的改寫,中斷後並不能確保可以重來。第二步就很安全,隨時重來也沒有問題。 這樣,我們就可以在任一台管理機,經過一個 shell script for loop,更新所有其他機器。 如果我們對於網絡還是有些疑慮,我們也可以試用一次性排程式的方式去做。 ssh i varsnapmultipasscommondatamultipassdsshkeysid_rsa ubuntu@10.115.189.200 echo 'yourscriptlocation' at 0800 PM 17.12.2025 這樣的好處是,我們可以連 tmux 的開啟也省略,git checkout 也可以經固定的 script 執行(只是很煩鎖)。但這也會有壞處,就是看不到執行的情況,只能事後檢查系統狀態,是否已更新過。 當然前述 ssh key 的方法也可以加入 git checkout 更加深化不同的更新 script,但這又會增大斷線可能。ssh key 還是以快速完成指令更實際。 註:因為網安原因,筆者把上述 script 中的 S U D O 關鍵字去掉,這樣 blog 才能發出。

免費自用的私人AI助理 | Ollama - 本地大型語言模型
科技新知
MacauYeah・2025-01-06

不知道在澳門的朋友,有多少可以正常接觸openai?因為地方政策問題,像openai這種國外的大型語言模型下稱LLM,澳門區都沒法接觸到。但隨著時間過去,即使我們不能直接接觸到算力很強的收費AI,我們只要有電腦,也可以佈署一些開源版本的LLM。只要我們可以安裝到ollama這套本地運算軟件就好 ollama是一個giuthub上的開源工具,讓用戶能夠在自己的電腦上運行各種大型語言模型(LLM)。基本上只要電腦是普通的桌上型windows, linux, mac,都可以運行它。下以面就介紹一下筆者的安裝經驗。 windows windows ollama windows 本地安裝ollama,真的很簡單,就是直接去官網下載就好 httpsollama.comdownloadwindows 安裝完成後,在windows cmd再加一個基本的模型就可以了 ollama pull llama3.2 之後就可以開始跟llama問問題 ollama run llama3.2 windows openwebui 如果大家不習慣windows cmd的醜醜介面,想經過瀏覽器存取,我們可以再加裝openwebui。但這個必需要經第三方python或docker安裝。openwebui github指引 httpsgithub.comopenwebuiopenwebui 經python pip install openwebui openwebui serve 經docker docker run d p 80808080 addhost=host.docker.internalhostgateway v openwebuiappbackenddata name openwebui restart always ghcr.ioopenwebuiopenwebuimain 最後,打開browser,訪問 httplocalhost8080,openwebui就會要求大家先設立管理員帳號。 就那麼簡單,大家就有一個真正的私人AI助理。 steamdeck steamdeck 因為很多linux功能都有被限制,所以筆者就直接使用 podman 安裝 git clone httpsgithub.commacauyeahollamasteamdeckpodman.git cd ollamasteamdeckpodman podman compose f podmancompose.yaml up d podman exec it ollama ollama pull llama3.2 同樣地,打開browser,訪問 httplocalhost8080就可以了,因為這個版本已有預設的管理員帳號,立即打開就可以使用了。 Ollama的開源模型 上文中一直提及 llama3.2 其實是 Meta 公司的開源模型,因為它的參數相對少,算力要求較低,可以在沒有GPU的環境下執行。若然大家算力足夠,可以使用其他模型,詳見 httpsollama.comlibrary 。見到合心水的模型,大家可以經 pull 指令下載。例如小紅書的網紅們很多都推薦qwen2,我們可以 ollama pull qwen2 備註 openwebui 及 ollama 並不直接支援自己建立自己的資料庫。我們需要其他工具去補完,但筆者觀看各種教學,自己建資料庫的效果都不太好,所以暫時不做任何教學。 只要我們一直經ollama pull,就可以更新語言模型。但如果大家追求即時的網絡最新資料,大家可以看看LLM RAG的相關文章。但筆者亦未有成功的案例,有更新會另作教學。 opewebui並不是PDF閱讀器,但它可以預覽PDF中的文本,我們需要手動複制PDF中的文件後,才能經ollama分析文件內容。 若想切換模型,在指令介面中,我們多開一個分頁就可以了。若經openwebui,則可以在每句對話之前,經左上方選擇不同模型。

Tmux - 繼 Screen以後的Linux多工神器
科技新知
MacauYeah・2024-10-08

因為各硬件軟件的發難,筆者又不得不回到那個只有純純linux tty console的世界。很多時候,那怕使用tty,我們在Desktop mode,也有現代terminal 可以用,需要多分頁,滑鼠選取文字、複制、貼上,都可以輕易做到。 但在mobile tablet device 上,手指操作真的很不方便。又或者你像筆者一樣,即使有電腦,但要操作一些Linux VM,它們連ssh都沒有,只能直接登入它們的tty,那麼懂得使用Tmux進行分頁及複制、貼上,就變得很重要。 Tmux 是什麼 Tmux 就是可以在Linux Terminal 同一個窗口中,實現多工處理的小程式。就像我們利用多分頁一樣,不同分頁做不同的事。不過最大的差異就是,生成分頁,排列分頁,我們都要使用鍵盤來完成。有時筆者也會用它來作為背景程式,以免不小心關了Terminal就會把所有運行中的指令都停掉。 我們就馬上來看實際例子吧 前置事項 安裝Tmux及運行Tmux Debain amp; Ubuntu 安裝 sudo aptget update amp;amp; sudo aptget install tmux 運行:tmux 進入tmux後,你就會至少有一個分頁,而且不會因為Terminal關閘而中斷 用法一 建立兩個分頁,並切換 增加分頁 先按 ldquo;Ctrl brdquo; 前置鍵,再按rdquo;crdquo; create 切換分頁 在多於一個分頁的情況下,先按 ldquo;Ctrl brdquo; 前置鍵,再按rdquo;nrdquo; next 用法二 同一個分頁中,建立左右並排的窗口 增加水平窗口 先按 ldquo;Ctrl brdquo; 前置鍵,再按 ldquo; 雙引號 切換窗口 在多於一個窗口的情況下,先按 ldquo;Ctrl brdquo; 前置鍵,再按方向鍵左或右 用法三 回到前一個tmux session中 因為不小必關閉了terminal,又或是remote ssh中,ssh斷線後,需要回到之前的工作狀態 未進入tmux 的狀態下:tmux attach 要留意tmux 可以有很多個session,要去到指定的session,就要為session命名。但這個不是筆者常用的情境,原本多個分頁已經很夠用,還要多個session,會很混亂。但不排除它在某些情況下有特別用途,有興趣的朋友可以自行挖挖看。 進階 回頭看過去的terminal screen output 在現代的Terminal中,原本按滑鼠滑輪向上滾,就可以看到過去的資訊,但tmux下反而不行,所以我們需要進入特殊模式 進入Copy Mode 先按 ldquo;Ctrl brdquo; 前置鍵,再按 開括號中括號 向上翻頁 上方向鍵或PageUp 離開Copy Mode Copy Mode中任何時候按rdquo;qrdquo; 進階 複制貼上 進入Copy Mode 先按 ldquo;Ctrl brdquo; 前置鍵,再按 開括號中括號 選擇範圍 移到需要複制的文字起點,ldquo;Ctrl Spacerdquo; ,然後再移動到結束點,再按rdquo;Ctrl wrdquo; 複制 貼上 離開Copy Mode後,再按rdquo;Ctrl brdquo; ,然後 關括號中括號 進行貼上 進階 複制貼上2 某些情況下,我們不允許使用ldquo;Ctrl Spacerdquo; 或 rdquo;Ctrl wrdquo;,因為它們可能跟系統的組合鍵有衝突,所以需要改為單鍵。 讓tmux使用類似vim的操作模式 echo ldquo;setwindowoption g modekeys virdquo; gt;gt; .tmux.conf 關掉所有使用中的tmux,重開tmux 進入Copy Mode 先按 ldquo;Ctrl brdquo; 前置鍵,再按 開括號中括號 選擇範圍 移到需要複制的文字起點,按單鍵ldquo;Spacerdquo; ,然後再移動到結束點,再按rdquo;Enterrdquo; 複制 貼上 離開Copy Mode後,再按rdquo;Ctrl brdquo; ,然後 關括號中括號 進行貼上 筆者常用的功能就這些,有興趣的朋友可以再深挖一下。 Reference httpstmuxcheatsheet.com

Github flow 沒有提及的發佈 - 佈署 | Release - Deployment
科技新知
MacauYeah・2024-08-23

不知道之前為大家介紹的github flow,大家覺得怎樣?好用嗎?今天,筆者又來講講筆者心中認為它沒有好好給出指引的地方。 我們的信心指數,其實沒有那麼高 在前文中,經過 pull request 、 code review 、 auto test ,道理上,開發者可以做的都已經做過了,然後就是等待發佈 Release。 對於單純的庫類型的程式碼,筆者認為,的確沒有事可以再做,實務上就是直接找人其他程多員試用最新版本,看看有沒有問題。只要 main master 上,明確的表示版本號的變更,就差不多等於直接發佈。有需要提供binary版本的,就還需要觸發上載binary的流程,但這個跟 pull request 觸發 auto test 差不多, auto test 成功後就上載。 對於服務類型的程式碼,例如 Web App 等,直接發佈到正式環境還是有些不妥吧?始終會即時影響到業務,我們至少有個測試場,經用戶做實際的業務操作去驗收。但這個時機,應該是在Github flow的什麼時候做? 在原始的git flow中,有一個叫做 develop 的相對穩定分支,僅次於 main 。它是功能開發完成後第一次pull request 的地方,我們可以用這個概念來做自動發佈到測試場。但若在github flow 中加入了這個 develop uat staging 分支,其實就等於複雜地回到過去傳統的 git flow中,對好多新手來講難以接受。Github flow 的成功簡化,其實很大依賴著自動化測試。現在的測試用例,並不再限於單元測試。就連整合測試,也可以經Docker等容器化技術去做,只要我們的自動化測試有足夠信心,就可以發佈。但反觀我們的 Web App 例子,我們認為自動化測試難似涵蓋所有情境,也難以開發。所以我們還在有個時間發佈到測試場,進行人工測試。 pull request 快速迭代 筆者結合自己的經驗,配上國外討論區 Stack overflow 的內容,筆者認為Github flow上進行 pull request 後,就是最好的發佈測試場時機。所以我們需要盡快進行驗收測試,完成後在Git commit上加上Tag,以示通過驗收測試,可以發佈正式環境的版本。 不過這個模式是有一個很重要的前題假設:快速迭代。當我們驗收完成後,盡可能快地發佈到正式環境,不然會阻礙下一個功能的pull request驗收,或是覆蓋了上一個pull request的驗收環境。 用反面的例子來說明,如果我們有很多功能需要驗收,或變化很多,或存在多輪的里程碑開發,我們就不適宜那上述模式。最保險的做法,還是回到傳統的 git flow ,引入 develop uat staging 分支。但如果大家還是那麼討厭傳統 git flow,筆者還是有另一個提議。 既不想回到傳統 git flow ,但又需要慬㥀的考慮驗收發佈流程 如果開發的功能變化比較大,需要多方面協調、測試、驗收,經歷多次里程碑後,才有一個對外發佈的版本,大家可以考慮分開 Repository 做開發。例如 v1,v2的 Repository 完全獨立。 v1 是已發佈的版本,有獨立的測試場,任何即時候需要修正,就在v1的 Repository 做 pull request。 v2 則是未發佈版本,亦有獨立的測試場。加入任何新功能後,就在v2的 Repository 做 pull request,用自己專用的測試場做驗收。到 v2 正式發佈後, v1 就封存處理,再開一個 v3 作為下一個大版本的開發。這個模式,那怕在庫類型的程式碼也用得上。 這樣做的好處是 git Repository 和歷史記錄都會獨立,自動發佈的腳本程也會簡單明確一些。壞處則是 v1 v2 難以做功能對比,我們只能靠人腦記著 v1 有沒有什麼後期加入的修正和功能,需要同步移植到 v2 中 相對的,著是同一個Repository,可以利用merge 功能確保 v1 有的,v2 都己處理,只是必需要很懂處理版本衝突問題。