分类 内核视界 下的文章

大家好,这里是 Linux 用户站带来的内核视界。 今天,Linux 存储领域迎来一个意想不到的新成员,这可能会改变我们与 Windows 文件系统互操作的体验,也反映了开源社区对现有解决方案的不满与主动革新。

1. 资深开发者 Namjae Jeon 发布全新 NTFSPLUS 驱动

Linux 内核开发者 Namjae Jeon(以开发 exFAT Linux 驱动和维护 KSMBD 内核服务器而闻名)近日宣布了全新的 NTFSPLUS 文件系统驱动。这是继内核中原有的只读 NTFS 驱动、用户空间的 NTFS-3G FUSE 驱动,以及近年被上游纳入的 Paragon Software 的 NTFS3 驱动之后,Linux 系统上出现的又一个支持读写的 NTFS 驱动选项。NTFSPLUS 声称在性能和功能上均优于 NTFS3。其开发动机源于对当前 Linux 内核中 NTFS 支持现状的不满:原有的只读“经典 NTFS”驱动已被移除,而 NTFS3 则被描述为“维护不善、存在诸多问题”,导致许多用户和发行版仍在使用旧的 ntfs-3g 用户态驱动。NTFSPLUS 基于原有的、代码更清晰且注释详尽的只读 NTFS 代码重构,旨在支持写入功能,并满足现代内核的要求,如 iomap、无 buffer-head,同时提供工具支持和通过 xfstests 测试,目标是实现高性能和稳定的维护。

硬核点评:
这真是“官方驱动不给力,社区大佬亲自下场”的经典戏码。Namjae Jeon 的履历就是品质保证,他的出手本身就是对 NTFS3 驱动维护状态的一种无声批评。开源世界的魅力就在于此:当某个由商业公司贡献的驱动(指 Paragon 的 NTFS3)可能因种种原因未能达到社区的期望时,总有具备能力和责任感的开发者愿意站出来,从头打造一个更符合开源理念和现代内核标准的解决方案。这对于广大需要在 Linux 和 Windows 之间频繁交换数据的用户来说,无疑是个福音。我们乐见这种基于清晰、可读代码的“重造轮子”,这比在一个“黑盒”或难以维护的代码上修修补补要健康得多。


您对今天的内核视界有何看法?特别是对于“由社区核心开发者重写一个驱动来替代维护不善的商业公司贡献驱动”这一做法,您是否认同?这是开源生态自我修复能力的体现,还是某种程度上的资源重复?欢迎在下方评论区留下您的高见。


【发生了什么变化】
Linux 6.18内核通过合并关键网络补丁,大幅提升UDP接收性能——在DDoS攻击场景下,吞吐量暴增47%,单服务器每秒多处理1420万数据包!此优化更将随Linux 6.18 LTS版本长期覆盖企业级场景。

【谁/什么导致变化】
谷歌工程师Eric Dumazet主导贡献:1)重构数据局部性(sk_backlog等关键结构重排序);2)用单socket自旋锁替代哈希锁数组;3)引入skb_attempt_defer_free()机制(借鉴TCP成功经验)。硬核技术三连击,直指DDoS防御痛点!

短评:
“性能即正义!从内核层‘外科手术式’优化,到LTS版本的普惠落地,Linux再次证明:对抗黑产,代码比口号更有力。” 🔥


消息来源: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 分区是什么时候?欢迎在评论区晒出你的“上古设备”故事。