来源:Better Late Than Never: Linux 6.17 To Enable Intel DG1 Graphics By Default
在 Intel 推出 DG2/Alchemist 独立 GPU 之前,DG1 图形处理器主要作为促进 Intel 现代独立 GPU 发展的初始开发工具。DG1 最终被应用于少量笔记本电脑的 Intel Xe MAX GPU 中,此后的几年中,eBay 上也出现了一些精选的 DG1 显卡。直到 2025 年,上游 Linux 内核驱动程序才为现代 Linux 发行版提供了英特尔 DG1 显卡。
英特尔在 DG1 Linux 支持方面已经努力了半个世纪,而且很明显,英特尔已经开始为 Panther Lake 提供出色的 Alchemist 和 Battlemage 支持,并已经开始为 Xe3 图形支持工作。DG1 现在是一个事后的想法,但由于 DG1 的市场占有率非常有限,因此从未在 Linux 下默认启用 DG1。在 Linux 下使用英特尔 DG1 GPU 需要使用带有 PCI 设备 ID 的"force_probe"模块选项,以便在 Linux 驱动程序栈中强制启用 DG1 显卡。
force_probe 选项是为实验/试生产中启用新的 Intel 图形目标而保留的,但在即将发布的 Linux 6.17 内核中,DG1 将不再使用该选项。正如四月份所写的那样,Linux 驱动程序将放弃对 DG1 的强制探测 。在此之后的几年中,Linux 上的 DG1 并未出现任何已知的问题,但 "force_probe "要求的保留很可能只是一个疏忽。
今天发出了第一个 drm-intel-gt-next 拉取请求 ,其中包含了计划用于 Linux 6.17 的材料。该请求包含在 DG1 上放弃force probe 的补丁。此外还有对 GuC 后端的修复,以解决调度停滞、错误处理改进以及其他各种修复。对最终用户来说,最值得注意的是 DG1 force probe 的移除,它终于可以开箱即用了。
因此,对于拥有 Xe MAX GPU 笔记本电脑或碰巧拥有 DG1 显卡或在 eBay 上购买了 DG1 显卡的用户来说,这无疑是个好消息,但 DG1 显卡目前已经相当老旧,用户最好还是选择 Battlemage、Alchemist 或其他开源友好的 Linux GPU。

姗姗来迟的开箱即用驱动体验,我曾经购买了两张DG1显卡,目前实际属于我的那张正借给朋友使用,我敢说没有比这更好的亮机显卡了。

消息来源:Debian 13 Installer RC2 Fixes An Annoying Issue, Improves Btrfs Rescue Handling
继上个月发布 Debian Installer Trixie RC1 作为即将发布的 Debian 13.0 的安装程序之后,今天又发布了第二个候选版本供测试。
如果安装介质不是真正的 CD,而是 U 盘、SD 卡、ISO 文件或类似文件,Apt-setup 现在将禁用 CD-ROM 源。这样做是因为 APT 无法在安装后使用它。长期以来,从 U 盘安装 Debian 时,当尝试使用 APT 时,需要在安装后注释掉 apt-sources.list 行,这一直是个麻烦事。很高兴看到现在有了这样的改变。

坦白说我在几天前试安装Debian13 RC1的时候就被这个问题坑了一把,这会导致安装后启动无法直接使用apt安装软件包。能获得修正无疑是众望所归。

Debian Installer Trixie RC2 还移除了 BusyBox 中的 wget 小程序,更新了镜像主列表,更新到较新的 Linux 6.12 LTS 内核,安装了 systemd-cryptsetup 和 cryptsetup-initramfs,支持通过 Debian Live 镜像解救通过 Calamares 安装程序安装的 Btrfs 系统,并通过 systemd-boot-installer 在 AMD64 和 ARM64 上安装 shim-signed,以启用安全启动。

我知道很多人现在认为Btrs仍不适合作为主目录分区,但是确实也有一部分人就是这么做的,Fedora现在甚至默认使用Btrs作为安装程序的默认磁盘选项。 总而言之,Debian在向好的方向发展。

尾声:我得提醒一下正在期待Debian13的用户,就在几天前我在实体机上安装试用Debian13 RC1的时候发现Nvida 显卡闭源驱动体验明显不佳,Wayland下仍然存在画面撕裂闪屏的问题。并且在我的3060笔记本上CS2游戏体验和性能表现明显劣于Fedora42 ,这可能是驱动版本导致的,因此我建议各位Debian 用户不要急于安装还未完成的Debian13。


作为一位依赖开源工具搭建个人数字空间的自由软件爱好者,AList项目被秘密收购的消息让我辗转反侧难以入睡。这不是简单的商业交易,而是一场关乎数字主权的微型战争。以下是我的思考与行动建议。


个人立场:被资本击穿的信任契约

尽管我并没有长期使用,但我也曾将AList视为对抗科技巨头的利器——它用AGPLv3协议承诺永远自由,用开源代码构建透明堡垒。但当项目像商品般被悄然转手,当新资方未经审核就植入统计代码,我意识到:自由软件不是免死金牌,代码托管平台的仓库转让按钮,随时可能成为扼杀数字自主权的刑场

开发者Xhofe的"过渡期护航"承诺充满矛盾:既然已收下资本的对价,所谓"暂时审核代码"不过是商业收购的标准安抚话术。真正的危机在于,开源社区奉为圭臬的协作伦理,在资本杠杆前脆弱得像个童话


自由软件理念的三重塌陷

  1. 透明性神话破灭
    收购全程的暗箱操作,彻底背离开源社区"公开决策"的基本准则。当项目主页的commit记录成为唯一的真相拼图,我们与使用闭源软件的用户并无本质区别——都成了信息黑箱中的"数据佃农"。
  2. 协议保护的局限性
    即便AList采用AGPLv3协议,资本仍可通过控制核心仓库、垄断分发渠道实现事实上的集权。新资方对非核心贡献者的权限剥夺证明:协议能约束代码复制,却挡不住治理权的私有化
  3. 工具理性的反噬
    "需要资源维护项目"的辩护词,暴露了自由软件经济的根本困境。当开发者被迫在理想主义与生存压力间抉择,我们是否正在用道德绑架掩盖系统性支持机制的缺失?

普通用户的抵抗路线图

短期行动

  • 立即迁移:切换到AList Community EditionBList,用脚投票支持社区分叉
  • 数字排毒:运行strings命令检查二进制文件,使用Reproducible Builds工具验证构建过程
  • 凭证重置:所有关联网盘API密钥立即更换,切断与商业版的数据脐带

长期策略

  • 去中心化存储:将WebDAV服务器与本地NAS结合,建立不依赖特定中间件的数据管道
  • 贡献者觉醒:每月用2小时参与分叉项目的文档翻译或漏洞报告,哪怕只是提交拼写错误修正

写在最后:自由是场无限游戏

这次事件最深的伤口,不是某个项目的变质,而是它揭示了自由软件运动的阿喀琉斯之踵——我们构建了完美的代码堡垒,却把城门钥匙交给了资本市场。

当我重新配置自托管方案时,想起Richard Stallman的警告:"自由软件关乎权利,而非价格。"或许该修改路由器标签上的GNU宣言了:
"不要问代码能否自由,要问谁掌握着你的数据枷锁。"



核心要点:

  1. 历史包袱终将卸下
    由于长期无人维护(自 2014 年起被标记为“孤儿代码”),Linux 内核开发者 Christian Brauner(微软员工)提议在 2025 年底前移除对苹果 HFS/HFS+ 文件系统的原生内核驱动支持。这一老旧的代码库已成为内核维护的负担。
  2. 苹果早已“弃疗”
    苹果自身早在 macOS 10.6 时代就将 HFS 降级为只读支持,并在 10.15 及以上版本彻底放弃兼容。尽管 HFS+ 仍被部分使用,但 Linux 的驱动实现质量一直较差,且缺乏官方维护。
  3. 替代方案与争议

    • 用户态方案:Linux 用户仍可通过 HFS FUSE 在用户空间挂载 HFS 文件系统。
    • 遗留依赖问题:部分 Linux 发行版依赖 HFS+ 驱动在 Intel Mac 上安装(因其 EFI 系统分区可能使用 HFS+),未来可能仅移除 HFS 驱动而保留 HFS+。

“代码如逆旅,旧枝当剪则剪。” 此次提案再次凸显开源生态对技术债务的零容忍态度。苹果生态的封闭性与 Linux 的维护成本本就矛盾,FUSE 的成熟已为过渡铺平道路。若无开发者主动接手维护,这场“断舍离”或将如期而至。

你的 Linux 系统最近一次访问 HFS 分区是什么时候?欢迎在评论区晒出你的“上古设备”故事。