博客

Haraka - a Node.js Mail Server

https://github.com/baudehlo/Haraka#readme

看作者的自述：Haraka is a project started by Matt Sergeant, a 10 year veteran of the email and anti-spam world. Previous projects have been the project leader for SpamAssassin and a hacker on Qpsmtpd, a perl based mail server which is quite similar to Haraka (but not as fast due to perl being slower than Javascript).

貌似不是一个蛋疼的项目... 刚刚发布 0.6.0 版本

Why Use Haraka?

Haraka's primary purpose is to provide you with a much easier to extend mail server than most available SMTP servers out there such as Postfix, Exim or Microsoft Exchange, yet while still running those systems for their excellent ability to deliver mail to users.

postfix 一直没有增加 libevent 的支持，对一个这么活跃的项目，以及这么被广泛使用的服务来说有点异乎寻常。从理论上来说，一个邮件系统的I/O能力是被其磁盘信件队列的I/O能力限制住了，所以网络I/O不追求高并发也可以理解。

但是考虑到垃圾邮件，潜在的DDoS攻击，在 postfix 之前弄一个这玩意确实值得考虑。

以前曾经想过用 twisted 做类似的东东，现在看来又多了一个新选择。

最后要说的是，node/v8 的 gc 确实很蛋疼

Phantom: 去中心化的匿名网络

翻译：曾怀东/朱翊然

互联网上的匿名是一个值得关注的问题，为此，几种不同的解决方案已经实施（如Tor，Freenet）。创建这样的网络是一个蛮有意思的尝试，这种网络也在避免各种互联网活动监控方面大显身手。而在相对自由的国家的人可能会发现它很有用，可以用来避免他们的ISP和政府的监督，在更专制政权下生活的社会活动家可能会发现能利用它获得更多，在某些情况下，甚至是生存或死亡的区别。幻影（ Phantom ）是另一个具有很多有趣熟悉的提供互联网匿名性的机制。

Phantom 协议是由 Magnus Bråding 在 2008 年的 DEFCON16 引入的（幻灯片[PPT]），旨在提供去中心化的匿名性。其思想是不存在会由于关闭或攻击导致Phantom无法使用的中心薄弱点。不像Tor和其他协议，Phantom要求端到端的加密，所以不存在“exit node”的问题。该问题会导致泄密或恶意参与者窃听通讯。另外，Phantom是为了高性能设计的，所以可以支持大数据量的网络传输。

Phantom最有趣的特性之一是它不需要改变现存的internet应用。对于网络浏览器还是其他应用，似乎使用的还是一个标准的 IP 地址和外界通信。事实上，这些地址是由Phantom软件处理的匿名协议（AP）地址。 Phantom做出的假设之一是IP地址能够映射到真实生活身份（这是一个非常有意义的假设），所以它的最主要成果之一就是保证这些信息不会被泄漏。

Internet被用来承载所有的Phantom流量，这些流量是internet的一部分。提供匿名访问服务（例如web server）的服务提供商必须在Phantom网络内部注册。很明显，从去中心化的角度来看，注册是一个问题，但是Phantom使用了分布式哈希表（DHT）来保存信息。现在已经有很多大规模部署的DHT，例如eMule的Kademlia。

DHT被当作“网络数据库”并且包含了两个独立的表。一个表是当前已经连接入 Phantom 的节点的 IP 地址，端口和其它属性，另一个表包含连接入 Phantom 和注册入的节点 AP 地址和属性。显然，为了保证匿名性，这两个表没有直接关联。想要获得一份DHT的拷贝，一个新节点只需要同一个已经存在的节点连接并加入这个分布式数据库就可以。初始可用的IP地址列表可能源于各种途径：网址，邮箱，甚至是纸片。只要列表中有一个的节点存活，新的节点就能够加入。

希望在网络上通信的客户端必须建立自己的退出节点（exit node）。它通过选择网络中一定数量的其他节点建立路由路径，最后一个节点即为退出节点。不像Tor，Phantom中没有已有的退出节点集合，因为在Phantom中任何一个在网络中的系统都可以作为退出节点。还有一点与Tor的区别是，endpoint选择自己的路由路径，而不是由网络来做这些决策。Phantom design white paper [PDF]对产生路由路径的协议进行了详细的说明。路径的每一步都用SSL进行了加密，该文章还描述了生成退出节点的复杂过程的细节。

同样，网络上的任何服务需要为每一个“入口节点”创建一条路由路径。在某些情况下，服务本身并不需要匿名，只是为匿名用户提供访问，这时候入口节点可能是该服务本身。在任何情况下，服务都要利用入口节点的IP地址在DHT注册他们的AP-to-IP的地址映射。对那些希望保持匿名的服务，他们会隐藏在其入口节点的整条路径的后面。

建立exit node和entry node后，节点就依路径创建路由隧道。这些隧道在端点的控制下，而不是网络或者任何的中间节点（包括入口/出口节点）。建立一个连接包括把这两条路由隧道连接在一起，以及连接客户的出口节点和服务的入口节点。隧道连接是双向的，使用了防备中间人窃听的加密技术

该系统的重要特征之一是，节点不知道他们对话的对象是端点或者仅仅是路由路径上另外一个节点。路由路径可以是无限长，甚至可以根据需要再次链接起来去提供进一步的隔离。

虽然整个计划看起来恶魔般的复杂，它已经作为Johannes Schlumberger的一部分硕士学位的工作实现了。也许令人惊讶，性能被描绘为还不错的：“在多跳路的Phantom路由隧道上最大达到100Mb/s的数据传输速度，因此加密的开销似乎并不太重要”。该代码可以在Hacktiyismo 增强源软件许可协议（HESSLA）下使用，这似乎是带有一些额外“政治”目标的GPL-inspired 许可证。根据自述，用一个tun的虚拟网络设备实施，而且可能需要相当复杂的设置。

总体而言，Phantom看起来很有趣。像Tor以及其他的技术，为了真正的使用，需要相当多数量的节点参与进来。Tor的一个最大的障碍在于出口节点因为它们发出的通信习惯获得指责。这些通信不能进一步的追踪回出口节点（至少希望如此），任何犯罪的或者恶意的通信是同任何跑在Tor节点上的用户隔离开的。由于在Phantom上的服务支持匿名访问，这样问题可能比较少。这也可能导致采用Phantom的可能性较小。

虽然电子前沿基金会最近一直在推动Tor的使用，广泛的使用Phantom（或者任何其他的匿名网络协议）还是有点困难的。有些方案显然是必要的，但是目前为止，后勤和法律的障碍似乎是许多人无法克服的。不幸的是，匿名网络可能会陷入“直到太晚的时候才开始成立”的困境。但是，很高兴看到人们仍在思考并且一直在为这个问题工作。

Android, forking, and control

翻译：马少兵/刘晓佳/李潇

关于 Android 和 Linux 主线开发的关系已经被谈论很久了。在日本的 LinuxCon，James Bottomley 又就此阐述了很多观点。他说，从两个项目之间缺乏联系和交流可以学到很多教训，如果社区能关注这些往事，未来我们应该能做得更好

• Forking the kernel

• 重写了 C 库和工具链

• 开发了一个 Java 应用框架（JVM定制）

• 项目启动的时候，对 GPL 极为排斥

换句话说，Android 是一个不同社区合作的典型代表。它们做了无数社区觉得不该做的事情，但是最后成功。尽管我们觉得 Android 的开发团队需要有所改变，但它的成功也说明，社区也需要有所改变。也许社区需要重新权衡代码质量以及市场成功，社区是否需要更加面向商业一些？？

一个最大的争论就是 forking，不仅仅是 kernel，Android 从零编写了整套用户空间，社区对此特别愤怒。但我们得理解这个事情的历史过程。最开始 Android 是期望它的变更能被主线采纳的，但在开始实现系统的过程中，时间压力很大，不得不尽早往前赶进度。我们都知道关于内核社区的补丁复查和接纳过程有很多议论，总之Google 无法等待社区接受后再发行它的 Android。但也许，除了 forking 内核外我们还能有其它选择

“难道内核分支是一种错误吗？”，在某种意义上来说，James说，那不是错误：毕竟有 GPL 担保。分支有时候是必须的，如果android系统不能被应用，原来那种正确也是无意义的。在此特殊情况下，如果不采用分支，android系统的商业的开发与应用将会处于一个艰难的时刻,很难实现其目标（关于电源管理以及其他）。最终将会导致android代码被推迟，而这一切，会使目前市场缺少很多产品，或许因为错过市场时机项目就悲剧了。分支，换句话来说，也是一个好的事情——相比较于内核社区的固定流程，不同的团队可以做更多的事情

James问到，分支化等同于分裂化吗？这是个很重要的问题：上世纪九十年代分裂化几乎杀死了Unix的市场。他声称失败的分支化并不会分裂Linux社团；相反，他们只是简简单单的消失而已。那些合并后回到父工程的分支化并不代表着分裂化；他们将代码和开发者带回了原始的工程。真正有害的分支化，是那些取得成功并带走了一部分社团的分支，它们不会再回到父工程了。从这个角度讲，很有必要让社团帮助分支合并回来。

除了分支化了内核，Android的开发者，曾经认为GPL对于商业化并无益处。该工程最初避免任何GPL-licenced的代码；本来计划是写一个全新的内核。最后，由于某些原因，采用了GPL-licenced的Linux内核；同时还保留一些其他GPL-licenced的组件。所以，James说，我们应该谢谢Andy Rubin – 是他最初讨厌从GPL来的代码 – 最后决定性的证明了一款含有GPL-licensed代码的手机在市场上是可以成功的。结果就是下游销售商不用关心他们设备里代码的许可证；只需要关注清晰一致即可。

关于Android特别应用框架呢？James说基于Java的应用程序框架是Android系统最大的创新；它将平台细节抽离出来，使得应用层尽可能地远离了内核。该框架限制了应用程序可用的API，对应用所能做的以更强的控制。给定该结构后，貌似重写C库是一件完全没必要的事情；在该框架下没有人会尝试直接使用C库的。

所以，Android并没有做错一切。但是还是犯了一些错误：从James角度看，最大的错误就在于一开始它缺乏支持SyncML的日历应用。这使得Android很难吸引商业人士。黑莓成功的关键之处就是它优秀的日历。摩托罗拉看到了该问题，并为Droid系列手机实现了它自己专有的SyncML日历系统；这实际上使得事情更糟了，因为商业人士购买Android手机的出发点就变成了它能够支持日历系统。如果除了Droid之外别无他选，就会非常令人失望，最终转投iPhone平台。直到一年后，2.1版本，Android才支持SyncML，也是从零开始重头编写。

Android的另外一个问题是它的“walled garden”开发手段。Android本来是个开源工程，但是谷歌却对基本的发行维持总控制；在谷歌把代码扔出墙外前没有别人可以看到代码。没有一个变化是来自第三方提供的，所以没有社团来维护该代码，没有共享的创新。举个例子，如果愿意接受来自外界的帮助的话也许早就解决了日历的问题了。谷歌对代码的总控制是因为需要给工程以市场焦点。这是达到市场统治的先决条件，但是对社团来说并无益处，并且迫使谷歌重复了许多已有的创新。

另一个大问题是来自甲骨文的起诉。该控告基于Android对Java语言的重写，这完全是因为 Android 害怕GPL所至。要是Android建立在甲骨文的GPL-licensed的Java代码基础上，应该不会有法律问题；按照GPL暗示的专利许可，Google本该被保护。如果甲骨文赢得这场官司，重写Java将意味着在许可证逃避方面极其昂贵的实践。令人悲痛的是该license是完全无关紧要的：Java runtime API 将应用同 GPL 隔离

学习到的教训

我们能从这些里面学到什么？James重申，只有最终合并回去，创建分支才是一件好事。虽然做出了大量的努力，但Android分支还未合并回去。也不清楚Android开发者是否已经开始实施内核社区提出的解决方案。他说，也说我们需要想出一种方法让合并更容易。尤其是在创建的分支壮大的情况下，社区应该有一种更好的方法来处理当前这个有可能在审查中陷入困境的过程。

创建分支的项目还要考虑一下这些过程。子分支开发团队容易产生“非我发明”的心态（指反感或拒绝使用不是自己发明的技术），这反而会导致他们不愿意展示自己的最终代码。把自己都知道贴出来就要被社区严厉批评的代码贴出来一点都不有趣。子分支发展越久，这种状况越糟糕；修正基础的设计错误（正如社区眼里wakelocks的作用）就会越困难。要防止这个问题就要求分支团队更加包容，更频繁的贴出他们的代码，并寻求社区的建议—即使他们并不打算接受这些建议。打开围墙并让双方交流各自的想法是很重要的。

James谈到了“授权恐惧”，说GPL是我们特别感到FUD的地方。我们在社区里的一些关于“授权”的讨论在行业界人士看来就像是一个令人害怕的问题。而社区里关于这个话题的讨论不像那样激烈，这反而大有好处。对GPL的恐惧是由外界的兴趣驱动的，但我们趋向于让事情简单。社区应当更加前瞻性的去缓和这种恐惧；将Android看作在GPL授权下如何运转的一个范例，这是缓和恐惧的一种可能性。Linux基金会做过一些这样的工作，但是James觉得社区该出手帮助。他说，GPL比起那些最具商业性的授权，遵守起来容易得多，这是我们需要更加明白的一点。

我们应该设计更加“bright line”的系统，这会让GPL问题变得更加明确。内核用户空间ABI就是这样的一个系统；开发者知道用户空间代码被认为不会被内核的 GPL 所污染。让这个界限更容易的理解，会有助于减少对GPL的恐惧。

社区应该在提倡和发展多样性，鼓励创建分支（这会创造更多显著地成就）并帮助他们合并回去。James说，如今内核最多能得一个“C”的成绩。我们只从看起来跟我们相似的人那里接受代码，Android的合并尝试比原本想象的更加痛苦。

企业们应当靠获得社区拥护而不是绝对所有权来控制代码。Linus Torvalds就是一个例子；他有许多控制权，但那是因为社区信任他能做正确的决定。一般来说，如果社区信任你，它就会交出大量的控制权；那就是为什么仁慈的独裁者模型如此平常的原因了。另一方面，那些试图通过设置开发壁垒或者通过要求贡献者转让版权来声明控制权的企业们与社区相处得更加困难。

James说，总之，Android对任何参与进来的人而言都是一个惨败；我们都需要想清楚怎么去做的更好。我们需要找出更好的鼓励和管理分支并减轻授权恐惧的方法。创建分支的项目从一开始就应该仔细考虑合并回去的事情。这样，那些商业成功的项目（如Android）能同样是社区的成功

Webian: 基于 Mozilla 技术的 Web 桌面

翻译：李凯/林业

第一眼看到的时候像一个打字错误，但是webian的确是一个实验性的，开源的利用Mozilla和gecko做为它的内核的桌面环境。开发者Ben Francis上周第一次公开发布它，立即产生了与Google的ChromeOS项目的对比，并且引起了Mozilla将会激怒搜索巨人并试图进入其领域的猜想。但是Webian是Francis的私人项目，并没有被Mozilla认可或赞助。但是，它的确展示了一些浏览器制造商感兴趣想要宣扬的关键概念，那就是Mozilla的HTML5和开源的web标准将会是未来开发平台的信念。

实质上，Webian是一个在Mozilla的Chromeless工具包之上写的一个应用程序的小集合，这个 Chromeless 和 Google 的浏览器无关，Mozilla 用Chrome来称呼自己的用户界面层已经很长时间了（早在 Google 发布浏览器之前）。Webian 去除了整个的浏览器界面（包括firefox使用的XUL和XPCOM）并且用一个HTML,CSS和Javascript写出的层取代了它。Chromeless是一个Mozilla的几年前的Prism项目的演变，现在的版本和Firefox4有相同的 runtime。利用Javascript APIs calling浏览器的功能。Mozilla实验室已经发布了其他的基于Chromeless的项目，包括基本浏览器和从一个SkyWriter collaborative editor 取得的代码编辑工具。

0.1 release

上周，Mozilla实验室为 Francis的0.1版本webian shell——Weibian的简单桌面——发布，刊发了一篇 guest blog post。这个shell是一个集成的且不需要其它任何窗口管理和桌面装饰的网页浏览器。它在全屏模式下运行，提供了一个主界面和在底部的一排标签以及一个在顶部的URL-and-title-bar。Francis从2009年就开始活跃的开发Webian，基于他在大学期间所编制的设计概念。其设计概念文档阐述了比该项目wiki更多的关于范围和架构选择方面的细节：浏览器是唯一的应用程序，它包含了简装的工具去访问其它的功能（比如硬件和设置），而且只有从几年前的thick client桌面metaphor很小的借鉴。

0.1发布版本包括源代码，以及Linux，Windows和Mac OS X下的2进制格式。并不是所有的设计文档中描述的功能都已被实现；Webian Shell在一个全屏浏览器中工作，但是主界面目前只有时钟和一个关机按钮。并且仍然没有Francis的"stripe" UI元素：通知和查询水平的互相堆叠，将浏览器窗口内容往下压而不是放在最顶层。根据设计文档，其目标是在可能的地方移除2.5 Dimensions 概念并且真正的以2D的方式对待2D。

值得注意的是，设计的Webian Shell在你的已存在操作系统之上运行，虽然它的确是全屏运行的（对Linux来说，意味着它在X之上运行，并且不与窗口管理组件交互），它并不像ChromeOS一样是一个完整的OS，并且，如今，你可以把它作为浏览器和作为最终桌面系统的UI demo来运行，但并不是你当前环境的完全取代。作为一个浏览器，它运行的非常快，对我来说比Firefox 4更快。一方面是由于不载入Firefox插件，摆脱Firefox自身的界面似乎提供了一个值得注意的速度提升（安装了plug-ins，必须注意在Chromeless和Webian Shell中运行）。

Webian继承了来自于Chromeless的安全模式。最新的版本在out-of-process plugins和out-of-process tabs方面有所改进。所以一个页面崩溃不会造成整个程序崩溃。但是，Flash和Java在一个页面的中断会迫使用户为了重启一个崩溃的plug-in而重新载入其它页面。隐私管理是另外的一个问题，Chromeless和Webian可以像Firefox那样技术性的维护单独用户的数据，但是管理数据的界面在Webian Shell里尚没有实现。

令人不爽的是，现在一些high-profile Google web服务并不在Webian Shell里运行，这是由于一个Chromeless的攻击合并了X-Frame-Options HTTP header的页面的上游漏洞引起的。当然这个世界上有许多的web应用，所以使用（测试）Webian Shell进行日常浏览没啥问题。http://lwn.net/Articles/446614/

长期的计划涉及了在Shell之外的单独的应用程序。但是，这个项目是基于W3C小部件规范工作在主界面的桌面小部件之上的，但是，一个实现了标记和组织内容的本地接口的照片管理应用，仍然是一个连接的远程的，基于web的发布与存储的服务。这个选择最初是难以习惯的：类似ChromeOS的方法宁愿去写一个完整的服务器投递照片管理工具胜过去利用浏览器来投递它。

尽管Webian是作为浏览器和（潜在的）桌面环境，其范围非常有限，但还是不可避免的要和ChromeOS进行比较。Fancis发在Mozilla Labs上的帖子，其导致一些网络媒体把Webian描述成Mozilla项目----Francis很快把这个错误改正过来了。他曾经得到过Chromeless团队的帮助（包括运行在X-Frame-Options上的bug），但是这个项目没有加入到Mozilla里面去，他也不是里面的员工。

这个项目仍然紧密的和Mozilla的许多目标保持一致。Mozilla已经宣布终止对Gecko嵌入API的支持，它作为Chromeless的一个独立展示案例，为了保持平衡而扮演着越来越重要的角色（承担更多的任务）。

Mozilla也在抓紧推行前端的“可安装web应用”（通过apps.mozillalabs.com网站）。Firefox通过扩展来提供应用程序支持，嵌入瘦客户端桌面系统（比如Webian）的原生支持可以说是对其价值的更好的展示。Google Chrome团队已经独立开发出可安装的网络应用程序架构，但是给浏览器处理的是一个相似的但是并不兼容的表单格式....Francis说两个他都将支持，虽然他更倾向于把这两种统一为一种格式。

在Webian设计文档中讨论的另一个特点运行在Shell　URL bar/text-line 部件里的命令行接口:支持搜索查询是其首要任务，但是算法，应用程序启动以及自然语言的问题也已经在邮件列表以及论坛里讨论过了。正如一些Webian社区的人指出的那样，这项功能已经在Mozilla Ubiquity中实现，所以在这里再一次与另一个基于Mozilla的项目进行交互，这看起来是件很自然的事情。

但是摆在chrome系统面前最直接的挑战是，Webian需要绑定底层OS。但此刻，Chromeless并没有与下层系统硬件建立链接，它必须提供Webian Shell计划中描述的硬件控制（尽管Mozilla' Rainbow在此领域还没有显示出一点“生命”的迹象）。因此，如果想要发展成为完全用操作系统替代的模式，Webian就必须要几乎完全舍弃跨平台兼容性的问题，选择一个单一的stack，建立于此。

显然Linux是首选，Francis在一封电子邮件中委婉地指出了这一未来方向。“Webian将有多少跨平台的功能在此刻尚属未知，优先考虑的事情将会是建立基于Linux的版本，不过如果能够实现某些程度上跨平台性能的话，那将会是很棒的。”

当然，完全基于Webian的OS offering在与ChromeOS竞争中，其是否胜利是完全不同的问题。Francis与其他编者不会将Webian看作Google与ChromeOS之间那样的商业关系。一些编者在邮件列表中争论到，Webian的非商业策略使它在使用者眼中更加可信，他们对Google的用户跟踪活动表示担心，或者对ChromeOS缺乏透明度及建立精英管理层的过程表示不满。

毫无疑问，对于很多自由软件的提倡者而言，其立场意义重大，但是它没有以基于Linux的内核来建立Webian并以可安装映像的方式将其提供出来。邮件列表中另外一种普遍的争论为，同Mozilla一样，Webian专注于对开放标准的完全支持。因此，它将使得HTML5 video有免费回放格式的特点，而非只支持收费的格式。

坦白地讲，那种思考无论如何带着高度的猜测性，并有可能此时此刻影响到Webian Shell的展示。此刻，它展示的是无Chrome的Mozilla——这个主意是浏览器开发商争取了很多年还没有被展示的产品。桌面是静止的而网络是新的交换平台这一概念在舆论界得到了相当大的回应，此概念常常包括了这种理念：当桌面战争持续不断时，开放资源群体落后于时代。但是迄今为止，ChromeOS是仅有的以终端使用者为目标试图建立“网页桌面”的系统，它与Google提供网页服务的所有权紧紧地缠绕在一起。

因此，Webian是值得密切关注的，因为如果没有其他的原因，将要提出的“web桌面”的构想，在没有Google的环境中试验。就我个人而言，我真心希望此过程继续下去，并同时加速发展一些Mozilla的“试验环境”项目。这些可以作为web服务方面，自由软件群体很有价值的动力。但如果没有其他因素，一旦所有chrome都去除掉，将会显示出基于Mozilla的浏览器有多么小巧和快速。

sohulinux 第五期

1. Android 权限

2. 支持内存能耗管理的 VM Infrastructure

3. Eclipse Orion——基于 web 开发的 IDE

4. Illumos: OpenSolaris 社区的继承者

5. Forking the ARM kernel?

Forking the ARM kernel?

翻译：李潇/林业

在过去的几个月里，许多人都提出了建议将ARM与内核分离出来，将之作为一个独立的项目来维护。或许分离ARM的理由对一些人来说看起来是很有吸引力的，在这些人看来无论对于ARM社区还是内核，作为一个整体没有太大的意义。

1. 更容易把握市场时机

2. 它符合消费性电子产品一次性的性质

3. 它更符合SoC世界的多样性

4. 它避免了维护者的瓶颈和代码审查之类的一些无用的额外工作

市场时机

持这种观点的人认为，hack出一个新的驱动程序所需要的时间要小于让 Linus 等接受它。我知道我学识很老，不再懂这个快速变化着的世界和半导体工业的新挑战，但是，我仍然有许多的工程学的知识和常识以至于我知道在这个工业里根本没有什么真正的、和过去完全断开的新东西。大多数 SoC 的IP模块并不是新的。所以当IP模块第二次被应用的时候市场时机又有何变化？如果一个驱动程序是 upstream 的，它可以很容易的被复用，但是常常的情况是，一个新的驱动程序从头开始编写，完成的时候仍然有一堆漏洞需要修正。当重写那些他们所出售的SoC IP模块新驱动程序的时候，供应商们真的得到了更好的时机么？

此外，真正一个完整的新一代的芯片市场化的时机不是几周就能衡量出来的。通常情况下，对于一个新的芯片从市场发布到稳定应用到设备上需要大约一年时间。这是对于得到一个新的驱动程序有了足够的时间。而且，市场发布的时间显然不应该是在工程部喝点啤酒，几个天才工程师在酒吧的草纸上勾勒出个设计的第二天，所以大多数的项目应该有更多的时间去推向 upstream。

嵌入式商品是一次性的

对于嵌入式的项目，特别是在消费品市场，硬件是一次性的是毫无争议的，但是另外一个事实是，SoC family 在很多方面是普遍的，只在一些小细节方面有所不同。此外，特定硬件的不同变种（比如智能手机）共用了绝大多数的基础架构而只在一些特定功能上存在差异。新一代 SoC 往往会有很多的上一代的模块被嵌入其中，因为没有令人信服的理由去取代那些已经被证明构建好且可以实现充足功能的模块。复用那些已知的的可以工作的部分不是一个新的概念，而且毋庸置疑的是实现市场化目标的一个基本的部分。

最近我们身上发生了这么一件事：一个几乎所有的外部组件都已经在内核主线中得到完美支持的 SoC 进行了升级。CPU 内核被替换，但外围组件保持一致——除了为符合新 CPU 核心所作的一些 VHDL 的细微改动。现在我的工程师性格也许应该期待Linux对于B代片上系统的支持只存在调整现有的驱动程序这样的小问题而已。现实是供应商们组建了一个小组去开展对“新”的片上系统和所有从头重写的驱动程序的支持。与此同时我们抓到一些驱动程序去审阅，而另一些进入了主线，所以我们为同一片半导体硅得到了两个完全不相同的驱动程序。

有一段时间，我非常难以接受这样一种观点：宁可从头开始重写成打的驱动程序也不愿坐下来鉴定那些已经存在的、被证明可以工作的驱动程序，根据新的 SoC 的设计去修改它们。嵌入式工业经常复用硬件，为什么就不能同样复用软件呢？

SoC 的多样性

无疑，每一个 SoC 供应商都会叫喊他的芯片在所有方面都是独一无二与众不同的，共享很多的代码基本是不可能的。从市场方面很容易理解这些，但是如果你深入查看 SoC 的数据表，独特的外围模块数量并没有多令人兴奋的增加，鉴于该系统芯片供应商相同的市场目标和相同的客户群，或多或少的预期。一份调查揭示了不同的供应商经常使用相同的或十分相似的IP模块去实现一个给定的功能。只有很少数量的功能性方法去实现一个给定的硬件需求，而且只有很少的相关IP模块供应商把自己“独一无二”的构建模块提供给其他的 SoC 供应商。差异性常常只是局限于供应商们在登记注册的安排上以及不同的供应商选择不同的功能子集这件事实上。

我们最近看到了一些被证明是正确的内核合并工作，当清理中断子系统时我注意到只有两种广泛运用的中断控制器。不用投入太多努力就可能将30个声称有“与众不同”的芯片实现代码全部替换掉。一个相似的成就是，在替换掉许多重复的通用输入输出（GPIO）芯片的支持代码过程中，这些都是很容易得到的成果并且有更潜在的合并方法。

避免无用工作

与那经常只有很少的时间去复审的维护人员们打交道似乎是一个瓶颈。那些导致了提出复审评论的额外的工作也看起来像是浪费时间。维护人员的数量和复审可用的时间固然是一个需要注意的限制性因素。复审的能力对于那些维护着一个特定内核的子系统的人不是限制，并且我们希望看到更多的人参与到复审的进程中来。花一点时间去复审别人的代码是一个收益巨大的工作，它就像对所有接近者打开了一个人的思想以使他们更好的理解全面的状况。

从另一方面来讲，让别人复审自己的代码也是很有益处的，一般来说可以让你的代码更好和更具可维护性。并且为我们避免在下一个项目中犯错提供了帮助。在最近的一次已经进行过很多轮的复审中，一个1200行的驱动程序被缩小到了250行，并且少量的漏洞和主线错误得到了修正。

我曾经有机会在一个冗长的复审进程之后和开发者们谈话，他们中的大多数人承认学习和理解更多的Linux开发方式的机会的痛苦要大于复审进程和一些必要的回顾工作。当检查最近的补丁时我经常注意到，这些开发者已经提高并且避免了一些在第一次尝试时所犯的错误。所以复审对于开发者和他们的公司来说都是有益的，复审帮助他们用更高效的方法写出更好的代码。我称呼那些仍然叫嚣着复审和其所带来的工作是主要障碍的人为表里不一的，他们在努力把他们所在公司的责任转嫁归咎到的内核社群。

一个问题是不培训他们如何同Linux社区一起工作就指定专有的实时系统（RTOS）开发者们去写Linux内核代码。不懂如何同Linux社区一起工作不是什么羞耻，毕竟，包括我自己在内每一个内核开发者都是从一个不知道的点开始着手的。但是它花费了我一段时间去学会如何同社区一起工作，而且它也将花费那些专有 RTOS 的开发者们一些时间去学会和社区一起工作，这些所付出的时间和努力都是值得的。

Fork ARM内核后，需要解决哪些问题？

假如有一个专门的ARM GIT仓库，扮演一个所有Vendor trees的堆积站。它将不时地把主线内核的增强功能吸收进来，这样的话，嵌入开发人员就能获得新的文件系统特性和网络特性等。推断出近期流向Linux的SoC支持补丁，移除掉这上面的所有正确性检查将导致那个ARM树的增长率立即超过所有主流内核的增长率。并且，如果主线内核的增强功能像需要我最近的一些工作有所改动一样，也需要ARM树的所有驱动都改动的话，那该怎么办啊？谁来完成这些改动？如果驱动都在主线内核里面，驱动是作为这些增强功能的一部分发生改动。如果有一个单独的ARM fork，一些ARM-fork的维护者将不得不完成这些改动。

而且，谁来维护这样一个树？我严重怀疑是否会突然出现足够的有经验并有资格去处理这样一大堆改动的维护人员。维护人员在与主线内核打交道时，他们有所抱怨，为了避免这些，他们也许只会扮演集成者的角色，仅仅是在中央区域对各个Vendor trees进行合并。

我们会从这样一个动作中收获什么？据我看来，我们将一无所获，它仅仅是让所有人都声称他们所有的代码是一个神秘的ARM Git tree的一部分。当然短期内，这样会完成最终的产品上市要求。

ARM-fork能支撑多久呢？

我严重怀疑ARM复制树能活得过若干个内核周期，原因很简单，核心代码的改动将导致不兼容SoC API产生完全不具有维护性的#ifdef混乱，这会让任何不得不维护这样一个“野兽”的人立刻抓狂。我十分确定没有一个ARM-fork的支持者曾经试过将五个vendor trees拉取到一个单独的内核树上，并处理DMA APIs，驱动子系统，基础结构的冲突改动。我知道嵌入式内核的维护者的确因为这些原因立即变得绝望，我怀疑任何一个合理的内核开发人员会足够发疯到花掉不止几个月的时间去处理这样一件恐怖的事情。

除了它那令人怀疑的用处外，这样一个ARM fork将会从对Linux内核所有方向的影响中完全地切断ARM世界。对大部分有经验的主线维护者和开发者而言，ARM将变成一个毫无兴趣的领域。我怀疑尤其是当操作系统层面的软件的复杂性正在稳固增加的情况下，ARM行业能否禁得起以这种方式将自己断开联系。

有更好的方法吗？

从没有一个方法能从根本上解决所有的问题，但是有一些小的方法可以有效地解决主要问题点。

导致出现现在这种状况的根源之一是它的历史本质。二十多年来，ARM行业与那些不可能改变核心代码和不可能与之进行有竞争的合作的闭源操作系统打交道。如今，迁移到Linux以后，ARM的大部分都还在这个著名的模型下工作，并且让那些在转到Linux之前也在以其他操作系统上工作过的工程师继续按照过去的方式让他们的系统工作。这对管理层也是一个完美的解决方案，因为现有的自上而下进行软件开发和管理的结构和思想依然适用。

只要由此产生的代码不用集成到主线内核并且每个厂商维护它自己特有的复制品，这种解决方案貌似是有效的。有时会从客户那里传来主线内核集成的合理请求，然而，当这种方案让采用新特性变得更容易的时候，对冻结的厂商内核的依赖就会越少，并且，从最近可以看出，该方案允许对多平台的合并。后者能让合理的发行以上网本、平板电脑和相似设备作为目标工作，这是很重要的。它甚至对长期传言的在不久将来将成形的ARM服务器同样适用。这样的合并不仅需要ARM厂商的合作，还需要主线内核许多方面的合作，同时也需要那些不一定是ARM领域的维护人员和开发人员的合作。

因此，我们需要让管理层明白到坚持这个有名的模型并不是解决逐渐增加的SoC硬件复杂性以及开源世界中开发高效和可持久性操作系统带来的挑战的最有效方法。同时，我们需要解释一下在工程的层面上将Linux与其他OS平台以同样的方式对待的话，将会让前进更加艰难，至少当代码审查出现在邮件列表的时候，将是很让人痛苦的。

另外一个我们需要努力做的地方就是大量的协作性合并，这些合并需要先让芯片提供商至少在OS工程层面上接受他们的SoCs并不是销售部想让他们相信的那样独一无二。正如我以上提到的那样，尤其是对低复杂性的硬件，仅有有限的几种方式去实现硬件上指定的功能。因此，我们需要鼓励开发人员首先去看一看现有代码是否可以重构以适应新的设备，而不是轻率的拷贝最接近的驱动（或者在最差情况下随机拷贝一个驱动），并设法以hack的手段去适应新的设备。

另外，内核维护人员也需要对这种情况更加警觉，并且帮助开发人员避免重新造轮子。如果不能达到驱动再利用的目的，我们可以将通用功能取出来放到核心代码里面，避免那样的重复。有很多唾手可得的东西在那儿，Linux整个内核社区需要变得更好并且花更多的心思去避免代码重复。

最近Linaro发起的ARM SoC合并提前开始了这样的行动。但是仅当我们意识到与现有公司文化的冲突并在非技术层面上解决掉这些冲突的情况下，代码合并才会成功。

保密

除了上面的这些问题，秘密堡垒将成为下一个主要的挑战。当然，芯片提供商可以对它下一代SoC设计保密，但是它在营销公告透露的信息至少能让我们准确地预测出部分设计。

最明显一个例子是以2011剩余时间作为目标的各芯片供应商提供的下一代ARM SoCs。其中很多都会支持USB 3.0。从 IP block vendor 提供的信息知道，相比较计划支持 USB 3.0 的 SoC 数目来说，支持 USB 3.0 的 IP block 极少。那意味着在里面有重复的驱动，我很确信这一点，工程师都知道没有那个团队会被允许跟竞争者的团队交流。即使他们被允许这么做，也不可能猜测出谁会用哪一个特定的IP block。所以当秘密堡垒出现时，我们会看到几个工程团队在几个月内为了让自己的“正确”实现能被合并到主线驱动而争斗。

为了代码实现而竞争不是一件坏事，但是不能交流信息、讨论设计变化不会对任何一方在“上市时间”的竞赛中有所帮助。我严重怀疑任何一个即将发布的驱动会有相关的竞争性优势，即使它有这种优势，当代码公开后这个优势也不会持续太久。相互协作以及为所有参入进来的组织保留先前的工程资源的机会被牺牲掉，而却用来以竞争为导向的行为样式上，这让人很伤心。这些样式还没被改革掉，因为他们不过只有二十多年的时间，还从来没有遭到开源操作系统竞争环境的审查。

前进之路

逐渐增加的硬件复杂性，产生了更多的操作系统层面上的软件，导致知名度高的OS层面的软件开发人员长久以来短缺，而这不是能用金钱或者通过安排大量的脸颊开发人员能够抵消掉的。ARM领域是如此多样化以至于所有提供商都没有机会得到足够数量的杰出内核开发人员，对他们的竞争者产生严重的破坏。在这个事实下，这个观点相当正确—那就是那些杰出的开发人员普遍更愿意工作在开源环境下而不是半封闭环境下。

大概是时候让管理者们反思他们的竞争模式并开始理解和利用协作模式的大量优势。有能力的开发人员当然不会放弃这个机会让自己加薪，但是若能得到更让人享受的工作环境，虽然薪水稍微低一些，对很多人来说却是一个强大动力去拒绝加薪的诱惑。对我来说，没有“上市时间”竞赛，没有股东利益手册，没有人力资源管理课程的想法是很吸引人的。

我希望为嵌入式提供商工作的管理者能够开始去理解开源是怎么运转的以及为什么与这个社区合作会有巨大好处。毕竟，平庸的、老旧的服务器提供商都能想出如何与Linux社区合作，因此对快速移动的嵌入式提供商也不是那么难的事。然而，我是一个现实主义者——有时被称为脾气暴躁的老人——在嵌入式行业做了超过二十五年的时间，一点不相信真会这样。对如此多的SoC提供商而言，做出与社区合作的决定是出于外界的压力和炒作。

外界压力不是开源狂热者所希望的那样由开源社区本身的影响力造成的。不是的，他只不过是客户要求芯片至少基本上被主线内核支持所造成的压力。炒作是无处不在的，似乎总可以称为一个有效的理由去避免基于长期考虑所做的常识性决策。

我身上的永久乐观主义仍然希望嵌入式世界很快会成为Linux社区的一等公民。而我身上的现实主义却又怀疑在我这个脾气暴躁的老人退休之前它是否会发生。

Illumos:OpenSolaris社区的继承者

翻译：曾怀东/朱翊然

在2010年8月，存储供应商 Nexenta Systems宣布了一项免费的OpenSolaris发行项目：illumos。Illmuos的最终目标包括两个方面：一是使用开源代码取代所有仍在OpenSolaris使用的专有代码，二是围绕之前的OpenSolaris代码库建立一个独立的社区。现在已经过去了将近10个月，Nexenta Systems于5月20日在Amsterdam召开了Nexenta European User Conference并展示了Illumos的计划和Nexenta的产品。现在正是关注Illumos进展情况的好时机。

源代码

Illumos的代码库正在形成或将要形成一组发行项目，包括来自Nexenta的存储应用，来自Joyent的云计算平台以及通用的OpenIndiana（这是OpenSolaris发行精神的继承者）。他最初的目标之一是用开源的组件取代OpenSolaris代码库中仅存的部分二进制代码组件。现在，Illumos仍然保留着部分二进制代码的组件，例如NFS lock manager，IKE deamon（Internet Key Exchange， IPsec的一部分），一些支持的库，以及一些驱动，但是据Garrett D’Amors（Nexenta系统的开发主管）所说，Illumos的开发者正在致力于解决这些问题。而且，去年编译Illumos仍依赖于Sun Sutdio编译器，Illumos现在使用GCC构建（build），尽管这还需要更多的测试。

Illumos已经从一些硬件厂商（Areca，4Front）那里获得了贡献的代码。根据D'Amore所说，还有来自于主机总线适配器和网卡供应商贡献的一些代码正在等待合并。而且，Intel和LSI成为了Nexenta的技术合作伙伴以及主要的赞助商，这意味着Nexenta获得了这些公司的规范和工程方面的支持。D'Amore还说到，很快会得到这两家厂商的代码贡献。值得注意的是与Illumos/Nexenta关系并不很好的AMD和Nvidia的缺席。但是，在D'Amore自己博客的评论中，他解释到：这些合作关系或是非合作关系不会一成不变：“我很高兴和其他厂商维持良好的关系，无论是NVDIA或是AMD。只是在此刻，这三家公司中只有Intel向illumos或Nexenta伸出了橄榄枝。”

成长的烦恼

目前，有一些针对Illumos运作方式的批评。因为对“思维狭隘，ZFS中心独裁以及大教堂式的开发模式”不满，Stamos Tolias已经开始呼吁创建分支。显然他开始筹措资金并准备在11月份将自己的分支项目公开。项目的领导来自于Athens大学，经费支持来自于某欧洲研究基金，并拥有EADS作为合作伙伴。Totlias并没有回应本小编的问题进行澄清。

Tolias批评Illumos的部分矛头直接指向D'Amore，后者在自己的博客上进行了申辩：

D'Amore进一步解释到，Illumos没有处于Nexenta的绝对控制之下：

D'Amore正在与Software Freedom Law Center合作，准备为Illumos创立一个法律实体，让这个法律实体成为一个独立的组织完全独立于Nexenta。所以，目前在某种程度上，Illumos的发展确实不够开放和独立，但是Nexenta一直在努力为一个真正的属于社区的Illumos进行着铺垫。

Nexenta

Nexenta建立在Illumos的基础之上，造成了两面性的影响：一方面是一个开源的GNU/Solaris操作系统（2009年是版本2），Nexenta Core Platform (NCP)，另一方面是一个商业存储解决方案，NexentaStor。后者是基于ZFS的存储解决方案，通常是由系统集成商和增值经销商（VARs）购买作为带有认证的硬件的整体解决方案的一部分，认证的硬件大多数来自于LSI，Quanta，Dell，Supermicro, 和 Intel这些厂商。

Nexenta的关键卖点是他自己声称的“"Open Storage”：因为NexentaStor使用者能够简单迁移到其他操作系统支持（同一版本或是新版本）的ZFS上，例如Solaris, FreeBSD 等等，他们可以不用担心厂商对他们数据的 Lock-in。相比之下，大存储厂商使用专有的磁盘格式，它们的解决方案紧密结合自己的硬件。使用Nexenta，用户甚至可以自己选择需要购买的硬件。

之前Nexenta的用户空间部分（除了kernel外）是基于Ubuntu的，但Nexenta 4（计划在2011年底发行）将基于Debian 6("Squeeze")。Nexenta工程师们做这个决定的原因是：Debian更容易移植，而Ubuntu有太多使用特定Linux特性的补丁这造成将用户空间部分移植到Illumos核心更困难。Nexenta 3仍会基于OpenSolaris内核，Nexenta 4将成为第一个基于Illumos的Nexenta产品。因此，既有OpenSolaris内核到Illumos内核的切换，也有从Ubuntu用户空间到Debian用户空间的变化，Nexenta 4 的确是一个很大的变化。

但是，现在仍然有很多的“FUD”在ZFS和合作者之间蔓延。去年，存储厂商NetApp向他的竞争者Coraid发送了一封威胁的信件，结果Coraid决定停止代售其ZFS存储设备（基于NexentaStor的）。在甲骨文和NetApp之间也有诉讼，该诉讼不得不处理NetApp对ZFS违反专利权以及NetApp使用来自于Sun公司的具体技术的权利的申诉。甲骨文和NetApp解决了他们的纠纷，但是他们和解协议的细节并没有公开。

Nexenta 以及其他在自己操作系统中使用ZFS的公司肯定不用担心和甲骨文公司的官司：ZFS代码的CDDL授权允许其使用任何甲骨文可能拥有专利的代码。但是NetAPP或者其他组织仍然能够因为ZFS代码对他们专利权的侵犯控告Nexenta，尽管从今年开始Nextenta成为了Open Invention Network (OIN)的一部分。在Nexenta的欧洲用户大会主题演讲上，首席执行官Evan Powell明确表示他认为这个成员身份是为了应对潜在的NetApp专利侵权诉讼：“如果NetApp要起诉我们，我们可以通过由OIN共享的Novell的UNIX专利起诉他们。”

StormOS

2011年1月，Nexenta还聘请了Andrew Stormont，他是StormOS——一个基于Xfce桌面系统的Nexenta核心平台衍生品——的开发者。这个桌面操作系统面向那些喜欢类似于Nexenta提供的ZFS/apt combo服务，但是不想安装桌面包的人群（因为Nexenta并非针对于桌面型用户）。目前，Stormont作为一个软件工程师，主要在为即将上线的Nexenta 4打包软件，但他最近也提交了Illumos补丁。

作为他在Nexenta Systems工作的一部分，Stormont一周中有一天是在做StormOS的工作，而且他在Nexenta大部分的工作，StormOS最终也能从中受益。但是从StormOS项目启动开始，它始终更像一部独角戏。StormOS的下一个版本——StormOS Flash——将基于NCP4以及一些来源于Debian 7的一些组件（比如X.Org和Xfce的更新包）。其中一项新的特性将是一个在文件管理器中整合ZFS快照的Xfce图形界面，类似于OpenSolaris中GNOME的时间滑块功能。

Stormont正在考虑的一个更具实验意义的特征是FatELF：在单独的二进制文件上支持32位和64位架构。Illumos内核已经具备在32或者64位的硬件模式下自动启动的能力，所以内核中的二进制文件就能够自动的运行于正确的模式。

在一次接受电子邮件采访中，Stormont解释了FatELF可以给StormOS带来哪些好处:

其他公司

Nexenta不是唯一支持Illumos的公司。Joyent是另外一个大的贡献者，它聘请了像Bryan Cantrill 和 Brendan Gregg那样的Solaris核心人员。Joyent已经发布一个存有他们的一些补丁的git仓库到Illumos树上。John Sonnenschein在他的的树公告中写道：

一些补丁是Joyent特有的，但另外一些的用途更普遍些。大部分的补丁为区域功能的增强（操作系统级别的虚拟化），以及DTrace（Solaris动态追踪框架）的改进位在云中提供更好的分析。许多这样的改变可能会在不久的将来找到它们的用武之地，虽然现在有实际的问题：Illumos 使用Mercurial 而Joyent使用Git。

另外一个代码贡献者是数据库公司 Delphix,该公司雇用Adam Leventhal，他曾经从事于RAID-Z工作(一种冗余模式，类似于RAID 5，使用ZFS)，也是DTrace的共同发明人。Delphix似乎更愿意保持其参与的安静性，因为它们还没有公布任何关于他们的贡献，但是粗略的看他们在Illumos仓库中的提交，表明他们肯定参与其中了。因此，虽然Nexenta Systems仍旧是主要的贡献者，但也有一些其他的公司已经参与其中。

Google Summer of Code

尽管发布还不到一年，Illumos 已经在Google Summer of Code (GSoC) 2011上作为指导组织者的身份出现。他们已经接受了两个 Illumos GSoC项目：Harshit Jain将更新Illumos，为了能引导GRUB 2，并支持用GUID分区表（GPT）从硬盘启动，该项目由D'Amore指导；而Shashank Karkare在Joyent's John Sonnenschein的管理下，将用C重写一些Perl系统组件(如intrd和kstat)。后者的目标是为Illumos消除Perl运行时的依赖。

此外，Nexenta还资助三名未进入GSoC的学生。例如，Andrey Sokolov将在没有区域（zone）的情况下做支持Illumos 上的linux二进制文件的工作（商标（branded）区域是在虚拟环境中在Solaris上运行linux二进制文件的一种方法），Bayard Bell将从事IKEv2守护进程的工作去代替IKE，Viktor Ikonnikov会位服务配置工具svccfg写一个GUI的前端。对于GSoC以及Illumos学生的未来版本，Illumos已经有了大量的项目设想的清单。

ZFS工作组

另一个在Illumos 保护伞下的令人关注的发展是ZFS工作组，虽然它有点低调。这个小组由Delphix 和 Garrett D'Amore的Adam Leventhal and Matthew Ahrens (他曾工作于Sun/Oracle 的ZFS)在几个月前成立的，Ahrens是该组的组长。小组的目标是通过协调工作和交换思想促进ZFS社区的合作。特别是，创办人担忧ZFS会分裂成各种不同的支持文件系统的操作系统的子社区。

ZFS工作小组包括来自Illumos/OpenIndiana, Mac OS X（最有可能Don Brady开发ZFS支持他的公司Ten's Complement），FreeBSD(或许是移植ZFS的Pawel Dawidek)，Linux, 和Solaris的开发人员. 按照D'Amore的说法, Oracle也在小组中占有一席之地。该工作组的活动不是公开的，部分成员不希望自己的成员身份公开，但是会定期的发表讨论的结果。

ZFS工作组的第一个结果是feature flags proposal。在公告中，Matthew Ahrens写道：

该工作组的第一个产品是ZFS 磁盘版本化方法的设计，在没有进一步明确的协同信息的情况下，此设计将允许分布式的开发ZFS磁盘格式变化。这种方法消除了两个开发人员都分配版本号31去表示他们自己功能的问题。这种“特征标签”版本化允许未知版本被识别，而且在许多情况下，即使在未知的磁盘特征的情况下，ZFS池或者文件系统可以是只读的。我的建议涵盖了SPA/zpool, ZPL/zfs, 发送流，以及分配压缩和校验标识符（枚举值）的版本化。

正如Ahrens所说，这个特征标签功能是必要的，因为与只有Oracle/Sun开发ZFS的时候相比，当前ZFS的开发正处于一种更分布式的方法。在ZFS v28之后，Oracle已经停止发布它的源代码，而Illumos，FreeBSD以及其他支持ZFS的操作系统不希望等到Oracle发布Solaris 11后的再一次代码公开，所以开发继续进行。因为特征标签，Oracle外的开发人员可以在不破坏互操作性的情况下添加新的压缩算法或者新的RAID变体：大多数情况下系统应该仍然能够在只读模式下访问ZFS池或者文件系统，如果它拥有未知特征。特征标签将在今年夏天应用，并且并入Illumos中。

结论

Illumos显然在向前发展，虽然这样做会让一部分人沮丧。Illumos的开发商大多数使用大教堂式的开发模式，而一些Illumos社区的vocal成员更喜欢完全开放的开发——就像linux正在使用的开发模型一样。对于fork和关于ZFS工作组封闭性质的批评是这些情绪的产生的后果。

然而，这些批评忘记了OpenSolaris的发展模式更加的封闭。虽然Sun发布了Solaris系统的大多数的代码，而且称OpenSolaris“开放源码”，实际并没有一个真正的OpenSolaris社区：它总是过于依赖Sun和后来的Oracle，这两家公司并没有努力去围绕他们“开放源码”的项目创建一个独立的社区。目前Oracle对于Solaris 11的开发模式是完全封闭的。

因此，虽然Illumos尚未完全开放Solaris代码库，并且还没有许多OpenSolaris的人梦寐以求的充满活力的社区，事情正在朝着正确的方向。它再也不是一个Nexenta独享的项目，它会有一个独立的Illumos基金会，而且这个项目已经吸引了一些大硬件厂商的支持。现在只是等待基于Illumos的Nexenta的发布和第一个稳定的基于Illumos的OpenIndiana的发布，让这个项目蓬勃发展起来，并重新获得那些在Oracle封闭的时候离开OpenSolaris社区的人的兴趣。

Eclipse Orion——基于 web 开发的 IDE

June 2, 2011
This article was contributed by Joe 'Zonker' Brockmeier
Web-based development with Eclipse Orion
翻译：李凯

Web 开发者应该使用以 Web 为核心的工具进行工作。这看起来是一个非常合理的事情，但是在实际的应用中，Web 开发人员被禁锢到设计用于桌面开发的工具上。Eclipse Project 正在寻求用 Orion 来改变这种现象，它是一款基于web的开发工具，用来进行web应用的开发。Orion仍然处于起步阶段，但它确展示出了很多的希望。

Eclipse project 在一月初宣布了Orion，并在三月份推出了一个主机服务版本。最初的贡献是来自IBM的原来的 Eclipse 团队做出的，并作为促进了这件事的发展。最新版本Orion 0.2 M7已在五月初发布了。

Orion跟许多开发者熟悉的Eclipse IDE是完全独立的。Orion是用一套松散的、成对的（前端是js，后端是Jetty + Equinox）组件集合成的工具。根据Orion 的整体架构，我们可以看出Orion的目标是使基于浏览器的工具成为其特色，这些工具与本地存储的数据进行交互，或者是通过REST APIs获取存储在“云”里的数据。前端代码是EPL和EDL双许可的。服务器端只有EPL许可。

适用于 Orion 的场合很多，可以是任意类型的web开发。从单个开发者用PHP、JavaScript、HTML和CSS开发简单的网站，到开发像Orion一样的架构，包括服务器端的Java组件、客户端的JavaScript、CSS和HTML。

这不是Eclipse Foundation第一次以 Web 为中心所做出努力。2008年，在EclipseCon上展示了一个基于web的Eclipse 4.0 原型。但是这个方案后来被摒弃了，Orion是一个新的代码库，它几乎不包含现有的Eclipse代码库的任何东西。

世界上已经有很多IDEs（像Eclipse）和其它开发工具，你也许会对为什么还很有必要再开发一款在浏览器上运行的工具而感到奇怪。Eclipse开发者Boris Bokowski对此有一个简单的回答——Orion并不等同于IDE。根据Bokowski的说法，开发者已经用了很多基于web的软件作为他们开发的一部分：Bugzilla，代码审查工具Gerrit，在线阅读文档，基于web工具的代码库，比如GitHub。但是他们使用桌面工具（诸如文档编辑器或者完整的IDE）来进行实际的编码和调试—------这并不是最理想的。Bokowski总结：

这个的优势在哪里呢？一般来说，从大多数基于web应用中派生出来的一个共同的优势是：开发者不用安装IDE，也不用一直保留一个（假设他们用了一个由其他人提供的主机服务实例）。它非常适合于 Web 开发，因为开发者已经用浏览器来进行测试和调试。Orion 是用 JavaScript 开发的，这意味着它的目标受众——Web开发者——应该也有能力扩展和帮助项目的发展。

Orion具有非常好的可扩展性，现在已经有一个插件架构在其上运行。然而，Orion处理插件的方式可能与你之前使用的方式有些差异。不同于在Orion托管的服务器端安装一个插件，Orion的插件 link 到那些 host 插件 JavaScript 源代码的外部网站上。这消除了开发者通过接入服务器来安装他们所需要的插件的做法。相反，他们可以链接到（或创建）插件，然后指向它们。

这些插件一旦被安装了就会一直存在着—也就是说，开发者在第一次用Orion指向它们之后就不用再重新安装了。目前，Orion并没有一个计划来保证插件不是恶意的或者提供一个kown-good插件库。如果Orion能发展起来的话，人们希望这个功能能增加进来。

Orion的开发原则是建议在任何时候都要重复使用已经存在的工具，而不是创造一些新的工具。有这么一个例子是，Orion正致为于Firebug的整合，并让Firebug 调用 Orion 当编辑器使。

获取和使用Orion

开发者使用Orion有两个办法。其中一个就是注册Orion的托管版本，叫做OrionHub。但是你也许想抓紧时间注册---根据测试公告，这个服务仅对最先注册的5000个开发者开放。当Orion社区发展以后，也许会增加新的账号注册——但在公告中并没有做出任何承诺。

或者你可以在你自己的机器上下载安装Orion。这个项目提供了用于Windows、Mac OS X、Linux的版本。相对于简单地注册OrionHub来说，安装稍微有点复杂，但是对程序员来说可以更多的控制，甚至修改 Orion 的功能。要特别提醒那些正在运行他们自己Orion实例的人们，需要注意----现在的Orion没有内置升级功能。这也就意味着，作为一个快速发展的项目，你也许不得不经常手工升级，所以必须记得自己备份用户帐号和数据。在wiki上有一些关于demo上如何清除服务器端数据的指导，你可以用这些指导来找出备份帐号和数据的方法。

在花费了一些时间来看Orion能提供什么之后，我得出的结论是它还需一些工作要做才能适合普通用户使用。事实上，Orion 的 FAQ也这么说. 尽管Orion团队正在自己使用它们，但是对于进行“实际的工作”Orion尚未做好准备。Orion最近仅仅获得了一些类似于HTML的语法高亮功能，仍然缺少 JavaScript 语言的代码完成（但是已经可以部分的支持 css 开发了）功能。现在是用 Textmate 的 grammars 做的语法高亮。想 hack 出自己所使用的语言的功能可以参考 wiki

Orion 已经可以跟Git库协同工作,包括从 OrionHub 向 Github 去 push。但目前最好还是用另外的Git客户端来完成 。Orion同时也缺少对其他版本控制系统的支持，Subversion、Mercurial或者其他VCS的用户暂时比较背。

Orion的下一个里程碑定于6月3日。这个版本会简化服务器配置，移动到 Dojo 1.6上，为内容辅助、按键设置提供扩展点，以及和不同的 Web 编辑器集成。Orion 已经获得了 Mozilla 的一些关注，打算将 Orion 编辑器放到 Mozilla 代码库里。从Orion的开发列表来看，这个项目已经相当活跃。

从目前来看，Orion并不是一个严肃的开发工具。尽管现在它已经具有了一个好的开发环境的开端，但是目前还无法在生产环境中使用；或许一年后它能做到这一点。如果你希望用它来开发你的下一个网站，你最好不要抱太大期望。然而，如果以浏览器为基础的网络开发环境的概念激起了你的幻想，那么Orion项目就是为了做这种贡献而开放的。关注这个项目是如何发展以及基于浏览器的模型超越桌面工具都将会是一件很有意思的事情。

支持内存能耗管理的 VM Infrastructure

From: Ankita Garg
Date: Fri, 27 May 2011 18:01:28 +0530
http://lwn.net/Articles/445045/
翻译：王鑫

现代的系统为了满足应用程序的需要，在每一代都会提供更高性能的CPU以及更多的内存。内存子系统已经开始提供更为广泛的能力——电源能耗的管理，这就促使我们需要重新审视操作系统管理内存的方式。Linux VM 子系统如今使用复杂的算法来优化管理资源以求获得最好的整体系统性能：除了内存区域的容量和地址外， VM 子系统若有必要也会跟踪内存区段特定的受限的寻址，以及和CPU的相对距离而定义的不同NUMA节点。考虑到各类不同主存比如PCM、或者non-volatile RAM中的内存子系统的能耗管理能力，可以开发出 Linux VM 子系统新的边界能力和属性，从而进一步被内核和应用程序所利用。

本补丁集提供了一个可以被用来标记那些属于特定内存能耗管理领域的内存块的边界的通用memory regions架构，并且从长远来看，还能够在内存能耗管理功能平台上做进一步探索。

Linux VM如何帮助节省内存功耗的？

• 合并内存分配的并且（或者）引用那些没有在整个内存空间被分散的。基本上，没有被引用的内存区域，可以处在低功耗状态。
• 支持目标内存回收，对于那些特定部分的内存能够被轻易地释放，允许那些被置为低功耗态。

什么是Memory Region？

Memory regions是一个开启了虚拟内存管理的通用内存管理框架，它充分考虑了内存分配和回收时的内存特性。它是位于真正的NUMA节点之下的抽象出来的一层，并将下层的内存硬件信息封装于其中。这一层是在启动时就被创建的，并且含有相关平台可管理内存功耗粒度的固件中的信息。比如，在支持“部分数组自刷新”（PASR:Partial Array Self-Refresh）[1]的平台上，regions可以按内存单元对齐，而这可以使其独立地自刷新或者关闭（内容破坏关闭）。另一方面，支持多内存控制器的平台则是这样控制内存的功耗状态的——为单个内存控制器下的所有内存只创建一个memory region。

对齐的目的是为了确保内存的分配、重分配以及回收是在一个确定的硬件边界上执行的。通过在memory region中创建区段，伙伴分配器将会在区域级别上操作。提出的数据结构按下图所示：

Memory regions有以下功能：

• 按照内存区域的顺序进行连续内存分配，因此保证了大号的内存区域总是比开头的那些内存区域缺少可分配的地址。
• 然而随着时间的推移，分配的内存将会分散到不同的区域。但是区域边界的概念和区域级内存统计将会保证通过目标内存分配和回收来使得特定regions被释放。

Mel Gorman提出的块式回收以及其它内存压缩策略，将会更进一步合并内存[4]。

Memory regions只是一个最基础的架构，它将使Linux VM知道物理内存硬件的特性，同时它也是实现其它复杂算法和技术来真正节省功耗的根本。

进阶

Memory regions框架是同现有的内存管理数据结构一起工作的，并且只是添加了一个被要求捕获特定边界和属性信息的抽象层而已。大多数VM代码路径同当前的实现相似，只是额外多了以预定义顺序对区段数据结构的遍历而已。

其它方法：

当然也存在着一些把同属于同一功耗范围的内存分组的其他方法。在真实的NUMA节点下伪造NUMA节点可以把内存硬件单元的信息封装起来以进行独立的能耗管理。通过最少的代码改动却可以完成像memory regions一样的功能。然而，伪造NUMA节点并不是一个很直观的解决方法，它破坏了NUMA的语义并且事实上并不通用。通过展示比真实情况的更多的NUMA节点，它呈现给管理员的并非是系统的真实情况。

挑战

内存的交叉存取被广泛地用在所有平台上来增加内存的带宽，提升内存的性能。然而，交叉存取会降低硬件中闲置内存的数量，从而影响了节省能耗。对于一个给定的平台，选择一个即有好的性能又有最优的能耗节省的策略是十分重要的。

本邮件的附件是一个 Request For Comments 补丁集，用最少的功能代码演示了可以实现的选项。它已经在1Gb的RAM的TI OMAP4 Panda板子和Samsung Exynos 4210板子上测试过了。这个补丁在这两个平台下以默认的配置文件编译的，可以被应用在内核版本为2.6.39-rc5上。我关闭了cgroup，内存热插拔，和kexec。对于这些框架的支持可以很容易地被扩展。u-boot的引导程序还没有导出关于物理内存条的边界信息，因此regions并没有按照硬件正确对齐，当然只能以硬编码的方式来做测试和演示。而且，代码假定节点中至少有一个区域。memory regions的编译时间排除将是下一步要做的事情。

运行结果

在Samsung Exynos 4210板子上，2GB RAM，以4个memory regions启动，每个region 512 MB大小的环境下，运行pagetest——一个简单的分配和访问指定页面号的页面的简单的C程序。分配的大小是512MB。下面是运行这个基准程序时的空闲页的统计：

（区域3的总页面数是57332，由于它包含了剩下的所有页面，因此区域大小并不是512MB）。

第一列代表了每一个region在基准的起始处的空闲页的数目，第二列在480MB的地方分配的空闲页数目，第三列则是512MB。region 1、2和3的内存是空闲的，只region 0被使用了。因此如果region按照硬件内存单元对齐的话，空闲region则可以被潜在地置为低功耗状态或者关闭。当然也可以不用这种方式从低址分配，但是一旦页面回收开始运行，页面的分配将会分散开来。

参考文献：

[1] Partial Array Self Refresh
http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=...
[2] TI OMAP$ Panda board
http://pandaboard.org/node/224/#manual
[3] Memory Regions discussion at Ubuntu Development Summit, May 2011
https://wiki.linaro.org/Specs/KernelGeneralPerformanceO?action=AttachFil...
[4] Memory compaction
http://lwn.net/Articles/368869/

Android 权限

翻译：刘晓佳

对应用而言，Android 权限系统采用的是一种非此即彼的机制；要么授予应用所有要求的权限，要么就无法安装。现在我们已经可以在安装的时候了解到应用都需要哪些权限，但对于非常在意隐私和安全的用户来说，能够选择否决某些权限——那些没有和该 app 正常应用有明显关联的权限，是一个更有用的功能。五月中旬以来，基于Android的CyanogenMod固件在其git tree中已经有了这项功能，然而令人惊讶的是，基于这项功能的一个新补丁遇到了一些阻力。

加入权限撤销特性的原始补丁是由Plamen K. Kosseff提供的，但该补丁解决了某些应用程序没有获得期望权限而崩溃的问题。另外，是否启用权限撤销功能可以在 CM 的“Performance Settings”菜单中选择，即使这个功能有 bug 用户也可以简单的 disable 之。现在 Kosseff 基于这个早期工作又提交了一个补丁，它允许用户“欺骗性”地授予 apps 某些权限。一个例子是，应用要求获取 IMEI 的时候提供一个假串号——这让包括CM创建者Steve Kondik在内的某些开发者很难接受。

如果没有伪造 IMEI 串号这个功能的话，也许该补丁早就被接受。Kosseff 的补丁里还有不少在隐私方面争议更小的特性。在补丁的注释中他描述了其它的方法，包括限制联系人列表中哪些信息可以传递给应用程序，或者仅仅显示SD卡的一部分内容给应用程序。不管哪种方法，都明显提高了隐私性，而且应该不会给应用开发者带来任何问题。

返回一个假IMEI值（或者返回一个假SIM ID和手机号码）主要令人争议的是，通常应用开发者都需要该信息来进行数据收集。尽管数据收集可能会被用在恶意企图，但从社区中大伙这个补丁的评论中很明显感觉到，大部分应用开发者是善意的使用该信息统计使用状况。Kondik和其他人都认为，把 CM 弄成一个对应用开发者“有敌意的环境”是会导致整个生态圈的排斥，包括应用开发者、Google、手机制造商、移动服务运营商。

但是，正如Kosseff所问到的，难道最终用户不应该为让应用程序访问哪些信息而做出决定吗？对于IMEI和相关信息，现在看来从CM开发者那里得到的答案是“不”。对于一个以解锁所有硬件潜力为目标的固件版本而言，这样做有点违背它的理念。其它项目，比如 Guardian，对这种补丁很可能就接受了。

争议的一部分在于作为使用它们代码的代价，程序开发者有权"拥有"什么并不清晰。对付费的应用来说，再清楚不过了，因为比起付费来没有更好的方式让应用开发者得到更多了。对免费应用来说，情况变得有些模糊。如果某休闲游戏获得了通讯录访问的授权，那么收回该权限或者提供一个空通讯录，这是否合理呢？此外，许多免费应用使用网络权限来抓取广告并显示在它们的应用中，这也是一种开发者使用来为开发程序提供经费的一种收费方式。此时收回权限对开发者来说是否公平呢？另一方面，如果应用发现（无法访问网络所以）无法播放广告，是否就该拒绝运行呢？

对于这些问题，并没有些简单的答案。对该问题的一种解决方案就是避免应用程序请求比它们需要的更多的权限，但是这些权限实际上并没有划分的足够细来阻止滥用。如果某人授予电子书阅读器使用SD卡的权限（假定SD存储了所需要阅读的电子书），这是否意味着可以延伸到获得其它电子书应用存储的资源的权限呢？这也假定需要网络权限来从不同地方抓取内容，那么也能使用该权限从手机中复制一份用户的阅读习惯吗？

对大多数消费者来说，这些保护措施大都没有意义。在我们看到的消费者的PC世界里，如果用户在获得最新款游戏，鼠标，或视频内容时需要安装某些东西的话，用户将会安装几乎任何东西，甚至会忽略来自系统的安全警告。但是对于我们来说，可能仅仅关心我们存在手机上的数据是否安全，而对授权给应用程序的权限进行更多的控制来解决这方面的问题却还需要走很长的路。一个免费应用程序的健康生态系统需要走的更远才行。