Fringe S02E08中一个Observer绑架(或者应该说拯救)他一直在观察的女孩的过程中,警察向其射击,企图阻止他。这一幕被附近的一架普通监视摄像头所捕捉,Fringe小组逐帧回放,发现Observer徒手抓住了射来的子弹。以下为相邻的两帧:
帧1
帧2
美国警察常见配枪Glock17使用9x19mm帕拉贝鲁姆弹,初速1400英尺/秒左右,Observer在约5米外遭遇近距离射击,他要抓住的是约v=400m/s的子弹;一个成年男子的手掌长度约190mm,从帧1目测估算子弹距离手掌约d=150mm。因此有,该监视摄像头的每秒捕捉帧数:
人眼的分辨速度在30帧/秒左右,是一般电影的每秒帧数,同时也是中国普遍使用的监视摄像头的每秒帧数;一般超过1000帧/秒的摄像机属于高速摄像机,而我们在剧中所遇到的不过是处在一个毫不起眼的位置的毫不起眼的监视摄像头,每秒帧数达到2600+,其成本则可达到中国一般监视摄像头的1000倍。
综上所述,美国非常非常,非常的发达。
如果你现有的装备因为某种离奇原因全部消失,现你有且只有不超过1万元人民币的预算重新配置一套单人用徒步露营装备,你会如何选配?
=============================================
@川西夏季(或太白夏末多雨,或小五台夏末多雨)
1背包:ULA CDT 500克 950元 大件不马虎,个人会选择山寨,不过预算够的话还是上品牌的
2营帐:隧道天幕 1100克 350元 若木杆或登山杖容易取得,则省却帐杆减少到650克
3睡袋:保定500克鹅绒无头 800克 550元 无头爱好者,选择面窄只能保定了
4防潮垫:加厚泡沫1米5剪裁 150克 30元 坚持选便宜货,用起来不操心
5鞋靴:Chameleon3 Stretch 900克 1100元 试一试贝尔的选择
6登山杖:无 0克 0元 一直在尝试,从未成功适应,由于基础装备缺杖,因而天幕采用隧道式
7主力光源:Photon Freedom 10克 150元 生火为主,日落前扎营,Photon支援做饭和就寝
8速干衣:长袖T恤 200克 100元 脖子短,衬衫太纠结,再速干也难受,圆领王道
9速干裤:凯乐石 270克 150元 没用过贵的,也没发现便宜的有什么短板
10冲锋衣/上衣:巴塔Rain Shadow 323克 1300元 一旦拥有别无所求
11冲锋裤/雨裤:迪卡侬 100克 80元 轻便够用
12保暖上衣:淡淡排骨 320克 850元 手里最贵的HW是一个防水袋,支持淡总不能光靠防水袋
13炉具:DIY酒精炉 10克 5元 生火为主,酒精为辅,全程酒精保守携带量500克西餐为主
14主力炊具:步林G020 180克 80元 一深锅一炒锅兼容中餐
总价格:5695元,剩的钱入其他一些必备散件如水具,以及GPS
=============================================
当然最好是能拿1万的预算加一身破烂环游中国,找个各位离奇失踪的装备,一下子丢了这么多,随便找回几件就赚了,恩恩……
自从Google Apps推出的那一天起,这一问题就困扰着无数人。
Google Apps提供了一个使用个性化邮箱后缀的绝佳途径,它涵盖了基础的邮箱、文档、日历以及大量其他的第三方应用。但是,它仅仅是Google账户所能提供服务的一个子集,为了不错过如Reader、Voice、Wave、Buzz等这样的优秀应用,我们可以将带有自己域名的Google Apps账户注册为Google账户(这里我们忽略Gmail账户,Gmail账户是一个完全集合的Google账户,但用Google Apps账户注册的Google账户,如不绑定Gmail,则不是一个Gmail账户)。于是问题来了——
a) 上面那段括号已经把你搞糊涂了,你决定退订我的博客;
b) 尽管账户是同名的,并且你也可以设置成同一密码,但他们不是一个账户,他们在不同的系统中,他们可以有不同的密码;
c) 由于b)的原因,同名的账户有各自独立的数据,即使是同一种服务,如联系人、文档、日历等;
d) 作为email的基础,你一定得在Google Apps中维护联系人数据,各种移动终端如WM、Android等在同步过程中,也会首选读取Google Apps联系人,可是,这些精心整理的联系人,却无法被Google账户的服务抓取,你不能在Google Reader里分享,不能直接用Google Voice呼叫,Buzz一片空白;
e) 还好,你用email接收到的文档和日历邀请,都能正常进入Google Apps账户,不过那些链接点击分享的文档,则会进入Google账户,Chrome同步作为Google账户的服务之一,则理所当然的使用了Google账户中的文档;
f) 按照Google的承诺,如果Google Apps启用Buzz,因为联系人的问题,或许Google Apps将不得不加入Profile服务,并且其数据也与Google账户的Profile分立;
g) 如果在Google Apps的后台,你以为你可以清楚的说出有哪些服务,那么你错了,你一定想不到Google Apps竟然提供Maps服务,在手机Google Maps客户端上登录,系统将认证你的Google Apps账户,是的,你得重新维护一套本已在PC上精雕细琢的个人地图,以备外出使用;
h) 总之你是要用括号来把我搞糊涂,无论是闭合的还是半开的,你决定退订我的博客。
这些困扰已经将大量的个人Google Apps用户赶回了Google账户,并且让我的博客订阅量屡创新低。
借着两会的春风和杭州的一场春雪,坚持了很久的旧IP终于被洗刷一空,赶紧更新你的hosts
128.121.145.252 twitter.com
128.121.145.252 www.twitter.com
QQ邮箱的POP登陆被视为一次客户端登陆,因此使用Gmail收取QQ邮箱带来的副作用,是每次上QQ都提示上次登陆地点为鲜红的美国:
另一个副作用是,由于Gmail在美国持续不断的登陆QQ,腾讯将拒绝该QQ号码在任何非美国IP下的密码更改请求,除非你比Gmail登陆的更疯狂。
真是拗口,简单的说就是让Google Apps中的Google Talk可以和Google以外的普通Jabber帐号通联,还是很拗口......
Google Apps正不动声色的成为Google的另一大巨额收入来源,使用的人也是越来越多,尤其是随着Docs和Talk的加入,加上原来的Mail和Calendar,实用性空前高涨。但是Google Apps中的Google Talk只能添加组织内的或Gmail联系人,添加Google外的联系人会一直显示invited没有反映。
Google官方文档提到,为了和网外帐户聊天,一组SRV记录必须被设置在DNS中:
_xmpp-server._tcp.gmail.com. IN SRV 5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp.gmail.com. IN SRV 20 0 5269 xmpp-server1.l.google.com.
_xmpp-server._tcp.gmail.com. IN SRV 20 0 5269 xmpp-server2.l.google.com.
_xmpp-server._tcp.gmail.com. IN SRV 20 0 5269 xmpp-server3.l.google.com.
_xmpp-server._tcp.gmail.com. IN SRV 20 0 5269 xmpp-server4.l.google.com.
_jabber._tcp.gmail.com. IN SRV 5 0 5269 xmpp-server.l.google.com.
_jabber._tcp.gmail.com. IN SRV 20 0 5269 xmpp-server1.l.google.com.
_jabber._tcp.gmail.com. IN SRV 20 0 5269 xmpp-server2.l.google.com.
_jabber._tcp.gmail.com. IN SRV 20 0 5269 xmpp-server3.l.google.com.
_jabber._tcp.gmail.com. IN SRV 20 0 5269 xmpp-server4.l.google.com.
根据Pidgin的Debug窗口的链接反馈信息来看,另外一组SRV也是必要的,尽管官方文档没有提到:
_xmpp-client._tcp.gmail.com. IN SRV 5 0 5222 talk.l.google.com.
_xmpp-client._tcp.gmail.com. IN SRV 20 0 5222 talk1.l.google.com.
_xmpp-client._tcp.gmail.com. IN SRV 20 0 5222 talk2.l.google.com.
_xmpp-client._tcp.gmail.com. IN SRV 20 0 5222 talk3.l.google.com.
_xmpp-client._tcp.gmail.com. IN SRV 20 0 5222 talk4.l.google.com.
NAME.COM和GoDaddy均提供了添加SRV记录的功能,GoDaddy的DNS记录管理界面很易读,而name.com则显得过于简陋,他们没有将SRV的几个参数如端口号分开,导致我走了很多弯路都没有设置成功。最后和support沟通了几个来回,才终于找到正确的设置方法:
Record Type: SRV
Record Host: _xmpp-client._tcp.yourdomain.com
Record Answer: 0 5222 talk.l.google.com
Priority: 5
以此类推。关键在于record answer的设置,使用name.com的同学可以参考。大概几分钟后,DNS记录就生效了,尝试添加网外的机器人如twitter@twitter.com,不再显示invited,而是立即上线。
你自认为很有想象力吗?del.icio.us的出现彻底击垮了我们对于想象力的过度自信,往往在最不起眼的细节上,想象力一跃成为杀伤力,并且变的难以企及。
是的你猜对了,我不是在谈论bookmark sharing,而是domain hack。在全球域名资源越来越紧张的时候,炒米者不断翻新各种组合,有的没的,牵强的附会的;而第一个富有想象力的将域作为名字的一部分的人,就像在数码商场闲逛的Jobs一样,对于世界不屑一顾但却能创造世界,这就是想象力的威力。
说了这么多,无非是想证明,我是一个没有想象力的人;相信你也是。因此,为了玩一把domain hack,我们可以使用一些现成的工具,如Xona的Domain hack search utility。即便如此,我还是很难在搜索框中作出一些想象,除了把自己的名字往里输。
这时你还需要一些运气,因为你不叫胡锦涛,你也不是很黄很暴力。michaelyang只能推出.ng的尼日利亚域名,并且贵的难以申请。于是,我放弃在TLD上作文章,而将名字放在前面,于是有了mich@elyang.org。看到了吧,elyang.com都没有了,对于想象力,我彻底绝望。
在玩了几天CardSpace后,我沮丧的发现php4无法在HostGator上使用Shared SSL,我必须获得独立IP以及一个昂贵的Private SSL,以将InfoCard支持加入Wordpress。但无论如何,我们可以先多了解一下这个方便的认证框架(直到下个月HostGator升级到原生支持php5)。
如果你喜欢没有密码的登陆方式,CardSpace很适合你,也很适合我(至少在TrustBearer将Thinkpad加入列表以前)。尽管支持CardSpace的网站不多,但MyOpenID使得我们可以在所有的OpenID网站上使用Information Card登陆。
这里,我们有必要区分一下,在应用和服务之间传递信息的是Information Card,而CardSpace这个术语是指运行在Windows上的Identity Selector。Identity Selector和Identity Provider(IdP)、Relying Party(RP)构成一个十分类似OpenID的三方认证框架:
在Linus著名的三段论中,技术产生于基本的生存需求,即技术降低了为达到同样的生存状态而付出的成本;换种说法,我们因为懒惰而创造技术。当用户懒得去记住越来越多的密码的时候,类似豌豆或者1Password的服务诞生;当网站也懒得去管理用户越来越多的密码的时候,OpenID诞生;那些指责OpenID将鸡蛋放在一个篮子里的人,恐怕多数还是会在各种账户中使用同一个密码,因为懒惰从来不是错误;如果当我们连密码都懒得记了呢?
为了摈弃密码,我们使用一种可以传送认证信息的加密文件,即客户端证书。熟悉银行业务的人对于客户端证书一定有所了解,这种在上世纪90年代就已经存在的技术,被广泛应用于网络银行以及税务申报系统,但在别的地方却很少见,以至一般人极少注意到它的存在。
那它到底存在么(记住,我们始终将话题围绕在OpenID周围)?如果你是一位MyOpenID的用户,恭喜你,它是存在的,并且它就在那儿。MyOpenID提供了这种称为SSL证书认证的登陆模式,在Authentication Settings下,你可以创建一个证书,这张证书被保存在本地,你可以备份并转移这张证书,你也可以在任何你认为安全的终端上创建任意多张证书。一旦证书被创建,它就和你的MyOpenID账户挂钩,当你在MyOpenID登陆的时候,MyOpenID向你的浏览器索取证书并完成验证,然后将你弹回Consumer。如果你想在你的网站上实现SSL认证支持,这篇HOWTO应该有所帮助。
无须密码的登陆过程给人的体验是很神奇的,由多至少的量变效应远远不及从有到无的质变。Microsoft在探索认证框架的时候,也创造了一种沟通用户和联机服务的系统:CardSpace。CardSpace用个人信息卡代替证书,在用户和服务之间充当信使。除了完成认证外,CardSpace还能同时向联机服务发送卡上存储的信息,因此它更符合一个账户系统的需求。
在被原生支持的Vista中,CardSpace拥有和SSL证书一样友好的用户体验。因此在去年上海那次OpenID交流会上,我曾夸张性的提出CardSpace将击败OpenID(估计没有人记得了),但那里的人是为了OpenID而去的——就像你在Joomla论坛提问是Joomla好还是Drupal好无法得到客观的答案一样——没有人理会我。
事实上,CardSpace没有击败OpenID,而OpenID也没有令CardSpace消失,微软在认证领域的努力使他们紧紧跟随OpenID而没有被抛下。如今,MyOpenID(是的,又是MyOpenID,我一直都坚信自己一年前在wiki中所作的判断)将CardSpace也纳入其中。还是在Authencation Settings页面上,你可以发现添加Information Card的小节,通过绑定信息卡,来体验一下不用密码的感觉吧。更早提供CardSpace登陆的OpenID Provider是SignOn,不过JanRain却率先公开了实施CardSpace支持的Python代码,而LinkSafe则神奇的成为一家能用Information Card登陆的i-name注册商(他们同时还是历史上第一个尝试提供免费i-name和i-name托管转移的商家)。
凭借SSL和CardSpace,MyOpenID的用户黏度空前高涨,我实在找不出任何使用其他OpenID Provider的理由。因为对于像我这样时刻携带本子的人来说,证书式认证是抛弃密码的良好解决方案,但无论SSL还是CardSpace,他们最大的问题是不便携:他们是用来在受控终端上使用的,在公共终端或临时在另一台机器上登陆需要繁琐的备份导出过程,这简直是一场用户体验灾难。
那么,除了摈弃密码,另一个方案或许更有前途,那就是替换密码。这方面已经作出尝试有TrustBearer以及更早的爱沙尼亚eID,他们使用更为便于携带的智能卡或USB令牌作为密钥。其中我更为看好TrustBearer,因为在最初的支持列表中,我们看到了指纹识别器,用无法抛弃无须记忆的指纹作为密码,将懒惰式登陆推到极致。
在各种动作或者科幻大片中,我们见识过一些超级安全系统,往往是射频、虹膜、指纹等多重认证,对于安全要求不是很高的普通应用来说,没有密码也是必然的发展趋势,因为懒惰,从来都不是错误。
前天晚上从永定门归来,前往Pandy家的途中,R66突然抽风,计算目的地距离为400多万公里,预计在100万小时后到达。
我在大约9点走完这段星际之路,并且我只要再花上走20次的时间,就足够在下次火星近地点登陆,而非150多年以后。
几天前,Andrew在Google Groups中发布了DotNetOpenID 0.1.1,包含了一些新的特性和安全更新:
听BD1OO讲课,风格很积极,完全不会想到无协是一个办事效率低下的组织。但我们在评价别人的效率之前,起码得弄清楚他们到底在做什么。
你可以在很多地方听到对于效率的抱怨,最容易的便是银行窗口,每一个排队的人都会不断的指责银行工作人员业务不熟练,作风拖拉。如果你在春运时期排队买过火车票,也会有类似的体验,几乎所有人都认为售票员处理之前的旅客动作生疏操作缓慢,而到自己这却三言两语就敷衍打发了。
一方面,这是人的一种自我心态,但最重要的还是由于信息的不对称导致的。你并不了解对方在做什么,你会主观的想像他的行为模式,用自己片面的体验来决定对方的动作和应该有的效率,犯了根本性的错误。
做明显的证据就是在银行排队,你听到的很多抱怨并没有多少深度,多半内容就是诸如"他怎么动作这么慢"、"处理一个人也就几分钟我都等了几个小时了"之类。显然,抱怨的人缺乏对银行业务的认知,主观的认为每个人办理的事情最多就是开个户要不了几分钟。
尽管不能否认一个从报名到考试再验机最后拿呼号的考试持续长达一年这个效率不能说高,但抨击无协的人有多少真正了解他们的具体工作环节呢。就像我不同意Hwua Wong同学将Matlab视为programming一样,永远不要认为自己知道的够多了,否则你永远只是user而非geek。
不仅仅是MT,IDN仍然在很多方面没有很好的被融合,GM的api key就是一个例子,这一问题已经提出并被开发人员认知有一年了,但现在还是没有看到完美的解决。
GM为第三方使用API提供了一个key,这个key和域名绑定以防止滥用。如果申请key的时候输入的是IDN域名,Google不会用punycode编码,而是进行unicode转换。转换后的IDN是一串百分号字符,被浏览器识别后会自动转回punycode或unicode。
为了至少让一部分浏览器工作,我们直接申请punycode形式的域名,Google则正确的生成一个可以在IE6或FF中有效的key。同时,IE7被改写而原生支持unicode,此时的key因为不匹配而无法正常显示。
兼容IE7的一个dirty hack的方法是使用iframe。在IDN所属页面中嵌套一个非unicode域名下的页面,并使用匹配这一域名的key。
在路过济南的时候,发现济南中心地带的路都是经纬命名,如我第一天住的旅馆位于经七纬十二。中国历史悠久,地名路名千奇百怪、种类繁多,但多数有渊源的路名字起的都比较有文化味道。所以当时觉得这种用经纬作路名的方法明显是现代人为了省事起的,而且经纬倒置。后来请教济南的同学,他表示路名很早就有了,至于多早他也很模糊,而缘何经纬弄反,就更说不清了。
刚才偶然看到中央四套一个关于济阳的记录片,谈到经纬路的问题,才知道了大概。
经纬的来历说法不止一个,第一个不是很可信但作为民间流传,倒是很有趣。据说当年占据济南的一个大军阀,十分自大但却没有文化,他本想给路起名流芳百世,结果搞错了经纬的方向,经路为横而纬路为纵。第二,济南这一带横纵路线长度不一,横向的路长纵向的短,当年济南纺织业发达,人们就参照布的说法,经长纬短来命名。
总之,经纬倒置是有由来的,并非弄错。至于名字的历史,确实跟我当初推测的一样,十分短暂,大约就是在上个世纪初,才百来年而已。
http://www.openvatar.com/avatar.php博客们最早广泛的接受头像始于 Gravatar ,他们用邮件地址作为用户 ID ,通过插件来实现头像调用,支持的平台相当广泛。内部 Gravatar 和 Openvatar 的调用语法十分相似(几乎一模一样), avatar id 也是一个 MD5 的邮件地址,同时还有一样的 size 和 default 属性。
?openvatar_id=9b2894b2fa12ea24c455f4be9331d3fe
&size=50
&default="http://www.mysite.com/avatar.jpg
还记得去年提到过的爱沙尼亚吗,他们将 OpenID 服务关联到公民身份证中,率先提供了一种使用硬体认证的 OpenID 。现在,不用后悔自己没有生在爱沙尼亚了(即使不为了 OpenID ,那里几乎 100% 的网络覆盖率也值得你重新投一次胎), TrustBearer 实验室最近刚发布了他们自己的 OpenID 服务,集成 TrustBearer Access 套件。
TrustBearer 实验室在安全认证领域有超过 10 年的软件开发经验。这次他们推出的 OpenID 体系十分类似爱沙尼亚的 eID ,通过在认证环节中插入硬体验证来提供强化安全的 OpenID 。更重要的是,由于兼容了现有的认证设备标准,他们的 OpenID 支持超出想象数量的外设种类。从智能门禁卡、 USB key 到指纹,理论上说,所有基于 CCID 的智能卡阅读器、 PIP 卡、 CAC 卡、 Java 卡都可以使用,光是那份已经过完全测试的支持列表就足以令人眩目了。
实验室也提供了自己的 USB key ,称为 TrustBearer Security Key ,价格 40 刀,可在线购买,当然多数人将可以利用已有的设备。
让我们继续认识 XRDS 中的各种元素以及它们能做的事情。
就像前面所说的, XRDS 包含一些称为 Service End Point 的节,它们用来描述服务,包括服务的类型、标识符等,以便应用端去发现和利用,即 discovery 。最初 Yadis 将这个概念带给 OpenID 和 LID ,因为它们都是一种以 URL 为标识的认证机制。从这种 URL 中解析出 XRDS ,那么我们不仅可以使用 OpenID 、 LID ,还可以加入任何其他有用的东西: SAML 、 XDI 、 Feed 、 SIP ……当然所谓“有用”,是得有能利用 XRDS 的应用服务,目前并不多,后面我们可以一一看到。
从协议上来看,所有这些都是可以实现的,无论 URL 还是 i-name 。你已经有了一个附有 XRDS 的 URL ,但 i-name 可以实验的内容更多,因此不要吝惜你的时间,去 FreeXRI 注册一个免费的 i-name 。
那么一个 i-name 的 XRDS 在哪?在 FreeXRI 中我们可以从 Your i-names -> Advanced -> Launch XRI Resolution for this XRI 得到,除了这个的 XRI Resolution Tool 外,一个更为普遍的方法是使用 XRI.net 解析网关,在地址栏输入:
http://xri.net/=my?_xrd_r=application/xrd%2Bxml看到了么,这是我的寄生在 i-name 上的 XRDS 。这个文档比较长,为了看的更清楚,我们使用 FoXRI 插件,这个插件可以视为一种简单的应用,它发现 XRDS 并尝试解释其中的服务(而非使用它们)。让我们至上而下。
<Query>*my</Query>这组新出现的叫支配元素,它们提供一些基本信息,用来控制 XRDS 、缓存和处理错误。
<Status code="100"/>
<Expires>2008-02-13T13:00:05.000Z</Expires>
<ProviderID>xri://=</ProviderID>认证授权及同义元素。针对 OpenID 的回收问题(《没有 MyOpenID 的世界》一文曾提到过), i-name 的解决方案是 i-number 。整个 XRI 解析十分类似 DNS 的运作模式, 而 i-number 类似 IP 地址,它相对稳定不易变化。当一个 i-name 失去的时候,它所对应的 i-number 不会消失;注册人可以将新得到的另外一个 i-name 同义到老的 i-number 上,而失去的那个 i-name 再次被注册后会分配一个新的 i-number。除了 URL 外,用户并不需要知道同义化的数字标识,但应用端应该从同义元素中取得 i-number 作为识别 ID 。如果不这么做,设想一下 myopenid.com 欠费被收回后,下一个注册者一瞬间掌握成千上万个重要 OpenID 的恐怖局面。注意,这并非 i-name 专有的, OpenID 将会采用这一方式来规避回收产生的问题,但现在只被少数网站理解和使用;你可以在 Jyte 上尝试一下,作为 OpenID 应用界的领头羊,他们提供你所知道的所有 OpenID 特性。
<LocalID priority="10">!E1FE.96F8.5841.1FF4</LocalID>
<CanonicalID priority="10">
=!E1FE.96F8.5841.1FF4
</CanonicalID>
<Service priority="1">很眼熟, SEP 来了。除了熟悉的元素和属性,还出现了一些新的,例如 match 属性、 append 属性、Type 元素、 MediaType 元素等。请参考 XRI Resolution ,我们在这只初步理解 XRDS 文档来看看到底它能做什么,更深的内容可以通过阅读规范来学习。第一个 SEP 有一个空的 <Type> 元素。 FoXRI 认不出这是什么,但其实这是一个缺省的 URL 映射。当浏览器经过 XRI 网关, <URI> 被返回,试试
<Type match="null"/>
<Path match="null"/>
<URI append="none" priority="1">
http://xri.net/=my/(+home)
</URI>
</Service>
http://xri.net/=my我们可以在 XRDS 中建立各种到 URL 的映射,不限于 http ,也可以是 mailto 、 sip 、 xmpp 、 call 等等。而通过 MediaType 来规定输出的类型,我们还可以映射各种资源形式,如 feed
<Service priority="10">想到什么了吗?一个支持 XRDS 的 RSS Reader ,可以从 OpenID 中获得对方的 feed 更新;一个支持 XRDS 的 VoIP 软件可以直接 call 一串 OpenID URL 连接语音通道;一个支持 XRDS 的 IM 客户端则可以将 URL 视为帐号籍由 XMPP 与他人聊天,一个……通过 XRDS ,我们的 OpenID 真的成为了个人标志,一旦有更多的应用加入进来,你的朋友不再需要询问你的 ID ,因为你们在新的服务上,直接就是好友了。
<Type match="null"/>
<MediaType match='content' select='false'>
application/atom+xml
</MediaType>
<MediaType match='default' select='false' />
<Path match="null"/>
<URI append="none" priority="1">
feed:xn--2hvy3a.com/planet
</URI>
</Service>
<Service priority="10">josephcp 在去年六月左右就做出了一个很漂亮的演示,我曾和他一起试验并帮他找出 bug (我不确定多少人试过它),这也是促使我当时想写 XRDS 的动力来源。简单的说:
<Type select="true">
http://josephcp.com/jyte_is_member
</Type>
<ProviderID/>
<URI append="none" priority="1">
http://jyte.com/api/contacts/is_member
</URI>
</Service>
一直都没有仔细制作过favicon,刚才心血一来潮上favicon.cc弄一个去。本来是想直接导入一张图片,但favicon.cc的识别代码不太有效,抓不到重点像素;只好一笔一笔的画了一个,画完是这个样子:
实际效果直接看地址栏,还别说,那个印章倒有点奥运标志的味道。
MT的trackback RDF使用了一对标准注释符"<!-- -->",这个符号有一个问题,就是任何两个连续的中横杠都会关闭它。而MT并没有支持国际化域名IDN,你必须用punny code作为blog域名,而punny code恰恰含有"--"。
你可以在trackbackrdf子调用中为IDN关掉注释,但这样一来如果MT掌管多blog,其中既有IDN又有非IDN,就有点麻烦了。
在社区中寻找答案的同时,只好先从index模板中去掉trackback RDF了。