Jump to...
redirecting...

Log for Ubuntu 台灣社群

我是白的....
離題警告
在這頻道,你很像很不想不讓人知道你的政治立場?
================離題警告================
[photo](media:AgACAgIAAx0CPRn5XQABAlUjakYivuEIfqJMLr2fpAlJwqmz24MAAoETaxuVp6FLXJafgahwImsBAAMCAANzAAM8BA@telegram)
```
你的 repo 在:

/home/chchang/.openclaw/workspace/m365-ca

這是 隱藏目錄 .openclaw 底下
/snap/bin/glow 這個 snap 版常會被限制讀這類隱藏路徑,所以會出現:

open README.md: permission denied
```

我還真不知道 snap 版本的指令會有這種問題...
用 glow 想看自己目錄底下的 README.md ,居然會出現 permission denied
sandbox權限設計不良
Snap 軟體的 home 權限限縮界面預設不開放存取使用者家目錄下的隱藏目錄:
https://snapcraft.io/docs/reference/interfaces/home-interface/

此設計主要是為了避免 SSH、 PGP 私鑰等機密資訊被惡意軟體竊取,而且大多數情況下應用不需要存取這部份的使用者檔案
[photo](media:AgACAgUAAx0CPRn5XQABAlUoakY6vU9hl1oiTtmnaT7K1oudAjQAAuMQaxuOsmFXVZwYQMtfIoIBAAMCAANzAAM8BA@telegram)
如果單純只是要讓軟體可以讀得到的話在支援的軟體中可以用資料流重導向的方式來規避此問題:

cat ~/.openclaw/workspace/m365-ca | glow -
glow <(cat ~/.openclaw/workspace/m365-ca)
另一個更 hardcore 的解決方式是對 snapd 專案貢獻一個新的 openclaw-workspace 權限限縮界面,然後請 snap 軟體包的發布者宣告可以連接那個界面:
https://github.com/canonical/snapd/blob/master/CONTRIBUTING.md
[photo](media:AgACAgUAAx0CPRn5XQABAlUrakZBTNzp76CxNEoLTysG7Q63A54AAqkSaxuozTlWo06BmF-msk8BAAMCAANzAAM8BA@telegram)
通 Linux 2.0 (★ 100 分)

Qualcomm Linux 2.0 已於 2026 年 6 月 30 日正式推出,定位為面向 IoT(Internet of Things,物聯網)與工業邊緣裝置的統一 Linux 平台。新版採用 Linux 6.18 LTS(Long-Term Support,長期支援)核心與 Yocto Project 6.0 Wrynose,主打跨 Qualcomm Dragonwing IoT SoC(System on Chip,系統單晶片)的單一軟體堆疊、開放開發流程與可量產架構。相較 1.x 版本分成 Base 與 Custom 兩套分支,新版改為單一核心、單一 rootfs(根檔案系統)與統一 device tree(裝置樹),降低安全修補、驅動更新與平台維護時的重複成本。

新版架構以開源基礎層搭配模組化 overlay(可選式能力層)為核心。基礎層包含音訊、顯示、圖形、相機與影像等開源使用者空間元件;Qualcomm 針對硬體加速的能力則以可獨立選用的 overlay 提供,例如 AudioReach 音訊處理、camX ISP(影像訊號處理器)相機管線、Adreno GPU(圖形處理器)加速、Iris VPU(影像處理單元)編解碼、感測器整合與 FastCV 電腦視覺加速。量產需求則由 SELinux(Security-Enhanced Linux,強制存取控制)、OSTree OTA(Over-the-Air,遠端更新)、安全強化、Docker、Kubernetes、KVM(Kernel-based Virtual Machine,核心虛擬機器)等 production overlays 組成,讓 OEM(原始設備製造商)可在自家 BSP(Board Support Package,板級支援套件)與產品映像層加入差異化設定,而不必修改底層平台。

Qualcomm 也強調 2.0 採取「upstream-first」開發模式,meta-qcom BSP layer 已取得 Yocto Project compatible 狀態,相關 layer、kas lock files 與多個開源儲存庫在 GitHub 公開,並以公開 CI(Continuous Integration,持續整合)驗證變更。即時運算方面,新版內建 PREEMPT_RT(Linux 即時核心修補)支援,並在 IQ-8275 與 IQ-9075 等部分 SoC 提供 RTSS(Real-time Subsystem,即時子系統)搭配 FreeRTOS,以滿足工業控制、馬達控制與機器人等需要可預測延遲的場景。支援平台涵蓋 QCS6490、QCS5430、IQ-9、IQ-8、IQ-6,以及新增面向工業 IPC(Industrial PC,工業電腦)的 IQ-X 系列;AI 工作流程則整合 Qualcomm AI SDK、LiteRT、Qualcomm AI Hub、QNN API,以及 PyTorch、ONNX、TensorFlow、GStreamer 等框架。

Hacker News 討論的焦點多半不在 Qualcomm Linux 2.0 的 IoT 定位本身,而是延伸到 Snapdragon X 系列筆電的 Linux 支援現況。多位留言者原本期待 Qualcomm 會正式支援 Snapdragon X2 或 Windows on Arm 筆電上的 Linux,但文章實際聚焦工業與嵌入式平台,因此引發失望。有使用者分享 Surface Pro 11 X1 Elite 與 HP Omnibook X 14 安裝 Linux 的經驗,表示目前仍有穩定性、韌體、風扇控制等問題,距離日常使用仍有落差;也有人提到 HP EliteBook X G2q 的 Linux patch,但其他人指出相關 patch 主要是 device tree,並不代表完整驅動支援已成熟。

討論中也出現對 Qualcomm 開源策略的質疑。有人主張若 Qualcomm 將驅動完整 upstream(送進 Linux 主線),就不需要另做 Qualcomm Linux;回應者則指出,GPL(GNU General Public License,自由軟體授權條款)釋出的程式碼不等於能直接被 Linux 主線接受,還必須符合維護性、架構一致性與品質要求。另有留言提到 QCS6490 單板電腦 Radxa Dragon Q6A 與 MNT 筆電模組,顯示這類平台已有實際硬體生態系,但目前仍可能遇到 Debian 映像選項縮減、NPU(Neural Processing Unit,神經網路處理器)使用受限、I2C 問題等早期痛點。整體看來,開發者肯定 Qualcomm 將 IoT Linux 平台推向更公開、模組化與可維護的方向,但也期待這些投入能更快擴展到消費級 Arm 筆電與主線 Linux 生態。

👥 42 則討論、評論 💬
https://news.ycombinator.com/item?id=48753069
所以Snap不會用Flatpak那種為了與傳統軟體相容而預設申請讀取所有檔案的權限呀,除非用classic
以這個軟體的性質來說 _理論_ 上可以跟 Snap 商店申請一個有支援 classic confinement 的 track,可以試著跟 Snap 發布者提議看看