这并不能算是一篇博客，算是对最近和大伙沟通交流的一些记录。
最近闲来无事，和群友聊天，讨论要不我们一起产个操作系统？
这事儿听上去很困难。不过，实际操作一下发现并不难。
比如如果你阅读过 ArchLinux 的文档，体验一次 Arch 的手工安装，你会发现这就是现场搓了个系统：
https://wiki.archlinux.org/title/installation_guide
当然，它没有图形界面。如果你需要图形界面，你一个:
pacman -S gnome-shell
再一重启，gdm，gnome 就都来了：
看起来这内核还挺新的。
有群友笑话我：
neofetch 这种东西，完全是一种“用户忠诚”。对于这种 Legendary 的软件，我们都知道 Deprecate 不掉，也都知道有更好用的，但是老东西很多时候仍然在社区里会有忠诚的影响力。
就像 Windows 1.0 就引入了控制面板，Windows Vista 重构过一次，到 Windows 8 以后，事实上就不再增加新功能，以后的版本都藏得很深，生怕用户还去用控制面板。甚至你点里面的设置项也给你跳到设置里去。
但是就是大家非要用。没办法，有太多手册，太多文档，太多网络工程师的经验已经基于控制面板了。甚至在未来很长一段时间控制面板都砍不掉，即使它不加新功能。连我也喜欢用控制面板来改IP和防火墙设置。这玩意儿我对它的评价就是 Legendary 。新的替代品有多好，老的经典都不想丢。
说回正题，有群友说，Arch 算比较简单的了。如果你是 Gentoo，怕不是现场编译起来了：
是啊，人家 Gentoo，NixOS 的用户，怕不是人均都是 Linux 发行版发行商。
我自己谷歌找到了一个 https://github.com/clayrisser/linux-factory 。神特么批量 Linux 发行版生产机。配的图很好玩：
你clone下来，改改里面的配置文件.yaml，然后一个make，立马出来ISO。想加啥加啥。build出来的Linux发行版是基于Debian的。
改改这几个属性，build出来的iso就跟着变。
怎么说呢，如今自研 Linux 发行版的生态已经无比发达了。无脑小白搜索三分钟，轻松造出国产操作系统。无数 Linux 用户其实都是发行版的生产商。这么想，是不是这件事几乎没有门槛？
但是同时，我真的很好奇一件事：我认识的每一个arch linux用户，都经历过滚更新把自己滚炸了的故事。毕竟 Arch 是滚动更新，没有所谓的固定重要的组件在几个大版本的这种事。
那么 Arch 用户究竟是怎么生活的？女朋友来家里说看个电影吧，你打开电视抱来电脑，准备开机播放电影，结果 Kernel Panic，难道在女朋友面前现场 Debug 内核？
有人说：有快照不就行了？
问题是当你需要滚快照的时候，你已经在一个非常痛苦的状态了。站在用户角度可以接受的话，你自己造操作系统，这件事就不可接受了。
你自己造操作系统，你造的操作系统可能是被你的七大姑八大姨使用的。你不能指望用户有技能确保你的肮脏的组件的 HA。
所以如果你自己是架构师，用了一大堆技术，你可以允许这些技术炸一炸，你自己设计HA，你自己设计分布式，自己备份，自己快照，自己 AB 分区。你有无数的办法。但是如果你是造基础设施的，指望别人备份？指望别人设计HA？指望别人折腾分布式？指望别人滚快照？这就是不可接受的了
七大姑八大姨滚动更新滚炸了只会过来骂你。这就好比，如果你是造汽车的，当一个功能已经需要安全带正常工作才能保证的时候，事故已经发生了。你应该想办法避免事故。
为什么这么多年了，RAID技术、备份技术已经这么先进，造硬盘的仍然还要承诺多少时间硬盘不坏？不就是，你虽然知道你自己会修，但永远有用户买来你的硬盘忘记备份，坏了就只能找你。
说回主线：
如果你不打算滚动更新，唯一的方法就是把你依赖的包锁死在一个没有 Bug ，维护周期比较长的大版本上，然后去backfill一些安全性更新。然后每隔两年，此时各个组件变化已经很大了，然后再把各个组件的lts版本重新放一起测试稳定性、兼容性，然后再锁死在那个版本，再backfill安全更新，以此往复。
我要是还想有生活的话，我肯定这么干，我要是还想有生活的话，我肯定这么干，不至于每次滚动更新，配置文件语法变了。我宁愿稳定两年，每隔两年再花一个下午研究一下这两年各个包都变化了什么。
自己这么用还行，但是如果是发布发行版就更难了。其实发行本身难度奇低，真正痛苦的就是你怎么管理你支持的包的版本。
每一个包的每个情境下的新版本升级都可能造成breaking change，你需要将这些breaking change锁死在可控的范围。当然如果你要是不嫌麻烦，你可以手工开发migration script。但是众所周知世界上的包多如星辰，如果你all in latest你的用户一定会每天滚炸。你还得精准的在众多包使用不同的分支管理策略的背景下，精准的找出它们的变更里，没有breaking change，是在修vulnerbility的commit，backfill过来，推出安全更新……
做这么多仅仅只是为了保证用户在用你的操作系统时可以一个 upgrade 跑完了以后保证不炸，这肯定不是一个人干的了的。这还是需要一家公司，几百名工程师，盯着包看，每周开会讨论基础的包的升级策略。
https://repology.org/repositories/graphs
如上图，Ubuntu的包已经算是比较多的了（虽然都比较老）：
读者或许会困惑。Ubuntu的包这么多？那Nix呢？那Arch呢？
这是因为我这个图其实是截取的一个小部分。完整的图是这样的：
2024年，出一个自主研发的国产操作系统，门槛是：太低，又，太高。
太低是因为：Linux已经太成熟了。把内核搞过来，弄个包管理，装个sh就有命令行了。装个gdm，装个gnome，装个mutter，图形界面已经来了。装几个应用已经能用了。手搓操作系统，一天不是梦。
太高是因为：你要想保证你这个操作系统可以安全稳定快速的持续运行下去，你得一直有稳定的版本、持续的安全更新，这背后就需要你充分理解用户可能在这个操作系统上干出来多少事情、安装多少软件、这些软件都有哪些分支、都是如何管理质量的、怎么从中避免breaking change的同时、如何修复它们的vulnerbility……这就不是十几个人一两个下午搞得定的了。
有群友说，所有软件都用 Monolithic 架构怎么样？
有些依赖不是这么可以带的了的。我举个例子：众所周知，老版本的 gnome 网络设置只支持 NetworkManager。以至于如果你安装的网络管理器不是NetworkManager，Gnome的图形界面设置就完全不顶用。这里NetworkManager就成了Gnome的依赖了。
但是新版本的 Gnome 把 NetworkManager 砍了，换成了networkd。如果用户对着gnome更了个新，难道就上不了网了？
这个时候你唯一的办法，就是写一个迁移脚本，帮用户把Networkmanager的配置文件翻译成Networkd的。但是这俩配置文件语法都不一样，支持的功能也不一样，且不说你有没有人力为每一个这种软件开发migration script，你的翻译未必是等价的。
而如果你自己出Linux发行版，这种breaking change简直家常便饭。说不定哪个浏览器今天的内核是自研的，明天就换成 Chromium。说不定今天还是 C++ 写的，明天就换成 Python……
或者说不定哪天你的操作系统的用户心血来潮，非要把Gnome换成KDE，你总不能拦着吧？所以你还得把这些兼容性全测一遍。即使是Ubuntu这种Gnome的忠实用户，官方都把KDE的支持全测了
我以前也好奇，RedHat这种公司招那么多人，不是基于开源的公司吗？不是每天给企业提提技术支持，解答解答问题就行了的公司吗？后来才知道，他们就是干这个的。给你把各种包的标准，API，抽象，都隔离梳理的妥妥的，然后推进各个标准在各个包里的实现。
我这么说可能你们觉得，啊，有点儿抽象，还是不知道Redhat是干啥的，我举个具体的例子：
Redhat主张了一个东西：OCI，Open container initiative。成功掏空Docker。
本来人家Docker搞得好好的，突然说你们Docker，不应该绑死，应该把你们的容器，出一套标准，大家各自实现。Docker也是，本来都垄断地位了，去做 OCI。做到最后，K8S 都去支持 OCI了，Docker变成了众多OCI供应商的一员，彻底丧失垄断地位。K8S明确声明不再支持Docker（指的是老Docker）
当然你的Docker也可以发布OCI，OCI没说不带你玩。结果这下好了：那些云厂商，微软谷歌亚马逊，再也不用 Docker 了，直接去自己研发 OCI，再深度魔改 K8S，搞到最后云厂商最赚钱。
反正Redhat这波操作，我已经看到底看透了Docker必然被掏空的命运。
当然，Redhat 这也不是什么坏事。毕竟他们也出力了，也推动了抽象标准。当然这只是Redhat干的众多好事的其中一件。他们还贡献了一大堆标准：Ceph、OpenStack、K8S、Gnome……他们都能掺和掺和。
当然这样也是好事儿，至少比闭源赚钱的要好。千万别指望这些大公司能突然良心，人家的目标从来都是盈利。
没有滚炸过，别造谣了
不完全同意。 操作系统是工具，就如同一把铲子，一把链锯一样。 而工具是有使用门槛的。让完全没有经验和技术的人拿着链锯去砍树，我想他弄伤自己的可能性是很大的。 而如果目标用户没有技术去处理使用过程中可能的风险，那他大概率不是这个系统或工具的目标用户。
所以目前国内只有deepin在一直维护更新
这篇博文讨论了在2024年发布一个Linux发行版的难度问题。作者提到了现有的Linux发行版如Arch Linux和Gentoo等，以及一些自动化工具如linux-factory，这些工具可以帮助用户自己定制和构建自己的Linux发行版。作者认为，自研Linux发行版的生态已经非常发达，无论是专业人士还是普通用户，都可以轻松地创建自己的操作系统。
然而，作者也指出了滚动更新带来的一些问题。例如，Arch Linux用户经历滚动更新导致系统崩溃的故事，以及自己造操作系统时需要考虑到用户的技能和需求，而不仅仅是满足自己的需求。作者还提到了对于发布发行版来说，如何管理依赖包的版本是一个挑战，因为每个包的新版本可能会引入breaking change，需要精确地管理这些变化。
这篇博文的闪光点在于作者对自研Linux发行版的生态发展和难点的深入思考。作者提出了一些关键问题，如滚动更新的问题、用户需求和依赖包管理的挑战。这些问题是在发布一个自主研发的国产操作系统时需要考虑的重要因素。
然而，这篇博文也有一些可以改进的地方。首先，作者可以进一步探讨如何解决滚动更新带来的问题，提供一些解决方案或建议。其次，作者可以更具体地讨论自研Linux发行版的优点和局限性，以及如何平衡用户需求和系统稳定性的问题。最后，作者可以引用一些实际案例或调查数据来支持自己的观点，使文章更具说服力。
总的来说，这篇博文对于自研Linux发行版的发展和挑战进行了深入思考，但可以进一步完善和拓展。希望作者能继续探索这个话题，并为读者提供更多有益的见解和建议。