[Linux中国合辑]

[ErrorEutopia]

2023 年开源和 Linux 世界的 8 个决定性时刻

2024-01-05 16:28

译自：https://news.itsfoss.com/best-open-source-linux-stories-2023/ 作者： Ankush Das
原创：LCTT https://linux.cn/article-16535-1.html 译者： geekpi

回顾 2023 年的过山车之旅。

对于 Linux 和开源，每年都会带来一些惊喜和冲击。

可能有的 Linux 发行版改变其基础，也可能某个独立项目被大型科技巨头接管，以及其他各种情况。在整个 2023 年，我们将竭尽所能，为你带来过山车般的体验。

如今，这一年已经结束了。现在是时候回顾一下 2023 年发生的一些重大事件了。

1、Ubuntu 首次推出 “Flutter” 商店

Ubuntu 的“软件中心”因其变化和改进而始终成为热门话题。

今年，Ubuntu 加大了力度，在 Ubuntu 23.10 中引入了新的基于 Flutter 的 “Ubuntu 商店”，提供了现代而流畅的用户体验。

它最终将取代 Ubuntu 多年来的软件中心，在我看来这是一件好事。

** :其他发行版可以用咩?

2、印度防卫服务转向 Linux

印度国防部决定用内部开发的名为 “Maya” 的 Linux 发行版取代 Windows。

当然，这并不是政府机构第一次决定使用 Linux 来提高安全性和隐私性。

然而，在像印度这样的国家，在政府机构的某个部门使用 Linux 的一个简单选择可能会对其他系统产生巨大的影响。而且，这对于 Linux 来说通常是一件非常好的事情。

** :Linux的大成功!虽然中国也有就是了

3、红帽的源代码锁定

最大的开源公司红帽决定将红帽企业 Linux（RHEL）的源代码锁定在付费墙后面。

虽然他们仍然允许个人开发人员通过免费订阅访问源代码，但不再像以前那样向所有人公开访问。

这一变化波及了所有基于 RHEL 的发行版和分叉：

红帽的源代码封锁给 CentOS 替代品带来灾难： Rocky Linux 和 AlmaLinux 面临困境？[1]

从 SUSE、甲骨文和其它竞争对手联手开发 RHEL 分支，到 Rocky Linux 和 AlmaLinux 等项目的各种其他更改。

对我来说，这是 2023 年最大的新闻，并将在 2024 年继续产生影响。

为打击 IBM，SUSE 将分叉 RHEL[2]

** :可真有你的,红帽

4、Linux 内核 LTS 支持周期的变更

为了减轻 Linux 维护人员的负担，LTS 内核的支持周期从六年降至两年。

据评估，使用较旧的 Linux 内核版本的人并不多，而且许多 LTS 版本的内核已经维护多年，这对于维护人员来说是一项艰巨而繁琐的任务。

作为用户，你不必担心它，除非你依赖较新的 Linux 内核上不再存在的特定硬件支持。

** :更新党狂喜,只要不挂就可以

5、Ubuntu 不再支持所有版本的 Flatpak

毫不奇怪，Canonical 的 Ubuntu 更青睐 Snap 软件包。

然而，Ubuntu 的各个版本确实有提供 Flatpak 支持的自由，比如 Ubuntu MATE。

不幸的是，Ubuntu 取消了默认的 Flatpak 支持[3]，理由是一致的用户体验。

当然，你可以手动添加 Flatpak 支持，但这不再是开箱即用的便利。

这个改变会影响你吗？ 好吧，如果你知道 Flatpak 与 Snap[4] 之间的选择，你就已经知道答案了。

** :还好我不用Ubuntu

6、出现了一个滚动发布的 Ubuntu 发行版

在所有其他有趣的发行版本中，Rhino Linux 发布了稳定版本。它的目标是在 Ubuntu 之上提供滚动发布体验。

你可以在我们的报道中探索有关该版本的更多信息：

基于 Ubuntu 的 Rhino Linux 滚动发行版已发布[5]

7、Vim 创建者去世了🥺

今年，我们失去了 Linux 领域的一位杰出创造者，Bram Moolenar，他是 Vim[6] 文本编辑器背后的传奇人物。

他的目标是改进最初是为 Unix 创建的 vi[7] 文本编辑器。

然后，Bram 在 vi 及其克隆的源代码的基础上构建，通过添加新功能对其进行改进，最后发布了第一个版本 “Vi IMitation”，由此得到了“Vim”的首字母缩写。

** :世界上最短的悼词为他所书写 ":wq"

8、Linux 游戏统计数据超越 macOS

作为 Linux 用户，我们对统计数据非常重视，并在达成里程碑时庆祝。例如，每月都会监测 Linux 桌面市场份额[8]。

今年，在 Steam 的统计报告中，Linux 使用率统计数据高于 macOS。你可以在这里获取详细信息：

Linux 崛起：Steam 的游戏使用率超过 macOS[9]

** :LInux不知道几杀了,此次,我和Linux将嘎嘎乱杀!我负责嘎嘎,Linux负责乱杀!!!

总结

2023 年发生了很多事情

例如，我们发现了各种令人兴奋的应用：

2023 年深受 Linux 用户喜爱的 8 个令人兴奋的开源应用程序[10]

不要忘记，发行版领域中的一些新成员引起了人们的关注：

2023 年崭露头角的 7 款不为人知的 Linux 发行版[11]

对你来说，2023 年最大的震惊（快乐/悲伤）是什么？ 请在下面的评论中告诉我们。

via: https://news.itsfoss.com/best-open-source-linux-stories-2023/

作者：Ankush Das[12] 选题：lujun9972[13] 译者：geekpi[14] 校对：wxy[15]

本文由 LCTT[16] 原创编译，Linux中国[17] 荣誉推出

• 1:https://news.itsfoss.com/red-hat-restricts-source-code/
• 2: https://news.itsfoss.com/suse-rhel-fork/
• 3: https://news.itsfoss.com/ubuntu-flavor-drops-flatpak/
• 4: https://itsfoss.com/flatpak-vs-snap/
• 5: https://linux.cn/article-16110-1.html
• 6: https://www.vim.org/
• 7: https://en.wikipedia.org/wiki/Vi
• 8: https://itsfoss.com/linux-market-share/
• 9: https://news.itsfoss.com/linux-steam-macos/
• 10: https://news.itsfoss.com/exciting-apps-2023/
• 11: https://linux.cn/article-16532-1.html
• 12: https://news.itsfoss.com/author/ankush/
• 13: https://github.com/lujun9972
• 14: https://github.com/geekpi
• 15: https://github.com/wxy
• 16: https://github.com/LCTT/TranslateProject
• 17: https://linux.cn/article-16535-1.html?utm_source=rss&utm_medium=rss
  原文地址:链接

[ErrorEutopia]

使用 NFS 将 Git 提交记录显示成文件目录

2024-01-08 16:43

译自：https://jvns.ca/blog/2023/12/04/mounting-git-commits-as-folders-with-nfs/ 作者： Julia Evans
原创：LCTT https://linux.cn/article-16542-1.html 译者： guevaraya 

大家好！某天，我突发奇想 —— 是否能把 Git 存储库制作成一个 FUSE 文件系统，然后把所有的提交记录做成文件夹呢？答案是肯定的！有 giblefs[1]、 GitMounter[2] 和用于 Plan 9 号的 git9[3]。

但在 Mac 上使用 FUSE 实在很烦人 —— 你需要安装一个内核扩展，但由于安全的原因，Mac OS 上安装内核扩展看起来越来越难了。此外，我还有一些想法，希望能用与这些项目不同的方式来组织文件系统。

因此，我想在 Mac OS 上尝试 FUSE 以外的挂载文件系统的方法会很有趣，因此我创建了一个名为 git-commit-folders[4] 的项目来做这个事。它可以同时使用 FUSE 和 NFS（至少在我的电脑上），WebDav 的实现起来还有点问题。

这个项目很有实验性（我不确定这究竟是一个有用的软件，还是一个思考 Git 如何工作的有趣玩具），但写起来很有趣，我自己也很喜欢在小型存储库中使用它，下面是我在写这个项目时遇到的一些问题。
目标：像文件夹一样显示提交记录

我做这个事的主要目的是给大家一些启发：Git 核心是如何运行的。总结来说，Git 提交记录实际上和文件夹非常类似 —— 每个 Git 提交都包含一个目录，其中 列出了文件[5]，这个目录也可以有子目录，依此类推。

只是为了节省磁盘空间，Git 提交实际上并不是以文件夹的形式实现的。

而在 git-commit-folders，所有的提交记录实际上看起来就是一个文件夹，如果你想浏览历史提交记录，你可以像浏览文件系统一样浏览它们！例如如果你像查看我的博客的初始提交记录，你可以如下操作：

$ ls commits/8d/8dc0/8dc0cb0b4b0de3c6f40674198cb2bd44aeee9b86/
README

其他之后的提交记录，如下：

$ ls /tmp/git-homepage/commits/c9/c94e/c94e6f531d02e658d96a3b6255bbf424367765e9/
_config.yml  config.rb  Rakefile  rubypants.rb  source

分支是符号链接

通过 git-commit-folders 挂载的文件系统中，提交是唯一真正的文件夹 —— 其他一切（分支、标签等）都是提交记录的符号链接。这反映了 Git 底层的工作方式。

$ ls -l branches/
lr-xr-xr-x 59 bork bazil-fuse -> ../commits/ff/ff56/ff563b089f9d952cd21ac4d68d8f13c94183dcd8
lr-xr-xr-x 59 bork follow-symlink -> ../commits/7f/7f73/7f73779a8ff79a2a1e21553c6c9cd5d195f33030
lr-xr-xr-x 59 bork go-mod-branch -> ../commits/91/912d/912da3150d9cfa74523b42fae028bbb320b6804f
lr-xr-xr-x 59 bork mac-version -> ../commits/30/3008/30082dcd702b59435f71969cf453828f60753e67
lr-xr-xr-x 59 bork mac-version-debugging -> ../commits/18/18c0/18c0db074ec9b70cb7a28ad9d3f9850082129ce0
lr-xr-xr-x 59 bork main -> ../commits/04/043e/043e90debbeb0fc6b4e28cf8776e874aa5b6e673
$ ls -l tags/
lr-xr-xr-x - bork 31 Dec  1969 test-tag -> ../commits/16/16a3/16a3d776dc163aa8286fb89fde51183ed90c71d0

这个并不能完全呈现 Git 的所有工作机理（相比简单的类似文件夹的提交，还有很多复杂的细节），但是我希望大家对“每个提交如同一个文件夹，里面有你的旧版本代码”有一个直观的认识。
这么做有什么好处呢？

在我深入介绍它的实现之前，我想说下为什么把 Git 提交记录变成拥有文件夹的文件系统很有用。我的很多项目最终都没有真正使用过（比如 dnspeep[6]），但我发现自己在做这个项目的时候确实使用到了一些。

目前为止我发现主要用处是：

查找已经删除的函数 - 可以用 grep someFunction branch_histories/main/*/commit.go 查找它的旧版本
快速查看其他分支的一个文件并从其拷贝一行，如 vim branches/other-branch/go.mod
在每个分支中搜索某个函数，如 grep someFunction branches/*/commit.go

所有这些操作都通过提交记录的符号链接，来替代提交记录的直接引用。

这些都不是最有效的方法（你可以用 git show 和 git log -S 或者 git grep 来完成类似操作），但是对我个人来说，我经常忘记 Git 语法，而浏览文件系统对我来说更简单。git worktree 还允许你同时签出多个分支，但对我来说，为了看一个文件而设置整个工作树感觉很奇怪。

接下来我想谈谈我遇到的一些问题。
问题 1: 用 WebDav 还是 NFS?

Mac OS 原生支持的两个文件系统是 WebDav 和 NFS。我说不出那个更新容易实现，所以我就索性尝试两个都支持。

起初，WebDav 的实现看起来更容易一些，在 golang.org/x/net[7] 上有一个 WebDav 实现[8]，这个很好配置。

但这个实现不支持符号链接，我想可能原因是它用的是 io/fs 接口，而 io/fs 还不支持 符号链接[9]。不过看起来正在进行中。所以我放弃了 WebDav，而决定重点放在 NFS 实现上了，用 go-nfs[10] NFSv3 的库文件来实现。

有人也提到了 Mac 上的 FileProvider[11]，我还没有深入了解这个。
问题 2: 如何确保所有的实现保持一致？

我已经实现了三个不同的文件系统（FUSE、NFS 和 WebDav），但对我来说还是没搞清楚如何避免大量的重复代码。

我的朋友 Dave 建议写一个核心实现，然后写一个适配器（如 fuse2nfs 和 fuse2dav）来转换成 NFS 和 WebDav 版本。这个看起来需要我着手实现三个文件系统的接口：

对应 FUSE 的 fs.FS
对应 NFS 的 billy.Filesystem
对应 WebDav 的 webdav.Filesystem

因此我把所有的核心逻辑放到 fs.FS 接口上，然后写两个函数：

func Fuse2Dav(fs fs.FS) webdav.FileSystem
func Fuse2NFS(fs fs.FS) billy.Filesystem

所有的文件系统都比较类似，因此转换起来不是很难，但就是有大量的烦人的问题需要修复。
问题 3: 我不想罗列所有的提交记录怎么办

一些 Git 存储库有成千上万的提交记录。我的第一个想法是如何让 commits/ 看起来是空的，这样就可以如下展示：

$ ls commits/
$ ls commits/80210c25a86f75440110e4bc280e388b2c098fbd/
fuse  fuse2nfs  go.mod  go.sum  main.go  README.md

因此所有的提交记录可以直接查看，但是又不能罗列它们。这个对文件系统是一个奇怪的事情，实际上 FUSE 可以做到。但我在 NFS 上无法实现。我认为这里的原因是，如果你告诉 NFS 某个目录是空的，它就会认为该目录实际上是空的，这是合理的。

我们最终是这样处理的：
按照 .git/objects 的方式，以前两个字符组织管理提交记录（因此 ls commits 会显示 0b 03 05 06 07 09 1b 1e 3e 4a），

但这样做会分为两层，这样 18d46e76d7c2eedd8577fae67e3f1d4db25018b0 则为

commits/18/18df/18d46e76d7c2eedd8577fae67e3f1d4db25018b0
开始只罗列一次所有的已经打包的提交哈希，将它们缓存在内存中，然后后面仅更新稀疏对象。主要思路是版本库中几乎所有的提交都应该打包，而且 Git 不会经常重新打包提交

这个看起来在拥有百万提交记录的 Linux 内核的 Git 存储库上似乎效果不错。在我的机器上实测它初始化大概需要一分钟，之后只需快速增量更新即可。

每个提交哈希只有 20 个字节，因此缓存 1 百万个提交哈希也不是很大，大约 20MB。

我认为更聪明的做法是延迟加载提交列表 —— Git 会按提交 ID 对其打包文件进行排序，所以你可以很容易地进行二叉树搜索，找到所有以 1b 或 1b8c 开始的提交。我用的 Git 库[12] 对此并不支持，因为罗列出来 Git 存储库所有的提交记录确实一个奇怪的事情。我花了 几天时间[13] 尝试实现它，但没有达到我想要的性能，所以就放弃了。
问题 4: 不是目录

我常遇到下面这个错误：

"/tmp/mnt2/commits/59/59167d7d09fd7a1d64aa1d5be73bc484f6621894/": Not a directory (os error 20)

这起初真的把我吓了一跳，但事实证明，这只是表示在列出目录时出现了错误，而 NFS 库处理该错误的方式就是显示 “Not a directory”（不是目录）。这个错误遇到了很多次，我需要每次跟踪这个错误的根源。

有很多类似错误。我也遇到 cd: system call interrupted，令人沮丧的是，但最终也只是程序中的其他错误。

我意识到终极大法是用 Wireshark 查看 NFS 发送和接受的数据包，很多问题便可迎刃而解。
问题 5: inode 编号

在开始的时候我不小心将所有的文件夹的 inode 设为 0。这很糟糕，因为如果在每个目录的 inode 都为 0 的目录上运行查找，它就会抱怨文件系统循环并放弃，这个也是符合逻辑的。

我通过定义一个 inode(string) 来修复这个问题，通过散列字符串来获取 inode 编号，并使用树 ID / blob ID 作为散列字符串。
问题 6: 过期文件句柄

我一直遇到这个“Stale NFS file handle”（过期文件句柄）错误。问题是，我需要获取未知的 64 字节 NFS “文件句柄”，并将其映射到正确的目录。

我使用的 NFS 库的工作方式是为每个文件生成一个文件句柄，并通过固定大小的缓存来缓存这些引用。这对小型存储库来说没问题，但是如果对于拥有海量的文件的存储库来说，由于缓存就会溢出，就会导致“stale file handle” 错误。

这仍然是个问题，我不知道如何解决。我不明白真正的 NFS 服务器是如何做到这一点的，也许它们只是有一个非常大的缓存？

NFS 文件句柄占用 64 个字节（不是比特），确实很大，所以很多时候似乎可以将整个文件路径编码到句柄中，根本不需要缓存。也许我会在某个时候尝试实现这一点。
问题 7: 分支历史

branch_histories/ 目录目前仅罗列对应分支的最近 100 个提交记录。我不知道该怎么做，如果能以某种方式列出分支的全部历史就更好了。也许我可以使用 commits/ 目录中类似的子文件夹技巧。
问题 8: 子模块

Git 存储库有时包含了子模块。由于目前我对子模块的理解还不深入，我先忽略它吧。因此这个算是一个问题。
问题 9: NFSv4 是否更好？

我构建这个项目使用的是 NFSv3 库，因为我当时只能找到一个 NFSv3 的 Go 库文件。可当我搞完的时候才发现了一个名叫 buildbarn 的项目里有 NFSv4 服务器[14]。有没有可能用它会更好一些？

我不知道这样做有什么问题，或者用 NFSv4 有哪些优点？我还有点不确定是否要使用 buildbarn NFS 库，因为不清楚他们是否希望其他人使用它。
就这些吧

之前已经解决了很多问题我都忘记了，这是我目前能回想起来的。我未来有可能解决或根本解决不了 NFS 的“过期文件句柄” 错误，或者“在 Linux 内核的存储库上启动需要 1 分钟”的问题，就这样吧。

感谢我的朋友 vasi[15]，他给我了很多文件系统方面的帮助。

（题图：DA/d22b1c01-e80a-4529-b88a-419ceef74b5e）

via: https://jvns.ca/blog/2023/12/04/mounting-git-commits-as-folders-with-nfs/

作者：Julia Evans[16] 选题：lujun9972[17] 译者：guevaraya[18] 校对：wxy[19]

本文由 LCTT[20] 原创编译，Linux中国[21] 荣誉推出

[1]: https://github.com/fanzeyi/giblefs
[2]: https://belkadan.com/blog/2023/11/GitMounter/
[3]: https://orib.dev/git9.html
[4]: https://github.com/jvns/git-commit-folders
[5]: https://jvns.ca/blog/2023/09/14/in-a-git-repository--where-do-your-files-live-/#commit-step-2-look-at-the-tree
[6]: https://github.com/jvns/dnspeep
[7]: http://golang.org/x/net
[8]: https://pkg.go.dev/golang.org/x/net/webdav
[9]: https://github.com/golang/go/issues/49580
[10]: https://github.com/willscott/go-nfs/
[11]: https://developer.apple.com/documentation/fileprovider/
[12]: https://github.com/go-git/go-git
[13]: https://github.com/jvns/git-commit-folders/tree/fast-commits
[14]: https://github.com/buildbarn/bb-adrs/blob/master/0009-nfsv4.md
[15]: https://github.com/vasi
[16]: https://jvns.ca/
[17]: https://github.com/lujun9972
[18]: https://github.com/guevaraya
[19]: https://github.com/wxy
[20]: https://github.com/LCTT/TranslateProject
[21]: https://linux.cn/article-16542-1.html?utm_source=rss&utm_medium=rss

[ErrorEutopia]

作者： Linux中国 硬核老王 | 2024-01-21 20:42

1. 海尔要求开发者下架开源的家庭助理插件

海尔向一名德国开发人员发出了一份移除通知，要求他立即从 GitHub 平台上删除他为该公司家电产品开发的 家庭助理Home Assistant 集成插件。“家庭助理”是一个开源的家庭自动化平台，用户可以通过一个集中的界面控制智能家居设备并使其自动化。除了便利性和成本外，该平台还提供了同类商业应用程序所不具备的卓越安全和隐私选项。在通知中，海尔声称“这些插件正在以未经授权的方式”使用其服务，对该公司“造成了重大经济损失”，侵犯了海尔的知识产权，要求开发者“立即停止和终止与开发和分发这些插件有关的所有非法活动”，以避免进一步的法律诉讼。

消息来源：Bleeping Computer

老王点评：愿开源开发者们不要为这种公司开发任何相关软件，以免惹火上身。大家知道那些家电厂商是支持开源软件的吗？

2. ReiserFS 作者在狱中回应被内核移除

ReiserFS 文件系统作者 Hans Reiser 因谋杀妻子被判处监禁。去年底，他在狱中回复了一封长长的纸质信函，回应了内核的相关讨论，在信中对自己的罪行表示了道歉，称自己已经是不同的人了。他随后讨论了对 ReiserFS 的贬低以及他对 Reiser4 的希望，对曾使用 ReiserFS 的发行版 SUSE 没能在市场上取得成功而遗憾。在 Linux 6.6 中，ReiserFS 已被正式标记为“过时”，将在未来几年来从主线内核中移除。

消息来源：Phoronix

老王点评：可惜了。

3. 谷歌推出画圈即搜索的“画圈搜索”功能

谷歌最近推出的“画圈搜索Circle To Search”功能，可以让你在手机屏幕上圈出某样东西，然后点击一个按钮，即可通过谷歌搜索你圈出的东西。该功能将首先在谷歌和三星的五款手机上推出。它可以设备上的任何地方搜索，而无需打开谷歌应用。它也可以结合谷歌的“多重搜索”功能，你可以用圈出的图片和文字组合搜索。谷歌称，当你想知道 “为什么” 而不仅仅是 “是什么” 时，多重搜索就是你需要的工具。

消息来源：The Verge

老王点评：看起来是有趣的功能，尤其是和 AI 结合起来的话会更有用。

原创：Linux中国 https://linux.cn/article-16573-1.html作者： 硬核老王

本文由本站网友原创，Linux中国首发。也想发表您的文章，为开源做一些自己的贡献么？欢迎投递！
欢迎遵照 CC-BY-SA 协议规定 转载，敬请在正文中标注并保留原文/译文链接和作者/译者等信息。
文章仅代表作者的知识和看法，如有不同观点，请楼下排队吐槽 :D

[ErrorEutopia]

好家伙,我以后不买海尔的东西了[doge]

[ErrorEutopia]

“Linux 中国” 开源社区，停止运营

作者： Linux中国 硬核老王 | 2024-02-01 12:37
这是一个艰难的决定 —— 这不是调侃，而是当你真正做出改变了你十几年生活轨迹的决定时，你就会明白这个决定确实艰难。

在写这篇告别信之前，我久久停笔不前。然而，要说的话，其实在我心里已经反复思考了好几遍。

从即日起，“Linux 中国” 这个社区，包括它的主网（ https://linux.cn/ ）、公众号、视频号，以及下属的《硬核观察》栏目，将无限期停止更新和运营。

停止运营的原因其实很平常，大抵包括以下几个方面：

“Linux 中国” 已经完成了其历史使命

最初，我们的愿望是想把 “Linux 中国” 建设成一个传播开源技术的公益型社区。但是经过十几年的发展，目前开源文化和 Linux 相关的开源技术已经得到了广泛传播（在这期间，我们或许也做了一些小小的贡献）。因此，继续运营所能起到的作用并没有那么大了。

出于偶然原因，“Linux 中国” 其实并未按照我们的最初设想发展，这么多年下来，真正坚持下来的项目也就是一个翻译团队 LCTT，翻译了数千篇文章，引导数百人参与了开源贡献。然而，近年来，随着计算机翻译技术的进步，尤其是 ChatGPT 的出现，翻译工作的必要性大为降低。自去年以来，我一直使用 ChatGPT 来翻译一些文章，尽管还需要一至两次校对，但基本没什么大问题。所以，LCTT 的存在也显得不那么重要了。

事实上，LCTT 已经陷入了一种半死亡状态，数百名贡献者基本上都处于休眠了状态，甚至由于技术原因，连自动化选题工作都难以维持。唯一能持续翻译的，除了我，就是我们的首席译者 geekpi 了。从这个角度来看，这已经不再是一个社区化的翻译组织了。

最初的方向选择和理想主义无法避免的结果

2003 年，在创立 “Linux 中国” 之前，我还创立过另外一个叫做 “炎黄角马（CNGNU）” 的开源技术社区。但后来因为我创业失败，这个社区就关闭了。随后，我的弟弟王兴江利用我手中闲置的域名 linux.cn 建立了一个新的网站，我们给它起了一个狂妄的名字 “Linux 中国” —— 实际上，需要澄清的是，我们和 Linux 的官方机构没有任何关联，也不代表 Linux 官方。

建立这个网站（社区）的初衷是为了传播知识和文化，并没有考虑过未来的盈利模式，这也导致我们后来排斥将社区变成一个商业网站，去做一些培训、会议之类的商业活动。

但这带来了巨大的资金压力，尤其是在托管服务器价格高昂的那段时期。幸运的是，我们得到了七牛云在 CDN 方面的赞助、阿里云在 PR 方面的投放，让我们得以发展。当然，还有一些其它的广告主和朋友的赞助，稍后容我一一致谢。

2015 年，我离开了中国电信，成为了一名自由人，没有人再给我发工资了。这些年，“Linux 中国” 有一些收入，主要是为广告商撰写和发布的一些文章，但是收入不太稳定。而在众所周知的那三年里，收入状况甚至更惨淡。说实话，过去几年，我大致处于一种个人经济上的慢性失血状态。

所以，现在，当整体经济不佳时，压力更大。

个人疲惫和人生的交叉路口

近些年，“Linux 中国” 越来越像是一个 “个人” 网站，几乎所有的流程都需要我亲自来完成。“Linux 中国” 的公众号自从开设的第一天起，就没有任何一天停止过更新 —— 无论是年三十还是我的身体抱恙，无论是在出差路上还是带家人出游。这两年，我又开始了《硬核观察》栏目，这需要我每天花费数小时采编、录制和发布视频，如今也有了 1263 期，从未停歇。

累吗？累，但更累的是，没有尽头的累。

我今年正好五十岁了，对我来说，这个年龄是我需要重新定位人生的一个标志点。当我三十岁时，我颇有一种 “顿觉昨日非” 的感觉，从此改变了人生轨迹；当我四十岁时，经历了父亲去世、稍后几年弟弟及其他亲人陆续去世的打击；今年，我再次站在人生的交叉口，我想我应该有所改变了。

幸运的是，我一直非常担心的身体健康，目前还算还没有出现大问题。前段时间去做了好几年没敢做的体检，基本上没太大的问题。

没有别的选择了吗？
坦白说，我认真反复想过。

但是，我没有找到合适托付 “Linux 中国” 的人或机构。一个不盈利、持续亏损的社区，很难找到能保持其独立性和原则的托付人。

我也不愿意将 “Linux 中国” 所有的资产都卖给商业机构。有人曾经愿意出高价买我们的域名，但是，他们出的价远远买不起我为此出售良心和名誉的代价。

总的来说，就是因为这些大大小小的原因，我做出了艰难的决定，结束这些年的坚持。对不起了，大家。

对不起
做这个决定前，我最无法放下的不是我投入的那么多精力，而是那些始终坚定支持 “Linux 中国” 的朋友们。包括那 174 位在微信公众号上“几乎看过你所有的内容”的读者，也包括经常在 B 站上给《硬核观察》留言数百字、期期不落都观看和点评的观众，以及 “Linux 中国” 主网上那些熟悉的评论者的 ID 和定位，他们让我倍感感动和内疚。对不起，是我让你们失望了，辜负了大家的期待和支持。

感谢
除了道歉，我还需要感谢很多人。

首先，我要感谢参与过社区的许多人，包括 LCTT 的五百多位贡献者和社区的朋友们。特别要感谢 bestony、geekpi、oska874、lujun9976、vizv、lkxed 等主要贡献者。“Linux 中国” 开源社区，其实是你们的，是大家的，而不是我的。能与大家共同拥有这样一段美好回忆，是我的荣幸。在此，我不能一一尽数所有贡献者，你可以在 https://linux.cn/lctt-list 看到 LCTT 全部贡献者的名单和贡献量。

其次，要感谢在 “Linux 中国” 成长过程中帮助过我们的许多公司。这包括七牛云、阿里云、UCloud、腾讯云、EasyStack、华为、字节跳动、青云、马哥教育、刘遄老师等等，以及我一时无法全部记起的朋友们。他们都是我们这些年得以一路走来的助力。

最后，我要感谢那些我可能完全不知道名字的支持过 “Linux 中国” 的人，就像我说的，“你的每次点击和分享都是对我们的支持” 的读者，以及那些在社区活动中总能认出来我的人。

接下来
这篇告别信发出后，除非有特殊情况，我将停止在 “Linux 中国” 的主网、公众号、视频号、B 站等所有渠道的内容发布。

我会在春节期间将 “Linux 中国” 所有发布的文章都打包成一份电子书，供大家收藏留用，所以大家不必自己用网络爬虫来抓取了。当然，我们的主网和公众号都会保持相当长的时间的访问，只是我可能不再更新了。

至于我个人呢？
我今年计划躺平几个月，然后准备一个人出门走走，或许是自驾，或许是摩旅，去寻找一下人生的意义。我可能会在我的视频号 “硬核老王” 中发布我的行程，也可能会停留在某个地方，可能会经过你的城市，也许我们可以把酒（水）言欢。

江湖再见，诸位。

“Linux 中国” 创始人 硬核老王

2024/2/1

https://linux.cn/article-16602-1.html

[ErrorEutopia]

江湖再见 !