Log for Ubuntu 台灣社群
PGSimCity－PostgreSQL 如何運作 （★ 121 分）
PGSimCity 是一個以 3D（三維）方式呈現 PostgreSQL（開放原始碼關聯式資料庫）引擎的可運作模型，試圖把資料庫內部元件與處理流程轉化為立體城市。使用者需要瀏覽器具備 WebGL2（瀏覽器中的 3D 繪圖技術）才能觀看；若瀏覽器不支援，頁面建議改用近期版本的 Chrome、Edge、Firefox 或 Safari。作者也明確表示這仍是早期、尚未經過完整審查的原型，模型與說明很可能存在錯誤，歡迎透過 GitHub issue 或 pull request（合併請求）回報與修正。
Hacker News 讀者普遍認為這種呈現方式很有吸引力，能把原本需要大量架構圖才能說明的資料庫排程與內部運作，轉化為較容易留下印象的視覺體驗。有人認為同樣的概念可延伸到雲端運算、Kubernetes（管理容器化應用程式的開放原始碼平台），甚至以 Factorio 類似的方式說明 Fly.io 的部署與狀態追蹤系統；也有讀者受到啟發，想用這種形式製作中央處理器（CPU, Central Processing Unit）或完整電腦模擬器。
不過，多數具體建議集中在使用者體驗（UX, User Experience）。目前導覽過程同時出現太多方塊、彈出視窗與變動中的元素，部分讀者指出這些介面甚至遮住約八成的畫面，使人難以掌握城市與元件之間的關係。讀者建議大幅減少使用者介面（UI, User Interface）元素、讓彈出資訊具備透明度或可收合，並把自動播放的導覽改成由使用者自行控制；相機平移與縮放操作也需要更直覺，才能在筆記型電腦螢幕上清楚閱讀。
更重要的改進方向，是為視覺模型補上明確的敘事與目的。讀者期待能輸入一則查詢，觀看它從解析、處理到傳回結果的完整路徑，同時理解那些持續執行、但不專屬於單一查詢的背景流程。另一項建議是清楚設定「客戶端」與「資料」等主要角色，示範資料寫入與讀取時各元件如何串連，而不只是把資料庫元件比喻成城市建築。此外，有人注意到畫面縮小時可能出現閃爍，推測是 z-fighting（兩個 3D 表面深度過於接近而產生的繪製衝突），可藉由調整表面位置改善。
👥 19 則討論、評論 💬
https://news.ycombinator.com/item?id=49063754
PGSimCity 是一個以 3D（三維）方式呈現 PostgreSQL（開放原始碼關聯式資料庫）引擎的可運作模型，試圖把資料庫內部元件與處理流程轉化為立體城市。使用者需要瀏覽器具備 WebGL2（瀏覽器中的 3D 繪圖技術）才能觀看；若瀏覽器不支援，頁面建議改用近期版本的 Chrome、Edge、Firefox 或 Safari。作者也明確表示這仍是早期、尚未經過完整審查的原型，模型與說明很可能存在錯誤，歡迎透過 GitHub issue 或 pull request（合併請求）回報與修正。
Hacker News 讀者普遍認為這種呈現方式很有吸引力，能把原本需要大量架構圖才能說明的資料庫排程與內部運作，轉化為較容易留下印象的視覺體驗。有人認為同樣的概念可延伸到雲端運算、Kubernetes（管理容器化應用程式的開放原始碼平台），甚至以 Factorio 類似的方式說明 Fly.io 的部署與狀態追蹤系統；也有讀者受到啟發，想用這種形式製作中央處理器（CPU, Central Processing Unit）或完整電腦模擬器。
不過，多數具體建議集中在使用者體驗（UX, User Experience）。目前導覽過程同時出現太多方塊、彈出視窗與變動中的元素，部分讀者指出這些介面甚至遮住約八成的畫面，使人難以掌握城市與元件之間的關係。讀者建議大幅減少使用者介面（UI, User Interface）元素、讓彈出資訊具備透明度或可收合，並把自動播放的導覽改成由使用者自行控制；相機平移與縮放操作也需要更直覺，才能在筆記型電腦螢幕上清楚閱讀。
更重要的改進方向，是為視覺模型補上明確的敘事與目的。讀者期待能輸入一則查詢，觀看它從解析、處理到傳回結果的完整路徑，同時理解那些持續執行、但不專屬於單一查詢的背景流程。另一項建議是清楚設定「客戶端」與「資料」等主要角色，示範資料寫入與讀取時各元件如何串連，而不只是把資料庫元件比喻成城市建築。此外，有人注意到畫面縮小時可能出現閃爍，推測是 z-fighting（兩個 3D 表面深度過於接近而產生的繪製衝突），可藉由調整表面位置改善。
👥 19 則討論、評論 💬
https://news.ycombinator.com/item?id=49063754
▸ 開盒資訊公務員：投入政府服務的資訊人員在想什麼呢？ 👤 阿面（主持：黃豆泥）
▸ 為什麼開源難以進入標案體系 👤 Ronny Wang + Sandra Lin
▸ 數位權利基本法：一場以民間立法推進開源政策的行動實驗 👤 司改會數位法小組
．
🌟 不論你是開源新手還是資深社群夥伴，這兩天都不能錯過！快把時間空下來，來現場跟我們一起聊開源、談政策、交朋友！💬🤝
（更多資訊請鎖定 OCF 粉專，議程細節與時間以現場公告為準！）
COSCUP 官網議程表連結：https://coscup.org/2026/track/526
▸ 為什麼開源難以進入標案體系 👤 Ronny Wang + Sandra Lin
▸ 數位權利基本法：一場以民間立法推進開源政策的行動實驗 👤 司改會數位法小組
．
🌟 不論你是開源新手還是資深社群夥伴，這兩天都不能錯過！快把時間空下來，來現場跟我們一起聊開源、談政策、交朋友！💬🤝
（更多資訊請鎖定 OCF 粉專，議程細節與時間以現場公告為準！）
COSCUP 官網議程表連結：https://coscup.org/2026/track/526
Kimi K3 將於 7 月 27 日在 Hugging Face 發布 （★ 156 分）
Moonshot AI 的頁面宣布 Kimi K3，稱其為新一代開放權重頂尖模型，也是全球首個「3T 級」模型（T 指 trillion，約 3 兆參數級），主要面向長時間跨度的程式設計、知識工作與推理任務。頁面日期為 2026 年 7 月 27 日，當時仍處於發布倒數階段，已有 330 人登記等待通知；頁面列出的規劃內容只有一項，尚未提供完整權重、架構、基準測試或價格等細節。
Hacker News 討論者認為，Kimi K3 的硬體門檻可能非常高。若採用原生 MXFP4（4 位元浮點格式），有人估計僅載入模型就需要約 1.5 TB 的 GPU 記憶體（VRAM，video random-access memory），8 張 B200 GPU 只勉強足夠，若要保留較長上下文並兼顧吞吐量，實際上可能需要 16 張。也有人推測，使用 1.5～3 TB 記憶體的多路 Xeon 伺服器或許能執行量化版本，但速度可能只有每秒 5～6 個 token（模型輸出的文字單位），比較適合交辦長時間任務；在尚未公布完整精度與量化版本前，這些仍是硬體推算。
討論也聚焦於微調與模型縮小的可能性。有人指出，LoRA（Low-Rank Adaptation，低秩適配）目前常搭配 4 位元基礎模型使用，但 GGUF（用於儲存模型權重的格式）正逐漸支援更多架構與更激進的量化；現有實驗已能在 16 GB GPU 記憶體中微調 35B 級模型，在 90 GB 中處理更大型的模型，但 Kimi K3 仍需要多張 GPU 與多台主機。討論者引用最新 AISI（英國人工智慧安全研究所）資安基準測試指出，相關模型表現可能高於 GLM 5.2，卻仍明顯落後於當前最佳的封閉模型；未來若能進行更充分的微調，或將其蒸餾成約 20B、200B 等較小模型，才可能擴大實際用途。
價格方面，第三方 API（應用程式介面）服務商的報價，或許能協助估算 3T 級模型的推理邊際成本，但無法單靠這項資料推導訓練成本，也無法與未知規模的封閉模型直接比較，因此不能證明各家實驗室正在補貼 token 價格。討論者預期競爭會進一步壓低費用，同時也要求服務商公開所使用的量化精度與其他會影響效能的最佳化方式，避免以未揭露的低精度版本換取低價。另有網友提醒，「開放權重模型首次站上頂端」的說法並非毫無爭議，因為 OpenAI 早期發布 GPT-2 時，也曾被視為當時的頂尖模型；整體而言，Kimi K3 的發布更像是開放權重模型在規模與服務成本上的一次壓力測試，個人本機直接執行的可行性仍相當有限。
👥 49 則討論、評論 💬
https://news.ycombinator.com/item?id=49065752
Moonshot AI 的頁面宣布 Kimi K3，稱其為新一代開放權重頂尖模型，也是全球首個「3T 級」模型（T 指 trillion，約 3 兆參數級），主要面向長時間跨度的程式設計、知識工作與推理任務。頁面日期為 2026 年 7 月 27 日，當時仍處於發布倒數階段，已有 330 人登記等待通知；頁面列出的規劃內容只有一項，尚未提供完整權重、架構、基準測試或價格等細節。
Hacker News 討論者認為，Kimi K3 的硬體門檻可能非常高。若採用原生 MXFP4（4 位元浮點格式），有人估計僅載入模型就需要約 1.5 TB 的 GPU 記憶體（VRAM，video random-access memory），8 張 B200 GPU 只勉強足夠，若要保留較長上下文並兼顧吞吐量，實際上可能需要 16 張。也有人推測，使用 1.5～3 TB 記憶體的多路 Xeon 伺服器或許能執行量化版本，但速度可能只有每秒 5～6 個 token（模型輸出的文字單位），比較適合交辦長時間任務；在尚未公布完整精度與量化版本前，這些仍是硬體推算。
討論也聚焦於微調與模型縮小的可能性。有人指出，LoRA（Low-Rank Adaptation，低秩適配）目前常搭配 4 位元基礎模型使用，但 GGUF（用於儲存模型權重的格式）正逐漸支援更多架構與更激進的量化；現有實驗已能在 16 GB GPU 記憶體中微調 35B 級模型，在 90 GB 中處理更大型的模型，但 Kimi K3 仍需要多張 GPU 與多台主機。討論者引用最新 AISI（英國人工智慧安全研究所）資安基準測試指出，相關模型表現可能高於 GLM 5.2，卻仍明顯落後於當前最佳的封閉模型；未來若能進行更充分的微調，或將其蒸餾成約 20B、200B 等較小模型，才可能擴大實際用途。
價格方面，第三方 API（應用程式介面）服務商的報價，或許能協助估算 3T 級模型的推理邊際成本，但無法單靠這項資料推導訓練成本，也無法與未知規模的封閉模型直接比較，因此不能證明各家實驗室正在補貼 token 價格。討論者預期競爭會進一步壓低費用，同時也要求服務商公開所使用的量化精度與其他會影響效能的最佳化方式，避免以未揭露的低精度版本換取低價。另有網友提醒，「開放權重模型首次站上頂端」的說法並非毫無爭議，因為 OpenAI 早期發布 GPT-2 時，也曾被視為當時的頂尖模型；整體而言，Kimi K3 的發布更像是開放權重模型在規模與服務成本上的一次壓力測試，個人本機直接執行的可行性仍相當有限。
👥 49 則討論、評論 💬
https://news.ycombinator.com/item?id=49065752
今天的分享有幾個結論：
👍️開源治理的代溝可能不是一個工具的問題：需要先構思協作的共同流程和消弭組織文化落差。
✌️不是一份厚厚的政策文件可以解決：大家先有一段共同經驗，知道彼此在擔心什麼，也有共同語言可以討論，後面的制度才比較有機會長出來。
👌組織還沒有正式 OSPO，也可以先做 OSPO 會做的事：從盤點現況、建立討論方式......到完成一次具體協作，這些都可以先開始。
從準備、協助 OSPO 成立的角度，我們協助組織看見既有的開源能力、進行連結和實作，讓這些經驗逐步成為留在組織內部、能夠持續運作的能力。如果你的組織也正面對類似問題，歡迎與我們聯繫。
👍️開源治理的代溝可能不是一個工具的問題：需要先構思協作的共同流程和消弭組織文化落差。
✌️不是一份厚厚的政策文件可以解決：大家先有一段共同經驗，知道彼此在擔心什麼，也有共同語言可以討論，後面的制度才比較有機會長出來。
👌組織還沒有正式 OSPO，也可以先做 OSPO 會做的事：從盤點現況、建立討論方式......到完成一次具體協作，這些都可以先開始。
從準備、協助 OSPO 成立的角度，我們協助組織看見既有的開源能力、進行連結和實作，讓這些經驗逐步成為留在組織內部、能夠持續運作的能力。如果你的組織也正面對類似問題，歡迎與我們聯繫。