林健的BLOG

sd-daemon-java

Enabling systemd-style socket service written in Java
https://github.com/sswv/sd-daemon-java
Licensed under the GNU Lesser General Public License Copyright (c) 2012-2013, Jian Lin

How to use
Please read the example code in "src/java/org/linjian/sd_daemon_java/example", diff'ing the "Server" ones with the "ServerNew" ones.

Notice
This program is not yet mature. Only a part of functions in ServerSocket and ServerSocketChannel are covered, which may contain bugs. The simple examples run properly with this program. However, if you want to use it in more complicated or more crucial applications, this program should be improved.

Reference
systemd-style socket service in C: http://0pointer.de/blog/projects/socket-activation.html

MPI-D will release soon!

MPI-D logo

Copyright (C) 2012 by the MPI-D team
Designed by Jian Lin (http://linjian.org).
Thanks to Xiaoyi Lu, Bing Wang, Fan Liang, and Juan Peng for advice.

The meaning of MPI-D logo

1. The white hollow lines in the logo are the abstract of DOTA model. The endpoints and crosspoints from left to right represent each level of D, O, T, and A respectively.
2. The logo consists of 2 parts, the left and the right, reflecting that the nature of DOTA model is a bipartite graph. The left part is in pure gray with the sense of flatness, while the right part is in gradient green with the sense of three-dimensional space. They represent that MPI-D can transmute insipid data into vibrant value, and also show MPI-D's recognition and practice on green computing.
3. The right part is a variant of the letter D that is the first letter of Data and DOTA. The D composes of 4 blocks, representing the 4 characteristics of data computing, that is, Dichotomic, Dynamic, Diversified and Data-centric. The top and bottom blocks of the D shaped like wings represent that MPI-D will help data computing to take off.
4. The left part composes of 3 blocks, representing the theoretical foundation of MPI-D: the 3 theorems of DOTA. The 3 blocks look like the wake of the flying D as well, enhancing the sense of speed.
5. The writing of MPI-D is in black, which is mature and contrasting. The use of the open source Linux Biolinum font with light serif is easily identifiable, and brings a relaxed atmosphere without losing rigorous.

MPI-D Logo 释义

1. 图形中的白色镂空线条是对 DOTA 模型的抽象，线条端点和交点由左至右，分别代表 D、O、T、A 各个层次。
2. 图形由左、右两部分构成，体现 DOTA 模型的本质是二分图。左侧为单一的、平面感的灰色，右侧为渐变的、立体感的绿色，表示 MPI-D 将平淡无奇数据变为生机盎然的价值，同时也代表 MPI-D 认同并践行绿色计算的理念。
3. 右侧绿色部分是字母 D 的变体，即 Data 和 DOTA 的首字母。D 字由 4 块图形构成，代表数据计算的 Dichotomic、Dynamic、Diversified 和 Data-centric 特征。D 字上方和下方的 2 块图形如同两翼，代表 MPI-D 令数据计算如虎添翼。
4. 左侧灰色部分由 3 块图形构成，代表 MPI-D 的理论基础——DOTA 三大定理。3 块图形如同 3 条尾迹，为腾飞的 D 字增加了速度感。
5. MPI-D 文字为黑色，成熟稳重、对比鲜明。使用带有平缓衬线的 Linux Biolinum 开源字体，可辨识度高，在带来轻松气氛的同时不失严谨。

References

[1] Xiaoyi Lu. Research on Key Issues of Professional Services in Cloud Computing. PhD dissertation, Graduate University of Chinese Academy of Sciences, 2012. (in Chinese)
[2] Xiaoyi Lu, Bing Wang, Li Zha, Zhiwei Xu. Can MPI Benefit Hadoop and MapReduce Applications? In Workshop SRMPDS 2011, Proceedings of the 40th International Conference on Parallel Processing (ICPP 2011), 2011.

　　前文所说的这个问题，理应在 Extmail 服务端解决，然而我向 Extmail 开发者发信，尚未得到回复。尔后委托 Jeoygin 同学修改代码，却得知 Extmail 在这块的设计逻辑有些混乱，并不是改一两行代码就能搞掂的，有一些纠结的逻辑必须重构。考虑到这是实验室的生产环境，加之受影响的只有我等另类用户，就不在服务器上折腾了。
　　退而求其次，在客户端解决吧。要么让 Claws Mail 在解析邮件时忽略非标准的头部，要么在收到邮件之后将其修改正确再解析。Claws Mail 的功能丰富，但遍历各个功能，没有发现能够直接解决这类问题的选项。虽然可以通过 Action 或 Run command 机制调用外部脚本修改邮件文件，但实验发现总有一些小问题：或是需要额外的鼠标操作，或是不能及时刷新。于是决定发挥主观能动性，自己写个 Claws Mail 插件。我仿照官方提供的插件示例，实现了一个 ExtMailHeaderFixer。思路很简单，添加一个处理接收到的邮件的钩子函数，当收到 Extmail 发来的带有 multipart 和 base64 头的邮件时，将 Content-Transfer-Encoding: base64 修改为 X-ExtMail-Header-Encoding: base64 即可。之所以不在解析时处理，而要修改邮件，是因为实验发现 Claws Mail 确实可以解析符合 Content-Transfer-Encoding: base64 语义的 multipart 邮件（即将 multipart 整体进行 base64 编码），不仅如此，Claws Mail 还能解析不同格式多级内联的邮件，我不想失去这个挺酷的特性。之所以不删除 Content-Transfer-Encoding: base64 这一行，或者把 base64 修改成合法的 8bit，而把这一行修改成对客户端无影响的 MIME 扩展字段，是便于必要时快速恢复邮件原样。这个方案也有缺点，即相关的钩子函数只对 POP3 邮件有效，对 IMAP 邮件无效，Claws Mail 这样设计可能与两个协议的语义差别（接收或同步）有关。在我目前的使用场景中，这个问题不大。
　　在 32 位 Ubuntu 12.04＋Claws Mail 3.8.0 和 64 位 Debian wheezy＋Claws Mail 3.8.0 下测试通过。把代码释放出来，放在 sf.net（万古不化……），按传染性要求以 GPLv3 授权，方便遇到相同问题的朋友使用：http://sourceforge.net/projects/extmailhf/。

　　实验室的邮件系统最近改用了国产开源邮件服务器——Extmail。我在使用过程中发现一个问题：Claws Mail 客户端收到来自 Extmail web 界面发来的带有附件的邮件，内容均为空白，既无正文也无附件。而使用 Foxmail 等其他客户端接收邮件，则正常。经测试，发现问题出在 Extmail web 界面生成的邮件头中的这一行：

　　如果将这一行删除，则 Claws Mail 可以正确显示邮件正文与附件。那么，这是 Extmail 的问题还是 Claws Mail 的问题呢？既然这一问题只出现含有附件的邮件中，就从实现邮件附件的规范——MIME 的 Multipart Content-Type 入手分析。查阅 RFC 1341 相关章节，其中明确说明了 multipart 类型的 Content-Transfer-Encoding 只允许是 7bit、8bit 或 binary，而具体内容（正文和附件）的 Content-Transfer-Encoding 应在各个 part 的头部声明。因此，Extmail 在邮件头部指定“Content-Transfer-Encoding: base64”是不符合 RFC 的。而 Claws Mail 可能对标准的执行过于严格，容错能力不足，因此不能显示不符合规范的 multipart 邮件的正文和附件。
　　我又查看了 Foxmail、Coremail 等 X-Mailer 发来的 multipart 邮件，发现多数 X-Mailer 构造的 multipart 邮件在头部都不指定 Content-Transfer-Encoding，只在下面的各个 part 中分别指定 Content-Transfer-Encoding。作为具有缺省值、可以省略的字段，multipart 邮件头部不指定 Content-Transfer-Encoding 应该是符合 RFC 的，这些邮件在 Claws Mail 中解析正确。
　　因此，这个问题的根源在于 Extmail 未严格遵守 RFC。简单查了一下，构造 multipart 邮件的相关代码位于 libs/Ext/App/Compose.pm 文件，应该比较好修改。不过 Claws Mail 的“死板”也算一个原因，应对中国制造就要学会超强纠错（还记得这个例子吗）。

---

　　Update 2012-04-24: 经 Jeoygin 同学提醒，有关 MIME multipart 的更新标准是 RFC 2046。该 RFC 仍限制 Content-Transfer-Encoding 只能是 7bit、8bit 或 binary。另外，Extmail 修改这个 bug 并不是一行代码就能搞掂的，Compose.pm 里面有一些纠结的逻辑有待重构。

　　续前文。
　　本期介绍的部分发行版或发布范围有限、或为社区产品，本人没有相应实体光盘，故以截图代替照片，请见谅。如果您有相应光盘，欢迎与我取得联系。

　　Asianux 是由中国的中科红旗、日本的 Miracle Linux、韩国的 Hancom 等亚洲 IT 厂商联合开发的一款基于 Red Hat Enterprise Linux 的服务器 Linux 发行版，始于 2004 年，至今发布过 4 个主要版本。这个发行版至力于为亚洲企业提供标准化 Linux 平台，力图以本土营销和服务的优势与欧美企业 Linux 提供商抗衡，中科红旗在这一产业联盟中处于主导地位。不同于纯商业 Linux 发行版，中科红旗认为 Asianux 的产业模式依赖于政府背景，我也的确在某事业单位的机房见到过真实运行的 Asianux。除服务器版本外，Asianux 还有面向 MID 的 Mobile Midinux 版本，可能同上一篇提到的中科红旗 Midinux 是一码事。

　　采用外挂中文平台和源代码级汉化的 Linux，除了之前提到的蓝点技术预览版（0.9）和阳春白雪中文环境之外，还有 Your Linux。Your Linux 是由北京 Linux 俱乐部和北京腾图电子出版社于 2000 年共同发布的，它基于 Mandrake 7.0，汉化相关的代码主要来自 Xteam 公司。北京 Linux 俱乐部是国内较早成立的、影响力较大的民间 Linux 爱好者组织，对 Linux 在高校的中的应用推广发挥过积极的作用。腾图电子出版社当时还以“腾图 Linux 风暴”为名接连出版过 Linux 网络安全卫士、Linux 数据库及应用工具大全、Linux 多媒体及模拟器完全手册、Linux 游戏宝典等多种应用光盘，切实反映了那两年国内 IT 企业对于 Linux 一拥而上的局面。

　　CDlinux 当数中国非商业 Linux 发行版中较有国际影响力的。它的主要开发者是 Ben Zhao （benz），最初开发于 1999 年，公开发布于 2003 年，最近仍在更新。CDlinux 的目标明确、特色鲜明：早期专注于实现支持中文的 Live CD，后期版本则将 CD 重新诠释为“Compact Distro”，旨在小巧的体积内集成多种应用软件与实用工具，方便地制作成 Live CD 或 Live USB，作为便携操作系统或修复、维护工具使用。CDlinux 也是高度灵活、可定制的，官方提供 Mini、Standard、Community 三种体积和功能有差异的版本以适应不同的应用场景，并提供扩展机制允许用户按需定制应用。在我的随身 U 盘工具中，自然少不了 CDlinux。

　　Prayaya Q3 是广州的 Prayaya 技术团队（其公司正式注册名称貌似为“广州市经略电子有限公司”或“广州市慧炬信息科技有限公司”）开发的一款 Linux 发行版。其产品定位与著名的 Puppy Linux 及上面提到的 CDlinux 类似，强调轻量级、模块化，便于在移动设备上安装及与 Windows 系统共存，一般作为随身操作系统或系统维护工具使用。Prayaya Q3 于 2009 年和 2010 年发布过 2 个主要版本，分别使用 LXDE 与 KDE 桌面，集成了 QQ、大智慧等中国特色软件，同时提供了自己的软件包管理工具。Prayaya 的主打产品其实并不是 Prayaya Q3，而是 Prayaya V3，一套用于 Windows 的虚拟操作环境。

　　Veket 是由国内的一群 Linux 爱好者协力开发维护的一款基于 Puppy Linux 的便携发行版，官方定位为“上网本操作系统”。Veket 以“天空竞技场”论坛作为技术讨论和版本发布的基地，大约从 2009 年开始公开发布，版本发布时常有“纪念公元前 1066 年周武王克商”之类的雷人噱头。与多数国产社区发行版类似，Veket 的主要精力放在迎合国内桌面用户需求上，在中国特色软件以及界面主题方面做了一些工作。Veket 社区还有其硬件开发计划，即所谓“Veket 微脑”，但我没弄明白他们究竟想做什么。

　　有些 Linux 发行版纯粹出于个人兴趣。MaxCapture Linux 是一款基于 Knoppix 的中文 Live CD，发布于 2004 年，作者是广东的一位 IT 从业人士徐文达。MaxCapture Linux 在 Knoppix 基础上添加了中文字体、输入法及各项环境配置，并没有在应用程序上大作文章。MaxCapture Linux 的光盘通过 2004 年 8 月的《玩电脑》杂志光盘公开发行，并作为当期杂志的“特别话题”进行了详细介绍，这一点并非每一位 Linux 爱好者都可以做到吧。作者还编写了 Knoppix 中文版定制方法，具有一定的教学意义。

　　自由软件，就是要群策群力。