3.35的Movable Type发布快一个月了，由于仅涉及到一些功能性的升级，跟语言界面有关的词条没有任何更新，因此一直未制作3.35版的简体中文语言包。今天是长假最后一天，抽了一点时间修正了3.34简体中文语言包中的部分词条，现与大家分享，顺祝大家调整好状态，尽快投入到长假之后的工作中。

Continue reading»»

在线的VISIO工具

看到有人说起BBS和Sina的区别，以及BBS或某些社区上经常出的一些事，就想谈一下这个管理问题。不过记不起来以前是不是讲过，依稀记得说过，所以就叫再说。

BBS，主要是校园BBS，曾经是一种奇怪的管理形式，至少几十年内在这个社会里是创新的。它使用学校的公共资源，包括网络带宽和电费，有时候还要用学校闲置下来的机器（也许是被站长占有的），管理者都是学生或低级教工，完全无偿服务，过一阵子还要换人，版主也是自主申请，按学期服务。基本上可以说，BBS成了一个自主服务自主管理，没有金钱参与的完全理想化的组织。如果搞不爽了，还可以弹劾仲裁，简直是希腊化的公民社会了。

在这个小社会里，大家共同创造，共同享受，可以说是最早的Internet 2.0形式，虽然是最典型的1.0网络时代的产物。在网友和BBS之间，有个真正的互相联系和依赖的关系。后来虽然一再被赶，这个记忆也没有消失，只要还是个BBS，站方不管是谁，都不能──似乎也不会主动地切断这种记忆。

如果说为什么BBS在华人社会这么流行和有生命力的话，那可能就在于这种记忆，因为华人社会实在太缺乏互相关注了：传统的家族关注已经解体，家庭关注在家族制的阴影下表现得更像是管制，而社会上缺乏互相关注。BBS是填补了这个空白，正如其他种类曾经成功过的组织一样。

当然，这些组织肯定是要消失的，因为它们抢了别人的饭碗。于是就有人来赶走这种BBS，让它生不如死。

我们搞这种东西历史还太短，还没有经验，但可以学习一下西方的先进经验。看书说他们有些交易属于赠于的性质，但还是要付一美元的费用，否则不能成立，不能订立文书。这种态度就很好，就是要形成规则，不要约定俗成，不要自发，而要固定下来。

BBS的管理危机来自两方面，其一是站务和网友出现冲突时的处理，其二是外部同BBS冲突时的处理。这两方面不好处理，都是因为缺乏规章制度，并且是可执行的实际的制度。但同时，又不能成为利益化的公司，因为它必须保持网友的参与，在所有事情上听他们的意见，因为BBS的价值正在于这些网友。

在这一点上，BBS和开源软件一样，是一种自组织的社区，它们也基本上是同一时间起步的。按运行比较好的开源社区的样子，最好就是成立非赢利组织，有固定的工作人员，他们可以领工资，组织可以有收入，但不以赢利为目的，以满足自身发展需要为准，或者干脆就以募捐为主要收入来源。它通常就像是慈善机构，没有很严肃的股权之类的要求。领工资的少数人承担日常管理工作，但整个组织的运行仍然要靠用户和参与者，参与者可以是长期的，也可以是短期的临时的，大多数只是使用，只在关键事情发生时跳出来发言。

这样的组织仍然把用户的反馈和参与当成自己的发展动力，用户提交的反馈，关键事务时提供的投票结果，组织者都认可。这是一种很理想的方式，并且在发达国家都有专门的法律来管理这类组织，在税务上还有优惠，因为它是社会自我服务的一种形式，减免了政府机构服务社会的劳动。

现在在国内成立这种组织的可能性似乎也出现了，但似乎都是名人成立的，像杨受成和成龙的，以及李亚鹏夫妇成立的等等，他们取得的资金是用来医疗等目的，是不是也可以用来支持一个BBS或网站的运作呢？

有了这样的正式的受法律保护的机制之后，对内可以在听从网友意见基础上形成有效管理，甚至还可以有专职人士参与使管理更有效，对投诉弹劾的处理更加迅速；对外可以以法律为武器，有效地保护自己的权利。总之是个比较理想的形式──也许只是个理想化的形式吧。

这可能是 Oracle 在 AIX 平台上最重要的一个潜在问题。

一般情况下，AIX 的逻辑卷前 4k 用于存储 control block (LVCB)，在 Oracle 9iR2 之前，Oracle 软件自动跳过这 4k 而不用。这带来了一个潜在的问题，当 Oracle 的 db_block_size 大于 4k 的时候，一个 Block 可能跨在两个 PV/LUN/磁盘 上(如果做了条带化，那么将总有数据块跨在两个条带上--其实也还是将跨在不同的 PV/LUN/磁盘上。这样当系统崩溃的时候，很有可能造成大量的 IO 不完整，一个 PV 上 IO 写入，另一边可能未完成，启动 Oracle 的时候将会看到 ORA-1578 错误，这几乎是致命的。

为了解决这个问题，AIX 推出了 Big Volume Groups 作为应对。建立 Big VG 后，创建 LV 的时候可以通过 -T O 的参数强制征用 LV 的前 4K 空间， LVCB 的信息保存在 VGDB(volume group describe area) 里面。前 4k 空间被使用的 LV 有了一个新的设备子类型(devsubtype)标记: DS_LVZ，通过 lslv 可以看到。(Oracle 也在 9.2.0.3 之后自动识别 AIX 的新 LV 类型，直接开始使用 LV 的前 4K 空间)

对于 AIX 的可扩展性 VG，则默认创建的 LV 就会 DS_LVZ 类型，不使用 －T O 也是这样子。Big VG 可能只是一个过度类型。

在 IBM 的系统手册中可以看到：

The IOCINFO ioctl operation returns the devinfo structure, as defined in the /usr/include/sys/devinfo.h file

如何知道当前裸设备创建的时候使用了 -TO ? Oracle 10g 的文档中说 $ORACLE_HOME/bin/offset 工具可以做到。可是我居然找不到这个工具。莫非是忽悠人来着? 通过另一个工具可以看到相关信息：

$ dbfsize /dev/rfoo01_pay
Database file: /dev/rfoo01_pay
Database file type: raw device without 4K starting offset
Database file size: 920 8192 byte blocks

要想得到完美的东西太难了， AIX 在 BIG VG 上仍然还有很多问题，目前已知的当属这个“MKLV -TO ON BIG VOLUME GROUPS FAILS TO PUT SOME LV INFORMATION”最为严重--得不到正确的devsubtype 类型，Oracle 则会报告读取数据文件头错误，这个更要人命。 DBA 这个工作，还真是脑袋悬在腰带上，风险莫测。 --EOF--

an infographical movie illustrating the principles of nuclear technology as a slick television commercial for a French energy company.

a short explanatory "behind the scenes" documentary with the movie's designers is available here.

[link: areva.com|thnkx Alex]

an ambient visualization device that controls the watering & feeding of a tree depending on the energy usage & the monitoring of appliances, heating/cooling, and recycling habits. if the user is extremely efficient with energy use, the tree receives nutrients & water, while it will "poison & malnourish the tree, eventually killing it", otherwise.

[link: benarent.co.uk & yankodesign.com|via treehugger.com]

reminds me of spore 1.1 & infotropism & growable data visualization. more eco-visualizations here.

对我这样的农民来说，到北京郊区的农村去感觉比较尴尬，没有太多新鲜感，吃的东西好不如城里，熟不如家里，又要装作城里人享受农民兄弟的服务。唯一的好处是可以在野地里转转。

这回去的响水湖，其实没有湖，顶多算是个池塘，好几处山上是真有比较不小的水流下来，也有点响声，不过水还是直接进了水泥池子用来养鱼了。这地方的小狗小猫都因为陪游客吃饭而养得膘肥体壮。山上居然还有野生的动物，我们就看到了一只大大的山猫在山间小路上散步。

让此行不虚的是爬了一段野长城，就是下面竖着“尚未开发不许攀爬”牌子的那种，并且还走了一条强悍的穿越路线。这条路刚出发时还比较好走，很快进了杂树丛之后就变得没有路了，脚印都要仔细寻找。这是两道岭中间的一条沟，越往上越陡。好在走一阵子就有一个两个塑料瓶出现，说明这地方还是有人走的，还有人把瓶子挂在小树上，似乎是作路标用的。最后几十米的时候几个人都不想爬了，不过最后还是上去了，手上胳膊上都划了不少血道子。

这里的长城不算很破，但实在让人觉得这东西修得没有必要。往南往北都是一道道的山望不到边，没有明显的路，敌人如果不是特种兵的话是绝不会到这里来的，就算来了，这高出山梁几米城墙也绝不会增加什么难度。如果是为了传递烽火信号的话，真是没有必要修这么实在的墙。城墙两边是实在的烧出来的砖，内部是大小石块垒出来的，工程量之大足以让人佩服明帝国的财政实力。有些地方城墙面对的山崖只有不过一米的距离，却也按规矩修了箭孔，实在不明所以，难道还要朝山崖射箭吗？许多箭孔上又刻出三道或五道弧线的花样，勾缝的灰泥也认真地抹出尖棱，感觉这些明朝民工还挺有闲情的。有一个地方让人觉得不专业，就是两道砖砌的墙上居然老长的距离不加横砖，成为两道独立的单砖墙，只在很远的地方加一块横砖，于是现在可以看到很宽的缝，但几百年过来居然多数还立在那里，真是不容易。

走到城墙上高处的烽火台上，就看到不远处就是一条比较大的路，于是避免了从杂树丛中滚下山来，很轻松地走下来了。

有一个很好的通讯录管理功能对于SN用户的扩展来说很重要：最近使用 LinkedIn多了起来，因为LinkedIn提供了直接通过web界面将GMail，Hotmail，Yahoo Mail的通讯录导入功能，然后可以从导入的联系人中识别出已经在LinkedIn注册的用户，并批量发送链接邀请。通过这三个邮箱的导入：LinkedIn上将联系人由几十人扩大到了200多人，FaceBook上也有类似功能：导入邮箱通讯录后，联系人增加了40多人。 用户之所以允许LinkedIn和FaceBook进行基于通讯录的病毒式营销原因有以下几点： 1 方便：基于web的导入比起让用户从web邮箱选择CSV格式导入再上传要方便很多； 2 信任：用户对网站服务隐私保护的信任，这2个导入服务都不存储邮箱帐号，密码； 3 定向/可过滤：从导入的联系人中选择已注册本服务的用户比直接向所有导入的联系人发送邀请通知要聪明很多：因为导入的邮箱联系人中有很多是网站的客服帐号，邮件列表地址等不适合发送的地址，通过已注册检查可以很方便的过滤掉这些地址，减少不礼貌的Spam；