DongHao: 09 2007存档

       自从苏-27一举成名后,苏霍伊就在它的基础上出了一套“苏-27家族”,包括苏-30,苏-34,苏-35等,其中苏-35在莫斯科航展上还露了一把脸,号称重型战斗机。苏-35长的和苏-27非常像,但核心部件更换了很多,雷达、机载武器都得到了加强,发动机也改为矢量推进的AL-31FP型涡扇发动机,机动性能更好。旧型号的苏-35有鸭翼,而新型号的苏-35没有,但由于俄罗斯战斗机编号混乱,结果它们都叫苏-35。
       片中一一演示了苏-35的雷达、发动机、机载导弹等,其中的作战模拟有点夸张,但也算是清楚明白。里面扮演反方的轰炸机很像B-52,估计俄罗斯人天生就恨西方的轰炸机 :)
       毫无疑问,好的宣传片必须有好的音乐(我向来看重这一点),这一部宣传片也不例外:片中音乐强劲且带有金属质感,简直和苏-35战斗机一样。



      可惜里面花大量时间演示了远程攻击,最精彩的近程格斗只show了一个“眼镜蛇”动作。

耳背

| | Comments (0) | TrackBacks (0)
       haodong:我的网站最近流量在跌啊....
       hero:什么?!
       haodong:我的网站最近流量在跌!
       hero:什么?!
       haodong:....什么?!

生意人

| | Comments (0) | TrackBacks (0)
       hero:听说有很多拐卖人口的,连拐卖女研究生的都有,不知道有没有卖女博士的,bihong,你要小心啊....
       bihong同学:....
       阿龙:(问hero)好卖吗?....

mdbm和bdb

| | Comments (5) | TrackBacks (0)
       简单的测试了一下mdbm和BerkeleyDB:往里面写一千万条记录,再全部遍历读一遍。读mdbm花了14秒,而读BerkeleyDB花了70秒,看来bdb确实比mdbm慢了许多,毕竟bdb只是把记录cache到内存,不像mdbm直接就把记录放在内存上(名副其实的内存数据库)。
       奇怪的是:bdb使用Hash索引比使用btree索引慢了三倍多!难道是Hash算法做的太差?不太可能吧....

       还特别发现了两个BerkeleyDB的工具db_load和db_dump,使用非常简便:
       db_dump url.bdb > url.dat              //从bdb导出为明文数据到url.dat
       db_load -f url.dat url_new.bdb         //从明文数据(必须是db_dump导出的格式)导入为bdb
       结果重新load的bdb变为原来bdb的三分之一大小了,仔细一看数据并没有变化,看来立中同志说的“BerkeleyDB为了快速写硬盘采用了比较浪费的格式,文件撑到了一定程度需要整理”非常正确,而这个dump&load也算是个离线整理数据的好办法。


    //Mutex.h
    class Mutex
    {
    public:
        Mutex(int resouce);

        //....
    };

    //Thread.h
    class Thread
    {
    public:
        void run(void)
        {
            //....
        }

    private:
        Mutex m_mutex;
    };

    int main(void)
    {
        Thread thr;
    }
        这段代码用 gcc 3.4.6 编译后产生的编译错误提示是:
        test.cpp: In function `int main()':
        test.cpp:25: error: no matching function for call to `Thread::Thread()'
        test.cpp:12: note: candidates are: Thread::Thread(const Thread&)
        *** Error code 1
       乍一看还以为是Thread的构造函数不对,找了半天才发现是m_mutex做为Thread的成员变量必须在Thread的构造中掉用自身的构造函数Mutex(int resouce) 。我的文件可不像这段代码这样明显,它们分散在好几个文件里,结果这个编译提示造成了极大的困惑。以后要小心编译器的误导。
       不过,编译器也并没有说错,确实可以直接用Thread的拷贝构造函数来创建一个新的Thread实例,gcc只是做了一件它认为正确的事而已....

新一代引擎

| | Comments (0) | TrackBacks (0)
        hero:我就是一个引擎
        Kimi:你不算,人家余斯恒才是一个引擎
        hero:他算什么引擎,人肉引擎而已了——“肉擎”
        大家:肉禽?......
        继上次发现和立中同志有共同的美剧爱好——《邪恶力量》(Supernatural)以后,昨天又发现我们在看同一部美剧,就是今年夏天开播第一季的《黑名单》(Burn Notice)。想不到大家的口味如此一致,真是相见恨晚。
       《黑名单》里的主角经常是一副坏坏的笑容,颇为可爱,片中他的遭遇虽然郁闷,但情节和话外音却轻松而调侃,可谓“举重若轻”,相比《越狱》的一团黑暗一团压抑,感觉上要舒服得多。更重要的是《黑名单》每一集剧情都相对独立,干净俐落,是不可多得的好片。
       推荐!

burn notice


武义之行

| | Comments (0) | TrackBacks (0)
        昨天到浙江号称“温泉之乡”的武义旅行。先是到寿仙谷,满山翠绿挺拔的毛竹在薄雾中轻轻摇动,让人心旷神怡。山道非常险,最险的地方几乎垂直,只能紧紧抓住路旁的扶手。
       自从96年爬金鼎山之后,再没有来过风景这么“南方”的山了,不过寿仙谷毕竟太小,一个小时就爬了个遍。金鼎山我可是花了六个小时才爬上顶的啊。

寿仙谷


寿仙谷


寿仙谷


       晚上就是非常奢靡的泡温泉活动。进去以后就是一个较大的游泳池,进去游了两下,水太浅了,刚到胸口,游得没有成就感,于是出水,再往深处走。嗯~后面绿树掩映下有不少小池子,什么“人参浴”啊,“当归浴”啊,一看,咦,这个池子都是女生在泡,我如果下去岂不是显得太过份了?算了,换一个,噢~这里兄弟多,十几个人挤十平米的池子,下去凑凑热闹。

       haodong:这个工作....
       宝方:那个工作....
       bihong同学强烈抗议:你们俩不要出来泡温泉都谈工作好不好?!
       haodong:喔....这个,好吧,要不我们谈谈轻松点的话题?
       宝方:好,那个,我觉得美国肯定要向伊朗动武的....
       haodong:同意,伊朗人够勇猛,内贾德比卡扎菲有种得多....
       bihong同学:xxxx

       之后还蒸了桑拿,冲了水疗,坐了鱼疗,不过天又黑人又多,坐在鱼池里好半天也没感觉有小鱼来挠,只看到几条小黑影在水面。想想看:毕竟是晚上了,那么多游客,鱼儿们白天都已经吃饱了,怎么还吃得下哩?

        上合组织的“和平使命-2007”军演里最亮眼的是空投演习,而空投演习中最亮眼的就要算伊尔-76了,因为所有的空投任务都由它包揽,可谓“舍我其谁”。

il-76
伊尔-76空投伞兵战车


        我过去只知道俄罗斯有个安东诺夫设计局专造大型运输机,后来才知道还有个伊留申设计局,也是名机辈出。命名人伊留申是俄罗斯著名的飞机设计师,1894年出生,1933年任总设计师。

伊留申


        伊尔-76于1971年首飞,北约代号“耿直”(Candid),属于四发中远程重型运输机,载重量40多吨,其中MF型载重量达52吨。虽然力气比不上“安”系列(安-124载重150吨,安-225载重250吨),但其航程、速度、耗油量、载重量都非常适合于中小规模的部队投送,所以成为了俄罗斯空投部队的主力“骡马”。由于缺少重型运输机研发技术,中国从90年代起向俄罗斯采购了数十架伊尔-76,“耿直”也算是中国空降部队的功臣。

il-76


il-76


        伊尔-76有很多改型,包括预警机、消防及、救护机、加油机等。其中伊尔-78加油机是最有名的改型。

il-78 and tu-95
两款经典飞机:伊尔-78加油机为图-95加油


        提起武装直升机,恐怕百分之八十的人都会想到美国的AH-64“长弓阿帕奇”,但其实俄罗斯也有很不错的武装直升机,比如米-24“雌鹿”,卡-50“黑鲨”等,其中最亮眼的当数米-28H武装直升机。米-28是米里设计局又一款经典之作,又名“黑夜猎手”,但北约给了它一个更威风更杀气腾腾的名字——“浩劫”(Havoc)。
       米-28于1982年首飞,米-28H是其最新改型,由于它在设计上大量参考了美国的AH-64(米-28最初就是以打败“阿帕奇”为设计目标的),所以如果从远处看两种直升机几乎无法区分,故而有人戏称米-28H是“阿帕奇斯基”,但其实“浩劫”的机动性和机载武器都强于AH-64。

mi-28
米-28“浩劫”


AH-64
AH-64“长弓阿帕奇”


       从侧面看,两中直升机的轮廓都是瘦长的剑鱼形,机头底部都配有机关炮和雷达(米-28的头部黑色雷达看上去像个大鼻子)。米-28H在螺旋桨顶部还加有一个球形雷达,视野广阔胜过AH-64。“浩劫”的体型大过“阿帕奇”,但俄国人过硬的发动机技术使它的机动性却更胜一筹。但“阿帕奇”的前置机关炮可以由驾驶员佩戴的头盔控制:驾驶员头部偏向何方,机关炮就指向何方;而米-28H好像做不到这一点,估计老毛子的电子技术还是要差一些。
       05年美国计划向台湾提供“阿帕奇”武装直升机,当时就盛传大陆会采购俄国的“浩劫”以对抗之,可见当今世上,能与AH-64一较高下的恐怕就只有米-28H了。

mi-28


mi-28


这是一段“浩劫”的视频,配以轻快动感的“mission impossible"音乐,颇有观赏性。


rewrite

| | Comments (1) | TrackBacks (0)
    haodong:apache怎么配置rewrite啊?
    车东:我给你找找......这样“RewriteRule ^.*\.html$ /hello.html"
    haodong:喔,这么强大。
    车东:同学,rewrite很强的!专门有本书呢。
    haodong:......车东,你以前向我推荐awk的时候就是扔给我一本书的,现在又是一本书。
    车东:你要学的东西还多着咧。
    haodong:学东西就是这样的:先是不知道,再是”知道有一本书“,然后是边写边看书,最后是再不用书。

声音

| | Comments (0) | TrackBacks (0)
    窗外一辆轿车的报警器在吱哇乱叫,声音很是烦人。
    hero:haodong,是你在叫吗?
    haodong:是啊,我在叫你。

心已被占据

| | Comments (0) | TrackBacks (0)
    连华:要不你把系统的类图画一下?
    xgp:我不会面向对象,也不想学。
    连华:为什么不想学?
    xgp:我的心已经被一些东西占据了。
    连华:是u盘吗?
    xgp:......不,是Lisp。
  
    于是,接龙开始了。
    haodong:我不会面向对象,也不想学,我的心已经被汇编占据了。
    老敖:我不会面向对象,也不想学,我的心已经被mysql占据了。
    bihong:我不会面向对象,也不想学,我的心已经被pascal占据了。
    hero:我不会面向对象,也不想学,我的心已经被awk占据了。

    立中同志:(写程序)
    我:(写程序)
    立中同志:(转过头看了我一下)
    我:(转过头看了他一下)
    (都没说话,又都转过去继续开发)
    不需要语言的对话。

  
    haodong:最近加班多吗?
    哼哼:每天从早上9点干到晚上10点,回家倒头就睡,哪有时间加班啊?


    xgp:(吃完饭回公司的路上)我每次看着平整的路面,都有一种想亲身贴地飞行的感觉....
    suning: (看着xgp“宽大”的身材)如果你学会了贴地飞行,我就可以站在你身上了——像冲浪一样
    xgp:........


    (六个人走在路上)
    hero:欧!地上有泡狗屎,小心不要踩上了,大家都小心点!
    haodong:我们六个人,要是都踩上,那就叫“六合踩”了


    haodong: 有u盘吗?借我用用。
    xgp:我口袋里有七个u盘,你要借哪一个?
    haodong:你太强了,居然随身带着....
    xgp:(递过u盘)给
    haodong:谢谢...你是一个随身带着七个u盘的男人,那么,我以后就叫你“男优”吧!


    hero:haodong,这辈子你打算写程序写到什么时候?
    haodong:写到我再也写不动为止。
    hero:哇,这么有抱负,那你估计你什么时候会写不动呢?
    haodong:(看了看表)一会儿下班了我就写不动了。

一塔湖图

| | Comments (0) | TrackBacks (0)
        前几天bihong同学给我看了张照片,是在艺园吃的一道菜,号称“一塔湖图”。那个站着的红胡萝卜是博雅塔,下面铺的锡箔纸是未名湖,牛排是湖心岛,右边白萝卜雕的那个就是图书馆了。

一塔湖图


又逛西湖

| | Comments (0) | TrackBacks (0)
        已经游过好几次西湖了,但既然这次又到杭州,那就还是要去西湖。

西湖


西湖


西湖


BerkeleyDB

| | Comments (0) | TrackBacks (0)

      做项目时遇到要存储大量的key/value对数据。mdbm可以,但它太浪费内存,同事建议用BerkeleyDB,它一样能存key/value对,而且对内存没有那么苛刻的要求。

      BerkeleyDB把主要的数据都存在硬盘,用cache来对付高度频繁的读写操作,但它不保证cache中的“脏数据”一定会立刻同步到硬盘上(除非你调用它的API同步函数)。这就意味着如果你的数据像黄金一样珍贵(比如银行交易数据),就不适宜用BerkeleyDB;但如果你的数据只是“比较”珍贵,丢个几十秒的数据没关系,那BerkeleyDB还是不错的选择。

      BerkeleyDB还支持Hash/Btree/Queue等不同的索引方式,由用户在建库时自己选择。它只能在建库时指定cache的大小,以后不能再改,通用性稍微差了些,但对于后端的底层存储系统,这不是个大问题。

      BerkeleyDB以前由sleepycat负责维护,06年oracle收购了BerkeleyDB。

      自己写程序试了试,结果coredump了,就在创建数据库的那个函数pdb->open()里,gdb又跟不进去,后来找了立中同志才知道:redhat下都默认装了bdb,我没必要下载一个自己编译,那样反而链接错动态库了。最后ok,bdb存数据确实很省。

 

听起来不痛

| | Comments (0) | TrackBacks (0)

2004年冬,大家在食堂吃饭。

haodong:我大四的时候在外面接了个活——做一个支票软件,做了三个月,拿到了一千元,反正是新手,不敢奢求太多。同寝室一个同学炒股,捣腾了一阵子,也是赚了一千元。我可是辛辛苦苦多少天啊!我当时可不平衡了,老老实实做事还不如去搞投机呢。

同学:这个不能这样看了,风险不同的,你干的是低风险的事所以拿钱少,别人干的是高风险的事就应该拿得多嘛。

haodong:我很难同意你,虽然找不到什么反驳的。

 

2006年夏,大家聚了聚。

haodong:最近工作怎样?

同学:比较累,就是那些事搞来搞去的。看看周围那些搞金融的,住大房开大车,随便挥挥手就是几十万几百万,我们这群就每天累死累活为了那点工资....不爽啊....

haodong:呵呵呵呵,我记得以前你还说别人是风险高所以收入高嘛。

同学:(无言,苦笑)

haodong:以前你只是听我说故事,没有感觉,还可以理性的“点评”一番。现在你工作了一阵子,知道钱赚得辛苦,又看到挥金如土的人,相形之下终于感到不平衡了,终于体会到我以前的感觉了,你现在不觉得他们应该高收入了?

人就是这样的——一件事情如果没有发生在你的身上,你是不会觉得痛的。

 

矜持

| | Comments (0) | TrackBacks (0)
hero: (在看suning的婚纱照)suning的婚纱照挺帅的....喔,这是谁,新娘的表妹咧!haodong,你要不要关注一下....

haodong: (马上起身)哪里!? 哪里!?

hero: 靠,不要这样嘛,你能不能矜持一点?

haodong:  矜持?!我都矜持了27年了!再这么矜持下去彻底没戏了!

高贵的愤怒

| | Comments (5) | TrackBacks (0)
        今天看到的最“火爆”的新闻就是Linux之父Linus Torvalds和Dmitry争论c与c++的优劣,Torvalds认为c++太过繁复,被一堆特殊的语言机制和编译器补丁所压倒;而Dmitry却认为Torvalds是“旧语言时代的恐龙”,认为c语言太简陋而不能适应未来愈加复杂的软件开发。两边开始还只是技术性的讨论,后来就变得有些火药味了,但总算是平息了下来——Dmitry低姿态的结束了这场争论。
        我其实是个c++ fans,但是不知道为什么,我总觉得这件事上Torvalds更能说服我  :)
       也许我成为c++ fans只是因为跟java比,c++更像c一些。
        c++确实有那么一点“臃肿”,构造函数、析构函数、拷贝构造函数、多态、模板....可比c要啰嗦得多,不像c那么精瘦那么底层,和OS靠得那么近。即使有STL,Boost这样成熟的库,c++的开发依然是艰难的——只要想想当你编译c++模板出错时编译器报的那些天书一样的信息就明白了。我现在能看懂大部分模板编译错误的信息,但是我怎能奢求其他语言的开发者能适应并喜欢上这些错误提示呢?
       c++长成这样其实也是被迫的——如今的软件越来越庞大,越来越复杂,但对性能的要求却还在提高。如果用c开发像ACE这样的网络通信框架、如果用c来开发QT这样强大而通用的界面包,恐怕只有超级程序员才能完成,但你不能指望所有的程序员都是超人。所以尽管c++复杂,尽管c++难学难用,尽管在c程序员看来c++就像个怪胎、像个异形,但它长成异形何尝不是因为计算机行业的需要呢?
       我们羡慕Torvalds,他一直以来都用c在开发操作系统,一个人一生只用一种语言开发一类软件是何等的幸福,就好像你可以跟某个你爱的人厮守一样。也许正因为如此,Torvalds对其它语言毫无感觉——反正他也没必要用。相反别的程序员,尤其是国内的同志们却更喜欢吹嘘自己用过多少种语言....这是一种荣誉吗?不,这是一种悲哀,只是大家还没有认识到。如果从国内有计算机开始你就是个程序员,那你就要先学汇编和c语言,到了90年代初,系统软件在国内活不下去了,你又只能去学foxbase学basic学c++,但是数据库系统ERP系统也活不下去了,你只能又去学java学.net....我们原来做过如此多类型的软件,学过如此多类型的语言!为什么中国的程序员就需要这么“博学”,这么“心态开放”?那是因为中国的计算机行业说到底也不过是美国计算机行业的跟班,这个行业的原创力和推动力还是远在美利坚,我们就是在不停的气喘吁吁的跟在后面跑而已。
       Torvalds对c++的愤怒应该说其实是对软件行业浮躁之风的愤怒——大家只记得去追逐更方便更容易产生“产品”的快餐语言,而忘了去追求计算机科学更本质的东西——简约和求新。
        只不过这次他怒错了方向,c++成了刀下鬼,如果让Torvalds谈谈java谈谈.net谈谈脚本语言,他估计会疯掉的。

        曾在一本讲苏联历史的书后面看到这样一个笑话:
        列宁是秃头,斯大林是有头发的,赫鲁晓夫是秃头,勃涅日列夫是有头发的,安德罗波夫是秃头,契尔年科是有头发的,戈尔巴乔夫是秃头,叶利钦是有头发的,普京是秃头,猜猜看,下一个是谁呢?
        这个月的《坦克装甲车辆》封面就是俄罗斯的T-90坦克,看着它我突然发现俄制坦克的一个有趣现象:它们的炮塔越来越矮了。其实俄制坦克与美制坦克的一个明显区别就是炮塔低矮,这几乎成为了一个标志。但它并不是一开始就如此的。
       二战前苏联的坦克曾经一度追求大口径主炮,为了装配大口径火炮,炮塔必然也要跟着扩充。最典型的就是科京设计的KV-2重型坦克,为了装上122mm口径火炮,不得不造了个巨大的炮塔,因此被戏称为”大脑袋的KV“。

KV-2
大脑袋的KV-2


       虽然在苏德战争爆发初期,KV-2曾经创造了”一辆KV-2挡住德军一个师整整48个小时“的光荣战绩,但那只是特例,KV-2高达4米,在苏联的平原上成为了德军反坦克火力最易发现的活靶子。所以战争后期苏联虽然不断生产KV-1,却再没有制造KV-2。
       KV-2之后苏联似乎接受了教训,再也不造高大的炮塔,科京后来设计的重型坦克IS-2炮塔就小了许多,IS-3的炮塔更是矮得像个乌龟壳。

IS-3
IS-3


       下塔吉尔集团的产品也有同样趋势:T-55和T-62都是采用半圆形的铸造炮塔,能尽可能弹开袭来的射流。

T-55
T-55


T-62
T-62


       到了T-72和T-90,改用焊接炮塔,形状变成了更低矮的圆盘型。

T-72
T-72


T-90
T-90


       而尚处于研发阶段的神秘的T-95“黑鹰”坦克则已经开始考虑”无炮塔方案“,真是从有到无啊。
       坦克之所以区别于步兵战车,就在于那一门威力巨大的主炮和一个明显的炮塔,但在最近几年的局部军事冲突中,坦克的大口径主炮似乎总显得过于笨重,尤其在城市战中,对付来自地下室或高楼的反坦克据点显得鞭长莫及,而步兵战车上灵活的小口径火炮却能克敌制胜。比如伊拉克战争,美军的斯特瑞克步兵战车就比M1主站坦克使用的多。于是,坦克的炮塔越来越矮,越来越灵活,越来越像步兵战车;而步兵战车的装甲越来越厚,搭载武器越来越重型,越来越像坦克,说不定有一天两种武器最终会走到一起,成为一种通用装甲战车....谁知道呢?

        做项目时碰到要查询和统计海量数据,所以想到了Hadoop,但同事反映Hadoop的性能不稳定,处理离线数据还行,处理实时数据就不保险了。又看了看其它的分布式文件系统,比如mogilefslustre等,它们只能分布式存储文件,不能分布式计算,换句话说:它们只能分摊IO,不能分摊CPU。最后决定离线数据还是用Hadoop。
       国内网站介绍Hadoop的文章都会提到MapReduce这个google的”招牌技术“。我是想不明白:GFS那套存储技术,很多做存储的公司都做得比它更好;而MapReduce做为分布式算法中的一个特例,很多互联网公司都有。但为什么大家都”误以为“这两门技术是来源于google的?因为以前做这些技术的公司都没什么名气,也没怎么宣传,而google拿出来写成论文大肆宣传。所以大家都把它当宝。
        大家都以为蒸汽机是瓦特发明的,其实不是,同时代的很多工程师都做出了蒸汽机,但瓦特是第一个拿它去申请专利的,所以大家都以为是他发明的。你可以认为瓦特是个有商业眼光的先行者,也可以认为他是一个利用同时代人智慧的窃贼。就看你怎么想了。


====== 2010.7.22 ======

看来很多同学对我这篇三年前的文章提出了质疑。我原想死撑一下,后来唐骏的事情发生了,我领悟了:有错就要认。
于是,在此,我承认:我的看法有问题,GFS的技术内涵,的确超过了很多做存储的公司,目前还没有规模和性能都比GFS高的分布式文件系统。

另外,说“MapReduce是分布式算法中的一个特列”,这应该不算错的,map-reduce算法并非google发明,但能从晦涩的教科书里找出实用的算法,精简之,工程化之,使之成为庞大而坚固的系统,这应该是google技术实力的强悍之处。
        前几天发文,错将切尔诺贝利军事基地里废弃的直升机认成了米-26,唉,都是大型运输直升机,又都长成个“大肚子”,真是挺容易弄混的,抱歉现在纠正一下 :)
        那几架其实是米-6 (少了个“2”),也是苏联米里设计局设计的,50年代末开始使用,比米-26早了整整20年,现在米-6已经退役了。外形上米-6和米-26确实很像——身躯都又肥又长,像个吃饱了饭的河马。但米-6载重量只有12吨,螺旋桨只有5叶,机头成圆柱型且有瞭望窗;而米-26体积更大(这只能在有参照物的时候才能看出来),载重量达到了20吨,螺旋桨有8叶(是我以前弄错了,米-26一直就是八叶螺旋桨)。从某种意义上说,米-26其实是为了替代米-6而制造的。

mi-6
陈旧的米-6


mi-26
体积巨大的米-26

         一段简单的代码:

#include <map>
#include <ext/hash_map>

using namespace std;
using namespace __gnu_cxx;

struct Node
{
        size_t a;
       	hash_map<int,Node> subNode;
};

int main(void)
{}
        用g++编译时却出错:
....
test.cpp:10:   instantiated from here
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_pair.h:74: error:
 `std::pair<_T1, _T2>::second' has incomplete type test.cpp:8: error: forward declaration of `struct Node'
        看样子是Node的定义还没有完成就让hash_map实例化它,所以无法成功。但是把hash_map换成map就可以编译通过了....即使是就用hash_map,上面的代码在VC2003.net环境上也可以编译通过。
        我估计原因是gcc里的hash_map的实现依赖于pair的大小,所以如果_T2(即Node)类型不完整,pair就无法实例化,hash_map的大小也就无法确定。map其实也有这个问题,如果在编译时加上-D_GLIBCXX_CONCEPT_CHECKS参数,就可以看到编译错误。但为什么默认关掉这个参数?八成这是gcc做的一个“跳线逻辑”,免得开发者老抱怨 :)
        至于VC2003能顺利编译,这是因为微软的一贯作风:宁可将就用户,不可将就标准。这和gcc是两个风格。
        要解决hash_map的这个问题有两个办法,一个是使用继承:

struct BaseNode
{
};

struct Node:
       	public BaseNode
{
       	size_t a;
        hash_map<int,BaseNode> subNode;
};

另一个是使用指针:

struct Node
{
       	size_t a;
        hash_map<int,Node> *subNode;
};
        我前段时间在youtube上找到了一段T-62坦克的mv视频,颇为精彩。当时我认出了那是大三的时候隔壁寝室放过的一部电影,好像叫《入侵阿富汗》。因为当时美国正厉兵秣马准备打击阿富汗塔利班武装,所以这部电影在学校很流行。
        昨天才完整看了一遍这部《入侵阿富汗》(The Beast Of War)。影片比我想象的要苍茫得多,到处是荒凉的戈壁,到处是险峻的石山,影片背景几乎就是一片暗黄。一辆迷路的苏军坦克被一心复仇的阿富汗游击队紧紧跟着,一名苏军士兵无法忍受坦克长的专横残忍,最终叛变,帮助游击队击毁了坦克。
        又是“叛离者”模式。《十诫》中摩西叛离了埃及法老,《黑暗精灵》里崔斯特叛离了魔索布莱城。叛离者的故事总是长盛不衰,就在于叛离者的经历是非常艰难也非常独特的,因而他们的故事也异常曲折和感人。
        看完影片总感觉它缺少了点什么,但它的情节并不空洞,节奏也不拖沓,那到底是缺少什么呢?是音乐。影片几乎没有背景音乐——不管情节是紧张还是舒缓,所以很多精彩之处难以造成观者的共鸣,不能不说是影片一大缺憾。像《断箭》这部奥斯卡获奖影片,其情节也并非登峰造极,但凭着Hans Zimmer劲度十足的配乐,一举征服观众和全体奥斯卡评委。如果能有同样重量级的音乐大师为《The Beast Of War》配乐的话,它也一定会成为一部经典影片。

        评完电影手法再说说内容。
        影片上面的苏军可谓如狼似虎——摧毁平民居住的村庄、在井里和湖边投毒、甚至用坦克活活压死俘虏....考虑到这是一部美国片,难免有夸张之处,但想想毕竟是侵略者,应该好不到哪儿去。美国人拍了这部《入侵阿富汗》,还拍了《第三滴血》,都是反映不屈不挠的阿富汗人反抗侵略的,但讽刺的是2001年美国人开着部队进入阿富汗了....几乎所有国内媒体都说美国会像苏联那样陷入“人民战争的汪洋大海”,结果呢,美国人三下五除二就把塔利班赶得不见人影了,接着很快把这个烫手山芋丢给了阿富汗临时政府和联合国,及时脱手。咦?看来美国佬比俄国佬还是要厉害多了。美国人不是傻子,美国军队更不是傻子,频繁的局部战争早就让美国人学会了怎么对付游击队。他们不吃老的一套。
       
        《The Beast Of War》里给人印象最深刻的就是T-62坦克,真个势不可挡。T-62优于同时期的德国豹1,美国M60,的确独领风骚。想当年珍宝岛事件,我们费了好大的劲才抢到一辆T-62,在它的基础上研发出了69式主战坦克,也可算颇有渊源了。

the beast of war

        今天在论坛上看到了一组照片,是关于1986年切尔诺贝利事件后被废弃的军事基地,几个胆大的家伙冒着残留辐射的危险跑进去拍的。军事基地里满是生锈和损坏的重型履带车、油罐车和直升飞机,当我辨认出那些巨大的直升飞机就是米-26时,忍不住心痛——那么多昔日的“大力士”,就这么老死在这个荒芜的地方。一架米-26造价是1200万美元,看看有多少架被遗弃....

mi-26


mi-26


mi-26


       米-26是苏联70年代的产品,为了在西伯利亚的冻土和沼泽地带搬运大型军事设施,米里设计局造出了这么一个超级巨人——载重量20吨的直升机,其体形和力气直到现在无直升机能出其右。这么大力的家伙,用的是五叶螺旋桨(后来改为八叶),装配两个D-136涡轮发动机,总功率近两万马力,相当于10架“阿帕奇”武装直升机。除了俄国佬,想不出什么人还会造这么大功率的发动机。

mi-26 mig-21
米-26吊起苏-22

        电影《莫斯科保卫战》里有一段:苏军总参谋长沙波什尼科夫看着从前线紧急召来的将军,一脸无奈的说:“老弟...最近局势不好...",我每次看到这一段都忍不住莞尔。
      
       记得大一时第二个学期系里新老生座谈,老生就主要谈怎么怎么出国,有几个老生可能混得差一些,就谈谈怎么找工作,至于保研——那就不用谈了,只要个人愿意,问题都不大。但是到了毕业的时候,事情都变得不太一样了,因为我们这一届和老一届有个巨大的不同——我们入学时是第一次大学扩招——所以毕业那年,大堆大堆的毕业生挤入各种各样的招聘会,举着简历、张着嘴嗷嗷待哺(不好意思,比喻的有点夸张了),那场面着实壮观。
        在这个就业市场人力资源高度过剩的情况下,考研和保研都变得异常困难。由于“911”事件,能出国的人少了,这一波人涌入就业和读研大军,局面更加不妙。老生们毕竟不是算命的,谁也料不到毕业时会冒出那么多同届毕业生,劳动力会变得那么不值钱。
        之后我对“过来人”的经验都带三分怀疑,不是怀疑他们的为人,是因为这世界变化太快,“过来人”的经验太容易过时。
       后来研一又搞个什么新老生座谈,嵌入式的一位老生开口就道:
       ”像我们学嵌入式的,工作还是很好找的,一毕业找个工资七八千的工作问题也不大...“
       我当时就冷笑。本人读研前好待打过几份编程的零工,知道找工作混饭吃艰难,你当现在是八十年代呢,一毕业就吃香!也不知道他哪里调查来的,信口雌黄。
       回到宿舍,一个嵌入式的同学还在那里为刚才听到的兴奋——唉,”老生“尽拿些过期的经验蒙小兄弟。
       后来嵌入式的生意还真就是叫好不叫座,每家大公司都在鼓吹嵌入式,但搞嵌入式的人还是那么苦,待遇也不见得好,兄弟们找嵌入式的工作也很艰难——门槛较高,大公司的招嵌入式方面的人要求会这个会那个罗里罗嗦,小公司就更离谱,他希望你什么都会,最好去了就能包揽所有活!
       我庆幸这次没听”老生长谈“,不然又空欢喜。

       我们这一帮子人赶上扩招、赶上考研潮、赶上大学毕业生像塑料袋一样多的时代,不能全怪过来人经验不灵,也不能全怪自己不争气,我们只能叹口气说:
       “老弟....最近局势不好...."

时间

| | Comments (0) | TrackBacks (0)
        晚上北京四台在演史泰龙的《绝岭雄风》,记得以前看过,仔细回想,是在中学初二结束的那个暑假,那就应该是1995年夏天。
       都12年了,时间过的真快。
前段时间由于工作需要编写了一个blowfish的php module,从blowfish的主页上下载的加密解密实现代码,自己加密、自己解密都没啥问题,但到了和别人联调的时候,对方用java写的blowfish解密程序却死活解不出来我加密的串。
查看对方的java代码,没想到blowfish除了密钥,还有那么多可配参数,java代码里写的解密模式为"cfb/nopadding",这是什么?仔细查了手册,除了cfb,还有ecb,cbc....我晕,blowfish主页上提供的代码都没有这些东西啊!
跑去问计算机安全方面的“伪专家”,他答道:
“这些只是加密模式,任何对称加密算法都有这几种模式”
“那我应该用哪种模式才能让别人的java代码正确解密我的串?”
“不同模式跟加密算法没关系,加密出来的串都一样,你就用blowfish主页上的那些代码就行了”
说了等于没说。
我改为自己找资料,最后有了结果:不同对称加密算法(像DES、blowfish)确实都有那几种加密模式(ecb、cbc、cfb等),但并不是跟加密算法没关系,使用不同的加密模式,加密出来的串都是不同的
使用什么加密模式,解密时也必须使用相同的模式,这就是对方无法解密我的串的原因——我压根就没使用任何加密模式...直接用Bruce Schneier老兄写的blowfish代码没戏了,我只能转而使用mcrypt,这个开源包不仅提供了各种对称加密算法,还提供了不同的加密模式,好用多了。
下载、编译成动态链接库libmcrypt.so,和我的测试代码链接运行,发现当我加密字符串“hello”,得出来得还是“hello”,再次抓狂,仔细看了mcrypt的示例代码??唉,我怎么稀里糊涂的把被加密的字符串声明成const了....最后能顺利编译运行的代码是:

	char text[1024];
char *m_crypt_iv = "0808008"; char *m_dest = "hello"; char *m_key = "abcdefg"; MCRYPT td; td=mcrypt_module_open("blowfish",NULL,"cfb",NULL); if(td==MCRYPT_FAILED) printf("wrong!\n"); i=mcrypt_generic_init(td,m_key,strlen(m_key),m_crypt_iv); if(i<0) printf("wrong!\n"); memset(text,0,sizeof(text)); memmove(text,m_dest,strlen(m_dest)); mcrypt_generic(td,text,text_len); mcrypt_generic_deinit(td); mcrypt_module_close(td);
 
其中的m_crypt_iv是cfb加密模式使用的初始向量,这段代码之所以不对被加密串进行64bit的填充(即nopadding),是因为cfb模式不用填充。
加密算法本身解决了,在编译PHP module时把libmcrypt.a加上,编出来的module就可以直接使用了。