Archive for the ‘戏言’ Category
公众演说技巧
把《演说之禅》草草看了一遍，小总结一下。
Made To Stick提到的演说六原则是：简单（Simplicity）、意外（Unexpectedness）、具体（Concreteness）、可信（Credibility）、情感（Emotions）、故事（Story），SUCCESs。满足这六个原则，可以做出令人印象深刻的公众演说。
某一领域的专家对公众介绍本领域的知识时，一定要注意避免“知识祸根”。所谓“知识祸根”就是说演讲者可能会错误估计受众对专业知识的了解程度和自己一样好，然后采用过于专业的方式去演说。正确的做法，应该是以直观、显浅的语言去进行介绍。
要做好一个公众演说，前期的设计是必不可少了。为了完成这个设计，我们需要准备一叠纸，一些彩笔，一块白板，一个安静的地方，一个好的图片库，还有一个好用的slideware。初期阶段应离开电脑，而在纸上设计。适当的头脑风暴，可以丰富内容，但是在选择内容时，不要犹豫，该砍掉的就要砍掉。
Steve Jobs的Keynote值得学习，他的演说技巧还是很符合Made To Stick六原则的。
关于开发管理的一些思考
目前我们组内对开发的管理还十分初级。Wiki刚刚开始用，没有用trac、bugzilla之类的工程控制工具，只用了Mercurial进行了版本控制，交流主要靠每周例会。
学生开发组织，我觉得是比较难做到规范化开发的。一则因为外围工具的学习成本高，项目等不及；二则因为学生组织与公司不一样，至少不会因为开发流程不规范而被fire掉。在学校里面，老板要的是效果、演示，不管你用什么方法去做。
在目前开发的过程中，也出现了一些问题。原来使用Mercurial的原因，就是一个DVCS看起来更适合我们项目。组内对于Xen都处于摸索的状态，需要做大量的实验，会产生大量的commit。使用svn的话，必须等到特性稳定之后才可以commit，不合适。
当然，实际使用过程中，我们仍然保持有一个“主”版本库，其中含有稳定的代码。原则上来说，主版本库更新之后，每个人都应该与之保持同步。
现在问题来了，大家都没有及时与主版本进行同步，所以现在diverge得越来越远了。到时再想merge的话，conflict将是一个很头痛的问题。但是用svn的话，这种情况就不会出现了。
当然，只要DVCS的使用者注意同步，这也不会是什么大问题。CVCS的好处是，这个步骤是强制的，不能有意无意的略过，大家必须保持一致。
现在我已经预见到以后merge会遇到的痛苦了。
UPDATE：和小胖聊了一下，发现其实还是工作流的问题。人是活的，工具是死的。工作流做好了，活用branch，CVCS也可以解决“不稳定的新特性commit”的问题。所以最现实的，就是把工作流做好。我们缺的不是工具，而是完整的工作流。
1984
前两天把George Orwell的《1984》看完了，不长。英式文风令我觉得很别扭，翻译之后更加别扭，但是对理解小说的中心思想没有太大的影响。
其中说到的很多事情，都仿佛正在发生和将要发生。
能在1948年就写出这样的小说，Orwell敏锐的嗅觉让人震惊。
没有思想的人是可怕的，没有思考能力的人是可怕的。
当一切不合理都习以为常时，是不是这个社会的病态呢？
世界的未来在无产者手中，只是他们现在还没有觉醒。
Big Brother is still watching you.
Easier said than done
在看PicoWebServer的一个security flaw分析，嗯，典型的栈溢出。虽然多了一个Unicode，但是还是可以做到DoS攻击的。作者的分析也挺不错，把出现问题的地方说得清楚了。
不过末尾有一句话有点大雷了：
An attacker has full control over the device if he is able to let the overwritten return address point to a “0D F0 A0 E1″ (”MOV PC, SP”) equivalent byte sequence. Since SP is the only register pointing into the potential shellcode supplied by an attacker, the aim of an attacker is to let PC equal SP.
还好作者用的是if he is able to，还有点不确定的意思。我是老老实实地用IDA Pro搜索了整个地址空间（是的，“整个”），也没有发现有这样的序列。首先，编译器不会产生这样的代码，那么在代码段内找是徒劳的了。其次，数据段有的话，那真是纯粹巧合了，看人品，而且数据段能不能执行，还是未知之数。
所以啊，总是easier said than done，虽然现在有这样的possibility，但是实际上做不做得到，那还真是认真考证一下才清楚。
师兄也和我说了，搞个什么MessageBox出来，那是不难，但是我们的目标还是要再远一点，要有点实际的东西出来。我也挺认同的，理念上的东西，大家都清楚，但是到底能不能用，可不可以，那还真是要做过才知道。不产生实际危害的漏洞，不是好漏洞（DoS不在考虑之列，这是比较次的危害）。
提一下我们现在的问题是什么：某个软件，接收ANSI字符（0×00-0xFF），然后把接收到的字符转换成Unicode再存储到缓冲区，然后造成了缓冲区溢出。问题是，我们虽然可以改写栈上PC的值，但是这是有限制的（Unicode转换的存在）。如何把控制流改到我们注入到栈上的shellcode中，这需要很多工夫了。目前这是第一步，先不考虑shellcode是否有效，就是要把PC的值搞到栈上就OK了。
这一周基本都在考虑这个问题，也有不少的想法，但是最后都被自己否掉了。罗列如下吧：
- 把要发过去的ANSI串A看作是Unicode，先进行Unicode到ANSI的变换得到B，把B发过去，这样在Server端变换之后，就变成了A。这个想法的致命点是，ANSI只能映射Unicode的一个很小的子集，也就是说，变换过程不是满射的。而且从比例来看，只有1%左右有情况可以逆变换成功。于是有第二个想法。
- 寻找Unicode编码中的闭包子集S，发过去S中的A变换后得到的B仍然在S之内，这样可以很容易通过控制A的生成来得到理想的B。但是现在我还没有找到这样的闭包。即使找到，也只有万里长征第一步，因为这样的S估计不会很大，变换出来的编码有限的话，对于地址的选择就很有讲究了。
- 在其他段寻找如MOV PC, SP这样的序列（也就是上面文章的想法）。不用说，目前失败。
- 构造某个系统调用/API的输入，然后跳转到那个系统调用/API。要求是这个系统调用/API足够强大，可以完成很多功能。但是矛盾的地方是，功能强大的API通常参数是十分复杂的，很难构造。而且，Windows CE的calling convention中，首先使用R0-R4去传送参数，不够才使用栈。怎么让R0-R4符合API的要求？看运气？否掉。
- 从转换函数入手，当然，这个想法很烂。但是也不是说完全没有可能，先留着呗。
现在基本是能想到的都想了，但是总是有这样那样的限制，使得这些想法成为不可能。明天和师兄讨论一下，看他有没有什么其他想法吧。
为什么国产的 Linux 发行版不流行
按照道理来说，国产的 Linux 本地化支持更好，也更了解当地用户的习惯，这样的产品理应比较受欢迎。但是国产的红旗 Linux 等一些发行版本，在国内的流行程度却总不如 Fedora、Ubuntu、SuSE 这样的发行版。为何？
个人认为，有以下的原因：
- 国产 Linux 推广力度不够，服务支持不够好。Fedora、Ubuntu 这样的发行版，背后都有一个很大的社区支撑。国内的发行版这个方面做得很不够。
- 国内的 Linux 发行版“自由”的味道淡了。由于中国不怎么尊重版权，所以对于 GPL 这样的协议，都没有得到应有的强调。很多 Linux 的爱好者，还是很看重“自由”的味道的。
- 偏见使然。很多人对国产 Linux 的认识还很片面。他们还停留在以前的一些不好的印象上面。我也犯了这个错误。近来我才发现，原来红旗也一直在进步，它的本地化真的已经是非常完美了。
OOXML approved as an ISO standard
From lwn.net
Here’s the official word from the ISO: Office OpenXML is now an official standard. “The issues addressed and revised have resulted in sufficient national bodies withdrawing their earlier disapproval votes, or transforming them into positive votes, so that the criteria for approval of the document as an International Standard have now been met. Subject to there being no formal appeals from ISO/IEC national bodies in the next two months, the International Standard will accordingly proceed to publication.”
OOXML最后还是过关了，貌似支持的国家还很多。目前有风言风语说ISO投票有鬼，呵呵，但是过了就是过了，也不想多说什么了。
中国的UOF出来得也挺早了，但是也没见哪个产品支持。学校里面的文件还是用的DOC格式（令我非常不爽）。ODF也叫了挺久了，也是雷声大雨点小，多少有点让我失望。
退一步说，这次中国虽然在ISO上投了反对，但是Microsoft的东西还是得照样用。我一直有这样一个观点：除非Word默认的保存格式是UOF或者红头文件规定只能用UOF，否则UOF在中国永远无出头之日了。
主流操作系统及其缺陷
给应急响应安全协会写的东西，水平有限，大家凑合这看吧。
现在的主流操作系统，无非就是Windows和Unix两大派系了。
Netware、OS/2、QNX、Darwin、BeOS，现在市场份额很小。还有一部分用于大型机的操作系统如VMS、Z/OS，一般人接触不多，所以也不加考虑。MAC系列在国内份额也很小，所以也不多说了。
写给各位正在使用和打算使用Redhat 9的兄弟
Redhat 9这个发行版似乎是老当益壮，历久弥坚，直到现在还有不少人在论坛上问一些关于它的问题。而这些问题，无非也就是为什么SATA硬盘无法安装系统、驱动找不到，诸如此类。而对于论坛上的各位版主和热心回答问题的兄弟，“请换用新一点的发行版”这样的话也说过无数遍了。在看到这个帖子时，我终于下定决心，写一篇文章去纠正一些新手们的观念。
起因：为什么RH 9 不适合新手呢？ 为什么有人觉得现在很多人还在用RH9感到惊奇呢？
一点小感受
做管理的和做技术的人，想的东西果然是不大一样的。做管理的，多要从全局考虑，以尽快尽好的方式达到目标，但是有时却对某个方面需要过高，估计不足。做技术的多追求完美，对外面的压力却有时多少有点逆来顺受啊。
所以说，做管理的，全局观要有，也要了解各个方面的基本情况；做技术的，也要独立自主，敢说话。
Linux 需要系统地学习
从我自己这么多年使用 Linux 的经验来说， Linux 是需要系统地学习的。当然，假如你只是报着玩一玩的心态去使用的话，那系不系统地学习是无什么所谓的。网上的资源很多，但都是非常散乱的，而且新旧不一，有很多有错误的地方。在这里，我要讲清楚几点学习 Linux 的注意事项。
1. 至少要有一本关于 Linux 的组织严谨的书本。
2. 要学看用户手册。个人认这是最权威的指南了。没有人会对系统开发者更清楚这个系统。
3. 多泡技术论坛。但是要记住，泡再多的论坛也不能成为高手。高手都是自己磨练出来的。论坛可以为你的知识锦上添花。
对于初学者来说，最容易迷失于网络的汪洋大海之中，被一大堆资料冲得昏头转向；沉溺于论坛，光注意到皮毛方面的讨论而没有对整个系统进行深入的理解。这样到头来也只是门外小菜鸟罢了。