博文

目前显示的是 九月, 2009的博文

终于在solaris上把icu编译过去了

由于google的部分网站被封,所以icu的主页根本打不开,要想把icu下载下来,也花了好大功夫。像往常那样./configure,make,但是在链接的时候报错错误是:ld: 致命的: 重定位仍旧与可分配但不可写的节相反
以下是出错的时候的log
make[0]: Making `all' in `stubdata'
make[1]: Entering directory `/usr/software/icu/source/stubdata'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/software/icu/source/stubdata'
make[0]: Making `all' in `common'
make[1]: Entering directory `/usr/software/icu/source/common'
g++-4.3.2 -m64 -ggdb -W -Wall -ansi -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -D__STDC__=0 -fvisibility=hidden -shared -h libicuuc.so.42 -o ../lib/libicuuc.so.42.1 errorcode.o putil.o umath.o utypes.o uinvchar.o umutex.o ucln_cmn.o uinit.o uobject.o cmemory.o udata.o ucmndata.o udatamem.o umapfile.o udataswp.o ucol_swp.o utrace.o uhash.o uhash_us.o uenum.o ustrenum.o uvector.o ustack.o uvectr32.o ucnv.o ucnv_bld.o ucnv_cnv.o ucnv_io.o ucnv_cb.o ucnv_err.o ucnvlat1.o ucnv_u7.o ucnv_u8.o ucnv_u16.o ucnv_u32.o ucnvscsu.o ucnvbocu.o…

wow的这场闹剧越来越有意思

http://tech.sina.com.cn/i/2009-09-23/23253462670.shtml鉴于这种新闻很容易被咔嚓掉,复制全文如下:来源:新京报网 时间:2009年9月23日2009年9月16日夜间,本网发布的《魔兽世界或两天内开服》报道,由于本报记者依据别有用心者对中央编办有关网络游戏审批管理文件的错误解读,在没有充分理解中央编办有关解释文件,也未向网络游戏前置审批部门——新闻出版总署核实的情况下,发布“中央编办下发有关国家机关的‘三定方案’,确定网络游戏的审批、监管、执法等权力由文化部负责”等错误信息,严重干扰了国家新闻出版总署依法履行对网络游戏《魔兽世界》的审批工作。又由于忽视了某些利益公司背后的用意,在报道中援引了所谓“如果网易不发行游戏光盘、杂志等媒体产品只是运营的话,只需要拿到文化部的审批即可”等错误解读。在此,我们对上述报道给网络游戏审批管理工作造成的感受和在业界造成的误导表示诚恳歉意。对社会公众,特别是对广大网民深表歉意。背景:上周末,网易突然停掉所有魔兽服务器紧急维护,然后开服毫无前兆的开始收费运营。我说他何苦呢,难道以后不再做新游戏了?

关于完美通行证登录协议的分析

以前和同事争论过,如果为了防止密码被数据库管理员偷窃,密码的hash运算应该放在服务器而不是客户端。但是现在越来越多的网页把这个过程用JS来实现。http://passport.wanmei.com/ 。这是登录地址。通过分析该页面的源代码,可知协议流程如下:1、C->S,发起http请求,建立连接2、S->C,challenge,一个随机数r。(就是验证码)3、C->S,username,hmac_md5(r,hash(username+password))这其实就是Challenge-Handshake Authentication Protocol (CHAP) 的一个拙劣的变种。如果我不知道原始密码,只要我知道hash(username+password),一样能登录。换句话说,真正的是密码是hash(username+password),服务器必须把这个以plaintext的方式在数据库存储,或者,它必须把password以plaintext的方式存储。优点:因为认证过程未采用HTTPS,在不安全的信道上传输。这种设计方式有效的防范了playback攻击。缺点:Both the client and server must know the plaintext of the secret一个可选的改进是采用MS-CHAPv2:
首先,服务器和客户端必须知道密码的hash值,并以之作为对称密钥Kab
1、C->S,建立连接
2、S->C,16位的随机数r1
3、C->S,生成一个16位的随机数r2。{r2,{hash(r2,r1,username)}Kab}
4、S->C,解密上一步的报文,如果成功,发送{r2}Kab

开发环境搭建完毕

我把emacs卸了,这个我爱了5年的baby。因为我觉得我目前用的这个桌面环境还是很稳定的,所以很少会用到控制台.事实是我根本不知道怎么切到控制台:-(
而在图形界面下,gedit已经很好用。虽然它不支持正则表达式搜索虽说它不能定义宏。唉…eclipse+cdt真的是很不错的选择。只是opensolaris自带的gcc太老了,还是3.4.x。虽说这是gcc所有版本中用的最广泛的,但是…毕竟太老了。IPS中有4.3,其实我在freebsd下已经在用4.5了。但是遗憾的是gcc 4.3和gdb 6.3貌似很不兼容。所以必须自己编译gdb 6.6。不过编译的过程是很顺利的,第一次采用默认的prefix,顺利的就过了。第二次装在了/usr/下,但是它错误的把libexpat.so找在了/usr/lib,其实我加了-m64,应该去/usr/lib/64下找。我没仔细去看为什么这个会和prefix有关。总的来说,就是eclipse 3.4.2+cdt/gcc 4.3/gdb 6.6/gmake/sun ld。另外,发现一个很有用的宏:_GLIBCXX_DEBUG,其实它历史已久,反正3.4.x中就有了,但是我今天才发现。关于它的详细描述可参见http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html一个例子是如此:#include <iostream>#include <string>intmain(void){ std::cout << "hello" << std::endl; std::strings("abc"); char c=s[20]; return EXIT_SUCCESS; } 如果不加_GLIBCXX_DEBUG,它会顺利运行到main结尾并return 0。如果加了,在s[20]那里会抛异常(行为很像std::string.at)hello
/usr/lib/gcc/i386-pc-solaris2.11/4.3.2/../../../../include/c++/4.3.2/bits/basic_string.h:721: typename _Alloc::rebind&l…

write cache的问题

freebsd 7.x下一种流行的做法是,用ufs做root filesystem,用zfs做数据盘存放应用相关的数据。比如delphij就讲了诸多理由为什么zfs不适合用来做根。可是如果你采用了ufs做/,那么他也会建议你关掉write cache/soft update以提高稳定性。但是zfs又建议你打开它。可是假如只有一个硬盘(比如90%以上的笔记本用户),那么write cache是开还是不开呢?总的来说,把zfs和ufs放在同一块硬盘上并不是一个好主意。但是如果光为了做根而浪费掉一块硬盘(其实只需要1G就够了),又太奢侈。不知道solaris是否支持从raidz组成的zpool上启动。对于freebsd我觉得这是一个很大的挑战。因为mbr中可用的空间只有446字节,对zfs对支持只能放在boot1/boot2去做。我的想法是将这2个东西用dd在每个硬盘上同样放一个,让boot2能识别raid0和raidz,我觉得是可以做到的。

opensolaris是一个混合64位环境

opensolaris的安装光盘不像freebsd和ubuntu那样分成64位版和32位版,而统一提供一张光盘。也不区分install cd和live cd。按他的说法,是可以自动识别64/32位环境。但只是kernel是这样的。实际上它所提供的大部分的应用软件、以及默认的桌面环境gnome,都是在32位下编译并运行的。甚至gcc,如果默认不加-m64参数,那么也是按照32位的目标进行编译。除了opensolaris 10外,64位的solaris我只用过solaris 10。情况也是如此。
这样好还是不好呢?我记得曾有一场争论,ls这样的命令是否需要提供64位版?其实如果不是技术的狂热者,站在用户的角度来看,他最希望的是kernel具有64位的执行能力,并且应用软件像32位平台那样稳定和丰富。如果64位的winxp也仿照这样的思想去实现,那么32位的winxp现在肯定已经彻底被淘汰了。
不过这也造就了一个传奇,32位xp版本的windows操作系统,在PC机上统治市场了8年,并将继续下去。还会有哪个版本有如此辉煌吗?

opensolaris的iwh驱动貌似很有问题

opensolaris很强大,一下子就认出了我的无线网卡,AGN 5100。但是这个驱动貌似很有问题。我在solaris下ping www.sina.com.cn 和 bbs4.newsmth.net 丢包率都是32%-35%左右,ping值在30ms左右。从国外某网站下源代码,也是时短时续,速度仅为几K或几百字节。切回来换成windows,然后继续ping,发现一个包都没有丢。ping值在7-10ms左右,偶尔会突然出现特别高的170ms左右。

opensolaris体验中

今天早上刻盘,安装了opensolaris 2009.6。安装的过程异常简单,zpool的创建、swap的大小这些全都没有给我手动选择的机会。驱动很全,该有的都有了。起码bluetooth和wifi是有了。指纹识别和摄像头这两个千古不用的设备,据说也有驱动。
首先把eclipse装了,还有gcc-4.3以及gdb 6.3。然后故意写了一个简单的C++的程序让它崩溃。int* p=NULL;*p=0;然后用gdb调试。发现,用gdb载人core dump的时候,gdb自己down了。每次都是如此。执行在gdb里运行这个程序,结果也是如此。于是我根本看不到崩溃的时候的堆栈。
我的AGN 5100尽管是有驱动了,但是还是没连接上路由。我不晓得哪里设置错了。我把路由已经改成wpa/wpa2都支持,TKIP/CCMP都支持。在solaris下用dladm scan-wifi能找到。但是connect的时候总是timeout。
root@opensolaris:~# dladm connect-wifi -s wpa -k wkey -T 80 -e scmdlink iwh0
todladm: cannot connect: operation timed out
明天把wpa的密码改短点再试下。
装了ntfs-3g,挂载的时候系统卡死,然后自动reboot了。
困了。安~

everything has lost

在经过长达9个小时的zfs scrub之后,我的freebsd的zroot pool并未能从病态中恢复。zfs scrub只是帮我找出了数千个无法被读取的文件,把这些文件删除或者zfs clear都无济于事。/var/log/message依然是被zfs无数的IO error掩盖。
我发现我的freebsd分区的CHS参数不对,于是就切到windows下读出正确的CHS参数然后用U盘启动然后bsdlabel -A -e修改。我不仅修改了CHS相关的东西,我还把zfs分区的大小也改了,改长了一点,以让它恰好是按柱面分割。
结果是,loader依然能读出zpool里面的文件,但是mount root失败并且我从U盘启动的系统中也无法正确的zpool import。说这个pool已经彻底坏掉了。这个pool的device name也不是我所设想的/dev/ad4s4a,而是/dev/ad4s4ca。我一直不明白为什么gpart show有时候会多出来一个ad4s4c。总之gpart show的输出很不稳定。要让它稳定,方法一直就是开机后等待2个小时后再运行这个命令。
最终我用gpart delete/destroy彻底清理掉了这个主分区,然后重建。然后发现bsdlabel的CHS参数是正确的。然后,gpart又时不时的捣鬼,经常说找不到ad4s4这个geom。我实在烦了。回windows删掉了这个分区。
然后去vmware下用iso在腾出来的那个空闲分区上装了一个opensolaris 2009.6。但是发现它只能在vmware下运行。
grub修改参数,去掉启动画面。给kernel加-v.
发现是mount root的时候失败了,zpool没有找到。
刻盘ing。。。