共 37 篇文章。
Good news is that the University has remembered to pay for a project, bad news are, I am looking for a person who is capable for maintaining Unix(R) Systems like FreeBSD and Linux, Solaris, and is knowledgable in scripting languages, etc (PHP, MySQL, etc) for the company I am working for, etc. Please let me know by sending your resume to delphij at delphij dot net.
转载自 人民网。转载此文章不代表本人对其内容的完全认可。
试图通过国家标准争取市场主动，甚至通过推行国家标准参与世界市场，正在成为信息产业发展的倾向。任何国家都需要技术标准管理，然而，如果管理不当，则很可能适得其反。WAPI国家标准是一个教训，而正在进行中的「国家Linux标准方案」很可能又成为一个教训。笔者就此为例做些探讨。
为了用Linux系统来消除微软公司对中国软件市场大部的控制，在第二届东北亚OSS推进论坛上，中方代表提出了「国家Linux标准方案」，说：「不可能等待别人来解决中文文字代码技术等标准化问题，中国正在制定自己的中文Linux标准。由于中日韩在文字代码技术等标准化问题上存在一致性，中国也希望日本和韩国能够支持和利用中方的标准。」然而，这个论坛却发生了「中国推国家Linux标准方案，日韩持观望态度」的局面。对这个事件，西方信息技术产业界及媒体十分关注，不但做了广泛深入报道，而且，从各个角度分析了中国政府确立国家标准的工作过程、提醒他们的政府和企业注意中国是否履行它对世界贸易组织所做的承诺。
推行Linux系统的中日韩统一区域的「国家Linux标准」出现拉锯局面，并非偶然。笔者认为，要正确地理解「国家标准」和遵守相关法规，要实事求是地发展中文Linux，否则，不但难以用中文Linux打破微软公司对中国市场的控制，而且，正如业内专家所说，还会给自己带来更多更大的被动。
在一阵阵唾骂和欢呼声中，《完全用Linux工作》被转载到了天涯海角。很多人支持我，也有很多人唾骂我。我不知道它是怎样流传到那么多地方，其实我不知道它都被转到哪里去了…… 我知道现在这篇文章又会罗里罗索写很长（因为我计划写这样一个东西已经很久了，坐在Emacs前面总是有一种巫师在炼丹的感觉……），所以先提出中心思想吧。中心思想就是：
很多时候我告诫自己不要去想关于OpenSource模式的问题，不过最近还是琢磨了琢磨。很久以前一个前辈跟我讨论过这个问题：
「盈利模式是一个很大的问题。现在Linux的发展模式意味着许多真正核心的开发人员并不能从中获益，这意味着一旦他们开始为生计担忧，项目很可能就会停滞不前；在国外通常会有公司雇用这些开发人员，让他们能够将项目进行下去，但在国内这种情况还非常少。」
http://computer.online.sh.cn/computer/gb/content/2004-07/01/content_888740.htm
你能相信一个连自己老窝都罩不住的操作系统吗？你能相信一群连自己老窝都守不住的人研制的内核吗？
哦，咳，咳，咳，听说了么？那个去年搞得GNU FTP差点彻底玩完，自己的bk服务器被人家添进奇怪代码的操作系统内核，又蹦出来拯救世界了！
While I believe that proactive security practice is necessary for every consumers, the most conversave ones should argue that even a security update will possibly break compablity.
Now I am in trouble. With rsync 2.5.5 installed on a FreeBSD system, we know that it is possible to overflow its heap, however, shall we patch it, or just let it as-is because it is not exploitable on FreeBSD, unlike Linux’s silly brk(9) implementation?
junsu has pointed a cool article to me. This article described a Linux kernel debugger, KDB, which seems to be useful even for reference on other kernel debugging issues.