从零构建成一个合适的好版本给大家用是可以的,但要大多数人从零开始就如同要大家学习原始社会制作石器来谋生一样艰难。
即使rust已经有一部分内容进入Linux内核主线也只是刚刚开始。国内用rust的人很少。我个人觉得Google搞的那个chrome OS云系统是现代操作系统的发展方向之一,但就以目前的技术水平来说,最好的暂时也就只能搞成chrome OS那个模样了。想法总归是好的,但是一下子不会有太惊艳的改动,君不见Windows7-->Windows8的改动在当时看来有很多超前的地方了吧,但是实际上却是叫好不叫座。
一步步来吧。
大佬
2000年我还在玩泥巴
从零构建成一个合适的好版本给大家用是可以的,但要大多数人从零开始就如同要大家学习原始社会制作石器来谋生一样艰难。
这是就开发而言的,不是对用户而言的。对于用户来说,最好是直接可以上手,不用管后面实现的原理
即使rust已经有一部分内容进入Linux内核主线也只是刚刚开始。国内用rust的人很少。我个人觉得Google搞的那个chrome OS云系统是现代操作系统的发展方向之一,但就以目前的技术水平来说,最好的暂时也就只能搞成chrome OS那个模样了。想法总归是好的,但是一下子不会有太惊艳的改动,君不见Windows7-->Windows8的改动在当时看来有很多超前的地方了吧,但是实际上却是叫好不叫座。
一步步来吧。
chromeos并不是未来的方向,它只是一个类似上世纪70年代的终端机模型。windows的桌面模式也不是我考虑的。你大概没有看到我最后一句话,就在20年前,那个时候我们都只是在使用pc时,我们就已经在设想移动终端上的linux了。也就是说,今天我构想,不是针对今天的用户习惯的,而是未来20年。
我是只希望V23启动器中有一个收纳功能,把不常用应用图标放到一起,这样进启动器会感觉清爽些。别的只希望bug少些,系统稳定。界面这些20.6用起来也舒服,也装过好多linux发行版,发现还是deepin用起来顺手。
不知道 NixOS 是不是你的菜。
另外你可以看下 https://0pointer.net/blog/fitting-everything-together.html 这个大佬的想法,可能有些地方会有共鸣之处。
合抱之木,生于毫末,九层之台,起于累土,千里之行,始于足下
不知道 NixOS 是不是你的菜。
另外你可以看下 https://0pointer.net/blog/fitting-everything-together.html 这个大佬的想法,可能有些地方会有共鸣之处。
NixOS可能与我说的某些方面有一点点类似,但我对这个系统仍然非常不满意,它只是提供了一个快捷的包管理模式,在底层的兼容性和安全性方面没有彻底的改善,核心基础软件仍旧是过去的那些。
我说的重点是从零开始的核心工具链,比起启动引导工具,设备识别和加载工具,微内核的调度和新的文件系统,类似区块链和git的全流程版本控制等等。
从用户的角度考虑,假设我现在有一个RiscV的开发板,我需要给它安装一个全新的内核,除了这个内核以外,我在安装文本中写入一个架构名称,系统能自动给我安装完一个镜像系统。而手头有一台陈旧的pc,我则可以调用一个检索工具,自动生成针对这台pc的安装脚本,并自动从网上拉取镜像。如果换成另一个比如科研军工的专属设备,则安装和使用过程可以全流程监控。二进制软件就像我们也go语言编程中导入模块那样,只需要在配置文件中写入import,后台由 module工具自动管理版本。
凡事豫则立,不豫则废。言前定则不跲,事前定则不困,行前定则不疚,道前定则不穷。
NixOS可能与我说的某些方面有一点点类似,但我对这个系统仍然非常不满意,它只是提供了一个快捷的包管理模式,在底层的兼容性和安全性方面没有彻底的改善,核心基础软件仍旧是过去的那些。
我说的重点是从零开始的核心工具链,比起启动引导工具,设备识别和加载工具,微内核的调度和新的文件系统,类似区块链和git的全流程版本控制等等。
从用户的角度考虑,假设我现在有一个RiscV的开发板,我需要给它安装一个全新的内核,除了这个内核以外,我在安装文本中写入一个架构名称,系统能自动给我安装完一个镜像系统。而手头有一台陈旧的pc,我则可以调用一个检索工具,自动生成针对这台pc的安装脚本,并自动从网上拉取镜像。如果换成另一个比如科研军工的专属设备,则安装和使用过程可以全流程监控。二进制软件就像我们也go语言编程中导入模块那样,只需要在配置文件中写入import,后台由 module工具自动管理版本。
这样的工作太庞大了,可以还不具备天时地利人和来启动这样的事情,不过理想中的目标还是可以往这种彻底重造的方向考虑的,但是一定不是一下子就能形成的,这其中只能分阶段迭代着去设计和实现,可能几十年(也或许永远都不可能,因为之前设计的再好,在实现的过程中都会遇到新的问题,需要改进设计)都不一定能达到最终的目标。
这样的工作太庞大了,可以还不具备天时地利人和来启动这样的事情,不过理想中的目标还是可以往这种彻底重造的方向考虑的,但是一定不是一下子就能形成的,这其中只能分阶段迭代着去设计和实现,可能几十年(也或许永远都不可能,因为之前设计的再好,在实现的过程中都会遇到新的问题,需要改进设计)都不一定能达到最终的目标。
要说庞大,并不比实现一个新内核难太多,至少技术层面是可以快速实现的。国内已经有很多很好的体系方案,比如RT-Thread,rCore,openEuler等,龙芯也有自己的一套实现方法。只要在底层做一个虚拟层,把硬件架构统一放置在这一层,上面再实现内核的调度,再往上是基础工具链,最后是应用层。我们做系统,只需要关注资源的获取和调度功能,把基础工具链一层做好就可以了。类似的基于rust和golang的全新操作系统试验在国外也早就开展,有很多已经可以使用了。
其实从软件版本来说,统信都是稍微低一些的版本,可能是趋于保守,盲猜短时间内不会上rust,而且目前来说开发者的数量也是个问题,既要为各厂商提供定制化需求,又要适配软硬件,所以欢迎各位大佬为deepin提交代码或者入职统信(狗头)
作为初级linux玩家,我希望有个最小安装版本,按中国时区一键安装自动获取IP,不要建用户,有个初始密码,自动更新,显示界面效果简化,纯色壁纸,可以选择启动到桌面还是命令行。支持dkcker,realvnc,ssh,宝塔面板。简单来说就是deepin一键开玩版。
Popular Events
More
鉴于国内终于要开始建设自己的根系统,我来说说我的构想吧。在构想之前,先废话回顾一下过去。
2000年的时候,我开始学习使用FreeBSD系统,主要是对于里面的终端模式下的configure程序以及Ports包管理有很好的体验感受。我是一个完美主义者,不喜欢别人已经完全做好的一套系统摆在面前,我总是想自己从零开始构建一个系统。然而技术又比较菜,没能够真正从零构建系统。后来我和朋友们讨论Linux From Scratch以及Debian From Scratch,从中学到了很多新的思路。再往后几年,我参与了Hiweed Linux的几个版本的规划讨论。那个时候几乎每天在Gentoo里面,办公室里和家里的电脑每天都在编译编译……直到后来开始接触ArchLinux和DragonFlyBSD,这两个发行版都允许我以最小base系统开始安装,再完全按照自己的需求进行后续的安装配置,那时候对pacman的热爱超出了一切。
如今我重新反思这一切的根本原因还是由于debian或fedora的基础系统不适合我的这种思维模式的人或要求。包括基本系统的便利性、包管理的复杂性,以及自由定制的可扩展性。最近的几年,我也在使用OpenEuler作为我的树莓派的基础系统。当我从两年前重返Deepin Linux时,我就在思考,我们是时候开始改变过去20年的陈旧陋习了!
这些陋习包括了:
1、基于C和C++的开发,使得一旦软件数量和开发者数量大大增加之后,代码本身的安全性、兼容性、可扩展性受到了严重的挑战
2、缺乏类似configure的基于终端模式下的更加简易的设置、自定义、救援工具
3、unix、linux核心工具也都太陈旧
4、对跨平台、嵌入式等新型设备的支持不足
最近两年,我在学习使用go和rust语言,也发现了不少新的工具,一些新的思路慢慢在脑袋里浮现。
1、构建最小基础系统,这个系统应该可以在不同的硬件架构中使用。
2、最小基础系统本身具有git的版本控制,使用类似docker的镜像进行发布。一旦系统发生错误或其他问题,可以利用版本控制体系,快速返回到早期的版本中。
3、基础系统的内核和工具链可以分开,以方便替换不同的内核。
4、基础系统工具链应当使用go和rust之类的安全开发语言进行开发,同时可以保证长久的兼容性。
5、包管理系统也具备git版本控制功能,类似的基础文件数据库就像Dolt dolt
6、基于cli开发或引入一些不需要桌面的比较完善的工具,类似lazydocker lazydocker
7、由于整个系统开始类似于云端和git,具备面向未来的扩展性、实时性、可回溯性、安全性等,需要开发和兼容全新的文件系统,譬如Euler文件系统那样的。
8、由于基于go和rust,原生应该支持多通道、分布式、去中心化的新特点。
先写这些吧,我希望未来的系统不是我们今天看见这个样子。就像20年前我们梦想和努力的那样:以后的linux应该在任何移动终端上运行!