墨羽硅

宅之境界

2009-05-03T21:59:00.002+08:00

默默地将手机的闹钟开启，选中那个标注为“工作日”的项目，一如既往的生活重新进入了轮回。开往帝都的火车上的两人大概还可以沿途继续欢乐吧，而依偎在我身边的只有猫了。

有个亲友跟我说过，最好的朋友总是三个人。的确，从小学、初中、高中直到大学，我总是在不同的三人众当中扮演自己的角色。孤僻也好，闷骚也罢，我从来都不擅长也不喜欢跟一大堆人混在一起，这也许就算是宅的性格吧。我在帝都的大学生活几乎没有任何可以向人诉说的精彩桥段，唯一保留至今的也只有最后一年结成的三人党了吧。如果要说是什么样的朋友的话，昨晚两人有如下的对话：“矿工，你平时晚上都干啥？”“宅～”

宅是什么？褪去各种正面及负面的社会看法，我的理解，宅就是认真去做自己喜欢的事情，宅人也就是执着于自己喜欢的事情的人。所以在这个层面上来说，我只是伪宅。不清楚自己自己真正喜欢的是什么，不能执着于自己真正喜欢的东西，物质欲望也日渐消散，说懒散不够懒散说勤奋不够勤奋，深陷于如同阻尼振动般趋向于静止的生活曲线。原本以为自己追求的是生活，到头来发现自己寻找的状态只是生存。为了生活的人总是追求最好的结果，为了生存的人总是考虑最坏的情况。

如果再给我一次选择工作的机会，我想还是不会选择留在帝都。也许并不是真的那么喜欢杭州，只是单纯地认为最糟糕的状况下也可以逃回家躲在被窝里吧。

在火车站送行前，来自帝都的两人说起了明年去日本旅游的计划。我觉得在弄明白自己真正的状况之前还是老实地待在国内比较好。人不是为了花钱去赚钱的，当然这是我的幼稚想法。直接用钱解决问题往往简单却粗俗。

09年的“五一”在怀旧中度过，跟大学里的亲友一起吃饭、吐槽、玩游戏，似乎又体会了那已逝去永不再回的时光。夜晚的天空依旧泛滥着橙红色的光，但愿这个世界不要太早完蛋。

《空之境界》人物浅析之无我之赤

2009-04-18T00:14:00.004+08:00

这次介绍的主角便是左边的这位大姐（御姐？）——苍崎橙子。

原作中对橙子的外貌描写很少：身穿紧身裙般毫无装饰的黑色长裤，以及崭新笔挺的白衬衫；头发不长，刚好能露出颈部。这副打扮的橙子小姐好似哪里的社长秘书。不过摘下眼镜时的眼神凶恶得难以形容，恐怕一辈子也做不了那个职业吧。本来小说中对橙子的设定是黑色长发，但是到了动画里却变成了红色，有些镜头为橙色，可能是为了跟其他人物有所区别的原因吧（好牵强的原因）。

特别值得一说的是橙子的那副眼镜。在《空之境界》中橙子对外宣称眼镜的作用是切换性格，就是戴上眼镜的橙子是温柔的没话说，“没有戴眼镜的话这个人是要多坏就有多坏”。简单的说，不带眼镜的橙子就是恶魔，眼神和话语都凶恶至极。此外，在网上搜到一些《魔法使之夜》的设定资料，里面提到橙子天生便拥有“难得的魔眼”。这个魔眼当然没有两仪那双“直死之魔眼”那么逆天，不过应该也是具有相当强大能力的吧，具体的还不清楚（好吧，蘑菇你又挖了个坑）。橙子有个不良癖好就是抽烟，几乎是不间断的。在第五章《矛盾螺旋》中预测到与荒耶之战自己不利的情况下交给黑桐保存的居然只是一包劣质（龙牌）香烟。她染上烟瘾的年龄应该相当早。从网上流出来的《魔法使之夜》前三章来看，当时的青子大概十六岁，比她大三岁的橙子一出场也是很拉风地叼着烟头……本来是很完美的御姐，这个坏习惯让她给我的印象大打折扣。

苍崎家族在魔术师界中是被认为异端的家族。苍崎姐妹的祖父是个魔法使。橙子一出生便拥有数量不多但精密度极高的魔术回路，并伴随着天才之名被认为是苍崎家的继承人。也不知发生了什么（也许是某人老糊涂了），最后老人家决定让青子继承家业——也就是魔术师家族最终要的魔术回路。可能还导致了两姐妹反复成仇之类的事情。以上内容全部来自TM社即将发售的《魔法使之夜》的设定，在《空之境界》中没有提及。虽然没有继承魔术刻印，但橙子依然在伦敦魔术协会进行了学习，并最终得到了三原色中“红”的称号（虽然他期盼的是“青”的称号），被协会指定封印。然后橙子关闭了工房偷偷跑回日本藏了起来，在一幢烂尾楼里开始经营自己的生意，这也是《空之境界》故事主线的开端。在番外篇《未来福音》中，那幢烂尾楼（橙子之前的工房）度让给了别人，自己又不知道跑哪里快活去了……

其实橙子最擅长的工作是设计，全领域范围，包括建筑和图稿。她的另一个身份是最高位的人偶师，制作出来的人偶可以拥有与真人一样的生理结构（如果去做SD娃娃一定会大卖的 >_<）。橙子做出的最完美的作品就是她自己，真正与本人完全一样的替身。一个死去，另一个替身就会苏醒，代替原来那个成为现在的橙子。这并不是说橙子的灵魂在各个人偶身上附身什么的，死了就是真正的死掉了。只不过有一个跟本体完全一样的另一个“人”代替了橙子的位置继续存在而已。所以说，橙子其实已经舍弃了自我。个人还觉得最早作为人类被生下来的橙子可能是被自己设计的人偶杀掉的。

虽然很想喊一声“橙子最高”，想想还是算了。橙子在《空之境界》中的主要任务是介绍世界观的，并且起一些叙述衔接作用。蘑菇的小说中必定存在三种人：变态、杀人鬼以及魔术师。魔术师往往是主要人物而不是核心人物。也许还说不上背景系角色，总体来说就是戏份太少。现在更期待《魔法使之夜》里橙子作为反派的另类活跃……

《空之境界》人物浅析之禁忌火花

2009-04-01T23:20:00.003+08:00

先放上萌图一张～

嗯，右边这位就是黑桐干也的妹妹——黑桐鲜花，礼园女子学院高中部的学生。

原作中鲜花第一次正式登场是在第三章《痛觉残留》，Ahnenerbe咖啡馆中与浅上藤乃同学一起出现的。并且一出场就跟两仪同学大吵一架，最后让两仪给黑桐带话“哥哥，请尽快和这种女人分手”……真是相当有性格的出场秀。

奈须对鲜花的外貌是这样描述的：鲜花的眼中有一种刚毅，也有如同要去挑战什么似的刚强。纵然外表是一副千金小姐的样子，却掩藏不住鲜花内里的坚强。如果说干也是由于仁厚而被同级生亲近的话，鲜花就是由于严格而被尊敬的那种类型吧。

当然，仅仅是这种性格也并不见得会讨人喜欢。一旦有事情跟自己的哥哥扯上关系，这个妹子就会激萌了（哇哈哈哈）……第六章《忘却录音》里鲜花是主角，强烈期待。顺便说句题外话，《忘却录音》里有黑桐兄妹童年的一段回忆，那个人设——小鲜花居然扎着双马尾还是用黑色蝴蝶结，怎么看都像FATE中的远坂（武内，你这是在制造怨念么 >_<）。鲜花的起源是禁忌，虽然没有觉醒，但对她的人生影响还是很大的，喜欢上自己的哥哥这种事情也并不稀奇。“式，坦白讲。与其说我喜欢特别的东西，还不如说我的性格会被禁忌所吸引。所以干也是我哥哥这点完全不成问题，我反而还会觉得兴奋呢！何况我认为，喜欢的对象是近亲，这是件非常幸运的事。”鲜花从两仪那边得到的评价是“你这变态”……貌似最近兄控现象在ACG届发生频率逐渐升高，鲜花可以算是始祖级人物了。

为了可以与黑桐干也建立起非兄妹的感情，体育课从来没有得到过A以外的成绩的鲜花谎称身体虚弱，到了叔父家中并当了养女。在与干也近10年未见面后正准备回来下手的时候发现中途杀出了个两仪式（新年第一天，两仪去黑桐家把干也拉出去一起参加初拜，让原本先与干也约好的鲜花相当生气），所以就依靠养父的身份和财产伪装成大小姐进入了礼园女子学院。礼园是个森严的教会学校，学生父母的财产远比学生的成绩更重要。平时连请假出校门都很困难的地方，对鲜花来说却是基本出入自由，因为学校也要考虑升学率……原作中称鲜花拥有考入东大的实力（相当于中国的北大），在全国的模拟考试中也能进前十名，大概在《未来福音》中濑尾静音提到的成绩很好的转校生也是她吧。并且为了接近哥哥想必也经常会跑出学校……

另外，鲜花是橙子的弟子（貌似也是唯一弟子）。按照TM的设定，魔术师的能力是需要靠魔术师家族一代代积累和加强的，第一代的魔术师基本没有什么特殊能力。黑桐家都是普通人，所以橙子会收鲜花为徒弟着实有些奇怪。从橙子的性格来说，也许是一开始就看出了鲜花对干也的特殊感情，纯粹是为了拉近两人想看好戏也不一定。而且橙子也当面询问过鲜花有没有对干也表白……不过，鲜花还是有一点特殊才能——纵火。准确的说，是操纵火。鲜花的能力并不强，平时也就能烧个纸头什么的，需要与人战斗时还要带上橙子赠予的火蜥蜴皮做的手套，当然对手也得是黄路这种菜鸟级别的才行……

在《忘却录音》事件结束之后，两兄妹有一段小聚，大体是这样的：

干也很在意那次正月时不守信用，为了弥补所以来找我。

“虽然有点晚，这是压岁钱，要吗？”

因为哥哥的这句话，我就不再追究正月的事。

真是的，我明明就很讨厌自己无法坚持的这一点，但现在却不免承认即使那样也不错。第一次要他买东西给我时，可是让我失眠烦恼到早上，而现在这样并排行走着，也是让我苦恼不已，不过……这不也是件很可爱的事吗。

非常非常可惜啊，这么萌的妹子最后还是没有保住自己哥哥，甚至在第七章《杀人考察（后）》中没有登场，《未来福音》也未曾对她提到过一个字，奈须真可恶！算了，也许那天蘑菇得到天启之后会单独为鲜花写几个故事也说不定。现在我就等着《忘却录音》中妹子的活跃了，啊哈哈哈！

纪念我人生的第一次重大加班

2009-03-29T23:06:00.001+08:00

周日——10点到9点——几乎无中途休息……

明天正常上班，早早睡觉去……

《空之境界》人物浅析之人畜无害

2009-03-26T22:28:00.002+08:00

首先让我感叹下：奈须蘑菇你太赞了！《空之境界》是至今为止唯一让我有兴趣从看动画到阅读原著小说并且购买实体书收藏的作品。如果一定要问这部小说有多棒的话，应该形容为看过之后就想把奈须拖过来鞭打一番并追问何时写续作的程度吧。

关于这部小说的世界观设定等等这里暂不讨论，TYPE MOON那个庞大的月世界就是个坑，待我闲来再发文详细说明。

本次介绍的《空之境界》的男主角——黑桐干也。关于黑桐的外貌，原著中的描写为：头发既不染色也不留长，皮肤既不晒黑也不纹身，既没有手机也不和女人搅和，个子在一百七十公分上下的程度，温和的容貌属于可爱的那一类，黑框的眼镜则增强了这种感觉。黑桐的最大特别之处就是他没有任何特别之处（笑）。虽然这个说法感觉很矛盾，但奈须对黑桐的设定就是非常普通的人类。

不过，黑桐只是貌似普通，作为男主角还是需要一点特殊才能的。橙子曾经说过，对于人来说有两个系统和两个属性，分别是创造者和探求者，使用者和破坏者。黑桐明显没有创造者的才能，橙子雇佣他的原因大概是看出了其探求者的才能。实际上黑桐的信息收集能力相当了得，在第五章《矛盾螺旋》里更是做到了让橙子也感到折服的程度，并且打趣说黑桐不去当侦探就太可惜了。

黑桐干也的家庭状况在小说中没有详细描写，只提到他大学辍学一事导致与父母关系恶化并长时间没有回家。非常值得一说的是黑桐有个妹妹——黑桐鲜花！关于鲜花我认为以后再细说比较好，因为这个妹子实在太萌了……

黑桐的日常生活状况也并不详细，作为男主角似乎并不算合格，所有战斗章节几乎全是由两仪一人搞定的。我非常纳闷的是这个家伙为什么对出现的大多数女性角色都有绝对杀伤力……从两仪式、浅上藤乃、黑桐鲜花（这是禁忌），到只见面后在咖啡店谈了一个小时的濑尾静音，甚至两仪未那（这个人以后再说，当时我也很震惊）都对这个男人有着特殊感情。简单的形容黑桐，典型的“老好人”。因为只是觉得两仪总是一副受伤的样子而去关心，遇到并不相识的藤乃和静音也会认真照料（并且说什么总不能就这样丢下不管），从妹妹那里得到的评价也是：这个家伙到底有什么好……是啊，这种家伙到底有什么好，偏偏有一大票女人迷上他。至于黑桐自己对后宫们的态度则是很明确的：就算两仪是男人也没有关系！这种被鲜花评价为“肮脏”的论调其实我个人是很欣赏的。身体的性别固然很重要，但人格性别才是进行交流的主体，尤其在面对两仪这种具有双重人格的变态时就更是如此。

奈须并没有把黑桐描写成完美的男人。虽然是老好人并且善于照顾别人，黑桐也是会吐槽的哦：橙子得了感冒就趁机反击，以发泄平日里收的气。并且小孩子般固执地不允许两仪杀死完全暴走的白纯里绪。另外，黑桐几乎不会做饭，“最普通的是杯面，最高级的是煮面级别”。

《空之境界》的故事主线应该还是两仪与黑桐的感情。只是这个感情在经历了两仪的车祸之后变得有些诡异。两仪体内的另一个人格“织”死了，留下的人格“式”失去了生的实感。通过两人遭遇的各种猎奇事件后，两仪心中的伽蓝之洞由黑桐所填满。第七章结尾出现的两仪肉体人格又把之前已经可以确定下来的感情线搅得有些复杂。好在最后两人算是走到一起，HAPPY END了。

总体来说《空之境界》对黑桐自身的描写不多，很多时候只是借用他的视角来陈述故事而已。其他各位女性角色的心理描写则是毫不吝惜文墨，待我下回分解……

縗

2009-03-22T12:21:00.002+08:00

1.手机在公交车上被扒。。3小时内办了新卡买了只便宜的黑莓
2.周日加班中。。
3.认识一个做传销的朋友。。真是扰人不倦。。软硬都来，可惜我软硬不吃。感谢我吧，如果我被传染了，马上就来传染你们
4.天气忽冷忽热。。能正常点吗？
5.偷偷介绍下现在工作地方的事情，是一家科普展示公司，我做展品设计，其实也不仅仅是局限在这里，老板很有钱，做好了估计能混的不错。现在我了解公司在做的浙江省科技馆的项目就有2个亿。所以加班。。我忍=。=

继续碎碎念

2009-03-15T16:49:00.004+08:00

1.前阵子看了部动画电影《空中杀手》(导　　演　押井守 Mamoru Oshii)。空战描写和机设还是不错的，某些色调很像《最终流放》，剧情略显闷骚，某人可以出动了=。=
2.今天去做了个头，明天上班去了，新环境新生活，努力挣钱，恩！

无题

2009-03-11T22:53:00.002+08:00

之前几周的杭州连绵阴雨，但我的嘴唇却干燥异常。开头只是嘴唇干裂，后来连上下的皮肤也开始干燥，甚至开始出现细碎的脱皮。果然我是异类，这个世界的不和谐音……

自我否定是个痛苦的过程。也许在幼小的时候还不是那么困难，因为自我的否定总是在周围人的推动下进行，通常可以称之为“成长”。随着年龄的增长，“成长”也将趋于缓慢并最终停滞，所以老人往往是食古不化的代名词。极端的自我否定可能产生严重的自卑心理和负面情绪，或者准确的说是容易将人内在的负面心理扩大并表象化，同时人自身对这些负面心理的恐惧造成自我否定变得愈加困难。

最近在看《空之境界》的原作小说，感觉很有意思。

越狱

2009-03-08T10:54:00.003+08:00

最近没干劲，已经有不少人向我推荐越狱，恩恩，暂时逃避下现实吧。
如果日常而又无意义，但不得不做的事是监狱，毕竟这是责任和义务么。那么完成那些私人计划的有意义的事就是挖开监狱的通道。也如同主人公一般，各种事让越狱变得很不顺利，让人烦躁。

现在的软件一些构成了地狱，而其他的就是照向地狱阳光。追逐阳光，直到象Linus所说的那样，我是这个世界的上帝。于是我将发动洪水，把火种留在诺亚方舟上.......

哈哈，开个玩笑，发泄下怨念。不过对GNU和Debian之类的Hack的浪子般的不负责的开发软件表示极度的BS。

似乎要天晴了?

2009-03-02T18:38:00.003+08:00

靠，最近都习惯把事情一条条列出来了，这是病，得医。。
1.连续3天早上7点起，然后冒雨挤公交，穿着唯一一身体面的半正装（薄），奔波于杭城，稍微带着点凄凉～真的很冷啊，今天等该死的815（估计半小时一班），居然看到冰雹砸到地上蹦蹦跳跳的，妈的，莫非要冻死一批穷人维持世界和平？
2.看了校内一个转载的文章，毕业半年换四个工作的达人也有，还是个女生，不说啥了，列个数据（纵观我08的求职经历：网申300家（其中校园招聘150家），笔试2家，面试5家，录了3家。而07年的数据是：网申60家，笔试50家，面试11家，录了2家。可见我08年真的是很勤奋，因为各大公司不招往届的，于是只能靠勤奋在150个网申中混到2个笔试机会，并靠忽悠获得了一个经过四轮PK的offer。）
3.明天要搬家了，蜗居到一个要出国的同学家去了，房子小了，厨房方便点，因为至少有个水池。。顺便借下他的运气=。=
4.这几天还要做方案，因为设计就是靠实力说话的，名气大人家也不会马上要你的，再苦两天吧。。
5.居然能进银行面试，唉，说不定有机会一冲动就去混个银行小职员当当了，8过希望不大啦。。面试的mm都挺pp的，zjuer的悲哀啊。。

工作碎碎念

2009-02-26T20:05:00.003+08:00

既然是碎碎念，那就一条条来吧～
1.断断续续也找了2个月工作了，出来才发现生活不容易啊～金融危机不是盖的，生活有甜蜜，也有痛苦，但至少目前为止还neet得蛮充实的。
2.设计在中国不好做，不管是威克上100元一个标志，还是工业设计师那微薄的薪水，还有那能上ccav的山寨的阿迪王，都表示现在中国这种急功近利的环境是很难静下心来沉淀的，设计是个快餐行业。另外再说一句，中国的设计师很多太水，看看威克的有些作品，我哭了
3、为了生活，我把简历改成了5个版本，以适应各个职业的要求=。=，混口饭吃先
4.居然有企业专门来收浙大学生，虽然和工业设计无关
5、目前来说我觉得学得广不如学得专，至少混口饭吃还是容易的
6.做什么都要适度，距离产生美，也更容易让你发现美
7、全球资讯榜最后的图片新闻居然有很多工业设计产品，虽然入选作品的品位我不大敢恭维
8.ccav5新闻女主播换了，真是的因为经常讲错话吗？？？虽然新来的没几天也出现过错误，额。。
9.好马不吃回头草，离开了就不要想着回去了
10.换房换风水！

我想……

2009-02-23T23:35:00.003+08:00

晚上无事，终于还是决定写点什么，如果不写的话真的会把仅有的文字表达能力都丧失殆尽吧……

稍微罗嗦一下本鱼的近况：

懒！每日对着类似的代码都有点懒得复制粘贴了，统统扔进库函数里面，看你们以后再需要出现的时候就直接调用，哇哈哈哈……

《Little Big Planet》神作了（虽然我早说是神作了，不然我还买来作甚），在第12届互动艺术成就奖的评比中获得了8个奖项。可惜的是我买来之后对这个游戏的热情实在不是很高……

《世界传说2 光明神话》今天终于通了，真是个很需要爱的游戏啊！

昨日从学校论坛得知SF社（版）准备拍摄一个静态电影，于是就热血涌到脑门，不经思考揽下了剧本和分镜的任务（故事情节已经有了）。关于静态电影，好像是一个新生事物。简单的说就是真人版的中国连环画。没错，中国连环画！貌似只有国内对这个东西比较热衷，google上搜索"static movie"基本没看到国外的作品。在网上看到比较好的是完美时空给自己的网游《赤壁》做的那个宣传（真的很不错）。之所以能在中国有所发展，本鱼私下认为可能是跟国人的连环画情结是有莫大的联系的。但是本鱼当初揽活时候的理解是单帧照片+配音+运镜+配乐，结果——现在只好另外改一个剧本以满足学校里的要求了。原先的剧本也不会扔掉，将抽空继续完成。同时我也联系了学校里组织拍摄的相关人员，要求提供500张以上的照片做素材，以实现本鱼的最初想法（单帧照片+配音+运镜+配乐）。之前构思了几个看上去还不错的想法，包括每秒8帧的快进（什么？为什么不是每秒15帧？因为太浪费了……每秒24帧？有人能看清画面上到底出现了虾米么……），抖动镜头等等。当然如果可以的话还可以做一个长时间的无配音无配乐定格镜头，3分58秒如何（偷笑）？这个计划实施期暂定为一年，如果一年也无法完成——那我也没什么办法。

最后，Linux是个好东西，就是用起来稍微麻烦了点……我到现在连个媒体播放器都没装上……

威克生活

2009-02-23T18:55:00.008+08:00

想赚点钱，所以这两天都泡在任务中国。放下自己的作品吧。
ps：上传图片的功能好像很愚蠢啊，图片传好以后总是置顶，照理应该出现在文字输入符后面吧，你们怎么搞的？
一、一个房产信息网站“爱房网”的logo，要求以文字为主体进行设计

二、一个童装公司的logo

老天保佑让我赚到第一桶金吧

梦想mixed现实

2009-02-17T14:50:00.003+08:00

人这一生该何去何从？
也许梦想就像信仰一样，在触手而不可及的时候，是最美的。
变得现实并不糟糕，现实可以让你更有效率地计算人生，给自己定下一个个目标，给自己的每一次进步一点点奖励。
没有付出的爱情不会长久，
没有努力过的梦想永远不会成为现实。

关于博客“墨羽硅”构架的一些想法（未完）

2009-02-16T14:48:00.004+08:00

我对墨羽龟的设想是一个网上的“三室一厅一厨一卫一阳台”豪华精装套房，“羽”是我的房间，“一厅一厨一卫一阳台”的公共设施代表我们的共同空间，基于这个理念，现在的墨鱼龟构架可能还不够完美，所以今天抛砖引玉和两位同居者商讨下改造我们的房子。
“羽”我想再分几个子标签：我的设计-设计眼界-商业合作-关系网（=。=），以后可能还会再细分，问皮：现在我们的标签是一层的，是能再多分几层的吧？（其实现在的标签差不多有我们需要的分类，但是貌似是杂在一起的，没有房间的概念）
墨和硅两位可以自行考虑是否要建子标签。
偶们的“一厅一厨一卫一阳台”，现在来说，动漫空间是不错的，就像客厅摆着一台大液晶和ps3一样。貌似可以再出一个音乐标签，发布一些大家喜欢的音乐做交流。嗯嗯，自己先说这么多，等你们两位的高见了，我会集中整理起来，然后就是大装修了～

回来了

2009-02-10T21:16:00.002+08:00

还是人多点好。因为些事情，把163的博客全删了，回到这个单纯的地方，你们还会收留我的吧TAT。博客在IE里显示非常难看，先讨论下整个容吧。偶的要求不高，简单点就好。在这里写写设计和心情～

牛年新气象

2009-01-27T18:28:00.032+08:00

凤凰区

桥

地方特色


院落

 窗

内景

2008年终致词

2008-12-15T23:48:00.000+08:00

2008即将过去。这是一个不寻常的年头，对我个人而言。因为这一年中，我从16年的学生身份中破茧而出的，成为了纯粹的一个社会人。也许可喜，也许可悲。仅在这一年即将结束的某晚草草写下致词，作为新一段人生旅程的路标。

致我的父母：

我爱你们，虽然从未说出口。时代赋予的烙印使得我并不能将这句简单而朴素的话语向你们轻易诉说。你们曾经给予我的，我并不能真正回报。生命的珍贵在于，它无法放在天平上称量。那些曾经的痛苦与快乐、眼泪与微笑，我已收藏在名为过去的角落中。将来发生任何事情，我都将会支撑起这个家庭，无论那意味着什么。

致我的朋友们：

如果我的口语曾经伤害了你们，请你们宽恕我。我只是叔本华所说的一只可怜的豪猪，寻找温暖而又害怕刺伤，时刻保持着距离而又不断尝试接近。你们的喜好、习惯和隐藏的秘密都是吸引我接近的原因，虽然有时那会带来疼痛。因为你们的存在使得旅途变得多彩，冬天变得温暖，生活变得丰富。我会履行所有与你们的承诺，甚至在需要时以生命为代价。

致我所关心的人：

也许你会抱怨我不够关心你，也许你会抱怨我并不在意你，也许你会抱怨我总是把想法压抑在心底而不告诉你。实际上，每天我也是会不定时地想起你。在我看来，重要的并不是喜不喜欢，而是我能带给你什么。如果两个人的世界相距太远，结果往往是在浪费时间。如果你给予我一个机会，我会用一生去努力为你追求这世上另一件珍贵之物：幸福。

致我自己：

你已经多次完成了人生的阶段性目标，现在则处于一个更重要的转折点上。明白自己真正的追求，排除噪音和其他繁杂或者不重要的事物。你明白钱绝对不是目的只是方法，最简单和粗俗的方法就是花钱。多看书，保持积极的兴趣爱好，尽可能的锻炼自己（包括心理和生理）。

CursedOctopus

2008.12.15夜

新的Linux包管理方式与目录结构

2008-09-12T19:14:00.003+08:00

特性：

模块化
“热插拔”
稳健性
读、写、执行分离
易于访问控制

模块化

整个系统如同拼图版一样拼成。并且呈现一定的层次结构：

微核：由内核+initrd构成，其中initrd的要求是启动、恢复系统的最小集合：
- initrd不能依赖除内核、自身以外
- 能够恢复系统——恢复核心环境（C库、包管理系统...）
- 含klibc、busybox、必要的模块
核心环境：具备一定完整功能的最小集合：
- C库
- 包管理系统
- init
- ...
其他环境

一个示例的目录结构：

说明：这是一个原生(Native)文件系统上的本地磁盘布局。Files文件夹存放字体、墙纸之类的资源。

PuzzleFS

PuzzleFS是假象中的实现“热插拔”功能的用户态文件系统(FUSE)。PuzzleFS还是用来实现访问控制的文件系统。

PuzzleFS管理着系统可以执行代码的文件系统命名空间视图。因此，PuzzleFS启动后，对文件系统的读写都交由PuzzleFS进行访问控制，可能地记录到数据库，最后分流到各自源上的原生文件系统实现。
PuzzleFS上的目录结构指定，类似示例目录结构。这样，它和主源的映射关系就比较简单。所不同的是，PuzzleFS是所有源的混合，其某个文件夹下的内容是多个源对应文件夹的并集。
当新的包发现时（新源挂载，或者包下载复制到对应目录——依据配置在执行域中），启动“热插拔”历程。
“热插拔”时，首先读取/验证新包的meta信息。meta信息包括以下：

数字签名
依赖关系（例如冲突...）
访问控制规则（基于路径的正则表达式匹配，可以更复杂地制定主体。当然这意味着对建链接的额外关注）
包的所属环境
包的分类
图标
...

讨论：
熟悉Singularity的朋友，可以想象依赖关系和访问控制规则是其相应风格的（MBP...）？
另外，这个方式符合“现代”的安全实现方式：在进行动作前，基于某种描述方式来对动作的影响进行描述，之后验证该动作不违背先前描述。因此，在系统辅助不产生冲突的情形下，软件的安全规则由软件开发者提供（没有人比软件开发者更了解软件的正常行为）
“热插拔”的第二阶段，是可选，为解包阶段。即包如果是压缩，或者需要安装时刻动作（比如编译...），则进行相应动作。包解包后存放的实际地址可以指定源。
第三阶段，为新包分配相关“资源”。包的内容是只读的，并且只有指定目录下的文件可以有可执行的权限（bin、lib）。因此，比如为包分配一个影子etc目录（在System下某个目录中或者用户目录下的某个目录下），当有程序改写etc目录中的内容时，则执行一个COW（Copy On Write），结果在影子etc目录下)
第四阶段，包的注册阶段。包的某些内容写入数据库（Sytem某个目录下）。这样做是因为：

比如，包中lib是公开的，则其下文件等内容数据库索引。对bin下的内容也是，加快相应操作
包的meta中的信息，比如实现分类，方便用户分类搜索浏览
包的源来分类浏览
包是封装的，任何其他包不能访问包中的非公开文件（配置文件)，则在数据库中注册（通用接口的）配置信息，即这是类似注册表或者GConf的。

总结：

PuzzleFS实现了“热插拔”、访问控制、包封装、搜索、通用接口的配置功能。

访问控制机制是通过PuzzleFS是对多个原生文件系统统一封装的用户态文件系统的自然结果。
包的封装是指对包的访问，（在访问控制规则许可下）限制只可对bin、lib以及通用配置信息的访问。其他，比如外包不能访问非本包的etc下文件。
搜索。是由于PuzzleFS背后有数据库支持的结果。用于比如加快输入命令，链接库等的查找，分类视图的作用。这是对之前硬盘搜索的自然嵌入（想像微软未曾经计划的WinFS、苹果的spotlight搜索、Novell的beagle...）
通用接口的配置。使得PuzzleFS扮演了注册表(GConf）的角色，用于包配置信息的导出共享等。相比注册表，这里的实现方式更加稳健：所有PuzzleFS数据库中的信息只是一个缓冲，出现问题后可以方便重建的。

项目

2008-09-05T17:36:00.001+08:00

一个高性能程序编写框架：

异步：

使用I/O设备、使用其他CPU（主线模型）
信号机制
调度（优先级）

对OpenCL等的封装，易于使用
管线对象：

一系列串行例程不需要用信号机制连接
流水线两个阶段约定数据传递方式（可以是Unix的shell风格）
由依赖图生成管线（并被缓冲，参见缓冲对象）
期待代替Gstreamer和LLVM编译器驱动

缓冲对象：

缓冲对象未必在内存中，可以在磁盘...（发布对象?）
内存的缓冲（SLAB风格的内存分配）
管线缓冲（缓冲由依赖图和状态动态生成的管线）
其他...对若干操作得到的结果（立体的）——一个操作就能得到结果（平面化，命中的情形下）
与系统资源监视服务互动，调整缓冲大小

Detective Conan：

嵌入在调用中。
在收集I/O结果、错误、性能参数。报告某监视进程。

用例：web服务器、下载器、启动器<缓冲、日志、收集结果>。

非MVC的UI编写框架

界面和模型参数的传递是“量子”的而非经典的（需要和控制器无限交互）
由ASL库启发
解析器等依赖LLVM，依赖图依赖上一框架
LLVM整合？

基于结构化、模式匹配的限制(contrain)模型

用于窗口系统对窗口“权限”的限制
所见即所得编辑器缺陷的弥补：附加在文字编辑器的模板，对某一域限制的图形化显示，违背限制的图形化显示。比如论文的索引，鼠标移到之上显示某些下拉菜单等的组合，移出恢复”所见所得“模式
易用的访问控制模型。结合系统包管理方式

包管理方式：

分布式<没有中心/usr...，热插拔>、文件系统布局、特性通知（忘了configure...）、访问控制<封装>

X windows的移除

分离功能，一些功能分离到EGL、OpenGL中
关注窗口树结构，DOM风格(事件传递、处理)
wayland now

LLVM SVA操作系统的设计

Singularity Like
...

将在某个CMS中实践部分

楚歌

2008-08-03T21:06:00.000+08:00

项王军壁垓下，兵少食尽，汉军及诸侯兵围之数重。夜闻汉军四面皆楚歌，项王乃大惊，曰：“汉皆已得楚乎？是何楚人之多也。”

——司马迁《史记•项羽本纪》

对于项羽来说，楚歌四起也就以为着自己的灭亡。刘邦觊觎的是天下，而项羽是他一统天下的最大障碍。但扔开这个失败的英雄，四面楚歌也即意味着长年战乱的落幕，民生撩乱的终结。

对于一个普通的楚军士兵来说，是该回家的时候了。

“我回来了！”我在机场门口大声呼喊。

整个大地以母亲般的温柔回应了我：“欢迎回来。”

是的，我真的离开得有些久了，以至于说话的口音也依然沾染着北方的水土。那段不算平淡也不算精彩的北漂经历将被我永久珍藏，毕竟是我第一次离开故土的回忆，毕竟是我曾经年少无畏的证明，毕竟是我生命中唯一的大学生活。然而我不会将其作为自己的荣耀，因为我是浙江人，这是我出生便已拥有的荣耀。10年，20年，50年后，我将依然深爱着这片土地，这个称之为家的地方。并不需要什么特殊的理由，无论多大的孩子都将永远怀念母亲的拥抱。

BY CursedOctopus

我的毕业设计以及一些啰嗦

2008-07-13T09:08:00.006+08:00

　　毕业设计论文比较长，估计也不会有什么人看，所以直接扔论坛里了。这个是链接

点我下载章鱼的毕业设计论文
腐败的龟不要再恶意挖出来重发了（我估计你想重新编辑发布的话也是会累死的吧 >_<）论文题目是《IMS中多媒体彩铃业务相关技术研究》。这里不对IMS进行任何展开，有兴趣的人可以参考《IMS:移动领域的IP多媒体概念和服务》一书。此书据说是IMS的经典（中文版翻译得差强人意），就是出版的年代有点早，有一些内容跟现在的实际情况略有差别。

　　彩铃这个东西，大家都一定使用过或者正在使用吧。传说最早开展彩铃业务的是韩国，从通信增值业务的发展来看，高丽棒子还是有点想法的。但是……我本人是绝对不喜欢用彩铃的！因为普通GSM网络的语音传输速度不过13Kbit/s，如此低的比特率根本不可能进行高质量音乐的传输，普通的wav和mp3文件也有44100hz的抽样率，转换为彩铃的压缩率可想而知……当然，通信技术还在发展，3G甚至4G无线通信网络的到来意味着更高的传输速度，视频彩铃都已经进入可实用阶段。好吧，我承认自己只是节省彩铃月租费 -_-b

　　言归正传，还是回到我的毕设上来吧。虽然题目说的是IMS中的彩铃，实质上更多的是讨论现有智能网环境下的技术方案，其核心依然是软交换（Softswitch)。要说软交换网络跟IMS的实质性区别，可能就是一些交换部分的构架方式的差别，更加深入具体的分析就不是我能够写出来的了。曾经看到的相关资料提到：在核心网元方面，智能网使用的是软交换（就是一堆交换机和服务器），各厂商和运营商没有统一的标准，各自为战；IMS细化了应用层的网元结构，提出了各CSCF与广义上的AS；从硬件上来说从智能网向IMS的升级过渡是比较方便的，更多的是软件方面的更改。说到底，IMS还是过分前沿化的网络构架方案，虽然中国各大运营商都有私底下进行研究和实验，实际能够达到试用阶段也还是需要几年的吧。
　　在IMS中有应用了一项非常重要的通信协议：SIP（会话初始协议）。SIP协议脱胎于TCP，其安全和效率不言而喻。并且如果IMS真正进入实用阶段，SIP就有一统天下的趋势了。关于SIP的技术规范极多，可以看出这种通信协议的良好发展前景。

　　毕设论文总体来说还是相当幼稚的，许多细节性问题根本不在我考虑的能力范围内。好在跟现在的工作也没多大关系了，有达人看到死命拍砖我也不怕（死猪不怕开水烫）。

缓冲溢出漏洞的防御

2008-06-29T21:38:00.001+08:00

缓冲溢出通常发生在C或者C++编程语言中。在2002年，针对缓冲漏洞的修正占了全部安全修正的22.5%¹，而基于此的开发攻击所占的比重更高（2003年为75%）。

图2展示了某典型的、使用固定长度缓冲区函数的栈在内存中的布局。当函数调用结束时，控制流根据返回地址继续。在x86处理器上，栈总是从反向生长的（即从高内存地址向低内存地址生长），所以缓冲区存储在返回地址之前。缓冲区溢出攻击，利用程序中的某个漏洞，如在图2函数调用中，放入超过缓冲区容量的数据，从而覆写返回地址指向一个恶意代码的起始地址，使得函数调用结束后就跳转到恶意代码起始处执行（图3）。

防御手段1——“金丝雀”（Canaries）法

通过在缓冲区和控制数据之间放置“金丝雀²”（或叫做“金丝雀”数据），来监视缓冲区是否溢出。当缓冲区溢出时，第一个损坏的数据就是“金丝雀”，之后对“金丝雀”数据进行验证就可预警发生了缓冲溢出。

Stack-Smashing Protector(SSP)是GCC编译器的对“金丝雀”法的实现。SSP在缓冲区与控制数据之间放置“特殊符号”（已知符号，随机符号或随机符号与控制信息异或产物），之后检查这些符号来侦测溢出。（同时，SSP还把数组变量移向栈底来增加溢出的难度）

“金丝雀”法的防御是有限的，比如不能防御通过溢出来改变结构体中的函数指针的攻击。

防御手段2——对内存页保护增加执行位

最近的CPU，都开始支持在内存的页保护中加入执行位（比如Intel和AMD的NX(No

eXecute )技术），从而阻止不在“可执行”页中的代码。这样，当溢出使得控制流跳转到恶意代码起始时，由于恶意代码所在页不具备执行位，故会产生页异常导致程序退出。

通过增加可执行位能够对缓冲溢出攻击提供较为全面的保护。但仍有不如意之处（以主流x86处理器为例）：

需要CPU支持
需要启用PAE³扩展（这是由于传统页保护字段中没有多余位可用）。启用PAE会带来大约6%的性能上开销
不能完全抵御缓冲漏洞的攻击。比如改写返回地址到system ()函数上，此操作并未对当前进程中注入新的可执行代码，从而绕过保护机制。

防御手段3——段限制法

使用段限制，即只有进程虚拟地址的前N个M字节可执行。N值由操作系统来选定。

操作系统来保证所有程序的代码在段限制长度之内（图4左部），而数据，栈则在虚拟内存高地址处（图4右部）。当缓冲溢出执行恶意代码时，会触发段错误而导致程序退出。

段限制法在大多数程序中可行，但在某些非常少见的情形下（比如负责Linux图形的XFree86^TM服务端）也许不是最好保护方式。此外，段限制法要求CPU支持分段机制。在不支持分段的情形下（比如CPU不支持或x86-64处理器运行于纯64位模式⁴）不能使用。不过此种情形下，处理器一般支持页保护字段中的“执行位”。

防御手段4——随机化内存布局

随机化内存布局基于一个观察：即攻击者只有知道缓冲区大体位置的才能实施攻击。在防御手段2中提到的如改写返回地址到system ()函数的攻击方法，也需要知道system函数的位置。这些可以通过攻击者在其电脑上运行相似的系统来观察到。通过随机化内存布局，使得攻击者不能猜测相关的地址，从而抵御攻击。

例如，随机化程序以下部分的内存地址：

栈
共享库
程序堆

随机化内存布局需要编译器支持，并且重新构筑关键的程序。

防御手段2、3和4，即构成了RedHat ExecShield技术，并且融合到了Linux内核2.6.25版。

1数据源自http://cve.mitre.org/board/archives/2002-10/msg00005.html

2金丝雀对有毒气体敏感，在煤矿中，被用来预警有毒气体。

3PAE允许32位CPU访问大于4GB的内存。参见Intel® 64 and IA-32 Architectures Software Developer's Manual，Volume 3A: System Programming Guide, Part 1，4.13 PAGE-LEVEL PROTECTION AND EXECUTE-DISABLE BIT

4参见Intel® 64 and IA-32 Architectures Software Developer's Manual，Volume 3A: System Programming Guide, Part 1，3.2.4 Segmentation in IA-32e Mode

强制访问控制技术

2008-06-29T21:31:00.001+08:00

SELinux（Security Enhanced Linux）

强制访问控制技术是对自主访问控制（discretionary access control：DAC）信任模型改进。在自主访问控制中，用户不全是可信的，而资源的所有者指定信任哪些用户（从而这些用户可以访问资源）。自主访问控制的缺陷在于其不能区别人类用户和计算机程序，或者说，在自主访问控制的信任模型中，用户对计算机程序充分信任，即认为程序是无缺陷的、无恶意的。这显然与现实不相符合。

类型强制（Type Enforcement：TE）

在SELinux，进程是访问控制的主体，联合某一安全上下文。客体是系统所有安全对象，包括进程（比如A进程向B进程发送信号时，B进程就作为客体）。SELinux的核心是类型强制（Type Enforcement：TE）。系统根据主体的类型（type），客体的类型（type）与规则作出访问控制的决策。

进程的类型在进程创建时确定且基本不变（一个例外是当进程有dyntransition权限时，可以在执行时改变其类型，这是个不安全的特性，故只允许进入对应许可集为原类型的子集的类型）。SELinux对系统中的所有需要保护对象的访问方式加以罗列，定义为对象类（object class）。之后依据主客类型，许可主体对客体的部分访问权限（即客体所属对象类的所有方法的某个子集）。SELinux实行白名单方式的访问控制，规则中未许可的访问将被拒绝。如图5：

基于角色的访问控制

SELinux中，基于角色的访问控制构筑在类型强制（TE）之上。一个SELinux对象安全上下文如下：

用户:角色:类型

在该上下文中，一个用户可能拥有多个角色，而每个角色则与多个类型相关联。

一个用户的进程（主体）的最初始的安全上下文在登录时获得。用户登录时确定用户的角色（从该用户拥有的多个角色中择一）。在登录后，运行新程序的进程的类型由如下决定：

可执行文件的类型
父进程的类型
规则库中，相关类型转换规则。如

type_transition user_t passwd_exec_t process passwd_t;

图6展示了通过类型转换来确定新进程的类型的全过程。

Bell-La Padula模型的实现

对BLP模型的支持是通过可选的MSL（multilevel security）机制实现的。为了支持MSL，SELinux对对象的安全上下文进行扩充：

用户:角色:类型:安全级范围（低安全级-高安全级）

其中，一个安全级有两个部分组成：敏感级（即密级）和附在本敏感级上的（0个以上）分类。敏感级之间是层次的，而分类则不是。因此，安全级范围的两端要求：

高安全级中的敏感级 > 低安全级中的敏感级
高安全级中的所属分类集合包含低安全级中的所属分类集合

例如，为了防止高密级的数据流向低密级的数据（保证机密性：向下读，向上写）：

mlsconstrain file write ( L1 domby L2 );

mlsconstrain file { read getattr execute } ( L1 dom L2 );

在第一条规则中，L1指主体的（安全级范围中的）低安全级，L2指客体（安全级范围中的）低安全级。这样，写某个文件必须保证，主体的安全级不得高于客体的安全级。

在第二条规则中，L1与L2分别代表主客体（安全级范围中的）的低安全级。这样，读取某个文件必须保证，主体的安全级不得低于客体安全级。

SELinux的访问控制过程

在启用SELinux的Linux发行版中，访问控制的过程如下：

进行DAC检查
进行TE检查
进行MLS检查

访问控制是每次访问时进行的。例如DAC仅在打开文件时进行访问控制，而SELinux则在每次对文件进行读（或其他操作）进行。这样作的好处是使得对许可规则的改变可以迅速反映出来。

SELinux的结构

图7，反映了SELinux在Linux内核中通过LSM（Linux Security Module）的一个实现。其有如下特点：

对内核对象提供访问控制
通过访问向量缓冲（Access Vector Cache：AVC），来减小访问控制带来的性能开销
通过伪文件系统SELinux（就像许多Linux的伪文件系统一样）来导出管理接口

图8，通过在用户空间部署SELinux¹，来提供对用户对象的访问控制。策略管理服务器（policy management server：PMS）管理和操作所有系统策略。

PMS本身是个用户空间的对象管理器，负责创建代表策略资源的对象类，并对这些策略资源实施细粒度的访问控制。通过PMS，可以允许用户管理工具不用改变TE许可规则，增加用户和赋予角色。更大的好处，可以仅授权数据库服务器改变与之相关的对象类（object class）和TE规则。

PMS把系统策略分离为内核与用户两部分，分别把他们载入内核安全服务器与用户空间安全服务器（userspace security server：USSS）。由于PMS是一个运行中的服务器，可以扩展其接口来允许远程的网络访问，从而支持分布式策略管理。PMS与USSS允许运行时刻注册对象类（object class）。

总结

SELinux的限制：

复杂性：用户需要定义类型（Type）和（极为繁多的）规则。SELinux全面涵盖了各式各样的安全威胁，这也是它复杂的一个原因。为了降低其复杂性，SELinux的策略可模块化，并适时载入。
性能：复杂性带来性能上的开销，这在桌面或者服务器系统上也许并不重要，但是对于消费电子设备来说是不可接受的。因此需要进行相应的优化。在08年的嵌入式Linux会议（Embedded Linux Conference：ELC）上，Yuichi Nakamura宣称通过削减策略（保留适合嵌入式环境的策略——一个令人生畏的工作，但通过创建更简单的策略语言和策略编辑器，Nakamura做到了：4.6M大小的策略文件削减为60K）、移除多余许可检查、优化读写路径和转换缓冲静态分配为动态分配，使得在其SuperH平台上的性能提升了10倍，内存节省了250K²。
动态最小权限原则：SELinux的主体（进程）被赋予某一类型（Type）后，在其生命周期内基本不能再改变（一个例外是有dyntransition权限时，允许其改变为某些权限更小的类型上）。在基于工作流的模型中，在工作流的各个阶段，可以指定不同的最小权限，即理想下，贯穿于工作流各个阶段的进程应在执行中改变类型——动态最小权限。
粒度：SELinux的访问控制的粒度是对象，或者具体的说来，是在当前安全上下文下，决策是否允许对客体对象方法的访问。而对于某些复杂的方法——整合多个功能、参数之间相互依赖，组合形成不同的访问方式，SELinux便无法控制了。

对于复杂性，需要程序的开发者负责开发，实现对应程序运行时最小权限的策略（程序的开发者应该更加了解程序运行的最小权限是什么）。用户信任并接受相应策略，并在安装时刻随程序一起安装到系统中（相应策略应与系统已有策略一致）。这样用户就无须为策略的编写而担心。事实上，可以把对程序的强制访问控制策略看成是程序的正确性断言，通过信任断言的有效性（断言失败，程序便被终结而不会造成更大的破坏），来信任程序。故用户可以回到原来的DAC世界中。

对于动态最小权限原则，可以考虑缩小主体的粒度，比如为一个代码段。不同的代码段完成不同的工作阶段，一个进程则由多个不同类型（Type）代码段构成。实现起来需要考虑的一个问题是相应代码段的安全标签的存储问题：主流操作系统支持的外存的存储粒度是文件，而多个代码段则可能被存储到一个库文件中，这样各个代码段安全标签存储、代码段的界定值得考虑。也许需要SELinux引入新的信任（比如信任编译器/链接器）。

强制访问控制技术——SMACK

针对SELinux的复杂性带来的实际应用部署上的困难，SMACK³（The Simplified Mandatory Access Control Kernel）通过简单的方式，来解决SELinux所针对安全威胁的某个子集。

SMACK访问控制方式相当简单：

标签与标签名一致
标签之间没有隐含的关系
主客体有各自的标签
客体的标签源自创建其主体的标签
直接指明访问控制许可

比如：sub obj r，就许可了有标签sub的主体对标签为obj的客体有读权限。所有的许可（信任）关系必须被直接指明。

Bell-LaPadula模型的实现

需要指明所有级别的相互许可关系，比如有三个秘密度依此上升的安全级：unclass、 secret、 topsecret，实现向下读，需要以下规则：

secret unclass rx（读、执行权限）
topsecret secret rx
topsecret unclass rx

强制访问控制：基于路径 vs 基于标签

在SUSE Linux，引入了名为AppArmor的基于路径的访问控制。基于路径的访问控制方式，相当灵活，例如：

/home/*/public_html/**.html r

许可了各个用户的public_html目录下.html文件的读操作。与之相比，在SELinux和SMACK中需要对上述每个文件打上相应标签。

对基于路径的访问控制最大的批评是这种方式很容易被绕过。比如可以建立一个指向目标文件，从而获得一条不同的路径，绕过对原路径的进行的访问控制。

基于路径的访问控制比较贴近管理逻辑（即高层），而访问控制机制只有在底层实现才能确保不被绕过，因此可以考虑在比如SELinux管理工具中基于路径，之后管理工具对相应文件贴上标签。这个过程中管理工具的行为类似一个编译器：把高层的逻辑翻译成底层的实现。

其他可以考虑的方式，是对文件系统的名空间给予保护，从而防止用户随便增加新的名指向被保护名（代表的文件），来确保基于路径的访问控制不被绕过。

总体来看，MAC更加倾向反应对程序的正确性的强制（断言），而非用户的意志。因此需要DAC（反应用户的意志来进行补充）。可以如下表达：MAC与程序紧密联系，而DAC则与用户联系密切些。因此，终端用户定制安全环境，应该更多地从DAC入手。

当用户的角色成为MAC确定最小权限的因素时（变量），MAC与DAC可能会存在逻辑上的联系，需要定义/导出公认的、一致的角色。

1这个项目在：http://sepolicy-server.sourceforge.net

2LWN.net Weekly Edition 2008.4.24 http://lwn.net/Articles/278492/

3SMACK已经融入了Linux内核2.6.25中

虚拟机技术

2008-06-29T21:20:00.001+08:00

在SELinux中，可信基包括：内核、对象管理器、安全服务器及相关工具。这是相当大的一个可信基，特别是Linux内核并非微内核设计，是个庞大的部分。在这个大的可信基中，难免不出现导致保护措施失败的Bug。

因此，基于纵深防御原则，引入虚拟机技术。

虚拟机技术有各种实现方式。比如操作系统级的虚拟化，通过引入IPC命名空间¹、对进程调度器引入调度实体²实现二级调度及内存容器³等，把一组相关的进程放入一个容器，构成一个虚拟环境，共享硬件资源。每个虚拟环境有一个虚拟的IP，从而虚拟环境之间构成虚拟网络进行通信。当某个虚拟环境崩溃时，其他虚拟环境不受影响。

关于虚拟机技术的总览，参见http://www.ibm.com/developerworks/cn/linux/l-linuxvirt/。下面回顾下Xen虚拟技术。

Xen有两种工作模式：全虚拟化（full virtualization）和泛虚拟化（paravirtualization）模式。前者不需要操作系统修改，借助CPU支持实现同一时刻运行多个操作系统。后者需要修改操作系统驱动，及其他相关代码，来实现同一时刻运行多操作系统。

图9显示了Xen虚拟机的一般结构，当CPU支持实行全虚拟化方案时，Hypervisor运行于根态⁴。当实行泛虚拟化方案时，运行于环0，客户OS运行于环1，应用程序运行于环3。

Hypervisor提供对客户机的页表进行修改（泛虚拟化），或者使用影子页表（全虚拟化），来把客户机的虚拟地址到客户机物理地址的映像（客户机页表）进行重新映射。

Hypervisor本身并不负责I/O，而是把设备专有地配给某个虚拟域或者转发来自其他虚拟域的（前端驱动的）请求到虚拟域0，由虚拟域0的后端驱动接收请求后，交由其自生的原生驱动处理后应答。

每个客户机可以配置成拥有任意数量的虚拟CPU，Hypervisor以虚拟CPU为调度单位进行调度。

Hypervisor和各个虚拟域之间的内部通信：

通过事件通道进行通知
通过环形缓冲区放置请求和应答
通过授权表来允许别的虚拟域访问本虚拟域的内存页。比如可以交换内存页来实现内存零拷贝。

在外存上的隔离，每个虚拟机使用各自镜像文件。不过，可以通过使用写时拷贝（Copy On Write：COW）特性文件系统，比如ZFS⁵或者Btrfs⁶，来使得各个虚拟机共享某些文件。当某一虚拟机写共享文件时，该文件被拷贝并被改写。

在Xen虚拟机技术中，某一虚拟域上的客户操作系统的失败不会影响其他虚拟域上的操作系统。Xen虚拟技术的可信基只有Hypervisor本身，比较容易确保其正确性。

Xen虚拟机技术的应用中，如在同一服务器硬件上一个虚拟机上中运行web服务器，一个虚拟机上运行邮件服务器。使得之一服务器的崩溃对另一服务器无影响，同时也提高了硬件的利用率。

1 http://lwn.net/Articles/256389/

2 http://lwn.net/Articles/240474/

3 http://lwn.net/Articles/243795/

4Intel® 64 and IA-32 Architectures Software Developer's Manual，Volume 3B: System Programming Guide, Part 2，CHAPTER 20 VIRTUAL-MACHINE CONTROL STRUCTURES

5 http://opensolaris.org/os/community/zfs/

6 http://btrfs.wiki.kernel.org

概念分布式操作系统——Singularity

2008-06-29T20:53:00.003+08:00

singularity是微软概念分布式操作系统，展示了一个“把可靠性和可信度作为首要的设计目标”，从头来设计的软件平台。

singularity的设计者认为，通过更为可靠的技术和设计方法是可以在很大程度上提高系统的可靠性的。因此，singularity的可靠性与安全的实现依赖了许多其他方面的技术：

通过安全的设计语言消除可以预防的缺陷，如缓冲溢出。singularity主要使用C#语言的扩展——Sing#来编写。
通过健全的验证工具在开发周期中侦测程序的错误。
通过一个改进的系统构架，在明晰定义的边界处，阻止运行时刻错误的传播。

软件隔离的进程（Software-Isolated Processes：SIP）

和传统的操作系统中进程的概念类似，SIP是作为处理资源的载体，为程序执行提供了上下文：

SIP关联一组包含数据和代码的内存页面。
SIP以某一安全ID执行，关联OS的安全属性。
通过内核ABI（Application Binary Interface），SIP来使用内核函数。
含有一个以上的线程。
每个SIP是自治的，含有自己的数据布局、运行时刻系统和垃圾收集器

与传统的进程不同的是：

SIP的隔离是通过软件而非硬件（如MMU单元等）实现的。
SIP之间不共享数据。通过在channels上交换消息进行通信。
SIP中的代码是密封的，不能动态载入和创建代码。

软件隔离

软件隔离通过篇基于语言的类型和内存访问检查来实现。类型检查保证值或对象被正确解释和操作，内存访问检查保证引用的内存在有效对象的边界内。软件隔离能够比硬件隔离更加细粒度。硬件隔离中，进程可以按照页保护字段的规定，随意访问自己的内存空间（栈和堆），而在软件隔离中，访问的方式和范围被限制，对粒度为变量的区域提供了保护（封装）。

借助软件隔离，所有的SIP和内核可以运行于单一的环0的地址空间中，从而进程的创建，系统调用，调度与通信等的开销减小了。

另外，类型和内存安检确保了函数的执行的完整性，从而可以在安检后，在SIP中运行的信任函数中使用特权指令。例如，访问硬件I/O的特权指令可以在安装阶段，安全地内联到设备驱动中。这也促进了性能上的提升。

	开销（单位：CPU周期）
	API调用	线程产出	消息反馈	进程创建
Singularity	80	365	1,040	388,000
FreeBSD	878	911	13,300	1,030,000
Linux	437	906	5,800	719,000
Windows	627	753	6,340	5,380,000

表1：进程基本开销（硬件平台：AMD Athlon 64 3000+（1.8GHz）CPU，NVIDIA nForce4 Ultra芯片组。

表1数据来源Singularity: Rethinking the Software Stack¹，并未指明操作系统的版本与配置。在An Overview of the Singularity Project²类似测试中，指明了操作系统版本与配置，且数据与此表相似，故可能是同一测试平台（硬件：AMD Athlon 64 3000+ (1.8 GHz) CPU，NVIDIA nForce4 Ultra 芯片组，1GB内存，Western Digital WD2500JD 250GB 7200RPM SATA硬盘（不含指令重排(command queuing)），网卡为nForce4 Ultra native Gigabit NIC（不含硬件TCP加速）。操作系统为FreeBSD 5.3，Red Hat Fedora Core 4（内核版本2.6.11- 1.1369_FC4与Windows XP (SP2)）据此，对照的测试OS是较老的版本，且存在配置上的问题（比如使用性能低下的pthreads），数据未必精确，但Singularity的性能优势较明显，具备参考意义。

软件隔离所带给SIP的低系统开销，也拓广了进程这一传统概念的应用范围。比如，对微内核OS最大的批评是其低下的性能，从单一内核中分离出的功能运行在各自进程中，来提高系统的稳定性和安全性。但这样作也造成了核与系统进程，系统进程与系统进程之间紧密的通信，不得不通过穿越硬件保护边界——造成了性能上巨大的开销。因此，实用的微内核操作系统总是在微内核设计上加以妥协，比如Windows NT系列系统就把NT内核与NT执行体就被合并到了单个可执行映像了。

软件隔离的不同于传统的构筑安全的思维：在传统的思维中，安全隔离应当在底层、外围实施，从而避免引不必要的依赖（这些依赖可能带来新的安全隐患），因此安全应当是专门独立出来。而在singularity中，安全并不单一存在，而是各种技术混合的结果。从最小权限原则上来说，只有越贴近应用逻辑（高层），才能实现细粒度的控制，这对开发安全的程序也是有利的——错误发现的越早就越容易排除。（后续章节将解释，singularity如何解决实施安全，带来新的依赖的问题）

在SELinux一节中，表达了这样一个观点，即强制访问控制是在操作系统支持粒度下，对程序正确的行为进行断言。而软件隔离则在语言层次上，对语言的正确使用作出断言（由编译器或者解释器负责）。（纯粹的）软件隔离同时也意味着对硬件访问接口的再次封装，即只有通过安全的编程语言才能使用硬件资源。这也是在SELinux一节中的得出的结论，明晰合理的接口相当于细化了安全检查的粒度。

可以依照纵深防御原则，把软件隔离与硬件隔离相结合，比如把单独内核运行在环0的地址空间中，其他SIP运行在环3的各自的地址空间（类似微内核那样），或者经过数字签名，信任的软件于内核一起运作在环0的地址空间中，其他未签名的不受信任的软件运作在环3的各自地址空间中。当然，还可以考虑，如把不安全的语言编写的程序运行在独立的地址空间中，而安全语言编写的程序与内核共处一地址空间，从而兼容以有程序。

这些配置也为观察硬件保护的开销带来了机会，下图源自Singularity: Rethinking the Software Stack。

图10，各种隔离措施所带来的系统性能上的开销。

图中，采用是WebFiles（基于SPECweb99的I/O密集型测试）在6种不同的配置上进行测试，并以第2个配置方案为标准进行衡量。测试采用了3个SIP：

客户端（发出对文件随机读请求）
文件系统
驱动

6个配置方案分别为：

No runtime checks：不进行任何安全隔离，用于对照开启软件隔离的开销（图中，4.7%）
Physical Memory：3个SIPs与内核运行于同一地址空间和同一特权级。禁用分页。
Add 4KB Pages：在上一配置的基础上，开启分页（页大小：4KB）与TLB
Add Separate Domain：在上一配置的基础上，把客户端SIP单独移到一个地址空间中（特权级维持为环0）
Add Ring3：在上一配置的基础上，客户端SIP的特权级改变为环3。
Full Microkernel：把每个SIP移到各自环3的地址空间中。

可见软件隔离所带来的开销非常小（<5%），与之相比较，硬件隔离的开销非常大。

软件隔离的另一个好处是，脱离了对MMU的依赖，从而SIP可以运行在一些特殊的处理器上（或者说可编程I/O设备），比如GPU（Graphics Process Unit，时下渐热的流计算的基本硬件），从而支持非均一处理器组成的分布式计算的网络。

内存管理——SIP之间不共享数据

在SIP中的指针必须指向自己的内存或者交换堆中所拥有的内存。

SIP通过ABI调用内核页管理器获得新的、独占的页。这些页不定与之前分配的内存页相邻，连续的页可以通过大的对象或者数组获得。ABI不传递对象指针。

SIP的栈是链式的，调用内核ABI时，寄存器等的现场环境被保留到栈中一特殊结构中，区分SIP与内核空间。中断处理使用专用的栈。

SIP间传递的数据必须驻留在交换堆中，交换堆中的指针只能指向其自身，对于交换堆，有线性（linearity）属性：任何时候，SIP至多只有一个指向交换堆中一块的指针（由此可推，交换堆中的块任一时刻至多属于一个线程）。只能通过向另一SIP（通过channel）发送消息来转移块的所有权，发送后，原SIP不能在访问该块（SIP可能含有指向交互堆的尾随指针(dangling pointer，指向此SIP不再拥有的块)，静态的检查确保SIP不通过尾随指针访问内存）。

每个SIP有其自己的收集器来回收其对象空间中的对象。

代码密封

SIPs含有的代码在运行时刻是密封的，不能动态载入和创建代码。动态载入往往用在诸如载入软件插件的环境中。糟糕的插件可能导致程序崩溃。动态创建代码往往用于某些语言的自省³（reflection）机制。

原需要动态载入的代码，现需要运行在子SIP，通过channel使用父SIP的服务而不是调用函数。Singularity中动态创建代码的自省机制被移除，取而代之的是编译时刻的自省（Compile-Time Reflection：CTR）

密封代码提供了如下好处：

使得程序分析工具能够静态侦测程序的缺陷
通过代码内容来标记一个SIP
在运行时刻执行环境中，不需要复制OS风格的访问控制。

基于Contract的Channel

在singularity中，Channel是唯一支持的IPC手段。Channel提供无损、有序的消息队列。Channel是双向的带有两个终点的队列管道。

终点有权能，比如只有接收了来自另一SIP指向文件系统的终点当前SIP才能访问文件。Channel终点或者在程序启动是获得（由基于清单(manifest)的配置文件获得），或者通过已有的channels中某个消息获得。因为传递的消息必须在交换堆中，故终点驻留在交换堆。这意味着每次终点只明确的属于一个线程（SIP至多只有一个指向交换堆中一块的指针）。每个终点有一个接收队列，向一个终点发送消息，就是把该消息放入该终点的接收队列中。

Contract是描述channel上的通信。其由消息申明（规定参数的数目和类型，及(可选的)消息的传递方向）和一组命名的协议状态组成。借助Contract，SIP之间的通信是有效、可分析的。编译器可以静态地验证发送和接收操作，确保channel不进入错误的协议状态。

Contract可以看成对通信这种工作模式的程序正确性的断言，也可看作基于任务访问控制（Task-Based Access Control）中对工作流的限定。

Channel遵循有限（finiteness）属性：contract的每个状态中，至少含有一对接收和发送操作——终点不能不等待消息而发送无限量的数据。这样作允许在终点中静态分配接收缓冲队列。

Channel的另一个好处隔离了消息传递的实现，比如在同一特权级同一地址空间中的两个SIP之间，实现成零拷贝：发送者通过在接收终点中，放入指向消息（交换堆中）的指针，来传递交换堆中的消息的所有者关系。不同硬件保护域之间的通信，可以实现为数据拷贝或者内存页的COW映射。

基于清单的程序（Manifest-Based Programs）

MBP是一个程序：通过静态的清单（manifest）定义。在Singularity中，执行程序实际上是调用清单而非调用可执行文件。

清单是对程序的描述，是一个机器可检查的，对MBP期望行为的说明（描述了一个MBP代码资源，需要的系统资源，期望的行为能力和对其他程序的依赖）

清单用来进行静态/动态验证MBP的属性。验证包括类型和内存安全、不含特权模式指令、与channel contracts一致（申明contracts的用法）、正确的对应版本ABI的用法。

MBP安装到系统后，清单用来标识MBP代码、验证其符合系统的安全需求，确保MBP对系统的所有依赖得到满足，防止MBP的安装干扰先前安装的MBP的执行。执行前，清单被用来发现MBP相关参数的配置，并对参数进行限制。MBP执行时，清单指导代码载入SIP执行、新的SIP与其他SIP之间的Channel、对系统资源访问的许可。

清单可以内联到程序中，也可分离出来（被多个程序所共享）。

清单（一部分）类似SELinux中的规则，在操作系统的粒度下，对程序进行了限制。可以看在是在OS粒度下程序正确性的断言。

清单另外还对MBP正常运行所需的依赖关系检查，确保了MBP的可靠性。在Windows环境中这部分工作由安装程序所完成，在Linux中，则由各自发行版的包管理程序负责。清单对程序相关参数的配置的检查，这一般由执行程序负责的。之所以独立出上述两点，可以明确的保证程序设计时考虑到相关的检查，使得程序结构更加清晰。

如果比较当前普遍的基于杀毒软件构筑的安全体系，杀毒软件负责对将运行的程序进行验证——不含有病毒库中的特征，且没有触发启发式规则报警。为了让杀毒软件更加有效，可以对待验证的程序要求含有“证据”表明其清白。在Singularity中，这种“证据”即是包含在高级语言Sing#中，而“病毒库”则对应了清单。

Singularity内核

Singularity内核是个微内核，提供基本抽象——SIP、Contract、MBP ，负责调度、对硬件资源的特权访问⁴、系统内存、线程和线程栈，创建/销毁SIP和Channel。

内核通过ABI向SIP提供内存服务。默认状态下，SIP只能操作其自身的状态、停止/开始子SIP（ABI调用只影响调用方的状态，如SIP同步对象不能够跨越SIP访问）。

ABI 强制标明版本，语义明确。没有ioctl或者CreateFile之类的模糊语义的函数。在SELinux一节的分析中得到的结论：明晰的接口有益于细化访问控制的粒度。

SIP通过channels而非ABI函数来获得高级系统服务（如访问文件、发送和接受网络包）。

ABI调用开销比函数调用开销大些：他们必须区分SIP的垃圾收集空间和内核垃圾收集空间。

抽象内核对象（如互斥、线程）的导出为强类型化的不透明的的句柄（handle表中各槽）。当SIP终结时，相应的handle表中的槽被回收。

Singularity的安全

安装时刻的安全机制

在singularity的安全模型中，核心是程序。Singularity为系统中的所有的服务（如设备驱动）、文件系统提供了单一的、树状的名空间。对程序发布者的信任体现在名上。例如，系统策略可以指定，只有由Microsoft签发的程序可以占有某个Microsoft专用的名空间，例如所有微软签发的程序位于/app/microsoft/下⁵。名空间也可按照对程序的信任度（根据系统策略）来使用。

可以看到，上述的安全策略基于路径。由于有安全策略对名空间进行了必要的保护，故此处的安全的。

某些安全强制在安装时刻进行。Singularity对资源的访问通过Channel完成，故系统安装器可以通过静态管理程序的Channel来实现对资源的控制。每个程序的需求在静态的清单中指明。系统安装器通过提供给程序的一个配置，从而在运行时刻实例化Channel，来解决程序清单中所有未绑定的Channel。这种静态的检查有时能用来实现最小特权的安全环境，例如，如果某个程序仅负责在本地处理，安装器将不提供对网络的直接的Channel。

动态访问控制

Singularity程序在运行时刻以一个或多个进程的形式实例化。每个进程由于调用而拥有一个不可更改的标识。

进程创建所有channel终点对，用其标识来初始化终点对。当channel的一个终点传递给另一进程是，接收进程便获得另一方进程的标识。当对共享资源进行动态的访问控制决策时，这个标识与促使该请求进程执行的调用链中的程序的标识，组成访问控制决策中的主体。（在某些情形下，如使用自有认证功能的服务器程序，将忽视调用链）调用历史是以进程为粒度追踪的。

在这个环境中，用户表现为程序的角色。认证用户的程序（比如通过密码或者证书）参与标识的合成。因此，远程登录的用户登录后的标识与本地通过智能卡认证后的标识不同。

Singularity的合成标识由文本字符串表示，例如：

/sys/login@/users/fred + /apps/ms/word

这个字符串可能代表了系统登录程序（用户“fred”通过密码登录）调用Microsoft word程序。

与SELinux相比，在SELinux中，用户角色对登录程序的类型作出贡献，而之后登录程序类型影响其运行的程序：或继承登录程序的类型（默认情形下）或依据转换规则转换到新的类型下。

在访问控制列表处，Singularity使用访问控制表达式（access control expressions：ACEs）来定义匹配标识的模式。这些表达式可以非常灵活。例如，可以指定只有Word能读某个模式保护的文件或者“fred”运行的任何Microsoft的程序能够访问它。

可以设想，通过定义可被继承的策略规则，大量的不同的ACEs将被一小组规则代替。这特性将在结构化的环境中，如文件系统中极为有效。

Singularity的可信基

回来之前的一个问题上来，Singularity的安全是多方面技术合作的结果，这样便引入多方面的依赖，是否也随之引入了安全隐患呢？答案是否定的。在Singularity中可信基由4部分组成：

硬件抽象层
内核部分（使用非安全编程语言编写）
运行时刻系统部分
编译器

其中编译器是个很庞大的部分，将来通过引入类型化的汇编语言（typed assembly language：TAL），来使用一个相对较小的验证器来验证编译器的输出。从而庞大的编译器部分由较小的验证器部分替代，减小了可信基。

总结

通过对硬件接口再次封装（通过安全的编程语言接口），限制了编程语言对内存的访问。这与缓冲溢出防御手段2、3类似（限制执行任意地址其的数据），但限制更多。

得益于这种封装，便于实现软件隔离，在性能上获得收益。开销小的安全手段适应更多的应用场合，从而提升系统平台的安全性能。

Singularity中强调了程序的可验证性：

通过安全的编程语言确保对内存正确访问的可验证性。
Contract给予了进程间通信的可验证性。
清单从系统角度，给予了程序正确行为的可验证性。
SIP代码密封等其他简化手段有助于验证的进行。

这种可验证性源自各种形式的断言。这些断言可能是语言级的，通信级的，系统级的——断言的粒度和时刻（编译时刻、链接时刻、安装时刻及运行时刻）的灵活性使得其最小特权原则得以顺利贯彻。

断言在高层的逻辑上进行有助于最小特权，以及友好的开发环境，但也造成安全的实现依赖面太广，使得安全本身的可靠性降低。Singularity通过一个小的可信基来验证其他安全的组成部分，从而确保了安全本身的可靠⁷。

1Singularity: Rethinking the Software Stack，作者：Galen C. Hunt 、James R. Larus， http://www.research.microsoft.com/os/singularity/publications/OSR2007_RethinkingSoftwareStack.pdf

2An Overview of the Singularity Project，作者：Galen Hunt、James Larus、Martín Abadi、Mark Aiken、Paul Barham、Manuel Fähndrich、Chris Hawblitzel、Orion Hodson、Steven Levi、Nick Murphy、Bjarne Steensgaard、David Tarditi、Ted Wobber、Brian Zill，ftp://ftp.research.microsoft.com/pub/tr/TR-2005-135.pdf

3自省（reflection），程序根据某些变量，改变自身的代码。

4Singularity中的特权指令的执行：不像一般操作系统中只能放到内核中执行，Singularity可以在安检后，放置特权指令到运行在SIP中的可信赖的函数中。（通过这种方式来优化channel通信、运行时刻性能和垃圾收集）

5这个想法有点类似Mac OS X的finder视图

6在SELinux，通过对象类枚举对象的所有方法，然后对不同的主体类型与客体类型（安全上下文）给出此时允许访问的方法（对象类所有方法的一个子集）

7这个思想有点类似merkle tree，上一层验证下一层，通过层层验证，验证整个环境

残念

2008-05-26T12:12:00.001+08:00

最是那一低头的温柔，你如丝的长发倾泻在我的手臂边，使我不得不以狼狈的表情掩饰自己期望去亲手感受那种顺滑的冲动。在我眼中，手持一本诗集侧身阅读的你已经超越了整个车厢，超脱出整个世界。

我不相信命运，因为我的生活经历告诉我，只有自己能够创造和把握的才是真实可信的存在。可是这次，我真的愿意相信这是命运的安排，才能有幸坐在你的身边。我几乎彻夜未眠，我觉得睡觉是在浪费与你相处与交流的时间。

你的眼睛是最吸引我的，如此清澈、明净，看不到一丝世故与杂念。我想起了柳文扬的《闪光的生命》，三十分钟与一百年的思考。幸运的是我能够拥有的时间不止三十分钟而是整整一晚十二小时；不幸的是我绝对没有柳大哥生前面对自己感情的气魄。

时间以亘古不变的速率缓缓流逝。你蜷缩在我身旁，安静地睡去，每一次轻微的呼吸都刺激着我紧绷的神经，扰乱着我杂乱的思绪。我假意转头望向窗外。原本还是皎洁的月色被阴霾所遮蔽，只剩下车厢外掠过的一排排路灯仿佛时刻在提醒我：时光飞逝。浮躁与不安盘踞在我心中。

晨光熹微，旅程渐尽。我忽然希望自己成为《一日囚》中的犯人，自己的余生永远囚禁在这火车上的旅途中。

地铁站挥手道别后的那一刹，我似乎有了解脱的感觉，因为不需要再面对你。然而我很快就明白这不过是逃避痛苦的开端。每天上午，当我在办公桌前坐下，展开电脑，短短的LOADING时间，思念就已如潮水般上涌。我拼命寻找一些工作以驱赶脑海中你的浮影，直到傍晚自己身心疲惫地回到学校。

你问我，送行一次又怎么样。是的，不会怎么样。生活是如此残酷，而我能够掌握和改变的太少。所以我只能乐观的去感受和体会生活的全部，一切的酸甜苦辣和每一个细节。我并不是想来改变什么，只是来送一个即将远行的朋友，一个曾经在我的生活陷入最黑暗的时候带来了一丝光亮的人，并且想亲口告诉她：我有一点喜欢她……

可惜的是，我在车站外徘徊了一个钟头，始终没有勇气进去见你。

“もしも願い一つだけ叶うなら、君の側で眠らせて。”——宇多田光《Beautiful World》

さようなら

2008-05-25T16:03:00.000+08:00

我把一切不能诉说的话语镌刻于此，我把一切不能传递的思念流放于此，我把一切不能实现的愿望埋藏于此。任时光摧残，土崩瓦解；纵岁月蹉跎，灰飞烟灭。此地，北京，我经历过的城市，我即将离开的城市。

晨风

北京的清晨总是以喧嚣开始。虽说已经是初夏，但还是有一丝凉意，出门不得不穿一件外套。天空泛着毫无生气的灰黄色，只有天顶的那一小块还隐约能够发觉些蓝色。

2008年5月19日，对我来说是有些特别的日子。不是因为一周前的汶川地震，也不是因为当天举国哀悼地震中的逝者。那只是对我来说有些特别，因为是与她相识正好满一个月。当然，我不可能跟她见面，原因是1200公里的物理距离，加上5厘米的心理距离。

西土城路10号，路边的蔷薇盛情开放，用红色点缀出勃勃生机。花瓣上晶莹的露珠在晨曦的照射下放射出瑰丽的色彩，引得路人频频侧目欣赏。

午阳

就算是正午的阳光依然显得如此慵懒，照得人也感觉昏昏欲睡。空气中到处弥漫着汽油和尘土的味道，干燥从皮肤侵蚀到内心。

一个月，三十天，七百二十小时，我也只能堆积出28条短信的交流。我是叔本华所说的“冻得直哆嗦的豪猪”：想要给对方温暖，却又担心伤害对方。结果就是如此可怕的隔阂感以及在旷野中大声呼喊也依然无力的孤独。

沙尘给整个城市蒙上了一层棕黄色。各色的太阳花和紫色的薰衣草也显得不再艳丽。北京似乎提前进入了秋季。

晚霞

北京的傍晚是唯一能够让人欣赏的时刻。如果下午正好经历一场新雨，就能够遇见久违的蔚蓝色天空。金色的富有层次感的云彩在斜阳的照耀下变换出迷人的景色。

好朋友说，连喜欢都说不出口的话就是还不够喜欢啊。我只能报以苦笑。

在学校论坛曾经看到过这样一个帖子，应该是每一个工科男生都深有感触的吧：

或许工科男生表达爱意的方式笨拙、语言苍白、甚至是匪夷所思的冷，

但是每一句话，每一件事，甚至是见面时那每一次微笑都是来自于我们心底无数次的求证与推理。

文科生的爱意是弥撒在空间里彩色迷雾，

让人能够立刻感受到那来自于周身的关怀；

可工科生的感情却是凝结成霜的深沉，

只有在你伸手接过之后才能彻底体会那厚重的美。

学校里依然还有些残留的槐花，挂在枝头或者落在地上，已经失去了往日的芳香。茂盛的枝叶在晚风吹拂下发出温柔的摩擦声，让人想起海边不息的浪花。

星空

在大城市里不可能看见群星璀璨的夜空，北京也是一样。但是在冬季寒夜，依然是值得抬头仰望一下，明亮的猎户座可能是这个硕大天穹的孤单点缀吧。

曾经有一个女生讽刺我是“性别错位的同性恋”，因为我的心理性别测试结果是阴性。或许，我所期盼的一直是柏拉图式的恋情，无论是过去、现在还是将来。缺乏心灵交流是否意味着自我的迷失，我不允许自己的大脑被荷尔蒙所掌控。不是用金钱和时间取悦于她，而是真诚地分享——生活。

墙角深藏着一株矮小的紫茉莉，安静地独自开放。幽雅的气味四处漂泊，将我如同飞蛾般吸引。

夜火

夜深人静，窗外却闪过点点星火，是飘忽而过的几只萤火虫。

一个月之前的心情，我也记录了下来。鸟说文笔不错，不过我也懒得再修改，直接放墨羽规论坛了。

http://groups.google.com/group/MoYuGui/web/%E6%AE%8B%E5%BF%B5.wps?hl=zh-CN

仔细回想，北京这个城市还是有些值得令我留恋的地方，毕竟是曾经的向往。然而，我并不属于这个城市，迟早需要离开。

さようなら、北京。さようなら……

BY CursedOctopus

5.12 四川汶川8.0级大地震

2008-05-13T15:07:00.005+08:00

一些反思：

《科学》杂志：中国地震可能是一次大灾难

转自：http://science.solidot.org/article.pl?sid=08/05/13/0253209&from=rss
研究人员担心，在大城市成都附近发生的M7.9级地震，极可能酿成自1976年唐山地震以来最大的死亡事件，唐山地震夺取了25万条生命。美国地震局（USGS）地震学家Lucile Jones表示，“这次地震也将带走无数生命”。她说，有数百万人生活在断层带易受破坏的建筑物中，这一糟糕的结果是无法避免的。四川东部的大地震裂开了连接西藏高原东部山脉和人口密集的四川盆地之间大约275公里长的断层。成都，生活着1100万人，距离地震中心不到100公里。 Jones在25年前就研究了这个可能成为巨大威胁的断层带，因为运动的板块正推动西部山脉沿着断层带向上和向东前进，越过盆地。她说，“对四川来说这是一次大地震，就像是在旧金山或洛杉矶发生类似的强震。”根据USGS收集的数据，有数百万人遭受会引起严重伤害的强震。USGS估计有620万人将会经历最可怕的袭击，地震将会严重破坏脆弱的建筑物。Jones 指出，多数中国的建筑物是易被破坏的。另外有1170万人会经历中等程度的强震，建筑物亦可能受到严重破坏。1976年发生的唐山（150万人口）大地震中只有两座建筑物屹立不倒。

中国官方地震信息网销声匿迹

转自：http://internet.solidot.org/article.pl?sid=08/05/13/0623203
一场地震能暴露很多问题。对于我们这些网民来讲，最无法容忍的也许是：在这危急关头，本应当作为最可信赖的官方信息来源——地震信息网和中国地震局网站竟然都无法打开。虽说现在并不是追问其责任的时候，但从alexa流量查询、web服务器信息，Wayback Machine上看，对比美国地震局网站，根本毫无专业性可言，纯粹就是一个摆设。

杭州——新华坊拾趣

2008-05-10T13:28:00.008+08:00

你们不是说我腐败么，那这次就干脆把败的情况通通交待算了 >_< 别的也不多说，上图（没有相机，只是正好带了PSP的摄像头而已）
首先是客厅

餐桌

厨房

WC（浴布拉着的原因是遮挡一下窗口的强光）

电视、DVD、数字电视机顶盒，还有古董PS2

貌似布置得还是有些情趣的

主人的房间（偷窥？），貌似很乱

阳台上的一盆假花

我寄居的房间（将来在杭州工作的话也会长期居住吧）

床旁边的现状是……

阳台外景（这个是雨天，原来还在天晴的时候拍了两张，发现居然差不多的样子）

猥琐的男主人

慵懒的男主人

美女们在看电视（又是偷拍？）

本鱼的近况的镜像

此次杭州之行一直状态不好，因为在北京的干燥天气下嘴唇干裂脱皮并附加上火等症状。然而，引一句诗“衣带渐宽终不悔，为伊消得人憔悴”，完满诠释了个人的心态。

PSP自制程序开发简介

2008-04-30T11:02:00.009+08:00

只是一个偶然的机会，我在网上闲逛时看到了Miro LUA v2.4发布的消息。接着我就点点点地下载并安装了这个PSP自制程序开发包（只有2.5M哦）。开发界面很简洁，如下图：

唯一让我感觉有些不习惯的是文档结构图是在代码界面的右边的，更像是做设计的。

如同这个开发包的名字，使用的开发语言是LUA。在网上继续闲逛的结果也就是得到了维基网上一个简短的教程，链接为http://wiki.ps2dev.org/psp:lua_player:tutorial。好吧，我承认自己对各大搜索网络搜索引擎的使用还有些障碍……

言归正传，这里稍微介绍一下LUA语言的特点。历史？这种东西就不用浪费时间去考究了，据龟说这个语言是巴西的某教授发明的（汗）。LUA号称是面向对象的程序语言，但是跟C++和Java还是有相当大的区别的。首先是语句结束不需要使用分号，直接换行就可以了。似乎Basic也是这样的吧，看来LUA也是面向初级开发者的语言。其次，我一直没有发现类（class）这个概念，连结构体（struct）都没有，通常都只有function（函数）。如果硬要说面向对象的话：“white = Color.new(255, 255, 255)”这样的定义方式倒是跟C++类似。If语句作为程序中最常用的语句之一，需要在末尾加上end才算结束，这个有点像VHDL（超高速集成电路硬件描述语言）。难道是因为PSP自身不需要复杂庞大的操作系统所以直接操作逻辑电路比较方便吗？这个只是我瞎猜，毕竟学得还太少。

总体来说，LUA语言还是比较简单的。不需要各类繁琐的头文件，不需要定义指针和控制内存（至少我看到的还没有出现这些），不需要自己编写很多基础功能（因为很多LUA程序都是开源的）。

这里附上我的第一个LUA程序。因为是第一个程序么，所以就按照老规矩：Hello World!

点这里下载

解压后直接放在记忆棒的GAME目录下运行就可以了。"test3.lua"就是源文件。

现在国内做开发的人还是相当少，但做出来的东西确实都是不错的。比如最近的一个MP3播放程序，是可以边播放边显示歌词的，支持中文的哦。希望以后可以有更多的国人参与到开发的行列中来（好像说的自己也是开发人员似的，其实连入门都算不上 >_<）。

水乡古镇——南浔

2008-04-27T19:59:00.009+08:00

杭城春花烂漫

2008-04-23T10:15:00.001+08:00

杭州是一座极富个性的城市，因为它坐落在个性化的浙江，是浙江省的省会。个性化并不意味着过度的张扬与浮华。站在延安路上微微颤动着的过街天桥上，桥上桥下肆意流动着的人与车，街边巷尾溢满的笑语跟闲话，处处诠释着个性的含义。

我已记不清这是第几次到杭州了。如果可以的话我希望可以把这里作为自己的第二故乡。

第一次到达杭州之后就直接前往了浙大紫金港。那是一个有些荒芜的校园，在炎热的夏日骄阳下就更显得缺乏名校应有的气氛。而且大叔以真正大叔的形象迎接我了场景实在是……好在饭菜还是不错的，亚洲最大学生食堂的气派足够把这座边郊学校的形象缺陷补完。虽然我在浙大紫金港停留的时间不过半天，但是我敢肯定，以后绝对不想再去那里（>_<），因为我不喜欢空旷缺乏生机的地方，以及那诡异的冒着白色蒸汽的窨井盖……

去年夏天，大叔这届本科生终于搬回了玉泉古校区。我也有幸在他们入住不久后就第一时间前往庆贺（其实也算蹭饭）。玉泉沉淀的历史使其显得古朴和低调。整个校园被随处可见的榆树所包裹，使得原本陈旧的道路看上去愈发具有沧桑感。

西湖是我为之停留时间最长的地方。07年暑假的大半时间我都躲藏在西湖边的一个出租屋内，白天躲避酷热的日晒，傍晚则沿着西湖岸边散布。玉皇山是个比较偏僻的地方，但也全依靠这种偏僻，我可以抬头便望见雷峰夕照，出门即到柳浪闻莺，有时晚上还可以在一公园跟着游人一起欣赏音乐喷泉。诶，可惜腐败的日子总是不能长久的……

此次去杭州的主要任务貌似已经可耻地失败，所以最后两天的生活已经彻底腐化了（龟：我就知道！鸟：……）。这次寄宿在一个好朋友租的房子里，好像是叫新华坊的社区。由于出门就是凤起路，再不远处就可以到延安路，所以某日干脆就早起独自出去溜达了趟。天气并不怎么好，阴阴的，还有些凉。我趁着早起的饥饿感放纵自己依靠嗅觉找路。我放弃了沿途经过的早餐铺、超市和快餐店，满无目的地继续追寻心目中的美味。直到我登上了一座人行天桥，面对着几个叫卖着长江七号的小贩，还有选择了一个舒服的姿势躺下的行乞者，以及在街边亲密地打了一个响亮的kiss的两个女孩。我发觉自己的饥饿感有些越界了，所以选择回头。在路上一家装修不错的蛋糕店选了三个价格不菲的蛋糕后，我放弃了继续漂流的打算。

在回北京的路上认识了一位浙大的学姐。我问她对杭州的感觉，她说杭州就像是一个巨大的植物园，处处都洋溢着生命的韵律。不错，西湖旁、吴山脚，几乎每个地方都是郁郁葱葱的古树。那些环腰粗的古老生命，在其他地方也许都该贴上保护文物的标签慎重保护起来吧。但是在个性的杭州，百年古树们只是默默地矗立在道路两边，与这里的人一起享受着生活。

四月中旬，正好是杭城的杜鹃开放最艳丽的时节。精致的紫色花朵到处可见，盛开在社区里的坛苑中，盛开在玉泉古校的厅径边，盛开在我干涸已久的心田里。

黑之契约者——又一部讲述异化的作品

2008-04-09T09:25:00.005+08:00

某日前网上看到某版主推荐动漫精品，《黑》与Noein、《永生之酒》被给出七星最高分。正巧对最近要做的事懒惰（主要是没兴趣），就颓废一下。

首先是设定，只能用诡异形容（顺便看了Noein的介绍，居然还有诡异，看来是版主的兴趣）。虽然是SF，设定可真像程序API手册上来就出现的类一样突兀，让人想起鸟以前伪荐的《特公》。大体是某日出现了某特殊区域（就像《特公》里某日出现的地底黑洞），围绕该区域筑高墙，并构建了出入的大门。伴随着上述现象，夜空被虚假的夜空随替代，并出现了一些有超能力的人，他们的存在和虚假夜空中的星星相对应（就像《三国演义》里所描述的人与星星的对应关系）。接下来概念介绍：

class 契约者:

超能力
每使用超能力就需付出某个代价（简单的是习惯，复杂的和性命相关）
每使用超能力时，（虚假）夜空中对应的星星闪烁（虚假星空就是其导出的名空间？proc文件系统？）
死去时夜空中的星星消失
被权力机关惧憎和利用
其存在普通人不知（权力机关居然有记忆消除器...）

class 延期偿付者 (契约者):

特殊能力
每次释放能力时夜空中对应的星星闪烁
死去时夜空中的星星消失

###########################################

超能力的释放无法控制，易暴走（故地位还不如契约者）
多次释放超能力后才需要付出某个代价
在很小的可能性下转换为契约者

class DOLL:

没有精神的肉体（个别例外）
行为受输入程序控制
能够分裂出观测灵

class 观测灵:

有电或水的地方才能工作
类似装有摄像头的探测机器人，用于侦察
以水和电线为介质潜行

与《特公》中一样，《黑》的世界中也成立处理超自然案件、对公众隐瞒超自然存在的公安部门。

主角设定为一名叫李舜生的中国人——代号为黑的契约者，虽外表老实，其实非常可靠，受雇某组织和一只名叫“猫”的黑猫（契约者）、“黄”的辞职警察和“银”的女孩（DOLL)组队执行任务。其大部分任务是消灭其他威胁组织的契约者，再加上“黄”这个人物有点像鸟进贡的《巷说百物语》中那个宽屏脸矮胖，故又有《巷》的感觉。根据《巷》的结局，推测最终BOSS——果然是组织，并且也是公安部门的幕后，目的是消灭所有契约者，恢复过去的地球。

又是异化的主题，人物塑造还不错，表现手法比较常见，有点让人疲倦。情节基本几集一个小故事，描述各个异化者(契约者)的故事以及主角和其团队成员的过去，到结尾清洗主角以外的配角。差点成了人类补完的结局，最后主角意志决定让双方逐步接受现状。

《黑》中出现了很多不同国家的人，并且主角是个中国人。可能是为了更好的表现异化的主题（比如民族主义、种族歧视都是异化主题的现实背景）——人不应对与己不同的存在感到惧憎，而需宽容。

《黑》的镜头处理和它表现的主题呼应，人物画风也顺眼，并且几集中会冒出了美女来^_^。

最后说下《黑》的声优阵容，主角声优几乎我无知。客串阵容到有不少“熟人”，比如池水通洋（《机动警察》太田功）、井上和彦（《火影》的卡卡西）、三木真一郎（《死神》的浦原店长）、三瓶布由子（《Eureka》兰顿）、名塚佳织（《Eureka》优莱卡）、小林沙苗（《棋魂》的塔矢亮）、川上とも子（《棋魂》进藤光，《AIR》神尾观铃）...不过大部分居然没听出来

《电脑报》新海诚专访

2008-04-06T09:50:00.004+08:00

原刊载于《电脑报》2005年6月27日G9版[动漫天地]

电脑报(以下简称"电")：你独立制作了这么多部优秀动画，实在是很了不起，中国国内你的Fans也日益增多。当初你在大学里学习的是文学，能谈谈为什么毕业后去了Falcom游戏公司工作吗？
新海诚(以下简称"新")：十分感谢中国朋友的支持。去 Falcom应该说是圆小时候的一个梦。我在十岁的时候就迷上了CG，当时还在读小学，也就是那时候开始用BASIC语言画一些简单的插画。说起来干这行的历史比学文学还旧远得多。后来我进Falcom公司负责程序、美工、动画与宣传片制作，我记得那时候简直为电脑的“16位真色”疯狂了，那些美妙的颜色运用在电脑绘画中确实让人感动。在Falcom五年期间我更全面地学习了CG动画制作，觉得我幼时的梦想圆了一半。

电：你一个人、一台电脑、一块手写板……在一部动画作品担任原作、脚本、监督、美术、色彩设计、机械设定、摄影、CG制作等多项工作，实在是太了不起了。还记得在制作这些动画过程中，最苦的经历是什么？当时是怎么克服这些困难的？
新：在制作《星之声》的时候，主角的人物形象让我伤透了脑筋，然后拍了数以千计的真人动作片断，记录在电脑里，又配合3DCG指导完成了主要人物的设计。后来做《云》的时候就有了一定的经验，和动画设计专家分工合作，做出的人物形象也比以前更加逼真。
目前，困扰我的就是怎样创作一个好脚本来。另外就是题材方面写什么，技术方面怎么写这两方面的烦恼。尤其是作品中的情节、主题，真真切切地需要一个作者在生活中点点滴滴地积累，去感悟。

电：你的这几部动画配乐大气又不乏温馨，能谈谈为什么音乐部分都选择和天门合作吗？
新：天门的音乐对我而言，是比任何人都能准确地吸取并表现作品的主题的。天门的音乐，不是“为了音乐的音乐”，而是成为了“讲述主题的音乐”。我的作品也不是“为了影片的影片”，而是想要成为“讲述主题的影片”。我们对于作品的态度的想法是一致的。

电：简单说说当时做《星之声》的制作流程如何？
新：就我个人来说，主要使用了如Adobe Photoshop CS、Lightwave 3D 8.2、Adobe After Effects 6.5等软件来制作动画。做一部动画，首先要心中有数，要给观众呈现一个什么故事，什么主题，然后编写脚本等等。以下我认为最一般的做法，以此来说明。但是，具体做法根据作品和人员构成会有所改变，不一定必须如此。

考虑要表达的题材。
将剧情写成文章。
以剧情为基础绘制连续图片。
将连续图片在计算机上剪贴，制作成连续影像。
在连续影像的基础上，进行人物和背景画面的作画.。
用综合软件将背景和人物合成。
加上效果音和配音。

电：CG除了人物和形象设计，还可以运用于MC（动画）的其他方面么？
新：这需要视CG和MC所涉及的对象而定。如果将CG看作Pixar's Work一类的平面作品，那么MC就指3DCG制作的动画。在日本商业动画中，用传统方式手绘人物形象，用3DCG做细节处理，这就是CG在MC方面的运用。我的作品《星之声》和《云》都运用了相同的CG风格（手绘人物形象，3DCG更多绘出背景）。为使2D和3D协调，我使用了一些技巧，比如有意处理一些3D的画面。

电：你开始想过让动画商业化的问题没有？
新：能达到今天的规模，是当初没有想到的。开始我只是想通过在网上卖自己的作品这种小规模的形式来维持生计。幸运的是遇到了Comic Wave公司，这是我所遇到过的工作上最棒的合作伙伴。

电：你怎样看待CG动画的未来？
新：谈到CG动画的未来，我个人认为会像网络游戏一样前景可观。相比传统动画费时费力的缺点，CG动画随着电脑技术的发展可以节省更多创作时间，而且它的艺术表现形式也非常丰富，只要我们有想法又技术，要做出一部优秀的动画就简单容易很多。以日本主流动画来说，现代CG会逐步完全代替传统的手绘，这种趋势是显而易见的。从中国目前的CG技术运用日渐成熟的现状看，也将逐步走向这个趋势。

电：现在，中国国内的CG爱好者越来越多，可最终像你一样能做出出色的完整作品的个人和团队却不多，借此，你能鼓励一下他们么？
新：我的大部分作品都是讲述一个人在成长过程中必须面对的困难，并通过努力渡过难关的故事。相信这种精神是无国界的。中国的CG爱好者们，你们能行！

电：你的下一部动动画有什么动向吗？真是很期待啊。
新：下一部动画还说不好，不过我正准备一些短片。我还要继续用我的DV捕捉人物的形态、表情、动作，更合理地运用在动画人物的塑造中去。虽然使用的都是一些冷冰冰的机器数码产品，但是希望能尽我所能，让动画更贴近人们的表现、情感以及思想，更加“传神”。

[MV]超强悍，117个动画镜头,你能认出多少?

2008-04-06T09:47:00.001+08:00

转自新海诚中文网：http://www.shinkai.cn/viewthread.php?tid=591

在无尽的生活中寻找工作的意义

2008-04-02T14:04:00.001+08:00

—— 致我的好兄弟们

看了鸟发的一篇鸟文（真的是鸟文，就一张图），似乎感受了一些颓废的气息。所以就利用中午休息时间拼凑了以下的东西，希望可以给两个兄弟一些鼓励。

首先感谢一下鸟给我的许多帮助，多次指导我修改简历，最后终于升级出了ultimate版的本鱼简历。虽然最后还是被网易秒杀了，但也得到了让人感觉能力不错的评价，并让我重新认识了找工作这件事。

简要说下自己的近况吧。现在中国网通研究院做毕业设计。网通研究院到底有多大？我也不清楚。但是我所在的一个NGN项目组的正式员工只有4人，上面两个项目经理，一个外聘程序员，其他清一色的北邮实习生。NGN就是下一代网络，项目组的主要工作就是制定下一代网络的各种规范，当然只是网通的企业规范。所以按照这里的王小华师兄（平常都叫他小华哥）的说法，这里做的都是超越时代的东西，也许你一不小心就变成了××技术之父或者××规范之母了。听上去很牛叉吧？早在20世纪初，有个德国人说计算机应该用二进制计算，然后就成了现代计算机之父，这个人叫冯·诺伊曼。我不是在这里诋毁伟人的巨大功绩，只是举个例子说明所谓的技术规范制定并非多么了不得的工作。具体的实现并不是由规范层面所决定的，就如同诺伊曼老人家也不用知道如何用C++写程序。我在网通研究院只是临时性的，所以重要的工作不会放手交给我（我也干不了），每天的日常工作就是看各类文档，学习积累。

工作久了（姑且把这叫做工作吧，虽然不给钱），免不了会有点厌烦，各个企业的规范看得多了也是大同小异。可这就是生活，工作也是生活的一部分，而且往往是重要的一部分（绝对不是最重要的）。

鸟在网易过得有多不爽我不能体会到，毕竟没有经历过类似的环境，只是希望不会无聊就好。舒适、有趣而且薪水高的工作谁都希望得到，但现在还不是我们做在真皮沙发椅上扔飞镖的时候。个人的工作梦想是能够进入一个团队做出一些（甚至只有一个也足够）让自己感觉一辈子都能够为此骄傲的东西。这也可能是我一直没有找到心仪的工作的原因吧。貌似龟是有这样的机会的，因为他一直是这么跟我吹嘘的。龙芯4之父？呀，还是算了吧……龙的父亲怎么可以是海龟呢 >_<

上面说了工作不是生活中最重要的部分，所以希望鸟可以把注意力转移到生活的其他。家人、爱情、朋友，不是日常生活的调剂品，而是每个人生活中永恒的元素，鸟一定要好好把握。

其他的也不多说了，小BOSS的目光让我的脊梁发凉，北京的温度还比较低呢。

最后晒一下：MHP2ndG的UMD前天到了，虽然每天要晚上7点才能回到学校，但是跟众人一切狩猎的感觉真是棒极了！啊哈哈哈……

在无尽的加班中寻找人生的意义

2008-04-01T22:28:00.003+08:00

如题

cee1的梦、想

2008-03-31T14:51:00.001+08:00

鸟老说我的文章大部分像在说天书。那么，好吧。这次就写点半天书的东西。

梦

不得不说，我有时候是理想主义者。所谓理想主义有时候是很残酷的，轻者类似洁癖，重者类似人类补完计划。不过，引用NERV副司令冬月的一句话——“我宁可生活在有人的地狱”（背景是与碇原堂在发生第二次冲击的南极，碇说这里连微生物也没有，是没有罪恶的世界了），即理想应与现实的交叉——所以我在理想主义者前加了“有时候”，所以这个部分的标题是“梦”——那朦朦胧胧地贯穿了人愿望的，而又会醒来的现象。

以下占位，等有心情了再写...哈哈

想

开源的运动，如同文艺复兴一般，其把那些“高深”的“技”、“术”变得透明，移除高科技的光环，从神坛上拉下，普遍地available。开源运动的意义不仅仅在聚集了“草根”开发软件，更重要的是展现了网络的力量，对传统教育进行了冲击，展现了教育的本质在于环境(context)。对于数字产品（网页、软件、文档、图片、音乐、游戏、电影...）的“绿色制造”（完全使用开源技术而非大众很难获得（包括经济上...）的闭源技术制造）也是有重要意义。值得注意的是，开源虽然始于软件，但是其波及范围已经远远超出了软件的范畴。举个例子说明如何其是从软件向其他领域扩充：硬件方面，受软件开源影响有开源的CPU（CPU设计电路开源），还有开放的计算资源（google和IBM的“云”项目），利用这些计算资源可以进行CPU非常繁重任务。以此为基础开源的思想的广泛在各个领域的传播。（PS：希望某鸟和某鱼将来工作上能用上我组装过的“工具”，实现绿色制造）

现代的(艺术般)制造，是一群人聚集在一起交流与表现其共同的理念与创意。开源运动降低了非相关因素的成本（现代制造离不开网络和计算机吧），使得人与人交流更加自由。（PPS：这个过程中，电脑和网络的功能越发被利用，人与人的交流完全通过虚拟电子电路来完成，这样黑客帝国中的虚拟现实情节就显的可行...为了避免这种情况（出于比如存在感,“存在”这个词貌似很多作品探讨，哪天有感觉了再展开），人与人也需要更多的现实（地理上）中交流，这就是上次和鸟交流的那个创意点子——围绕地理上人聚合来提供相关服务，弥补现代人心灵上的需要。

留言板

2008-03-27T15:05:00.001+08:00

留言后可能不会立即显现，请耐心等待...

双屏电脑

2008-03-25T09:50:00.002+08:00

特点：

正反两面双屏，触摸屏

屏幕大小如本本屏幕大小，比如14.1寸
两人面对面交谈（屏幕不是很大，不隔离两人）

用例：

当两人面对面讨论、协作时:

每人拥有各自屏幕及操作空间。相比两人并坐，两人不会互相影响
两人面对面直接对话交流
两人的视角相同
一方在屏幕指点画圈，另一方屏幕可显示出（多种显示模式）

鳥の詩

2008-03-21T10:37:00.001+08:00

鸟の诗(tori no uta)

词：key

曲：折户伸治

编：高濑一矢

歌：Lia

kieru hikoukigumo bokutachi wa miokutta 消（き）える飞行机云（ひこうきぐも）　仆（ぼく）たちは见送（みお）った	目送消逝飞机云的我们
mabushikute nigeta itsu datte yowakute 眩（まぶ）しくて逃（み）げた　いつだって弱（よわ）くて	刺眼的云就这么逸出视线　渐行渐远（总是如此软弱）
ano hi kara kawarazu あの日（ひ）から変（か）わらず	从那日起不变的
itsu made mo kawarazuni irarenakatta koto いつまでも変（か）わらずにいられなかったこと	永远不变的　对逝去的过去
kuyashikute yubi o hanasu 悔（くや）しくて指（ゆび）を离（はな）す	痛苦悔恨的放开手

ano tori wa mada umaku tobenai kedo あの鸟（とり）はまだうまく飞（と）べないけど	那只鸟虽还不能飞得很好
itsu ka wa kaze o kitte shiru いつかは风（かぜ）を切（き）って知（し）る	但总有乘风而去的一天
todokanai basho ga mada tooku ni aru 届（とど）かない场所（ばしょ）がまだ远（とお）くにある	到不了的地方尚如此遥远
negai dake himete mitsumeteru 愿（ねが）いだけ秘（ひ）めて见（み）つめてる	便将愿望深藏　直视前方

kodomotachi wa natsu no senro aruku 子供（こども）たちは夏（なつ）の线路（せんろ）　歩（ある）く	孩子们　循着夏天的行迹
fuku kaze ni suashi o sarashite 吹（ふ）く风（かぜ）に素足（すあし）をさらして	在风中　打(露)着赤脚
tooku ni wa osanakatta hibi o 远（とお）くには幼（おさな）かった日（ひ）びを	远处是　幼时的日子
ryoute ni wa tobidatsu kibou o 両手（りょうて）には飞（と）び立（だ）つ希望（きぼう）を	两手中　希望飞散

kieru hikoukigumo oikakete oikakete 消（き）える飞行机云（ひこうきぐも）　追（お）いかけて追（お）いかけて	不停追逐消失的飞机云
kono oka o koeta ano hi kara kawarazu itsu made mo この丘（おか）を越（こ）えたあの日（ひ）から変（か）わらず　いつまでも	从那时越过这小丘起　就从未变过
massugu ni bokutachi wa aru you ni 真（ま）っ直（す）ぐに仆（ぼく）たちはあるように	但很快的　我们终将同在　而能达到
watatsumi no you na tsuyosa o mamoreru yo kitto 海神（わたつみ）のような强（つよ）さを守（まも）れるよ　きっと	即使如海神般的坚强吧　一定的

ano sora o mawaru fuusha no hanetachi wa あの空（そら）を回（まわ）る风车（ふうしゃ）の羽根（はね）たちは	那空中回转的风车扇叶
itsu made mo onaji yume miru いつまでも同（おな）じ梦见（ゆめみ）る	总作着相同的梦
todokanai basho o zutto mitsumeteru 届（とど）かない场所（ばしょ）をずっと见（み）つめてる	望着到达不了的地方
negai o himeta tori no yume o 愿（ねが）いを秘（ひ）めた鸟（とり）の梦（ゆめ）を	只好将愿望深藏作著鸟之梦

furikaeru yaketa senro oou 振（ふ）り返（かえ）る灼（や）けた线路（せんろ）　覆（おお）う	回首是灼热的线路
nyuudougumo katachi o kaete mo 入道云（にゅうどうぐも）　形（かたち）を変（か）えても	即使笼罩的云　改变了形体
bokura wa oboete ite dou ka 仆（ぼく）らは覚（おぼ）えていて　どうか	我们总还记得
kisetsu ga nokoshita kinou o 季节（きせつ）が残（のこ）した昨日（きのう）を	残留季节的昨日

kieru hikoukigumo oikakete oikakete 消（き）える飞行机云（ひこうきぐも）　追（お）いかけて追（お）いかけて	不停追逐消失的飞机云
hayasugiru aizu futari waraidashiteru itsu made mo 早（はや）すぎる合図（あいず）　ふたり笑（わら）い出（だ）してるいつまでも	对过早的信号　两个人笑了出来
massugu ni manazashi wa aru you ni 真（ま）っ直（す）ぐに眼差（まなざ）しはあるように	很快的眼神交会
ase ga nijinde mo te o hanasanai yo zutto 汗（あせ）が渗（にじ）んでも手（て）を离（はな）さないよ　ずっと	即使渗出了汗也永远别离手啊

kieru hikoukigumo bokutachi wa miokutta 消（き）える飞行机云（ひこうきぐも）　仆（ぼく）たちは见送（みおく）った	目送消逝飞机云的我们
mabushikute nigeta itsu datte yowakute 眩（まぶ）しくて逃（に）げた　いつだって弱（よわ）くて	刺眼的云就这么逸出视线　渐行渐远（总是如此软弱）
ano hi kara kawarazu あの日（ひ）から変（か）わらず	从那日起不变的
itsu made mo kawarazuni irarenakatta koto いつまでも変（か）わらずにいられなかったこと	永远不变的　对逝去的过去
kuyashikute yubi o hanasu 悔（くや）しくて指（ゆび）を离（はな）す	痛苦悔恨地放开手

青空AIR

2008-03-21T10:29:00.007+08:00

青空 AIR

作词：Key

作曲：Key

编曲：折戸伸治

Vocal：Lia

Ano umi dokomademo aokatta tokumade あの海どこまでも青かった远くまで	那片海洋蔚蓝的一片直到远方
Ano michi dokomademo tsuzuiteta massuguni あの道どこまでも続いてたまっすぐに	那条小路笔直地延续没有尽头

Ichiban hayaku sunaoni warattamono gachi 一番早く素直に笑った者胜ち	还记得那次游戏看谁会最先笑出声来
Ichiban sukina anohito waratteru 一番好きなあの人笑ってる	还记得最喜欢的那个人开心的笑容

Dare yorimo toku e ittemo koko kara mata waratte kureru? 谁よりも远くにいってもここからまた笑ってくれる？	就算走得比谁都要遥远他仍会在这里对我微笑吧？
Hitomi wo tojireba futto natsu no nioi 瞳を闭じればふっと夏の日の匂い	只要轻轻地闭上双眼便会感到夏日阳光的气息

Ano kawa asonderu futari kiri doro darake あの川游んでるふたりきり泥だらけ	那条小河嬉戏的两人满身是泥
Ano kumo otteiru todoitara shiawase to あの云追っている届いたら幸せと	那朵云彩只要能追上就会幸福

Ichiban hayaku kono saka nobotta mono gachi 一番早くこの坂のぼった者胜ち	还记得那次游戏看谁能最先跑到坡顶
Ichiban sukina ano basho mezashite 一番好きなあの场所目指して	还记得最喜欢的那处地方我们一直向往

Takusan no omoide ga aru hoka niha nani mo iranai kurai たくさんの思い出がある他にはなにもいらないぐらい	有着太多太多的回忆不需要其它的任何东西
Hitomi wo tojireba sugu ano umi no nioi 瞳を闭じればすぐあの海の匂い	只要轻轻闭上双眼就能够感到那片海洋的气息

Mata natsu ga kuru giniro ni hikaru また夏がくる银色に光る	夏天还会再来映照在银光闪闪的水面
Minamo ni utsusu futaribun no kage 水面に移すふたりぶんの影	两人的倒影

Dare yorimo toku he ittemo kokokara mata waratte kureru? 谁よりも远くにいってもここからまた笑ってくれる？	就算走得比谁都要遥远他仍会在这里对我微笑吧？
Hitomi wo tojireba futto ano hi no aozora 瞳を闭じればふっとあの日の青空	只要轻轻地闭上双眼便会感到那日蓝天的气息

最终兵器彼女Op & Ed

2008-03-20T13:25:00.002+08:00

ASL (Adobe Source Libraries)总览

2008-03-20T09:14:00.003+08:00

stlab.adobe.com

作者：

Sean Parent, Adobe Systems Incorporated

Mat Marcus, Adobe Systems Incorporated

Foster Brereton, Adobe Systems Incorporated

更新日期:

2004-12-6

2007-4-3

翻译：

cee1 (fykcee1@gmail.com) 2008-3-19

摘要

本文档总览 ASL (Adobe Source Libraries)。ASL的目标是开发通过用说明性的描述(declarative descriptions )，组合一般算法来构筑高级程序的技术。

ASL最开始的两个重要的库：属性模型库(Adam)和布局库(Eve)。它们负责在软件程序中模型化人机界面的外观和行为。

ASL是Adobe软件技术实验室(Adobe Software Technology Lab ：STLab)一个项目；一个通过提供更好的技术和教育来增加开发者的创作力和软件质量的研究小组。

Adobe Begin是一个用来表现这里提到的观点的简单程序。

个人前言（选译）

这是个开始...

这里是我准备发布Adobe Source Libraries时的想法。这里有些精妙的代码，我希望那些会擦出未来研究和开发的火花。

如果看软件产品的界面，很可能感觉是机械化的。给你的幻觉的是在直接操作底层模型：如果你按这里，你知道什么将会发生（或者什么应该发生）。如果你按那里，会发生另外的。

界面之下是一个非机械的系统。大部分的实现可以用“有机”来更好形容：乱糟糟一堆对象通过信使系统松散地互联。这个系统不是随机的，可以通过使用任意数量的、已很好建立的方法学来仔细设计它。

然而，这个系统的真实构架，是一个由个别数据和互联逻辑形成结构。软件由代数结构所定义。

这个主题在ASL中不断地在很多方面重现，包括：

值依赖的语义，而不是引用或者指针语义，作为控制联系的机制。
陈述算法的需求，通过语义概念而不是接口。
清晰化联系，使用明了的数据结构，在缺少继承的联系机制中引人注目。

这是个好的开始...

这些库被结合到Adobe的产品中，用简洁和简短陈述代替了成千上万行代码。Eve布局引擎节省了 Adobe地方化方面重要的人力资源。

最有“抱负”的库，Adam，源自一个直觉——简单人机界面背后的逻辑可以用一个函数精炼描述：

f (x) -> x'

提供这些功能的代码，占到Adobe代码基的1/3,并且是开发中几乎半数bugs的来源。显然，这些函数不是如此简单，至少不想上述表现的那样简单。其复杂度大约源自高度的互联变量。单靠事件处理代码，其没有足够的上下文来解决上述系统中的复杂问题。

...

属性模型库和布局库简介

属性名模型库包括求解器和用来描述一集合中值间的约束和关系的陈述语言，典型的，传给程序命令(一个函数)的参数。当用在人机界面时(human interfaces：HI)时，属性模型库提供了控制HI行为的逻辑。属性模型库在概念上和一个电子表格(spreadsheet)或者表单管理器(forms manager)类似。值被设置时依赖之的值被重新计算。属性模型库提供了解析互相联系的值的工具，但不是一个一般的约束系统。

布局库由求解器和用于构筑HI的陈述语言组成。布局求解器读取HI元素的丰富描述，来形成一个与手工布局相媲美的高质量的布局。对于跨多个操作系统平台和语言而言，单一HI描述就足够了。布局库被开发出来和属性模型库合用，但是也可单独使用。

这些库不构成一个传统的应用程序框架。它们是可以被融合到多个环境中的组件库。它们也可一起使用，或者独立使用，但必须和其他工具一起来构建一个应用程序。几乎所有构成属性模型和布局库的组件也可以独立被使用，并且作为ASL的一部分被文档化。

ASL用C++开发，并且大量的使用了Boost库<http://www.boost.org>，所以编译ASL需要boost。

布局库开发有三个目标和两个需求：

目标：

更加容易地指定和修改HI布局。
所有平台单一定义（跨平台）
所有语言单一定义（国际化）

需求：

必须满足片段能结合到应用程序中去。
创建布局和手工布局的一样好或者更好。

实现目标三依赖于一个记号字符串系统。ASL提供了xstring库作为类似系统的一个例子，但是布局库不直接依赖任何字符串系统。

以下例子在本文档中通篇使用。这里用来给个第一印象。一个简单的对话框的布局描述如下:

layout clipping_path
{
view dialog(name: "Clipping Path")
{
   column(child_horizontal: align_fill)
   {
       popup(name: "Path:", bind: @path, items:
       [
           { name: "None", value: empty },
           { name: "Path 1", value: 1 },
           { name: "Path 2", value: 2 }
       ]);
       edit_number(name: "Flatness:", digits: 9, bind: @flatness);
   }
   button(name: "OK", default: true, bind: @result);
}
}

注意为了简洁，字符串以简化的方式显示。一般，一个记号字符串系统将被使用。

图一：上面描述的Clipping Path对话框（在Mac OS X中）

虽然这个例子创建了一个静态的布局，布局库能也能在HI元素隐藏或显示时控制的元素放置，比如当窗口改变尺寸或者内容改变时。

在布局表述中的绑定属性（bind attributes），代表HI元素联接的对象——一个下层的模型。在此例中，模型是是一个传给函数的参数模型（推测起来，一个改变文档"clipping path"的函数）。属性模型库管理HI事件输入的参数间的约束和关系，并且把信息回填给控件来显示。

绑定属性的值引用属性模型中的一个单元。此例的属性模型被陈述为：

sheet clipping_path
{
output:
result                  <== { path: path, flatness: flatness };

interface:
unlink flatness : 0.0   <== (path == empty) ? 0.0 : flatness;
path            : 1;
}

绑定数字文字域到属性模型中的flatness单元，从而HI显示此单元中的值并且使得HI状态影响单元状态。字符域在”0.0”和上次用户输入值之间切换，而弹出菜单则在”None”和文档中可用路径之一切换。当”None”被选择，则文字域灰色不可用，因为flatness单元不能直接对结果产生影响；若此时文字域中输入数字（导致设置了绑定的flatness 单元的值）将对reslut无效故控制被禁用。

虽然模型中的改变在绑定的HI中反应，模型并不引用HI，是完全独立的。它能绑定到任意数量的可选界面，同一模型被用作脚本验证。模型也被用来脚本产生（记录）。

虽然这些库被开发出来解决Adobe产品的应用程序HI开发问题，也存在其他可用的技术。它们可被用于形成布局和逻辑，网页应用程序前端的开发，网页布局和逻辑，或者文档样式表布局。

我们也在努力应用文档模型来扩展这些库中的概念。

属性模型库的目标

属性模型库的目标是高尚的——部分是为了这个库能成功成为一个明显优异的应用程序构筑HI组件的方式。

减少构筑界面的劳力

询问几乎所有软件工程师，什么是他们最痛恨作的，答案将会是“构筑人机界面”。甚至引入布局库，工程师从大部分繁冗的工作中解放出来，构筑人机界面的工作量仍旧繁重。实际上，HI相关代码占了Adobe应用程序中实现某个特性总代码的近1/3。与框架代码形成鲜明对照，框架代码占了我们的应用程序大约1/10，故此项目潜在影响力非常明显。

属性模型库立意通过一种清晰格式，来模型化当前由复杂事件处理代码管理的部分。它同时也减少了冗余逻辑，合并通用逻辑来重用和共享。通过使用属性模型库，用描述来替代当前实现界面的一些必要代码，从而体积减少10倍，复杂度减少大约600倍。

增加界面实现的质量

正如上述，Adobe产品中的大部分代码用来管理HI，预计相应数量的bugs。但在现实中，HI相关的Bug不成比例地高。在Photoshop的20,000-bugs数据库中，抽样显示每500处bugs中一半和界面层相关，这也是属性模型库立足处。这些bug相对不严重，但仍对资源产生中重要影响。横向比较Adobe产品大约40%的bug本质上是“行为上的”。使用属性模型库以后，这些bug中的多数(在 Photoshop抽样中，20个有4个)不会发生。其他bugs，虽然他们仍旧发生，但可很简单地找出和修复或是通过设计更加贴近实现来完全剔除。

允许界面在产品间共享

Adobe应用程序从其他公司获得并且内部开发超过10年。随着时间流逝，平台改变，产品必须移植。结果造成了没有两个主要的应用程序基于同一应用程序框架开发。

我们的应用程序在套件合成和角色转变（从孤立的域到一个大工作流中的组件）过程中，对重要HI元素共享的需求不断增加。在某些领域中，诸如文件和财产（asset ）管理，文本，颜色，元数据，web优化和透明度，都期望与每个应用程序很好整合，并对应用程序通用。布局库已可从某种程度上实现界面布局共享。

由于应用程序的框架、对象模型不同，整合与代码共享显得困难。即使布局被共享，其后的实现不能被共享，但仍旧要满足良好整合。其结果是构成HI背后逻辑的代码在每个程序中用其各自控件和事件处理的模型来重复。造成代码和劳力大量重复。属性模型库试图合并那些逻辑，允许其在我们应用程序间与底层框架无关地轻松移动和定制。

把HI开发工作交给设计师

当前，用户界面设计师负责设计视觉预览，同时可能加些文字来对行为描述。这个工作是使用图形工具比如 Photoshop来绘制界面，添加注释来描述行为。然后设计交由工程师来编写布局和行为的代码。某些时候，设计的行为违背了底层命令的需求，工程师不得不再找设计师来解决之。只有设计由工程师完全实现后，重要的用户测试才能进行，通常需要工程师和设计师再来修正，再测试...这个过程重复多轮。

构筑在布局库上的可视化设计工具将使设计师来布局界面，保存为一种能直接被应用程序开发者使用的格式。这个工具再结合属性模型的支持，通过显露约束与保证设计师实验正确功能的界面，就能增进开发工程师和界面设计师的沟通。

了解属性模型库

Adobe专业应用程序设计遵循模型、视图、控制器(Model、view、controller：MVC)模式。模型代表正在被编辑的文档，视图代表了文档在窗口中的显示。控制器是用来修改文档命令的集合。这些命令遵照一种命令模式(参见Gamma, et. al. p. 233)，每个作用于文档的命令都是一个事务。

图二：应用程序中典型命令参数流动

我们大部分的应用程序遵循此图或者此模式的变种。这种模式下，来自预设或用户配置（preferences）或可能的脚本的信息，与目标文档的状态信息相结合。然后这些信息（部分可能由用户直接提供）被用来构筑传递给命令的参数。这个命令之后在文档上执行，如果此事务成功完成（可能由于资源不足或者用户取消操作而失败），命令的设置被送往脚本系统来记录和记录在用户配置（preferences）中。灰色框是命令参数输入处（由用户输入并/或在处理前验证），同时也是属性模型库关注之处。

图三：Edit Text域依赖Popup的状态

上图展示了命令参数处理的部分过程。这是上面用过的clipping path例子的一个描述。信息从一组预设（通常是用户上次选择的）或者脚本读入到系统，并和来自当前文档状态的信息合并。这个信息被传给对话框建立代码（用来建立对话框的域和控制。控制通过某个恰当资源描述或用布局库格式化。）[****STOPPED HERE****]当界面中的控制被操作，事件产生，其他控制随之更新反应验证过的参数。最后，通常是在响应用户选择”OK”，来自HI域的信息被收集，进行最终验证，对话框拆除，参数送出指示处理。当没有对话框中的项没有“相互交谈”，行为可以被编码成附加到每个项上简单验证过滤器（比如，一个Text edit域上的过滤器只接受数字）。更加复杂的过滤器能处理简单区间内的值-或者组合一群HI元素为一标准簇（就像edit text域绑定导一个滑动条）。然而，即使有这些简化，脚本验证代码和散落于HI元素验证代码间仍有重复。需要定制的代码来设置，拆除和管理对话框的交互（在非常简单的情形下，交互可能完全由过滤器处理）

命令接口并不局限于模型化对话框。调色板( Palette）界面和直接操作也创建命令参数。属性模型库也能应用于这些情形中。

虽然这个”简单”的例子不足以说明，互联关系会迅速超过项的数目N，全相联时，有(N²-N)直接联系。一个对话框带来吓人的复杂度。例如，Photoshop6中的层特效对话框有超过250个元素。虽然元素间的互联会在某种程度上受限，最终的复杂度仍旧显著。一个图像尺寸的对话框只有一些元素但却是全相联的。带来几页的逻辑，尽管数次Photoshop发布中持续努力，仍旧成为一个不断的bug和bug修正的源泉。即使最仔细地编写，这些修正不断地创建其他缺陷。

所有基于事件系统的代码紧密和应用程序框架及应用程序文档模型绑定。这种紧耦合禁止代码在其他应用程序中重用。

模型化控制器

在更复杂的情形下（比如滑动条和Edit text域联系），导致三角循环依赖。进一步分析显示循环由于HI控制提供了两个功能——既输出显示又输入。通过逻辑上分离这两个功能，循环依赖被破坏。大部分事件句柄，脚本验证，设置和拆除中的逻辑现在压缩成单个”模型”。剩下就是一个HI控制扮演视图和控制器角色的传统的MVC模式。这在图四中描述。被模型化的是传给命令的参数。这个模型和绑定到它的HI独立，给予设计师改变布局和选择HI元素的巨大灵活性（而不需触动底层模型）

图四：Adam分隔了HI控件同时扮演的视图和控制器角色。

合并成单一逻辑减少了系统的复杂性（从 N²-N到N）。更多的，脚本验证和对话框验证的逻辑可以共享，因为只存在单一含系统状态的模型——之前单独的被编写现在可以被封装成应用在整个系统上的简单“规则”。比如，任一HI设计师告诉你，给出界面项当前状态时不产生影响，该界面元素视觉上应该禁用。在一个典型事件处理系统中，没有一种方式测定什么是有影响的，什么是无影响。借助Adam，这个规则可以在应用程序中一次表达而非在每个对其他元素启用状态有影响的元素中表达。

Adam模型系统在概念上类似一个传统的电子表格。单元格用文本标识符命名，而非组织成行/列布局，构成一个“电子表格”。一个“电子表格”类似C语言的结构体，不同的是数据成员（对应单元格）可以有表达式附加之（这样，当依赖成员被修改时，数据成员被再次计算）。依赖关系引擎是双向的，允许查询一个给定的状态如“哪些输入单元影响输出单元”。这类查询用来驱动控制器内的开启状态(如输入不能影响任何输出，附加在那个输入单元的控制器被禁用)。反向的依赖关系查询也被用来作不变量测试，使得引擎能报告哪个输入单元造成不变量违例，而不是报告发生了一次不变量违例。

Adam & Eve 构架

总览

图五：Adam和Eve的基本组件，以及它们的互联方式

两个主要的组件：解析器和引擎。Eve1有其（松散的）基于C的语法。Eve1的解析器和引擎合一，使得很难提供其他可选语法。对于Eve2和Adam，引擎彻底与解析器分开，通过提供解析器来支持其他语法。可选地提供一个格式化器来从Eve2 DOM和Adam表格直接创建。最明显的“其他语法”是XML，许多其他形式也可（HTML，经典Eve，CSS，JavaScript，Java Swing及平台资源）。

Adam表达语言(The Adam Expression Language：AEL)

AEL开发出来作为Adam和Eve2基本表达语言。其语法大量地从Eve1中借鉴（继续“C风格”）。基于XML的语言被考虑过，但由于其太冗长、不便阅读而最终被抛弃（即使依赖一个好的可视化编辑器，基于文本编辑仍是某些用户的偏爱）。然而，基于XML语言作为一种选择没有被完全抛弃。

AEL开始被设计为支持来回编辑(round-trip editing)和良好错误报告。新解析器是LL2的并有一个简单的词法分析器。注释被组织到语法中（而不是被词法分析器作为空格无视掉），从而支持可视化编辑器的来回编辑（round-trip editing）。

Adam

前面提过，Adam表格(sheet)类似C结构体。一个表格由单元格成员组成。单元格成员可以是这些类型： input, output, interface, logic, constant或 invariant

开头例子是一个表格指定(specification)：

sheet clipping_path
{
output:
result          <== { path: path, flatness: flatness };

interface:
unlink flatness : 0.0 <== (path == empty) ? 0.0 : flatness;
path            : 1;
}

[开放问题 1] invariant(不变量)是一个类型为布尔型的输出单元格。附加到一个invariant的句柄在invariant计算值为假时调用。句柄被提供给invariant的名字、invariant依赖的一些输入单元格。默认句柄抛出一个类型为adam::invariant_violation()的异常（不变量违例异常）。

为了理解Adam做到的，考虑以下语句：

unlink flatness : 0.0 <== (path == empty) ? 0.0 : flatness;

作为C++语句，上述语句意味着：

当执行时，计算path的输出，flatness输出赋值为0.0或flatness的输入

作为Adam语句，意味着：

一旦path的输出被修改，flatness输出赋值为0.0或flatness的输入
当path的输出不等empty，同时flatness的输入被修改，更新flatness的输出

更多的，进行了以下查询：

给出一个当前状态，哪些输入单元格对输出单元有效？
给出一个当前状态，flatness 输出依赖那些输入值？
flatness的输出当前依赖哪些值？其中哪些最近更新？

与上述语句相关的行为：

flatness的输出被修改，升级显示
设置和flatness的输入相联的edit text域的启用状态（根据flatness的输入是否影响任何输出值，当状态改变时更新）

表格中的语句相关度越高，Adam表达相对于传统事件模型更加有效。上面的语句代替了Photoshop 中一个57行（15个语句）函数。

表格的实例是一个写时复制（copy-on-write：COW）对象，从而支持事务操作。易于实现撤销，当出现不变量违例时重置或者返回。[注意：认真考虑下，COW也能在对话框内实现多次撤销]

[开放问题2]表格中的输入单元格可从字典类型载入，输出单元格可被提取为字典类型。这个功能可用来实现载入，保存，“收藏夹”和预设，也是绑定表格到应用程序的一种可行方式。

修改表格的输入单元格触发一次再计算过程（可通过设置一个复杂的状态来避免）。依赖此改变值的任何单元格被再次计算。如果此过程中一个不可变单元格计算后返假(false)，则抛出异常（含违例的invariant名，及其他触发此违例的单元格）。[注意：提供不变量依赖的所有输入单元格是有用的。提出“弱不变量”(“weak invariant”)的概念也是有意义的——停止传播并导致任何更多的依赖输出单元格到无效状态。需更多经验来看到底需要什么。]

逻辑单元格(Logic cells)用来作中间计算，其状态既不可被读也不可由表格之外设置。

接口单元格(Interface cells)用作输入和输出。通常，接口单元的输入和输出值相互同步。可以在接口单元格前加"unlink"关键字，来阻止输出值不向后传播给输入值。

[开放问题3][开放问题4]界面有时依赖”最近发生的”这个概念。例如尺寸可变对话框中的一个显示“宽度”Edit text域，可能要么显示用户输入的宽度值，要么显示用户改变高度时（译者：锁定宽高比改变尺寸？）计算的值。为了支持这个概念，Adam维持一个随着每次再计算而不断增加的创建计数(generation count)。在再计算时，修改单元格同时打上创建计数戳。

虚拟机

虚拟机是一个用来计算表达式的简单的栈机器。一个表达式归约成一个代码序列（每个代码代表一个值或操作数）。值被压入，操作数应用到栈顶的值上，压入结果。一个中缀表达式能通过重载操作符从序列中再构成。这对来回编辑（roundtrip editing）有用。概念上，AVM（Adam 虚拟机）类似FORTH或者PostScript语言并支持压入一串代码序列为一个值。

在Adam中，依赖关系通过执行语句时监视单元格查找来追踪。查找在实际执行时被延后。简化的布尔量和条件操作符把表达式作为参数，故被标记为依赖某个表达式的单元格实际上依赖表格的当前状态。

[开放问题5]也许需要延后计算（知道函数请求计算）传给函数的参数。虽然可能让作用域规则更加复杂，但允许函数编写时，有条件地使用其参数，从而便于跟踪依赖关系。

绑定

Eve2的关键特性之一就是绑定HI元素到Adam表格的某单元。绑定通过各种绑定属性(bind attribute)来实现。绑定属性的值是Adam单元格的名字(name，译者是一种AEL的类型)例如：

check_box(name: "Check this", bind: @check_this);

名字也可用来绑定其他属性（译者：而非绑定属性）到表格。例如：如上例check box的名字可由用户设置，如下编写：

check_box(name: @user_name, bind: @check_this);

指导(Guides)

指导（Guides）是Eve1中label_width和 top_inset属性概称。在Eve2，指导能处理跨层次的联系，允许n列对齐和基线（baseline）对齐。很多地方，指导是自动的，对用户不可见（由客户端代码设置，由引擎计算）。[注意：当前存在一个找到和谐的指导的好算法。该算法对位置计算不成熟，但初步实现应该能达到“比Eve1更好”的目标]

动态计算

改变视图尺寸（或由于用户拖动边界，或响应内容/状态改变）,极为类似带有附加约束条件（比如视图的最小尺寸）地布局视图中的内容。Eve1开发后，认识到它也能用来控制改变尺寸逻辑。唯一的问题是Eve引擎和解析器混杂在一起，故不能某次程序改变后不能调整布局。Eve2分清了结构，提供了调整属性和强制布局再计算API。

外边区(Outsets)和容器几何

在Eve1 外边区(Outsets)被用来保证有足够的空间来绘制阴影、默认高亮、和操作系统控制的“溢出”。一些工作成果：根据外边区来调整尺寸和项的位置。然而这个逻辑当前是有缺陷，会导致不合适的外边区以及项不合适放置和尺寸。修正这个缺陷，尤其是还要配合指导，将会给引擎带来巨大的复杂性。然而恰当地使用，外边区应该不会影响项的位置和尺寸，但给对话框外观带来视觉上的瑕疵。更多的，outsets被用来让空白（如留白(margin)或项之间的控件）“吸收”。Eve2正确地在布局之后的后处理（post-pass ）中应用外边区。如果尺寸和位置的调整是必要的，一个诊断信息会被输出，但布局不被改变。

Eve1也没有容器边框的视觉几何的概念；边框的留白调整为包含边框。Eve2增加了边框和内边区(inset)(与Eve1的inset的概念不同，Eve1的inset成为缩进(indent)更合适)的概念。客户端代码得益于此，能够容易地指定容器的几何（代码设置一个固定的边框宽度而不再是添加边框到留白中），并能在后处理中更好的侦测不合适的重叠。

库的整合

ASL的与客户端代码整合相当直观。因为ASL不依赖继承整合到客户端代码中，整合过程不过是添加支持代码而非转换已有代码。图6绘制了一种可能的整合ASL到客户端代码的方式。

图6：ASL代码整合和客户端支持代码

ASL代码与客户端代码存在清晰的边界，支持代码用来绑定ASL和客户端。橙色框部分是客户端需要实现的。绿色框由ASL提供，蓝色框由代表操作系统例程。

这个处理过程起始于Adam和Eve界面(比如对话框)描述定义。客户端提供读取这些定义的代码，把它们送给Adam和Eve的解析器。解析器应该和其他一套另一边外的支持代码互动，发出合适的信息给Adam和Eve。也要注意到，解析器到引擎支持代码可能与控件集支持，代码互动（在初始控制、窗口和类似的）。Adam和Eve在它们提供的数据上执行，把结果输出给控件集支持代码。代码将转换来自两个引擎数据和参数为操作系统可用的信息。与操作系统相关的部分应该在客户端支持代码中实现。当OS调用带着通过事件和数据返回到客户端，客户端支持代码将会把合适的信息发回给Adam和Eve。Adam和Eve将升级必要的参数，并向客户端支持代码发送通知（回送重要的信息给OS，比如新的控件值）。这个OS/客户端/ASL/客户端/OS周期随着用户与界面互动不断重复，也是整合了Adam与Eve的“事件循环”(“event loop”)模型。

大部分客户端整合代码非常简单。最复杂的代码片段是控件支持代码集（作为Adam和Eve，他们相应的解析器以及OS一起的回调函数)。某个给定例程的代码通常只做过滤和翻译数据，再把数据路由到合适的目的地。客户端代码最复杂的处理过程应该在此模型之外。毕竟，这个代码是处理过程中构建参数的方式；这个处理过程应该与此代码无关。

附录——其他开放问题

当前Adam类型不严格。可能需要申明单元格强制为某类型。如果这样做，一个限定词“optional”将被添加来指示域也可以含”empty”。

研究XForms。结构化表格和表格融合。

附录——语法

此文档的语法用EBNF（扩展巴克斯范式表达 Extended Backus-Naur Form）记号。EBNF在ISO-14977标准中定义。可从ANSI网站花$38.00获取（PDF）。最终文档草案免费在线获取。

目前前有四个语法。在下文件中可获得：

Adam语言参考
Eve语言参考
表达式参考（描述词法和表达式语法）

附录——未来的点子

可视化编辑器

布局库和属性模型库的可视化编辑器将成为ASL的巨大补充（Begin例子程序正在这个方向上进化）。最终，它将有两个编辑视图（大纲和预览），但预览窗口也支持直接操作。也许提供源代码视图（ala GoLive）。

一些简化跨平台预览的支持将被提供。组合入的属性模型库将提供活跃仿真。

记号字符串系统能分离应用程序中需要地区化的（译者：比如为中文用户显示中文字符串记号）。然而，剩下的一个主要问题是测定字符串的上下文来作合适的翻译。提供这个上下文信息是编辑器的目标（以“查找字符串...”命令形式）。从而能够在HI中放入合适的字符串。在验证信息情形下，HI在带有触发信息的属性模型规则的上下文中显示。

Eve2考虑中的特性

一个直接操作Eve层次结构的API对于动态视图有用。绑定某值到视图中节点允许某些简单地直接设置值——但不允许对结构操作。Eve层次结构的Xpath接口应该是一个待添加的有用特性。

布局的最大尺寸限制将对调色板非常有用。当前可以设置一个有些用的最小尺寸但需要为地区化进行手动检查和调整。一个最小的解决方案是：当尺寸约束违反时，允许一个可选的视图定义。其他选择是优雅退化布局（打破指导链接，格式化选项）来强制一个对话框来适合。组合这两者很可能移除大部地区化的工作量。

Eve前一实验版可以为单词绕回文本调整布局。这个实现起来相当直观，很可能会包含在Eve2的发布中。

直接指定菜单项在Eve1中办不到（数据集不够丰富，不允许定制容器布局）。在Eve2中，客户端有多种方式支持此特性。

当前Adobe应用程序，正在允许应用程序层上自定义热键。如此特性扩展到对话框，也许需要Eve或记号字符串系统支持之。然而此时，没有如何实现这样特性的建议。

墨羽硅