https://hangyan.github.io/tags/os/Recent content in OS on 涯余的博客Hugozhhang.yan@hotmail.com (涯余)hang.yan@hotmail.com (涯余)Wed, 04 Sep 2019 21:25:35 +0000https://hangyan.github.io/post/2019-09-04-oberon/Wed, 04 Sep 2019 21:25:35 +0000hang.yan@hotmail.com (涯余)https://hangyan.github.io/post/2019-09-04-oberon/<p>文章链接: <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.7173&amp;rep=rep1&amp;type=pdf">Oberon – The Overlooked Jewel</a></p> <p>很多行业以及技术在早期都呈现出了一种百花争鸣的态势，然后到了成熟期一般都只是几家公司或者技术在互相竞争。操作系统也是如此，目前的主流 OS 里基本上就是 Mac/Linux/Windows 三家。但是在互联网早期，出现了很多设计里面差别很大的操作系统，从 GNU 的 Hurd，到 Lisp Machine，还有 Oberon 等。他们之所以消失，并不是说本身技术方面不占优势，而是从商业以及用户习惯上来讲，最终使用的人数太少而逐渐销声匿迹而已。而且从设计里面上来说，相当一部分的 OS 设计是因为理念太过超前而违背了当时用户的使用习惯而被舍弃。所以即使从今日来看，探究一下这些<code>老旧</code>的操作系统的设计理念仍然是大有益处的。</p> <p>Oberon 的作者也是 Pascal 的作者。他自己对 Pascal 是很矛盾的感情。Pascal 本身只是他的一个作品之一，他本身的能力是非常强的，先后设计了很多完整的操作系统，编译器等等。但是外界对他的期待都在 Pascal 上。他也一直拖着不去更新，而是专注于自己感兴趣的领域。Pascal 渐渐式微，Oberon 也淡出大众视野。他沉浸于自己的创造乐趣之中，也给后世留下了无数珍宝。</p> <p>文章提到了几个 Oberon 操作系统的特点，让人都非常印象深刻。</p> <h2 id="系统级-gc">系统级 GC</h2> <p>GC 在我们一贯看来都是属于高级语言的概念，操作系统很少有人会用 GC 来做资源管理。Oberon 实现了系统级别的 GC： 进程使用文件，不需要显式地自己去关闭文件句柄等。现在操作系统的应用程序因为系统没有 GC,不管是操作系统本身还是应用程序都需要许多额外的处理此类细节的代码逻辑。而且需要设置各种文件句柄的上限等等。Oberon 所采取的策略对未来的操作系统来说很是很值得借鉴的。</p> <h2 id="更少的对话框">更少的对话框</h2> <p>对话框这个东西，自操作系统有了图形界面不久就一直存在。软件用它来给用户提供编辑，确认等操作。但是对话框并不是一个好的设计，因为它需要会打断用户的思路，强行让用户分散注意力去关注于一个全新的界面。现代的操作系统仍然有很多的这样的或无奈或多余的设计, 比如：</p> <ul> <li>Mac OSX 在关机的时候，因为平时开的软件比较多。经常就是需要一个一个地点各个软件弹出的确认退出的对话框。系统并没有一个默认的忽略选项，即使用户完全不在意各个软件是否需要保存当前状态。Mac OSX 为此做了一个 <code>Force Quit</code>的功能，用户需要一个一个地强制退出可以忽略的软件</li> <li>文件的更名操作既可以弹出对话框，也可以直接按 <code>Enter</code> 去修改。后者就比前者简单好用的多</li> <li>Mac 安装软件的一步拖动方式就比 Windwos 的在对话框中一直点下一步好很多</li> </ul> <p>Oberon 在设计之处就考虑到了这个问题，尽量在用户界面少使用对话框。比如它的文件<code>另存为</code>操作，就可以直接点击文件名，输入一个新的，然后点击保存命令即可。这比现在常用的弹出一个对话框让用户输入再确认好的多。</p> <h2 id="校园合作">校园合作</h2> <p>这是最让我震惊的一点。 Oberon 操作系统在作者所在的学校里，所有的人都在用这种操作系统。它发源于本校，主要的开发者都在本校工作或者退休了，使用同一种编程语言: Oberon，有足够用的应用程序。这样一种操作系统对学生来说， 在教学上拥有无与伦比的优势：详尽的文档，近在咫尺的开发者，你可以从头到尾了解一个操作系统的实现细节，学习它，研究它，改造它， 提升它的性能，给它开发应用程序。所有的这一切，都会被记录下来，作为一个学校的令人自豪的存在，被后来的追随者延续它的生命。</p>https://hangyan.github.io/post/2019-08-22-db-os/Thu, 22 Aug 2019 11:21:52 +0000hang.yan@hotmail.com (涯余)https://hangyan.github.io/post/2019-08-22-db-os/<p>数据库一般认为是一种系统软件。而操作系统处于更底层的位置。这是一种通常的认知。</p> <p>Unix 的一切皆文件的设计思想，从一定程度上来讲，表明了操作系统内部不同组件之间有一定的结构上的一致性。比如网络接口和文件接口，都有如下的操作</p> <ul> <li>Rread</li> <li>Write</li> <li>Close/Open</li> <li>permission</li> </ul> <p>等等。进程和内存管理也是类似的逻辑。所以我们现在可以看到 Linux 系统中有很多类似的尝试，用文件的形式来来作为很多内部组件对外的接口。</p> <p>这是 Linux 一直在被<code>夸赞</code>的地方。一个听起来优美的设计哲学，吸引了很多人从<code>奇怪</code>的，程序员不友好的 Windows 逃离过来，并花费大量的精力来学习和理解这个设计之下隐藏的诸多<code>肮脏</code>的细节。</p> <p>工作越久，越来越多的人发现。相比较而言，平时还是 Mac 和 Linux 用起来更方便。即使是爱折腾的程序员，也大多不愿再去浪费时间去折腾 Linux，去折腾 VIM/Emacs。不是因为年纪大了，而是因为这些东西确实用户不友好，而且有设计缺陷。</p> <p>几十年前， <Unix Haters Book>已经很清楚地点评了 Linux/Unix 上的诸多问题。然而它并没有推动 Linux/Unix 去改变和解决这些问题。开源是一面美好的大旗，但它也蒙蔽了跟着的人。</p> <p>Linux 桌面的失败简直惨不忍睹。自由的 fork, Client-Server 的架构，无尽的口水仗。最终活下来了两个无法合作的 KDE/Gnome。Windows 自然也有很多设计的问题，但注册表现在看来相对于 Linux 的配置文件来说简直是太优秀了。多年人，有些人会想到：</p> <ul> <li>不同 cmd 的 input 和 ouput 的格式都不一样，增加了很多研发的负担</li> <li>能否用一种统一的数据格式来表达配置以及输入输出？比如 json</li> </ul> <p>也有人尝试过，但从来不会真正影响到社区。即使成功了，systemd 的经历也历历在目。</p> <p>虽然能将操作系统的诸多概念简化成文件，但文件仍然是一个相对复杂的抽象概念。除了文件系统，没有哪个其他模块能够与文件如此对齐。就数据本身而言，打开文件之后，读写数据，本质上简化为两个结构: <code>list</code> 和 <code>dict</code>，组合起来就是一个 <code>table</code>。</p> <p>读写文件，基本上就是不断地对这个 table 做修改，增加，删除，修改行。CSV 格式的文件更是可以直接直接对应于一张表。所有其他的内部模块,其操作也是类似的；</p> <ul> <li>创建进程： 往进程列表里添加一个元素</li> <li>销毁进程: 从进程列表里删除一个元素</li> <li>添加设备: 往设备列表里增加一个元素</li> <li>配置设备: 修改设备的属性</li> </ul> <p>不只是 Linux，所有操作系统面临的都是同样的问题，使用的都是同样的的机制: 不听地对Table 做各种操作。现状是，所有的操作系统在不同模块的管理上都是有差别的，因为没有统一数据模型的支持，每个模块都在不断地用不同的形式做类似的操作，其提供给用户的功能也因此而受限。</p>