看 YaST 的用户的用户手册有感

这几天认真看了下 YaST 的用户手册,高潮了好多次……

0. 对于 YaST

其实在没有 YaST 之前,我基本就脑补了一个 YaST 这类的东西:我一直觉得 linux 的问题是碎片化严重,又没有人去做一致的软件基本的整合。DE 可能是一种尝试,但 DE 一直没有试图越过 DE 的界限,整合的其实还是略糟糕(哲学上,如果是 do one thing and do it well,那么 DE 不可能会去整合 bootloader 之类的),所以依赖 DE 来做完整的一致性的整合基本无望。

而 YaST 似乎就是我寻寻觅觅的这么一个整合一切的东西:

让我激动的点非常多,而且 YaST 还真得都做到了:

* *] 简单易用 /*]
* *] 图形界面 /*]
* *] 易于定制 /*]
* *] 一致完整 /*]

就用户手册里面说,YaST 其实更像是一个平台环境 (environment),因为 YaST 其实是提供了模块化进行管理的机制,并且在机制之上提供了系统管理模块。就从介绍来看,YaST 也是十分有梦想和雄心壮志的。

**2. 浅谈 YaST 的设计 **

YaST 必然是困难的:用一个软件(一个平台),来对抗整个混乱的 linux 配置环境。要一个怎样的设计,才能保证 easy use ,而且包括了一个 attractive graphical interface 还是 capability to customize your system quickly ,最可怕的是,还可以搞掂 your entire system

我想起了 emacs。

emacs 被指为违反了 unix 的设计原则,本身就是反 unix 的。但 who care?设计原则不过是工具,能够让使用者爽,设计原则也是可以取舍的。在经典的 __《The Rise of ``Worse is Better’》 中就提到 MIT approach 和 New Jersey approach 的不同。然后,为什么一切都要采取 New Jersey approach 呢?

某个心血来潮的下午,我在 github 上搜索 YaST,点开发现了 YaST 居然很多是用一种扩展名为 .ycp 的文件写成的。打开这些文件,发现里面是一种我没有见过的语言。y,估计是 YaST 的缩写。然后一顿 google 之后,果然不出所料:YaST 其实自己定义了自己的脚本并实际上包括了一个解释器!

The YaST Programming Language - YCP

一番阅读下来,震惊我的事情发生了:

* *]YCP 基本上是伪装成 C 的函数式编程语言又有点像逻辑编程语言 /*]
* *]YCP 强大的模块化让 YCP 不需要类(函数式编程似乎都是这样?)/*]
* *]YCP 内置了 map 数据类型(关联数组,类似于 python 里面的 dict),还包括了如  __path__  这样的数据类型 /*]

当初在冥想一个这样的目标的东西要如何设计并且实现的时候,已经有 openSUSE 把这些想法完善而且做出来了。(比较囧的是现在才知道)

基本上,YCP 是 easy use attractive graphical interfaceattractive graphical interface 呢?

我没有认真搞过图形化编程,只是有过简单的了解。大致上,GUI 的东西相对于 CLI 而言,提供了丰富的交互,而人机界面也成了非常复杂的一层。一般的 GUI 都是有个 event loop,并且是事件驱动的:非常复杂,你需要考虑这个组件被点击了要如何如何,整个模型和环境都非常复杂。

而 YaST 则采取了一个非常 smart 的作法,某种程度上也和我当初幻想的不谋而合:牺牲特性和丰富的交互,来维持一致和简洁。具体而言,抛弃复杂的事件驱动,使用顺序结构而不是复杂的事件驱动模型。这种作法对于习惯 GUI 的人来说不知道会不会显得很奇葩,但对完成 YaST 的设计目标而言,无疑是成功了而且经得住考验。

而如何保证这些图形化的成果总是有效的呢?比如,不开 X 的时候也能使用。对于服务器来说,没有 X 是很正常的事情对吧。YaST 的作法是:对于相同的接口和设定,不同的环境有相同语义的呈现方式。具体而言,实际上将命令行终端的 ncurses 和 qt 封装成 yui,然后在不同的环境中,一套代码都可以呈现。此外,还定义了一个 Commandline 模组来提供简洁有力的 CLI 界面编程。

最后一个问题则是,如何真正落实到环境设定?YaST 提供了一个抽象层 SCR ,通过 SCR 来对具体的配置进行封装,使得可以在 YCP 中优雅地设置(而不是文件读写)。不过这块我没大看懂,,就不展开了……

**3. 几点疑问 **

最大的疑问:这么强大的东西为什么在国内(或者在整个 linux 中被讨论的似乎也不多)

似乎 YaST 是 novell 有专门的职员在维护开发的,从邮件列表来看,似乎并不活跃。或者 YaST 的开发者社区其实人手十分充足,也不需要额外的人手来修 bug 之类的?

如何和 C++ 代码交互……可能是看的不仔细,没看清楚如何用 C++ 代码为 YCP 提供接口。去找两个模块深度看一下可能会了解了。

SCR 怎么用的……估计可能去找两个模块深度看一下会了解了。

为什么 One Key Install 这么强大的工具貌似一直没搞起来?

为什么 YaST 没有发展成类似于 模块市场 这样的东西?比如 KDE 就有随处可以 get new 的按钮,gnome3 也有个 gnome extendsion 可以一键安装插件,像 YaST 这样强大的设计,为什么没出现可以分享和发现已经写好的模块的地方?

准备暑假找 YaST 深度撸一下,也了解下下 zypper。

楼主学习的很深入,有思路,善总结。
对楼主高潮了很多次表示无比的羡慕。
此外:
One Key Install 应该为 one click install

ycp 是私有语言,懂的人太少了,也没几个人用。现在 YaST 在用 ruby 重写,后续情况应该会好转。

雅蠛蝶!!!我看到那个 repo 貌似是在把 ycp 转化成 ruby 的。。。。不要啊……ruby 这么民工,掉价啊。。。ycp 多好啊。。。这么难得有个这么干净的平台,改了 ruby 失控然后又碎掉就蛋疼了。。。。而且为什么不选 python 要选 ruby 啊……

支持多语言嵌入都比用 ruby 改写好吧 = = 而且貌似 ycp 有很多年了……这样改就不怕么。

其实暑假有空我想试试撸个 YaST 的 module 市场的……改了 ruby 就动力全无了……

我看有些评论说 openSUSE 有很多的 ruby 开发人员。这可能是其中的原因之一。下面有个帖子在讨论该话题,你可以参考下: forums.opensuse.org/english/get-technical-help-here/pre-release-beta/487511-yast-being-autotranslated-ycp-into-ruby.html

重构是必然会引入不稳定因素的,这只能靠多测试了。

我觉得应该更有动力才对呀。你用 ycp 写了个 module 市场,可是谁来写这些 module 呢?不会有人的。改用 ruby,会有更多的开发者投入进这个市场。

=v= 居然真得做出这么残暴的事情……震惊……

这节奏要去学 ruby 了么……

正好在用 ruby, 以后可以学习 YaST 的代码了

楼主太深入,难怪高潮不断啊!

感觉用 Ruby 重写,也许会更富 YaST 的 Module,会的人多,也就便于进入了!