记得佳盛修过两回硬盘，虽然每次海波和我也忙得鸡飞狗跳，但直到自己来承担业务的主要责任，才能真切体会佳盛当时郁闷和无奈的心情。
RAID5 + Hotspare，每天定期早晚各一次机房巡视，按理说已经很安全了。但偏偏不知道哪里出了故障，掉了2块盘后没有报警，等第三块盘坏，一切都 over 了。
供货商检查后声称，RAID5信息已经被破坏，完全不可恢复！
最后同事介绍到护航时代，经过一天的处理，居然数据被完整的恢复出来了！！
根据人品守恒定律，开始怀疑未来几年的运气是不是已经这次提前用完。:)
附：黑色星期一带来的好处是，看到俺很郁闷的样子，晚饭后家人很宽容的把碗洗了，省去一次家务劳动，hohoho~~~
再附：这里发下宏愿，2008上半年一定要拿出邮件的存储备份方案，下半年实现部署，再也不想体会那种绝望的感受了（NO的同事不太信任新来这批DELL的柜子）
碰到一件怪事。
是测试某软件产品，在我们的 4-cpu 的服务器上运行，用 top -H，可以监视到其工作主进程的每个线程的情况。
问题是不定期的有一个(甚至2个)线程占满 cpu(100% usr)，看起来是典型的死循环；但怪就怪在这个死循环的线程能自己恢复正常，我设置了 top 每 10 秒输出日志，结果还发现每次占满 cpu 都是大约整整 3 分钟的时间，然后负载就下来了。
很容易得出结论，这里还有一个控制线程，每隔一定的时间检查各个 worker 的情况，发现不对了就恢复之...
于是把这个现象报告给 ISV，对方觉得奇怪，我们没有这种定时检查的机制啊？怎么会每次都正好 3 分钟？
显然这是一个诡异的 bug，到现在还没有查出。
而我有时候就想，如果没有主动控制？我怎么才能写出一个正好执行 3 分钟的死循环 bug 呢？
昨天突然想到这么一段代码：
在 PIII 700 上跑了一下，嗯，成功的写出一个正好 45 秒内占满 cpu 的死循环。
不晓得最后找到的 bug 是否如我的猜测
Firefox 吃内存的问题已经困扰它的用户很长一段时间了，每次无奈的看到 Task Manager 里占三四百兆的 Fx，程序员的心里恐怕都会浮起 "memory leak" 这个词。但是，据 Mozilla 开发人员 Stuart Parmenter 最新的调查表明，问题根源未必全是程序员粗心大意忘了 free，而很可能是内存碎片占了很大因素
怎么来避免内存碎片呢？只能去寻求更好的 malloc/free/realloc 库了。在 Windows 平台上，自 XP 和 Server2003 开始，微软提供了一个叫 Low-fragmentation Heap 的机制，以解决碎片问题。Stuart Parmenter 已经编译了一个基于 Low-fragmentation Heap 的 fx3-b1 build 供大家测试。【Stuart Parmenter 还提供了一个叫 RAMBack 的插件来回收内存】
在 Linux 或其它平台上怎么办呢？有热心人在评论里面提到 "Use Doug Lea's malloc. It's far better than Windows Low Frag heap"，而且还指出了另外的一个方案： reaps (http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf 和 http://slashdot.org/comments.pl?sid=120623&cid=10160124)
另外，感觉由于 webkit 在 Mobile 平台上的成功 (iphone 和 gphone)，Mozilla 也开始重视移动终端了，要不怎么这么费劲的去找用户早就抱怨了很长时间的内存问题，并且计划重新启动 Minimo 呢
Ulrich Drepper 最近的大作，在 lwn.net 上 已经 免费 发布 到了 第 6 部分，最后一个章节目前只有 lwn 的付费读者可以看到，普通读者还得静心等待一段时间才能一窥全貌。
Ulrich Drepper 是我所知道的 RedHat 的除 Ingo Molnar 之外的另一个大牛，(哦，不好意思，我还认识 RH 的一个小牛牛阿壮)，以至于偶尔把这两个人搞混。Ingo 是内核高手，Ulrich 则是 glibc 强人...既然牛人已经说了这份文档讲的是 What every programmer should know about memory，所以我想咱们这种水平很糟糕的程序员还是老老实实的看看吧。
PS: 是否应该翻译成中文呢？？
为了将 python 对象得以持久化保持（比如为了 web app 的 session/cache 需要），我们不得不将其序列化后转成字符串扔进文件或者数据库里。
Python 提供了两个基于 C 的模块 cPickle 和 marshal 来做这个序列化反序列化的操作。marshal 貌似仅限于少数几种 python 内置数据对象，所以想象起来好像 marshal 比 cPickle 要快一些，而且我们自己做的几次benchmark好像也证明了这点。但实际上果真如此吗？
scaner 也曾写 blog 说明他的测试是 marshal 比 cPickle 快，但有留言说用同样的程序得到了相反的结论..
今天在搜索中发现有老外做过比较全面的测试（07年10月18日的文章），结论是在某些情况下--比如浮点数、长的字符串--cPickle 是比 marshal 要快滴。最后他的建议是： "...even for simple data structures, for a caching layer you might as well use cPickle; you are not particularly slower for the thing you're going to be doing a lot, and you get a bunch of (potential) benefits in return."
其测试程序在http://utcc.utoronto.ca/~cks/programs/python/marshal-vs-cpickle.py
Python S60 对 1st 的支持在 1.3.1 之后就不再提供官方支持了，可能觉得这部分用户群实在是太少了。
不过还是有某牛自制了 1.4.0 的 sis，让老机器用户仍然可以享受最新版 PyS60 的功能（比如对中文 SMS 的支持）
其地址是：http://cyke64.googlepages.com/pys60distribution (注意：发表本文时 googlepages 貌似正在被盾中...)
这个哥们还提供了一堆有意思的库(http://cyke64.googlepages.com/)，有些不错的东西
这个题目有点长还有点拗口似乎。
话要说到去年底我翻译的这篇 web.py 0.2 教程，这个页面发布不久后，收到一封陌生人的 email，问我这个页面是手工做出来的，还是用工具做的。我据实回答。他说能不能做个工具自动做呢？我还真没想过这个问题，平时也很少翻译东东，所以就不了了之。但他的“拷问”倒是一直敲打着我。
最近 jQuery 玩了玩，于是做了这个工具来练手。如果要做到跟被翻译的页面风格一致，应该要另写一个程序去解析页面，把什么 <h1>、<p> 之类的拆出来，万一页面要是用 <div id="..."> 去控制格式，那就更不知该如何处理了，困难不小，头比较大，没有继续这个更高的需求。
欢迎有需要的人试用生成 Google 翻译效果页面工具
HttpWatch 一个很酷的功能就是告诉你哪些内容是直接 cache 的，哪些是 304 缓存的
Fiddler2 做不到这一点.... 那么何不俺自己开发一个?
但涉及到开发 BHO... 还是用 python + comtypes 来搞吧...
可 BHO 是要 dll 的，貌似 python 只能玩个 py2exe。
难道采用 C embed Python ?? 还是看看 IronPython 吧。
在 IronPython 网站上找到了 Pyc 这个例子。成功的按例子把脚本编译成 .exe(winform 的 HelloWorld 例子编译后不过 6kb 大小)，看起来生成 dll 是没有问题的。
没有继续下去开发 BHO (经过这么一番浏览后俺已经很累了)。 只是想，按照这样方法做出来的 dll 大抵也可以做得很小，只不过需要运行系统上有一套 .NET Framework 罢了，这算什么，貌似很多软件现在都需要 .NET Framework 呢。
IronPython 主页上的一则消息吸引了俺的注意：Silverlight v1.1 Alpha includes IronPython support!
Silverlight 是什么？以前只知道它是 MS 推出的一项类似 Flash 的技术。Flash 是用 ActionScript 开发的，而 Silverlight 用什么语言开发，却一直没有研究过，想来也是一个 js-like 的语言而已。但......可以用 python 来开发 Silverlight 应用？？？？？？？
立刻合上笔记本屏幕，仔细的想了想这里面的关系。* 而 Silverlight 是基于 .NET 的，跨浏览器的，RIA执行平台
我这才觉得自己算是稍微有点理解 .NET Framework 了。真是了不起，在PC终端上，微软的理念无人能比。(但它的公关经理好像不怎么称职，hehe)
附: 这段时间我每天有相当长的时候是用 IE7，而不是 Maxthon or Firefox。老实说，IE7 确实是一款不错的浏览器——对普通用户而言。今天尝试了最新的 Safari(310A18) + 最新的 WebKit，支持了中文输入，除了某些页面上中文显示有问题外，还是蛮顺手的。
前不久从 Ajaxian 上看到一个叫 Companion.JS 的东东发布了 0.2 版本。今天得空测试了一下，相当不错强烈推荐。
有意思的是这个工具支持 Firebug 的 console API. 感觉 Firebug 现在是确定了 JS 调试的权威地位，后来者都以它为标杆来追赶。
IE Developer Toolbar + Fiddler2 + Companion.JS，现在 IE 终于有了一个还过得去的调试环境。说不定哪天 MS 把 Companion.JS 也收购了，反正比 Facebook 便宜多了，哈
前不久，向 U 盘上拷了一张照片打算去冲洗，但就在出门前，突然发现 U 盘无法访问，提示未格式化的驱动器...
这有何难，立刻想起曾两次挽回俺分区的 TestDisk，正好用来恢复分区。于是信心满满的执行，它也发现了 U 盘上的 FAT 分区表，预览前看了看分区表里的根目录信息，完全正确，写入！
随即俺就傻眼了，虽然恢复后的 U 盘可以访问了，看起来文件也都一个不拉的挺好，但文件内容统统都不对了..
懊恼中突然想起 TestDisk 作者还提供了一个数码照片恢复工具，在 TestDisk 目录里面就有，于是试了试，效果还不错，把丢的那张照片找回来了！！
PhotoRec 的工作起来是扫描所有磁道信息，发现可疑的曾经存有文件的数据(而且格式它能识别的)就 copy 出来，这样甚至可以起到一个 Undelete 的效果。俺 1G 的 U 盘最后恢复出的数据有好几G，当然实际上不少文件实际上数据是错误的了。
PhotoRec 除了能恢复照片，还能恢复 pdf、txt/html、doc、甚至 rm 等许多格式，强烈推荐!!
附：最后去冲洗店，把俺的 U 盘一插，就看见里面除了 1 张照片外又多了 2 个 .exe 文件和一个 autorun.inf。恶心的是和店员反馈他们的机器有木马，竟然满不在乎的说到处都是，也懒得管。真恐怖! 以后去数码冲印要小心
本站的feed
最新评论