Shell's Home

要死的磁盘挂载

Mar 20, 2009 - 1 minute read - Comments

follow了我推的人应该都看到了,从昨天到今天,贝壳都在狂找U盘挂不上去的原因。贝壳的两个本子,一个T61一个HPmini,明明都装的Debian testing,两边的配置都一样,怎么就是一个可以挂载U盘,一个就是无权限呢? 贝壳首先进行了包检测,是否少装了包,结果没有。然后再进行了配置对比,也没有发现差异。而后,贝壳祭出了绝技,strace和dbg的调试。一跑,贝壳傻眼了。一台机器是AMD64,一台是i386。CPU和内核完全不同,导致整个行为没有一点可对比性。难道无法挂载是因为CPU的问题? 在贝壳长达10多小时的排查后,贝壳无意中打开了HPmini的fstab文件,发现一个让人绝倒的事实。贝壳的HPmini是从u-live上面镜像过来的。因此继承了u-live上面LABEL=live-ntfs /的设置。而亲爱的gnome-mount是会启用这个文件的—— 结果,这就是贝壳悲惨世界的原因——

上网本,UMPC,手机的混血

Mar 17, 2009 - 1 minute read - Comments

贝壳最近又手痒想败家了。对象是上网本,UMPC,或者HTC G1。不过以上三者都不怎么完美,要能结合起来就非常有诱惑力了。要是价格低点那就更—— 不说瞎想了,就说说上网本,UMPC,G1的概念和对应客户。以及贝壳为什么想要混合以上几个东西。 UMPC是指和电脑具有类似构架,但是更为小型的电脑设备。当然,官方有更严格的规定,例如最低分辨率,触摸屏等等。UMPC和上网本的区别主要就是官方的几个内部规定,满足就是UMPC,不满足则是上网本。但是对贝壳来说,不管这些,好用就好。贝壳希望的机器,具有7寸的触摸屏幕,对应的键盘。这样的话,贝壳可以用键盘来操作电脑(熟悉的人应该记得贝壳的快捷键使用和单手操作电脑的绝技吧),并且触摸屏可以剩下一个触摸板的空间。 但是,仅仅以上条件却不能让贝壳满意。为什么呢?首先是因为体积。现在的上网本经典大小是230x160x30,这么大的一个家伙,就算带出门也够当板砖用了。其次,这东西不支持SIM卡插槽,这造成了非常麻烦的问题(当然,支持恐怕是更麻烦的问题)。贝壳无法通过这个本来直接上网,打电话,管理电话。 其实,后者的特性主要是针对HTC G1去的。现在的手机基本已经相当的智能,但是却有两个先天的问题。一个是没有能让人用起来很爽的键盘!这样写起程序来非常费劲(旁:汗—— ..-_-||||,手机上还不忘编程,真TMD是程序员)。其次是构架不同于经典的x86构架,扩展和使用程序都非常不方便。 如果一个本子,有200x150x30的大小,0.8kg上下的重量,支持SIM卡插槽,支持触摸屏幕,使用SSD硬盘。还可以标准的安装debian,使用linux下的各种程序。那基本就是贝壳梦想中的本子。当然,如果价格能在3000以下更好….贝壳可以拿这个本子到处跑(虽然体积还是个问题),到处写程序看电影看小说都不成问题。还可以打手机(那可以直接从thunderbird中拨出阿~~),GPRS上网(TMD混蛋中国移动,现在 3G还没出来呢)。 当然,现在很多手机基本也可以实现上面的功能,除了一个标准尺寸的键盘外。但是可惜的是,这些手机的系统都不是标准的系统,一般用户是无法重写和定制的。如果按照刚刚的方案来定制,那么整个机器上跑的就是一个完整的系统,甚至可以跑一个XP起来。稍微定制一下就可以当手机专用系统用了。像贝壳这样的编程人员更可以方便的给手机编程,来扩展手机的功能。 还有更好的一个方案,就是将手机回归原始。使得整个手机除了电话和短信外,什么功能都没有。而后给手机指定一个标准接口,在需要进行复杂应用的时候,直接插在上网本的外面当外接设备使用。这样手机的屏幕和键盘都可以极度精简,体积小巧方便使用。接入电脑后,非常方便的可以浏览网页,观看电影等等。其实本质上就是一个强大的手机(当然,要用经典构架)外接一个大型(相对大型)的显示器和键盘系统。

Remember The Milk

Feb 16, 2009 - 1 minute read - Comments

这是篇广告文。 不知道你有没有听说过GTD?我长话短说介绍一下,如果你每天都有成堆的事情要做,经常忘记做什么事情,每天都在焦虑是否有什么被忘记了。或者你经常被意外的事情打断,无法顺利工作,甚至忘记正在做什么,那么你真的需要好好看一下Get Things Done这本书。这本书的主旨在于推荐你一种生活方式,一种不需要焦虑是否忘记了什么的生活方式。他的步骤很简单,最少只需要纸和笔就可以进行(当然,贝壳推荐用电脑)。如果你需要做什么,用纸记录下来。做好一件事情,用笔划掉。每隔一段时间,回顾一下,什么事情还没做,什么事情拖沓了,哪些事情应该先做,哪些事情应该后做。简单来说,就是Todo List。 那么Remember The Milk(下面简称RTM)好在哪里,值得贝壳特意推荐呢?事实上,贝壳在GTD上换过不少工具。Mozilla Sunbird,太庞大,要用的时候老去开笔记本?gtodo,很小巧,问题大同小异。Rainlendar,很漂亮,显示还不错,Todo List就碰到了一样的问题,贝壳总不能天天开着笔记本走路吧(虽然实际情况差不多)。Google Calendar,倒是非常好,行事历丰富,支持短信提醒,同步选项众多。Outlook,Sunbird,Rainlendar,甚至可以直接同步到手机上(不知道的同学,请参考GooSync)。但是有个致命缺陷,无法将事件标记为完成。这样要表示完成就只有删除事件,导致无法回顾。因此,贝壳最终选择了RTM,配合Google Calendar使用。 贝壳已经将RTM设定为主页,这是贝壳的第二个主页,头一个是iGoogle,可惜做到后来太杂乱无章,废弃。每天贝壳空下来了,跑到RTM上,看看今天需要完成什么事情。如果有突发事件(例如你在写论文的时候突然需要找一些资料,有人突然说贝壳来一下),那么评估一下突发事件的状态。一般来说,如果突发事件没有上下依赖关系,没有回顾的必要,没有突发中的突发(这是最主要的),那么完全可以不用记录。否则你需要先记录突发事件,将他标记为最优先。如果不这么做,当再次发生突发事件的时候,你要么补充记录上一个的,要么就会忘记事情。一般来说,10分钟以内可以处理掉的事情是很少被再次打断的。当然,如果可行,贝壳推荐突发-延后的处理方式。就是说,当突发发生后,将突发要处理的目标记录下来(例如,12点前去客户那里一下),标记为最优先,然后接着处理当前的事务。这样一般只会中断1分钟的思考,不会造成记忆的混乱,你的工作可以顺利的继续下去,不会受到各种因素的干扰(当然,必须先处理例外,例如:贝壳来一下),也不需要担忧忘记事情。 如果在不能开机的状况下,例如路上,贝壳优先考虑使用RTM的mobile版本。如果不行,那只有记录在写字本里面,回去补充。而后,每天晚上,贝壳会翻看一下今天的记录,看看明天有什么需要做的事情,哪些优先,哪些可以推迟。如果有空,可以做什么计划好的事情。等等等等。那么同学们会问了,Google Calendar呢? GC可以和RTM结合,从而看到RTM的事件列表(方法就自己gg吧,贝壳不废话了)。当然,这只是有限的结合,意义并不大。GC真正的意义在于方便的和手机同步,从而对固定议程,重复议程有很好的显示和提醒作用。例如记忆生日,提醒周报,记忆飞机等等。这个和RTM的GTD并不冲突和重复。

磁盘对倒迁移

Feb 12, 2009 - 5 minute read - Comments

贝壳的本本坏了。 Acer的质量真不怎么的,只是正常使用而已,买来不到一个月就返修。费时费力不说,还差点因为IWT的问题无法修理而要付钱。结果刚刚过保半年,总共买了一年半后,坏了。 趁机问老板要了一台ThinkPad,虽说联想的做工不如IBM,不过依旧非常舒服,不愧是商务王者。但是,贝壳原来在笔记本上配置的复杂到死的系统,要是在新机器上一一重装的话,费力先不说,项目肯定是无法按期完工了。 贝壳修旧机器的时候,拆下了硬盘和电池。这里顺便提醒送修笔记本的同志们,记得拆下硬盘和电池。硬盘是你机要数据的所在,将来要恢复系统就全靠他了。而电池——到时候要是发现电量少了,这种东西谁都说不清楚。所以还是拆下来的好。那么,最低限度的,要从旧硬盘上读出数据,否则很多东西完全无法运作了。所以——贝壳找人借了一个移动硬盘盒。嘿嘿,这种东西可以将笔记本的SATA转换成USB使用,从而在新电脑上直接读取旧电脑数据。 为了不重装电脑,贝壳决定在新电脑上直接使用旧电脑的系统。将旧电脑的数据整个复制到新电脑上,就是俗称的磁盘对倒。下面是一个关键的问题,是重建文件系统,然后复制数据好呢?还是直接镜像整个系统?如果是复制数据,相对的数据清晰干净,但是容易发生一些莫名其妙的错误。如果是整个镜像,对了错一并带入新系统。贝壳在这里选择比较保守的方案,镜像整个磁盘。 首先贝壳从U盘启动(刚刚做了U live debian,冲着拯救去的系统,不知道是说幸运呢,还是乌鸦嘴呢),而后删除原有磁盘的所有分区,输入dd if=/dev/sdc of=/dev/sda,将整个磁盘复制到新电脑上。这里注意,贝壳没有设定区块大小,因此速度比较慢,正确的设定大小有助于加速复制。贝壳的数据是 120G(因此向公司申请的电脑最低是120G硬盘),复制速度是10M/s多一点,复制时间大约是3小时15分钟。从晚上9点一刻一直到晚上12点半。在完成复制后,直接重启,从硬盘启动Linux,成功! 在几乎没有任何干预的情况下,Linux就可以开机成功,不得不说这给了我很大信心。然后我去启动windows——不动。 贝壳被迫回到了Linux,仔细调试驱动,设法最快的弄出一个可用的系统。下面详细记录了ThinkPadT61上安装Debian的全过程,有兴趣的可以看看。至于六牙四皂和某猫小姐就可以跳过了。 首先贝壳调整了复制后的硬盘上的分区。由于分区表是按照120G的时候计算的,因此新硬盘上的分区使用不足。启动gparted调整大小后,sda6占用了全部新增空间,暴增到200G。而后贝壳开始查看pci设备和驱动。 # lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c) 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c) 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 0c) 00:19.0 Ethernet controller [0200]: Intel Corporation 82566MM Gigabit Network Connection

回京感想

Feb 8, 2009 - 1 minute read - Comments

昨天临时接到通知,贝壳周五(二月六日)要去北京出差。具体情况不多说了,不过——贝壳要回老家了。可一年半没回去了阿—— 早上5点半从杭州的宿舍出来,赶7点半的飞机。打车走了快一个小时,杭州的机场确实也够远的。师傅紧赶慢赶总算给我提前40分钟赶到了机场,离停止办理手续只有10分钟。这点住北京就很有优势,出门10分钟就到机场。6点半起床,赶8点的飞机绰绰有余。飞机很顺利,事情很顺利,贝壳就不多废话了。唯一的插曲就是贝壳的linux不支持投影仪,搞了半天总算在老板的机器上成功演示。 别的不多说了,就说说北京的风景吧。多了一堆莫名其妙的建筑,其中多数是政府机关的办公楼。贝壳原来认得的地方全都不认得了,鼓楼,宣武门,东直门,也就长安街还保持了一点原来的风景——当然,不算那个巨蛋的话。东直门改的面目全非,斜街那里完全看不到了,建了一个什么汽车中心。西单图书大厦已经快7年没去了,门口那堆书的摆设还在,但是被围起来不能坐了。西单文化广场被修的光怪陆离,完全看不出原来的样子。灵镜胡同没去,不过想必也不复旧观。 贝壳干完事情,被放到了丽都。本来准备和几个高中同学聚聚,可无奈前天才刚刚接到通知。刘江陵同学和佟国美同学非常义气的回了消息,不过很遗憾的,都没赶上机会。李鸿国比较忙,就不说了。老猫直到贝壳快闪了才有反应,够迟钝的。贝壳最后无奈的决定,不去顺义了,直接去机场,第二天可是8点的飞机。丽都旁边贝壳只认得915,那是去顺义的。所以贝壳弄了部车去机场,走的是附路。 机场附路,算算可是有年头没走了。自从在牛栏山上学以后,京顺路通了,附路修路。贝壳就主要坐915去北京,很少走附路了。现在的附路路面都翻修过,比原来顺了很多。运河上的桥还是那个老样子,不过有一段因为要修轻轨,因此被重修了。到了机场,贝壳碰到了一件非常囧的事情,贝壳被锁在家门外了。算算都26的人了,居然还会碰到这种问题。家门口等家长回家,又不是小学生。不过无奈的,贝壳就碰到了这种事情。老妈去上海探亲,老爹上班。大老远的从上海来北京出一次差,居然被锁在了自己家门口。无奈,贝壳出门转一圈吧。 从家里出来,贝壳绕着机场走了一圈。发现机场多了很多小店,建筑也被翻修过了。想必是为了迎奥吧,机场这里是最敏感的地方。唯一没变的就是机场高速的收费站和贝壳的破窝。呆在小时候常爬的假山旁边,不出意外的发现当初奋斗(真的是奋斗,贝壳小时候很胖)很久才能爬上去的山顶差不多就是一伸手的距离。公园的松树还在,前面的大广场却没人跳舞了。工人文化俱乐部(原来唯一的作用就是放电影,我们过去常常在这里看)被改成了XX货真价实的俱乐部,上了金色的招牌,不过恐怕就和工人无关了。最大的变化是贝壳的小学,机场二小,永远的消失了,变成了94中机场分校。估计是机场这里去94中的太多了,干脆弄个分校过来,省得费力。家后面的一排树全推了,改成了通向三号航站楼的大道。 坐在家门口的公园旁边,贝壳感觉五味沉杂。这么多年在外面,始终觉得自己是个过客。没想到到了自己家,才发现家已经不再是从前的样子,自己还是过客。上次出差,呆了两个月。这次出差,呆24小时。贝壳始终来来去去,来了又走走了又来,到底哪里才能停下呢?

MSN Space可以通过邮件创建

Jan 30, 2009 - 1 minute read - Comments

听说MSN Space Blog可以通过邮件创建,今天测试一下。 如果大家正确的看到了这段内容和前面的缩进,可以试试通过邮件编写blog。对于经常出差离线写东西的人很有效哦。

牛年快乐

Jan 26, 2009 - 1 minute read - Comments

过年了过年了 祝大家牛年快乐,万事如意 贝壳敬上

24点计算原理和程序

Jan 20, 2009 - 1 minute read - Comments

最近开心上狂算24点,于是贝壳搞了一个24点计算程序,并且说明原理。 我们将24点问题一般化,变成一个搜索问题。假定从一个初始表开始,里面有一些原子。我们定义一个操作,结合。每次操作任意从中选择出两个(或者以上)原子,使用算符连接,成为一个新的原子。那么,一般来说,24点就是计算所有可能的路径,从初始表开始,持续进行结合,直到只剩下一个原子,并且对这个原子求值得24。 有人可能在算符优先级上想不开,其实不用考虑这个问题,每次求值的时候,按照求值顺序优先就可以。你想到的另外一种优先级可能,会在穷举的时候被列举出来算掉,不用担心遗漏。 同时,算子必须是两目以上算子,因为单目算子可以持续作用于同一个对象,因此原子表中的原子个数并不严格单调减少,造成无法肯定路径收敛于有限步骤上。并且,如果允许单目算子,那么我只需要求导和阶乘就可以对任何数字求24点。 ((a')!+(b')!+(c')!+(d')!)!=24 因此,单目算符是没有意义的。 另外,注意算符分可交换和非可交换的。例如:a+b=b+a,但是a-b!=b-a。如果不注意这点,倒是不会漏算,但是会造成搜索空间增大,并且有重复结果。 以下是24点计算程序,python版本的。有兴趣的朋友可以用scheme重写,相信会更简洁有效。回头会用django封装一下,做成网页给大家玩玩。 #!/usr/bin/python import sys symbol_list = [ ("%s+%s", True), ("%s-%s", False), ("%s*%s", True), ("%s/%s", False), ("%s**%s", False), ] def diff_seq(length): for i in range(0, length): for j in range(i + 1, length): yield (i, j) def get_less_state(input_state): for i, j in diff_seq(len(input_state)): temp = input_state[:] del temp[j] del temp[i] for s in symbol_list: rslt = s[0] % (input_state[i], input_state[j]) rslt = "(%s)" %

论同时的双系统--准虚拟对双系统的进一步扩充

Jan 12, 2009 - 1 minute read - Comments

熟悉贝壳的人都知道,贝壳是个linux爱用者,不过因为工作关系,经常要使用windows。贝壳在自己的笔记本上使用了linux/windows混合双系统,并通过共用磁盘的方式共享数据,解决这个问题。但是长期的使用表明,这种解决方案存在几个巨大的瑕疵。首先是系统切换时间常,因此长期在一个系统中工作,而很少触及另外一个系统。其次是稳定性差,windows下一旦崩溃,进入linux后就需要检测数据盘,80G的数据慢慢扫描,感觉晕到死。那么是否有一种方案,能够同时使用两个工作级系统(注意,不是实验级,贝壳成功的在windows下的vmware里跑了一个oracle,这个可以说是实验级的典范。然而工作级系统的要求和实验级完全不同)。 从系统发展史的角度来说,我们可以预见,将来的系统将是脱离硬件的。首要的原因就是和硬件不相匹配的各个层级的计算能力需求。现在系统发展有两个极端,一个是虚拟机,试图将一个硬件整体分离,运行多个系统。另一个是高性能集群,试图将多个硬件合并,运行一个系统。从根本上说,这是因为高性价比的硬件集中在了一个性能区间,而实际的性能需求却是完全分离的,因此我们才会出现如此两类完全背离的需求。而现在有大量宝贵的人力浪费在了系统和硬件结合,系统稳定性问题上,这无疑是对将来发展的一个巨大瓶颈。虽然无法预知将来的技术发展会以何种方式解决这个问题,然而可以预见的是,解决硬件和性能的背离将是人类计算机发展史上一个重要的里程碑,解决这个问题的人必定会在计算机历史上留下重重的一笔。 同时,更进一步,贝壳揣测,将来的解决方案将是系统硬件调度/驱动和系统软件管理分离。一个软系统拥有一个用户表和一个硬件表,硬件表上写他可能有10个键盘,两个显示器,或者一堆其他设备。系统借助某个可信方案,管理了一系列虚拟抽象设备和真实设备形成的映射。作为系统层以上的软件,我们只要关心如何操作这个虚拟设备即可。而实际上,我们可以通过管理参数和对应关系实现各种需要。例如我们可以将多个机器的硬件管理核心加入一个系统,形成集群。或者我们可以在一个机器的硬件管理核心上加入多个系统,形成虚拟机。这个基本是分布系统的观点。如此一来,系统层软件就无法得知也无需得知自己是在到底运行在什么环境下。只是这个系统设计方案对高性能要求的子系统(主要是显卡)相当不利。 从揣测回到现实,为了实现一个工作级系统(幸好,还不是工业级),我们需要为系统制定一些评判标准,以判别各个方案的优劣。我们首先能想到的评判标准就是速度,一个慢吞吞的系统解决方案是没有任何实用价值的。当然,这个速度是有差异的,可能是linux快一些,windows慢一些,或者相反。我们假定实际的需要是windows快一些,因为linux可以通过定制进行加速。 我们的第二个评判标准就是稳定性,经常会崩溃的系统不比慢吞吞的系统好到哪里去,甚至会更加让人讨厌。虽然工作级系统并没有工业级那样高的要求,然而高负荷稳定,宕机平均频率低于3天/次还是要保证的。而后我们还希望两个系统可以做到数据互通,即两个系统间的数据尽可能的共享,至少要做到文件和邮件的共享。最后,我们希望解决方案简单易用,便于实施和维护。 而后,我们列出了一个原始方案,和以下几个改进解决方案,并给出优劣评价,谨供大家参考借鉴。同时我们在其中还补充了一些无法实际解决问题的虚拟化解决方案,并且说明无法使用的原因,供适合的人自行选用。 原始方案,windows+linux+数据分区。此种方案是最中规中矩的,性能最高的方案。具有对硬件最好的支持,最容易的维护。如果需要运行游戏(尤其是魔兽,WOW),这也是唯一可行的工作级方案。稳定性评价属于尚可,主要由于ntfs在linux的稳定性并不好,ext3在windows需要使用非官方驱动,和某些(就是avast)驱动不兼容。数据互通比较方便,通过数据分区可以轻松的共享文件和邮件。 windows虚拟方案,vmware+虚拟分区。这种方案是改进方案中唯一可以跑游戏的,因为虚拟机随时可以关上。性能上满足windows快 linux慢的要求,虚拟系统显示性能良好,也可以通过文件共享部分的解决数据共享问题(文件共享方便,邮件共享困难)。稳定性很好,基本没有什么不稳定的问题出现,操作和维护都不困难。然而之所以一开始这种方案就被排除在外,主要是因为这种方案无法让linux驱动实体硬件,无法通过机器启动。这样也许对一些跑起来玩玩的人或者是内核工程师/测试员比较有用,然而如果要在linux里面进行大量工作,编译程序,运行服务,这种方案就力有未逮。因此这个方案可以说是一个实验级方案,而非工作级。 windows虚拟方案,vmware+实体硬盘。速度一般,windows快linux慢,基本和上面一个方案一样,唯一的区别就是linux也可以被实际驱动。然而这也成了整个方案的最大败笔,因为linux的驱动灵活性不如windows,因此无法经受这种系统切换的动作。举例来说,真实的机器上,硬盘是sata的,作为sda识别和使用。而虚拟机上则是IDE的,被识别成了hda。于是启动环境一变,就需要修改大量配置来调和这个问题。又例如,在真实机器上,X使用fglrx驱动,而虚拟机下面要用mesa。如果我在/etc/xorg.conf中不指定驱动,那么真实机器的驱动也会变成 mesa,导致性能下降。如果指定驱动,又会导致虚拟机内X无法运行。诸如此类的问题林林总总,需要大量细节修正,因此维护复杂,稳定性差,不建议正式使用。在贝壳机器上更严重的,出现了虚拟机内和虚拟机外争抢数据分区的状况,这种情况下数据分区实质是被当做盘阵用了。使用非专用的磁盘作为底层共享存储,并在上面运行ext3系统,这是及其危险和愚蠢的。 linux虚拟方案,xen。速度超快,但是上来就在贝壳的机器上暴出几个问题,因而没有继续测试。首先是安装xen后x无法启动,出现fglrx驱动无法加载的状况。其次是xen要求使用虚拟盘启动,可贝壳经常需要跑到windows下面打游戏。因此在简单测试后被剔除出局。感觉这种方案的最大问题在于配置管理太过复杂,debian下面已经很轻松了,只需要安装对应内核,使用工具建立虚拟机,但是依旧感觉麻烦到一塌糊涂。相信这种方案在专业级服务器领域应当有不俗表现。 linux虚拟方案,openvz。这种方案压根就不适合贝壳的状况,因为这个虚拟方案要求宿主和客户必须是同一CPU同一系统(不要求同一linux发行)。主要用于希望将一个主机切分成多个独立的同构主机,以达到分离管理的目的(例如业务服务器和数据库服务器分离)。需要做大型网络管理/虚拟主机业务的人可能会对这个虚拟方案感兴趣。 linux虚拟方案,vmware。速度一般,linux快windows慢,视频效果不错。vmware毕竟是商业公司,视频驱动挺齐全的。但是内核驱动的编译麻烦到死,首先是要求编译器版本和主内核编译器版本一致,于是贝壳去搞了个gcc-4.1,然后连接了上去。下面又是内核头定义出现版本差异,搞到现在还没有搞定。谁能搞的定的给个参考,最好是debian上的解决方案。 linux虚拟方案,kvm。这个是贝壳目前使用的方案,基本比较理想。速度很快,和xen基本差不多,显示速度不如vmware(理论上说装好显卡驱动应该会好点,不过贝壳找不到CLDC5446的XP驱动,那是Win32和Win95时代的显卡)。linux快windows慢,但是还在可忍受范围内。稳定性很好,只要测试通过,运行中到目前为止没有死机(当然很多参数是加了之后开机即死机)。数据可以通过samba互通,邮件也同样可以互通。然而使用samba无疑复杂很多,而且性能并不太好。只是从稳定性上说,让linux自己去驱动ext3总比半吊子的windows驱动更好,同时也不会出现争抢的问题。易用性上还算可以,无论是内核编译还是系统使用都不太难,最大的麻烦就是网络配置。根据贝壳的测试,在真实机器上superpi运行100W 位需要45秒,虚拟机内需要54-60秒,尤其在换用kvm-72.2后反而更慢了(54下降到60,折合真实机器83.3%下降到75%)。 总体来说,贝壳更倾向于使用全开源的准-全虚拟解决方案kvm,主要因为他简便易行,对系统影响小,不改变现有系统。同时性能高,稳定性好。主要需要解决显卡效率问题。如果以上问题无法彻底解决,贝壳打算换用linux下的vmware,想办法搞定他的内核模块。

新年快乐

Jan 1, 2009 - 1 minute read - Comments

废话不多说了,新年快乐。 TMD想找个人说新年快乐也找不到,全出去Happy了,真该考虑找个女朋友了。 另外,专门在Linux里开个虚拟的Windows来写这个东西——鄙视一下微软的产品对Firefox 4 Linux的支持。另外,真TMD的复杂,真浪费。