作者彙整: 星星

谷歌与开源组织合作 在Linux整合大量迷你软件

据IDG新闻服务报道,一位Linux开发者于当地时间本周二透露说,由于看好逐渐兴起的Linux市场,谷歌正在积极准备与开源组织合作,在操作系统中整合谷歌出品的应用程序.
Good OS创始人兼总裁David Liu在美国洛杉矶举行的LinuxWorld大会上说,通过与开发者合作,谷歌可以将其应用程序渗透到更多的低价笔记本电脑产品中,用户可以通过这些应用程序进行诸如网络浏览和电子邮件等基本的应用.

谷歌提供的软件包括Google Docs和Spreadsheet这样基于网络的应用程序以及一些基于本地操作系统的迷你程序.虽然低价笔记本电脑目前还处在发展初期,但是这类产品有望在今后几年呈现爆炸式的增长.
谷歌和Good将进行合作将谷歌的一些迷你应用程序预装在Good即将发布的名为GOS Gadgets 3的Linux系统中,这些迷你应用程序为用户提供游戏和系统查看功能,包括查看电池剩余时间和无线网络信号的强度.Liu还表示,这一系统是专为超低价笔记本电脑设计的,整合谷歌的应用程序也将非常有意义.因为谷歌的应用程序对系统的要求更低,而基于网络的应用对于本地资源缺乏的低价笔记本而言也非常具有吸引力.这款系统还将与谷歌网站上的约一万个小程序建立链接.
除此之外,微软和苹果也分别在其各自的操作系统中整合有迷你应用程序.
Liu说虽然所有人均可使用谷歌的小程序,但是谷歌位于北京的开发人员将会帮助Good将这些应用程序整合到GOS系统中.虽然官方并未正式宣布此项合作,但是双方仍将通力合作保障这些程序的正常运转.Liu表示,谷歌并不希望自己与开源组织之间的合作受到太多的关注.除此之外,谷歌还积极地与 Wine这样的模拟软件进行协作.Wine可以让使用Linux的用户使用微软Office这种原本只能在Windows上运行的软件.而Wine也将被捆绑安装在GOS系统中.
GOS Gadget 3系统还将预装谷歌的Picasa软件,同时提供谷歌Gmail的网络链接.该系统将会在今年九月发布,产品完全免费,该公司正在与电脑厂商接洽,希望能够成为低价笔记本电脑的预装系统.
IDC的研究显示,到2012年,Netbook也就是超低价笔记本电脑的出货量将达到900万台.该产品的先驱——华硕易PC今年一季度的销量已经达到35万台.然而,华硕CEO沈振来却表示Windows版的Netbook的需求量将会大于Linux版的产品.
谷歌未立刻就此发表评论.

时代华纳拟将AOL一分为二

据国外媒体报道,时代华纳今天宣布,将在明年初将AOL的拨号和广告业务分拆为两大部门。
时代华纳表示,通过在年底前分拆有线电视部门和AOL,公司将专注发展内容建设,而不再推动现有渠道业务。今年5月,时代华纳已宣布在年底前剥离有线电视 业务。再加上明年的AOL业务分拆,时代华纳今后将主抓内容业务。
对此,时代华纳CEO杰夫·比克斯(Jeff Bewkes)在一份声明中称:“随着重组的进行,我们将来的主要目标是打造和管理高质量的品牌内容。”

拨号业务分拆后,时代华纳很可能将该部门出售或与其他企业合并。而竞争对手EarthLink上周曾表示,有意在拨号市场展开并购。据悉,时代华纳已与潜在买家进行了非正式接触,其中包括EarthLink。
据分析师预计,AOL拨号业务价值20亿美元至30亿美元。但时代华纳希望能卖出更高价格。尽管拨号业务已持续多年下滑,但目前仍是一项盈利业务。用户数量为870万,而第二大服务商EarthLink仅为330万。
至于广告和互联网业务,据知情人士称,AOL仍与雅虎和微软保持着非正式谈判。其中,与雅虎谈判进行地比较深入,主要方案为:雅虎合并AOL,时代华纳将持有少量股份。

谷歌音乐搜索:仅限于中国内地

谷歌音乐搜索的地址在香港无法访问,返回的页面非常简单,就一句话:抱歉,谷歌不在您所在的地区提供您所需要的服务。显然,知识产权的地域性在互联网上得到了体现……作为一名律师,我当然是欢迎Google的这种合法搜索引擎的。没有秩序的社会,是律师的地狱……作为一个网民,我也欢迎这种安排。谷歌通过谈判,获得了版权人的许可,向用户提供免费的音乐作品,然后与版权人分享搜索页面的广告收益。
这样的安排,在使用户得到免费音乐的同时,保证了版权人的利益……其实,Google英文版也有音乐搜索引擎,只不过它是唱片的搜索……利用Google的 Advanced Google Search Operators工具,有人(并非Google公司)制作了基于Google的音乐搜索引擎,,命名为“Musgle”。它倒的确带来一些更为有趣的法律问题。

在cnBeta上看到谷歌音乐搜索上线的消息。地址是:http://g.cn/music,在中国内地的访问者应当可以见到类似下面的页面:

根据报道,和其他音乐搜索最大的区别是:谷歌音乐搜索搜索到的都是经过唱片公司授权的正版音乐。在我订阅的财经新闻中,也提到Google是在与音乐公司持续数月的谈判后,才在中国内地推出这个免费的音乐搜索服务的。我试了一下,上述谷歌音乐搜索的地址在香港无法访问,返回的页面非常简单,就一句话。

“抱歉,谷歌不在您所在的地区提供您所需要的服务。 “

显然,知识产权的地域性在互联网上得到了体现——只有中国内地的“谷歌”用户才能获得这项音乐搜索服务。这也是我为什么在帖子标题中破例使用“谷歌”而不用“Google”的原因。

作为一名律师,我当然是欢迎Google的这种合法搜索引擎的。原因倒不是出于什么大的价值关怀,而是一个很简单的屁股决定脑袋的理由:没有秩序的社会,是律师的地狱。

作为一个网民,我也欢迎这种安排。谷歌通过谈判,获得了版权人的许可,向用户提供免费的音乐作品,然后与版权人分享搜索页面的广告收益。这样的安排,在使用户得到免费音乐的同时,保证了版权人的利益。想起几年前一次在北大召开的mp3下载法律问题研讨会上(这个研讨会的赞助者是中国的某搜索引擎提供者),弥漫着“要么让搜索引擎分享收费下载的利润,要么搜索引擎就拐弯抹角地找法律空子提供音乐搜索”的空气。相比起来,Google无疑又让人感到了(至少相对于其它一些网站的)“不做恶事”的风格。更重要的是,它宣示了一种既有制度的张力:无论我们多么希望一个Free Culture的到来,这个Culture要成其为Culture,就必须有秩序。

其实,Google英文版也有音乐搜索引擎,只不过它是唱片的搜索,不提供试听,地址是:
http://www.google.com/musicsearch?q

在这个搜索引擎中搜索Jacky Cheung(张学友)的结果截图如下(可以发现都是链接到iTunes的付费下载)

此外值得一提的是,利用Google的 Advanced Google Search Operators工具,有人(并非Google公司)制作了基于Google的音乐搜索引擎,命名为“Musgle”,Musgle可以找到可供下载的mp3文件,点下面的图标可进入:

Musgle

通过Musgle,访问者不能试听音乐,但的确可以下载相关音乐的mp3文件。这种对搜索引擎的二次开发,在技术上遇到的障碍应该不大,不过它倒的确带来一些更为有趣的法律问题。比如:Google是否因此还是难逃版权纠纷?如果Google不必承担责任,那么Musgle的举办者呢?这个问题值得相当精细地讨论——对于这类法律问题,还是那句话,没有概括的“是”与“否”,只有对细节的分析和暂时的答案。这方面的问题,以后有空再谈。在此之前,也希望专业的读者在本文后提出自己的看法(纯粹表达情绪的就免了,呵呵我这里不是天涯)。

Transitional vs. Strict Markup

推广Web Standards的人经常说XHTMLHTML更加严格,当然从某种意义上说是的,比如它要求所有的标签关闭并且所有的属性都用引号。但其实XHTML 1.0还分两种(加上Frameset DOCTYPE的话算三种,本文不讨论),Transitional(过渡型)和Strict(严格)DOCTYPEs。并且HTML 4.01也有同样的文档声明。

从字面上就可以看出来意思:Transitional DOCTYPEs只是为了实现从旧时代到新时代的过渡,而且Strict DOCTYPEs是默认的文档声明, 对构造HTML 4.01XHTML 1.0都适用。

使用Transitional DOCTYPE一般是由于代码中含有过多陈旧的写法,并且一下子很难完全转换到Strict DOCTYPE来。但是Strict DOCTYPE才应该是你的目标。它鼓励甚至有时是强迫你把结构与表现区分开来,把表现层的代码都写在CSS里。HTML 4 Document Type Definition: –

本HTML 4.01 Strict DTD不包括表现层属性和标签,W3C将逐渐淘汰这些属性和标签,您完全可以使用样式表来实现。您应该使用Strict DTD,如需获得表现层属性和标签的支持,请使用Transitional DTD。

Strict DOCTYPE还有一个好处,即可以让浏览器使用它们最严格、(一定程度上)最符合标准的模式来渲染页面。

Tommy Olsson在Web Standards Group的Ten questions for Tommy Olsson一文中很好的阐述了使用Strict的好处:

我觉得,使用Strict DTD,无论是HTML 4.01 Strict还是XHTML 1.0 Strict,远比讨论是用HTML还是XHTML重要的多。它代表了未来互联网的质量。它将结构和表现分开,使得维护一个站点非常容易。

对于刚开始接触web standards和正确的、语义化的结构的人,认清Transitional和Strict DOCTYPEs的区别非常重要。更多详细列表请参考:XHTML: Differences between Strict & TransitionalComparison of Strict and Transitional XHTMLXHTML1.0 Element Attributes by DTD

对于准备向Strict进发的人来说,两者的有些区别很可能会使开发者犯错误,接下来我将会谈到。

Strict DOCTYPEs下不支持的标签

  • center
  • font
  • iframe
  • srike
  • u

Strict DOCTYPEs下不支持的属性

  • align (表格相关的支持:col, colgroup, tbody, td, tfoot, th, thead, and tr)
  • language
  • background
  • bgcolor
  • border (table支持)
  • height (imgobject支持)
  • hspace
  • name (在HTML 4.01 Strict中支持,XHTML 1.0 Strict中的formimg不支持)
  • noshade
  • nowrap
  • target
  • text, link, vlink, 和alink
  • vspace
  • width (img, object, table, col, 和 colgroup都支持)

内容模型的区别

元素类型的内容模型描述了什么样的元素类型实例可以被包含。这一点上,两种文档声明的最大区别在于blockquote, body, 和form元素仅能够包含块级元素,如:

  • 文本和图像不允许直接包含在body中,必须被p或者div等块级元素包含
  • input元素不能直接是form元素的下一层
  • blockquote元素内的文本,必须被p或者div等块级元素包含

将所有的表现都交给CSS,恪守Strict标准

在向Strict DOCTYPEs过渡的过程中,了解每个元素是做什么的比知道每个元素长啥样有效的多。

首先考虑结构和语义,然后再担心表现。

正确使用XHTML的冒险

原文:http://www.456bereastreet.com/archive/200501/the_perils_of_using_xhtml_properly/

作者:Roger Johansson

翻译:Neo (http://www.omemo.net/neo)

修正:JunChen

JunChen注:omemo.net网站似乎已经挂掉,链接都失效了。文章写得非常不错,一直是Best of 456 Berea Street。在这里发布的时候我进行了少量代码上和翻译上的修改,以忠实原著。

我使用XHTML有些年了,但直至去年夏天我才着眼于如何正确使用,那就是说,以application/xhtml+xmlMIME类型来伺服(server)它。虽然我遇到了这些问题,但我知道问题远非如此。就如你即将发现的一样,当你开始使用真正的XHTML,你会遭遇很多似乎细小但让人困惑的问题。

请注意这不是一篇讨论支持或反对使用XHTML的文章。我只是写下我所知道的潜在的易犯错误,并且让你自己来决定自己的选择:HTML 4.01,为所有浏览器伺服为text/htmlXHTML 1.0或者为能够处理其的浏览器伺服为application/xhtml+xml而其他浏览器则伺服为text/htmlXHTML 1.0。否则有些东西会完全不一样。

只有在问题发生的时候,我才有机会去了解和认识这些东西。有些情况下我必须花很多时间来查找问题和求助于其他人,来寻求一个解决方案。但我在其中学到不少东西,我会把我已经使用XHTML后应该知道的都告诉你。

注意我这里提及的问题只会发生在能正确处理application/xhtml+xml MIME类型的用户代理中,而因此XHTML被作为XML。这也可能是这里不提及XHTML的早期使用的原因——很少有人使用这样的浏览器,所以几乎不会有人因只伺服为text/htmlXHTML所烦忧。

今天,实际上把XHTML伺服为application/xhtml+xml正慢慢变得平常。我所知道的理由有两个:

  1. 使用Firefox,Mozilla,Opera,Safari和其他兼容XHTML浏览器的人数增加了很多,所以你不再仅仅为自己和伙伴这样做。嗯。或许你就这样做,当将影响更多人。
  2. 在web开发者之间,对XHTML的真正面目是什么的觉醒越来越多了。使用XHTML已经有多次多时的热烈的讨论,尤其是伺服为text/html的时候。如果你参与了任何一次讨论,你知道我在说什么。

假如你,像我,决定实现某些类型的content negotiation和在传送XHTML的时候使用正确的媒体类型,你需要知道什么能(和将)在你发布的文档中发生,并且知道怎样避免问题的发生。对于对content negotiation同进行content negotiation的脚本例子有兴趣的读者,我推荐你阅读Content NegotiationServing up XHTML with the correct MIME type。还有很多这种类型的文章,但这是我读到的最精彩的两篇。

每一个基本的教程都有一些HTMLXHTML的明显区别:元素和属性名字使用小写,属性值总要用引号。不要使用简化属性,确保所有的元素都有结束标签和没有不正确的嵌套等等。但是,当XHTML伺服为application/xhtml+xml时还需要知道更多东西。

良好的结构是必须的

文档必须是良好的结构(well-formed)的XML(跟合法的(valid)XHTML不必然相同)。就是必须,不是可能。

如果文档结构不好,符合标准的浏览器(当前我知道Mozilla,Firefox,Netscape,Camino,Opera,Safari和OmniWeb——相当多的浏览器除了IE)将会显示错误信息并且以某种方式中止处理文档。

此外,这还意味着不再使用未编码的”&”号。

XML声明可能是必须的

如果要使用UTF-8或者UTF-16以外的变法,必须要XML声明,除非HTTP头已经提供编码。

在HTTP头中是否要指定字符编码有些模糊,Architecture of the World Wide Web, Volume One: Media Types for XML这样写的:总体上,不应该在协议头为XML数据指定字符编码,因为数据本身已描述。

另一方面,XHTML 1.0, Second Edition: Character Encoding写到:

为了让文档使用指定的字符编码,最好的办法是保证web服务器发送正确的头。

就是说,在XML声明中指定字符编码是好的习惯:

<?xml version="1.0" encoding="iso-8859-1"?>

只有五个实体是安全的

只有五个预定义的实体(&lt;, &gt;, &amp;, &quot;, 和&apos;)的支持是有保证的。其他的可能完全被忽略或者直接输出。比如,如果XHTML文档包含如&nbsp;或者&rdquo;的实体,Safari会直接地输出。Opera反而选择忽略未知的实体,同时Mozila家族会认得这些实体并且就像HTML中“如果文档引用公共的映射浏览器伪DTD目录中的标识符并且没有单独声明的文档”来处理。

使用UTF-8字符编码是最受推荐的,让你(几乎)可以使用你需要键入文档的任意字符,不需要实体或者字符编号。如果你不能或不愿使用UTF-8,数字式的字符编号是可以支持和安全使用的。

SGML式注释的内容可能会被忽略

SGML注释(HTML风格注释, <!-- 注释 -->)可能会(并且会)被浏览器当作注释,就算是在script或者style元素内部使用。

HTML中,普遍地把scriptstyle的内容装入注释中,为的是在不认识scriptstyle元素的浏览器中隐藏他们,并且在页面上把其内容生成平白文本。

XHTML中,这样做会引起浏览器忽略掉注释里的任何内容。

在老的浏览器中隐藏scriptstyle的习惯可以追溯到1990年代中期。我的经验是,有如此表现的浏览器是十分罕见的,所以你可以安全地忽略它们,并且停止在脚本和样式中装入SGML式注释,就算你使用的是HTML。

脚本和样式元素的内容也被当作XML

样式和脚本元素是PCDATA(parsed character data,解析字符数据)块,不是CDATA(character data,字符数据)块。因此,在其内看起来像XML的任何东西都会被当作XML来解析,并且会引发错误除非是良构的。

为了在scriptstyle块中使用<、&或者–,你需要用CDATA

  1. <script type="text/javascript">
  2. <![CDATA[
  3. ...
  4. ]]>
  5. </script>

在CDATA里,你可以任何顺序的字符,它们不会被当作XML来解析(除了结束CDATA部分]]>)。

需要以text/html发送的文档中,CDATA部分的起始和结束标签需要注释掉,以便在不能处理CDATA部分的浏览器中隐藏:

  1. <script type="text/javascript">
  2. // <![CDATA[
  3. ...
  4. // ]]>
  5. </script>
  1. <style type="text/css">
  2. /* <![CDATA[ */
  3. ...
  4. /* ]]> */
  5. </style>

如果要确保很老的浏览器隐藏CDATA部分,需要使用更为复杂的方法,像在Ian HicksonSending XHTML as text/html Considered Harmful中描述的那样:

  1. <script type="text/javascript">
  2. <!--//--><![CDATA[//><!--
  3. ...
  4. //--><!]]>
  5. </script>
  1. <style type="text/css">
  2. <!--/*--><![CDATA[/*><!--*/
  3. ...
  4. /*]]>*/-->
  5. </style>

一个更好的办法可能是在发送text/html的文档前使用content negotiation脚本来删除任何CDATA部分。

当然,最聪明和安全的途径是把所有的CSS和JavaScript都移动到外部文件中,但不总是现实的做法。

没有会自动补全的元素

HTML中,假如表格的tbody元素漏写的话浏览器会自动补全,而XHTML不会。如果你没有清楚地添加tbody,它就不会出现。在编写CSS选择器和JavaScript的时候请铭记在心。

用document.write编写的脚本不再工作

XHTML中使用JavaScript,document.write不会工作。Ian Hickson在Why document.write() doesn’t work in XML解释了原因。你需要使用document.createElementNS()代替。关于更多可以在Experts Exchange中的论坛主题中找到。

这也是Google AdSense不在XHTML中工作的原因之一。那些希望以application/xhtml+xml伺服XHTML并且使用Google广告的人,这儿有一个解决办法:Simon Jessey的Making AdSense work with XHTML。尽管有点麻烦,但还是工作了(我在这里也使用了),同时被Google所认可。

引入样式元素

XHTML中,为了兼容定义CSS规则的XML方法,你应该使用XML样式表声明(访问 XHTML 1.0, Second Edition: Referencing Style Elements when serving as XML的XML样式表声明和Associating Style Sheets with XML documents的xml-stylesheet处理说明)。要载入外部CSS文件,我们需要使用style元素,同时应该使用XML样式表声明来引入样式元素。为此,使用id属性给style元素一个分解的标识符,然后在XML样式表声明中引入该标识符:

  1. <?xml-stylesheet href=”stylesheet1.css” type=”text/css”?>
  2. <?xml-stylesheet href=”#stylesheet2” type=”text/css”?>
  3. <!DOCTYPE html
  4. PUBLIC “-//W3C//DTDXHTML 1.0 Strict//EN”
  5.  

  6. “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
  7.  

  8. <html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en”

lang=”en”> 

  • <head>
  •  

  • <title>XML stylesheet declaration</title>
  •  

  • <style type=”text/css” id=”stylesheet2”>
  •  

  • @import “stylesheet2.css”;
  •  

  • </style>
  •  

  • </head>
  •  

    我不知道在实际中究竟有多必要,并且不使用XML样式表声明的话会有什么问题。或许有人会指点我的。

    CSS的应用规则有些不一样

    CSS应用到body的性质(property)并不应用到XHTML的整个文档。最值得注意的是应用背景颜色或者图片。在HTML中,应用到body元素的背景将会覆盖整个页面。在XHTML中,你必须同时样式化html。在Juicy Studio的CSS body Element Test中有这个行为的演示。

    XHTML中作为CSS规则的元素和属性名字是大小写敏感的(而且必须是小写的)。避免问题最简单的办法是,不管在HTML,XHTML还是CSS中所有东西都保持小写。

    有挑战,但不是不可能

    当我开始为兼容的浏览器伺服XHTMLapplication/xhtml+xml时,在作出决定前假如我能读到想这篇一样的文章,或许我的头痛可以减轻不少。我甚至考虑使用HTML 4.01 Strict。虽然如此,我还是从经验中学到不少,而学习总是一个好东西。

    正确地使用真正的XHTML,十分希望这篇文章能为你提供一些更有用的信息,并且可以为是否需要走这条路提供更多有根据的决定。

    HTMLXHTML可能比我在这里提到的还有更多地不同,所以在这里把你在使用application/xhtml+xmlXHTML时遇到的问题提出来,如果你知道任何的错误或者忽略,务必告诉我。

    谷歌中国宣布联合巨鲸网推出音乐搜索功能

    谷歌中国和巨鲸音乐网正式宣布,在谷歌中国的整合搜索推出音乐搜索功能的实验版.
    此项新功能通过由巨鲸音乐网提供音乐内容、谷歌提供搜索技术、音乐界与巨鲸音乐网分享广告收入的模式来满足中国用户不断增长的互联网娱乐需求.

    访问:Google 音乐搜索

    此次谷歌中国在 www.google.cn 平台率先推出该功能的实验版,也是谷歌在全球第一次尝试音乐搜索服务.目前,在实验阶段,谷歌整合搜索的音乐功能可以为用户提供上百家唱片公司旗下的数万 首歌曲的搜索服务.在此次发布的整合搜索音乐功能实验版中,先期囊括了上百家唱片公司的数万首中文歌曲,这一正版音乐搜索功能的推出,可避免用户以往音乐 搜索死链频频、下载速度慢、歌曲质量差如音效差、不完整甚至受到病毒侵害的苦恼.

    此次合作创建了一种崭新的商业模式,即由巨鲸音乐网与音乐产业对巨鲸音乐广告收入分成,为正版音乐的合法下载提供了一种可持续的解决之道,谷歌通过自身强大的搜索技术和用户基础为巨鲸音乐带来新的产品功能、体验和大量用户.

    分析指出这种合作盈利模式的出现,搭建了一个多方共赢的平台:广大用户自此可以合法地、方便地、免费的、高质量试听、下载正版音乐;唱片公司通过授权,合理、合法地维护了自己的版权;谷歌则获得新的用户群,同时通过负责任的方式提升用户搜索体验.

    巨鲸音乐网CEO陈戈表示:”针对中国上亿网民巨大的免费音乐下载、视听等使用需求,是时候建立相应的商业模式,用服务于广告主的音乐广告平台、广告产品及服务来回馈于音乐的创造者.我们非常高兴谷歌同我们分享同样的理念.”

    谷歌大中华区总裁李开复博士表示:”谷歌十分认同巨鲸音乐网一直倡导的下载正版音乐的做法,互联网产业绝不应该成为音乐产业的对立面,此次通过与巨鲸音乐 网合作,共同在整合搜索中发布音乐功能实验版,实现了用户利益、关联产业利益、谷歌利益的良好平衡,谷歌一直深信共赢而非独大才是致力于长远的发展之 道.”

    欢迎来到Web 3.0:现在你的其它的电脑就是一个数据中心

    原文作者:Marc Benioff
    原文链接:Welcome to Web 3.0: Now Your Other Computer is a Data Center
    翻译:bill.chen
    从10年前一直到现在,我们一直在见证一场决定性的变革:从客户端-服务器的软件到作为服务的软件。Google, eBay, 和 Amazon.com等企业在消费市场建立了互连网应用程序的价值,同时salesforce.com,Google,和其它一些公司也一直在证明相同的 模式也会在企业级市场取得成功。

    到目前为止基于Web应用程序的转型已经产生了两个强烈的浪潮。现在我们看到了第三个,我们称之为Web 3.0,它可能会证明相对于传统软件产业它是最重要一个。

    世界不需要另外一句行话,我想说的是新生代的企业家,开发者,和传统的独立软件开发商,都需要抓住Web 3.0的巨大机遇,它可能创造机会,变革。Web 3.0是关于使用基于服务的软件平台来替换现有的软件平台。

    为了详细说明Web 3.0,我们需要仔细回顾Web历史上的重要浪潮。它们不是严格按时间定义的,而是交叉重叠在一起的。

    Web 1.0: 任何人可以交易

    Web 1.0 是关于来自一些主要的公司,如:eBay, Amazon.com, and Google 的杀手级的应用程序的出现。我们一直认为它们仅仅是网站,但它们实际上是一些令人惊讶的应用程序:功能丰富,容易上手,扩展性强,这些特性以前很少被普通 消费者看到过。交易,不仅仅是针对货物的,还有知识的,变的普遍和即时。效率,透明,这个曾经是全球金融市场的领域,现在被个人消费者和商业者占领。 Web 1.0在今天依旧是很大的推动力并且在将来持续很长时间。

    Web 2.0: 任何人可以参与

    Web 2.0是关于互连网上的下一代应用程序,特点是用户产生内容,合作化,社区化。任何人可以参与到内容的创建中。在YouTube上上传一个视频,在 Flickr上上传参加聚会的照片,或者在Blogspot上写自己的政治见解,所有这些都不需要专门技术,仅仅需要连接上互联网。参与改变了我们对于内 容的理解:内容不是固定在发布商那里,它是活动在任何地方的。Google的AdSense带来了一个即时的商业模式,尤其对于博客作者,并且视频共享网 站已经重写了流行文化和内容过滤的规则。

    当你围绕Web1.0或者2.0创业的时候,建设一个安全的,可扩展的数据中心并不是一项容易的工作。对于进入把软件当成服务的行业,大量的时间和资本依 旧是进入的一个门槛。而且,传统的客户端-服务器的软件开发依然复杂。并且创建一个成功的应用程序还需要辛勤的部署和维护。

    Web 3.0: 任何人可以创新

    Web 3.0通过改变传统软件行业的技术和经济基础来改变现有的一切。新的Web 3.0强调的是任何人,在任何地点都可以创新。代码编写,协作,调试,测试,部署,运行都在云计算上完成。当创新从时间和资本的约束中解脱出来,它就可以欣欣向荣。

    对于企业来来说,Web 3.0意味着SaaS程序可以比传统的C-S软件更快,更高效的开发,部署,升级。

    对于开发者来说,Web 3.0意味着他们需要创建一个理想的应用程序东西需要的仅仅是一个想法,一个浏览器。因为世界上的每一个开发人员都可以访问强大的云计算,Web 3.0是全球经济的推动力。

    对于独立软件开发商,Web 3.0意味着他们可以花费更多的时间专注提供给客户的核心价值上,而不是支持它的基础架构。因为代码生长在云计算上,全球的精英可以为它做贡献。因为它运行在云计算上,全球的市场都可以把它作为服务来订阅。

    问问我的朋友Jeremy Roche,CODA 公司的CEO,CODA是欧洲第二大ERP软件供应商。CODA成功从大型主机转型到客户端-服务器模式,但是现在它面临着一个更大的转型到SaaS上。 建立基础架构,不仅仅是数据中心,而是整个软件堆栈,将花费2亿美金和几年的时间。Jeremy正在使用我们的Force.com平台来来开始转变。他们 的系统工程师不需要维护服务器,负载均衡,网络交换机,而是找很少的人来调试维护他们。软件开发人员不需要开发安全和共享模型,数据库和工作流引擎-他们 只需要用我们的。同时,Jeremy的团队可以专注于他们擅长的:建立一个杀手级的会计软件。CODA2go将会在这个秋天发布,从而让Jeremy在竞 争中领先一步。

    创造价值

    Web 3.0将带来多大的改变?检查一下工作中的技术变革将带给我们一些好的线索:

    Vic Gundotra,Google工程副总裁,在最近的salesforce.com会议上提出了这个有趣的观点。Vic回顾了计算机的历史,从大型主机的时代开始。

    客户端-服务器时代在两种情况下都导致了极性的反转。计算能力非常容易访问到但是限制于使用的范围。有很强的功能,但是部署非常的困难。Vic说Web 3.0时代消除了这些缺点并潜在的最大化了计算能力,访问,容易部署,功能的深度。就像Vic所说,关键在于行业的领导者,如:Google, salesforce.com和其它的公司应该使运计算更容易访问和更具可编程性,保持深入的连通性,并且使客户端更强大。

    在我们看来,从大型主机到客户机-服务器的迁移对于像IBM,DEC这样的公司是非常痛苦的,但是同时也为新一代的公司,如Microsoft, Oracle, PeopleSoft, and SAP创造了大量的财富。Web 3.0威胁着 Microsoft的.net,BEA和WebSphere。我期待Amazon.com,Facebook, Google, and salesforce.com将会做的更好,我认为能利用上 Web 3.0的公司分布会更为广泛,并且他们可以创造更多的财富和创新。

    我们的一个程序员在他的个人电脑上有一句话生动的描述了Web 3.0精髓。是这样说的:”我的其他电脑是一个数据中心”。说明世界上的任何一个程序员可以创造。并且这就是革命的意义。

    Xhtml文档声明的区别

    在你每一个页面的顶端,你需要文档声明。是的,必须。

    如果不指定文档类型,你的HTML不是合法的HTML,并且大部分浏览器会用“怪癖模式 (quirks mode)”来处理页面,这意味着浏览器认为你自己也不知道究竟做什么,并且按浏览器自己的方式来处理你的代码。你可以是一个HTML大师,在地球上打遍 天下无敌手,或者你的HTML可以无瑕疵,CSS可以很完美,但如果没有文档声明,或者错误的文档声明,你的网页与一个短视的,独眼的长臂猿婴儿十分艰难 地堆砌起来的没两样。

    XHTML 1.0 Strict(严格)的文档声明是这样的:

    <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd“>

    下面的是XHTML 1.1的文档声明,作为XHTML的最新版本,看起来更完美,但还是有一些问题,随后我们会稍微讲解……

    <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd“>

    如果你不愿放弃HTML 4或者你还有Netscape 4死忠用户,你可以使用XHTML 1.0 Transitional(过渡型):

    <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“>

    你使用这的唯一理由是你还要兼容老版本的,少用的浏览器。过渡型XHTML 1.0允许HTML 4的表现元素,其也可能在如Netscape 4的浏览器中表现更好。但使用这些元素将对你网页的效率和可用性有害。

    最后,如果你是使用框架的怪人之一,可以使用像下面一样的XHTML 1.0 Frameset(框架)文档类型声明:

    <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd“>

    注意DOCTYPE标签必须大写和前置一个英文半角感叹号!。它是唯一一个打破规则的标签,它不需要关闭。

    语言声明

    即使HTTP头或者在html起始标签内设置了xml:lang属性,你也必须为文档指定一个主 要语言。尽管处理一个合法的XHTML文档这不是必须的,但也是一个易用性的考虑。值是缩写的,比如en(English,英语),fr(French, 法语),de(German,德语)或者mg(Malagasy,这是什么语?译者也不知道,呵呵。——译者注)。

    声明一个主要用英语内容的文档,例子是这样的:

    <html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en”>

    在声明主要语言之后,假如还需要使用其他语言,你还可以在内联中使用xml:lang属性(比如<span xml:lang=”de”>HTML Hund</span>)。

    内容类型

    HTML文档的媒体类型和字体集也许要指定,可以使用HTTP头来完成,比如:

    Content-Type: text/html; charset=UTF-8

    HTTP头部的第一部分(如text/html)是文件MIME类型,让浏览器知道文件的媒体类型因此可以知道怎么处理。所有的文件都有MIME类型。JPEG图像是image/jpeg,CSS文件是text/csss和HTML一般使用text/html。

    HTTP头部的第二部分(如UTF-8部分)是字符集。
    也许设置HTTP头的最简易方法是在HTML中使用“HTTP同义(HTTP-equivalent)”的头标签,像这样:

    <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />

    些微复杂当更好的方法是使用服务器端脚本语言来发送头。用PHP的话,你可以这样做:

    <? header(“Content-Type: text/html; charset= UTF-8”); ?>

    如果你不愿意(或不能)使用服务器端脚本语言,你也许可以直接给服务器设置一个 “.htaccess”文件。大部分服务器(Apache兼容)可以在根目录使用一个“.htaccess”的小文本文件,写入下面的内容,你就可以把所 有的“html”后缀文件都与MIME类型和字符集关联:

    AddType text/html;charset=UTF-8 html

    字符集包括大部分西方基于拉丁文语言的“ISO-8859-1”,日语的 “SHIFT_JIS”,中文的“GB18030”和UTF-8,一个 Unicode Transformation Format版本,提供大范围的多种语言的单个字符。基本上,你应该使用一个你知道的,能为你用户清楚认知的字符集。除非你使用基于拉丁语的语言(包括英 语)(ISO-8859-1被普遍接受的),你应该使用UTF-8因为它可以显示大多数语言的大多数字符,使用它也是安全的,因为它可以在大部的计算机上 使用。

    注意

    XHTML应该当作application/xhtml+xml的MIME类型来使用,再清楚不 过,这是XML程序。不幸的是,大部分浏览器没有对这没有第一线索。所以,一般认为使用text/html的MIME类型是不错的。根据W3C的建议和网 页标准工程的未来亮点,调味的XHTML 1.0也许可以作text/html使用,但XHTML 1.1不应该,这就是这个网站以XHTML 1.0 Strict(严格)作为例子,假定text/html的MIME类型。但是你仍然可以(或许不应该)为它们设置正确的MIME类型给浏览器,轻微的调用 一下服务器端即可。

    这个网站使用PHP为XHTML 1.1设置application/xhtml+xml的MIME类型给那些能够理解和处理这个类型的浏览器(如Mozilla),为XHTML 1.0 Strict设置text/html给其他浏览器(如IE)。为每一个页面的顶部加入如下代码:

    <? if(stristr($_SERVER[“HTTP_ACCEPT”],”application/xhtml+xml”)){ header(“Content-Type: application/xhtml+xml; charset=UTF-8”); echo(‘<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>’); } else { header(“Content-Type: text/html; charset=UTF-8”); echo (‘<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>’); } ?>

    这些检查核实浏览器是否接受application/xhtml+xml的MIME类型,如果接 受,就发送这个MIME类型并把XHTML 1.1文类类型写到HTML中。如果这个MIME类型不被接受,就发送text/html的MIME类型并把XHTML 1.0 Strict(严格)的文档类型写入HTML。

    除了你知道你正在做着正确的事情和为自己准备将来的路的平和想法外,最直接的益处就是,使用这个 方法,Mozilla浏览器把你的文件当作XML程序对待并且如果你的XHTML还没有抓痒,就是说不合式的,Mozilla就不会工作。然后你就可以排 错了,而不需要用校验器来运行你的文档了。

    配置 Apache 为 XHTML 发送正确的 MIME 类型

    2007 年 6 月 18 日

    http://www.ibm.com/developerworks/cn/xml/x-tipapachexhtml/

    本文将向您展示:如何配置 Apache 以便为支持可扩展超文本标记语言(Extensible Hypertext Markup Language,XHTML)的浏览器标记文档的媒体类型为 application/xhtml+xml,同时仍然向不支持该语言的浏览器(如 Microsoft® Internet Explorer®)发送 text/html。

    当 Web 服务器向浏览器发送文档时,它会给文档加上一个响应报头作为前缀,如 清单 1 所示。此报头包含了用于告诉浏览器如何解释文档的元数据。元数据的一个最重要的部分是最后一行中的 Content-Type。它将告诉浏览器如何呈现内容。例如,浏览器用于显示 JPEG 和 GIF 的代码是不同的。最重要的是,很多浏览器用于显示 XHTML 和超文本标记语言(Hypertext Markup Language,HTML)的代码也是不同的。

    清单 1. 一个典型的 HTTP 响应报头

                    HTTP/1.1 200 OK
    Date: Thu, 04 Jan 2007 19:39:13 GMT
    Server: Apache/2
    Last-Modified: Wed, 06 Sep 2006 11:19:37 GMT
    ETag: "4dfce0-c4aa-26828440"
    Accept-Ranges: bytes
    Content-Length: 50346
    Content-Style-Type: text/css
    Content-Type: application/xhtml+xml

    Web 服务器应该给 XHTML 文档加上媒体类型标记 application/xhtml+xml。识别此媒体类型的 Web 浏览器就会相应地将其以 strict 模式而不是 tag soup 模式运行。这使浏览器能更可靠地进行显示,对于级联样式表(Cascading Style Sheets,CSS)布局和基于文档的对象模型的 JavaScript ™ 程序,这一点尤为重要。事实上,在一些情况下同一文档能以两种不同的方式显示,取决于其处理模式是 tag soup 还是 strict。如果想要生成格式良好甚或是有效的 XHTML,则 strict 模式将会是您计划使用并希望使用的模式。

    不支持 XHTML 的浏览器也能以 tag soup 模式处理格式良好的文档。结果并不完美,但可以满足一小部分使用很老的浏览器的用户需要。对于大部分使用不符合标准的 Internet Explorer 的用户来说,结果也还可以接受。但是,当前版本的 Internet Explorer(包括 6 和 7)无法识别 application/xhtml+xml 媒体类型。如果向 Internet Explorer 发送 application/xhtml+xml 文档,它将会反过来要求您保存文件,如 图 1 所示。
    图 1. Internet Explorer 不知道如何处理 application/xhtml+xml
    某些文件可能会损害您的计算机。如果下面的文件信息看起来可疑,或者您不完全信任其来源,请不要打开或保存此文件。文件名:a.xhtml

    因此,处理 XHTML 时,要获得最大的兼容性,就需要向 Firefox、Safari、Opera 和其他符合标准的浏览器发送 application/xhtml+xml,而向 Internet Explorer 发送 text/html。在这两种情况下发送的是同一个文件。您只需在超文本传输协议(Hypertext Transfer Protocol,HTTP)的报头中更改文件的媒体类型标记即可。使用 Apache Web 服务器时,可在服务器配置文件或个人目录中的 .htaccess 文件中做此更改。

    Apache 配置指令

    根据默认,Apache 通过检查文件的扩展名来决定与每个文件一起发送的媒体类型。扩展名类型映射存储于 httpd/conf 目录(通常是类似 /usr/httpd/conf 或 /etc/httpd/conf 的目录)下的 mime.types 文件中。比如,清单 2 显示了 Apache 2.0 的 mime.types 文件的部分内容。

    清单 2. Apache 的 mime.types

                    # This file controls what Internet media types are sent to the client for
    # given file extension(s).  Sending the correct media type to the client
    # is important so they know how to handle the content of the file.
    # Extra types can either be added here or by using an AddType directive
    # in your config files. For more information about Internet media types,
    # please read RFC 2045, 2046, 2047, 2048, and 2077.  The Internet media type
    # registry is at <http://www.iana.org/assignments/media-types/>.
    
    # MIME type                     Extensions
    application/atom+xml            atom
    application/mathematica
    application/mathml+xml          mathml
    application/msword              doc
    application/octet-stream        bin dms lha lzh exe class so dll dmg
    application/postscript          ai eps ps
    application/rdf+xml             rdf
    application/reginfo+xml
    application/xhtml+xml           xhtml xht
    application/xslt+xml            xslt
    application/xml                 xml xsl
    application/xml-dtd             dtd
    application/xml-external-parsed-entity
    application/zip                 zip
    audio/mpeg                      mpga mp2 mp3
    image/jpeg                      jpeg jpg jpe
    image/naplps
    image/png                       png
    image/svg+xml                   svg
    image/tiff                      tiff tif
    text/html                       html htm
    text/plain                      asc txt
    text/sgml                       sgml sgm
    text/xml
    text/xml-external-parsed-entity
    video/mpeg                      mpeg mpg mpe

    一些更老的版本没有根据默认安装所有这些映射,并且可能事实上使用了一些十分有害的映射。尤其应该注意,对于原始 XML 文件使用 text/xml 而不是 application/xml 是一个常见的问题。

    具有了这些默认的映射后,您所需要做的全部工作就是为 XHTML 文件加上 .xhtml 或 .xht 后缀,而不是 .html 后缀,之后,所有这类文件都将被作为 application/xhtml+xml 处理。这对于 Firefox、Opera 和 Safari 效果很好,但对于 Internet Explorer 却并非如此。您所需要的是一种方法,通过它可向 Internet Explorer 发送一种媒体类型而向所有其他浏览器发送另一种媒体类型。

    浏览器嗅探

    2007 年,可以放心假设所有非 Internet Explorer 的浏览器都能识别 application/xhtml+xml。(如果您确实希望支持很老的浏览器,则破解我下面提出的规则也很容易。)因此您就需要识别 Internet Explorer 的所有版本并将媒体类型更改为 text/html。幸运的是,Internet Explorer 在发送 HTTP 请求时可告知服务器浏览器的类型,如 清单 3 所示。

    清单 3. Internet Explorer 的 HTTP 请求报头

                    GET /test/a.xhtml HTTP/1.1
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, 
            application/msword, application/vnd.ms-powerpoint, */*
    Accept-Language: en-us
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
    Host: www.xom.nu
    Connection: Keep-Alive

    关键在于 User-Agent 字段。虽然由于传统原因 Internet Explorer 在开始时感觉像是 Netscape,但 MSIE 字符串可将其识别为 Internet Explorer。所有版本的 Internet Explorer 在 User-Agent 字段中都包含了此字符串,而所有其他现代的浏览器都不具备此特征。

    您需要配置服务器以便查看报头中的 User-Agent 字段,并向 Internet Explorer 发送 text/html,向所有其他浏览器发送 application/xhtml+xml。mod-rewrite 模块并不局限于重写 URL。它还能根据 User-Agent 更改 HTTP 响应报头。清单 4 展示了配置文件中需要放入的代码。

    清单 4. 向 Internet Explorer 发送 text.html

                    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} .*MSIE.*
    RewriteCond %{REQUEST_URI} \.xhtml$
    RewriteRule .* - [T=text/html]

    第一行会打开重写引擎。

    第二行的第一个重写条件表明:下面的规则仅适用于 HTTP 请求报头中的 user-agent 字符串包含子字符串 MSIE 的情形。正则表达式 .*MSIE.* 实现了此功能。

    第三行的第二个重写条件表明:下面的规则仅适用于浏览器请求的文件具有 .xhtml 扩展名的情形。常规的 .html 文件被作为普通的 text/html 提供给所有浏览器。

    最后一行是实际的重写规则。此规则有点不太常见,因为重写并未真正更改 URL 中的任何东西。接下来,匹配整个 URL (.*) 但接着将其替换成它自己 (-)。然而,最后的 [T=text/html] 字段会把 Content-Type 报头更改为 text/html。如果同时匹配上述两个条件,则使用此规则。反之则不然。

    安装规则

    根据服务器设置的不同,此代码可能位于以下几个位置之一:

    • 主 httpd.conf 文件
    • httpd.conf 文件中的 VirtualHost 部分或单独的虚拟主机配置文件
    • XHTML 文件所在目录中的 .htaccess 文件

    这些指导说明在 Apache 1.3 和 2.0 中应该都有效。如果您在 .htaccess 文件中使用这些规则,则似乎没什么作用,这时,确保对目录做出了如下设置以允许在主 httpd.conf 文件中进行覆盖:

    <Directory /var/www/foo>
      AllowOverride FileInfo
    </Directory>

    Lynx

    如果可以的话,您应该多支持一个不能识别 application/xhtml+xml 的浏览器:Lynx。Lynx 是一种文本模式浏览器,主要由自动化脚本和处理 shell 的 UNIX® 爱好者使用。它的市场份额很小,但是其独特的功能使它具有了足够的重要性,颇值得我们关注,但前提是不给其他用户造成不便。

    幸运的是,所有 Lynx 的 user-agent 字符串都以词 “Lynx” 开头,而其他的 user-agent 字符串都不包含该词。因此,为支持 Lynx,您所要做的全部工作就是将该字符串添加到重写条件正则表达式中,如 清单 5 所示:

    清单 5. 向 Lynx 发送 text.html

                    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} ((.*MSIE.*)|(Lynx.*))
    RewriteCond %{REQUEST_URI} \.xhtml$
    
    RewriteRule .* - [T=text/html]

    第二行中的新正则表达式匹配任何包含 MSIE 或以 Lynx 开头的字符串。如果发现另一个浏览器不能很好地处理 application/xhtml+xml,则可向其 user-agent 字符串中做类似的添加。

    伪装成 Internet Explorer

    一些更老版本的 Opera 和 Safari 通过在其 user-agent 字符串中包含 MSIE 将自己伪装成 Internet Explorer。但是您无需为此忧虑,原因如下:

    • 几乎已经没什么人使用那些版本了。
    • 与一些更新版本的 Safari 和 Opera 不同,那些较老的版本总的说来处理 text/html 比处理 application/xhtml+xml 的效果好。

    要了解更精确的目标信息,请参阅 参考资料 中到 user-agent 字符串完整列表的链接和可供您参考的 application/xhtml+xml 浏览器支持。

    结束语

    XHTML 是 Web 的未来。但是,像很多其他重要的技术一样,它的采用由于得不到 Microsoft 浏览器的有力支持而受到阻碍。如本文所展示的那样,没有理由等待 Microsoft。您可以轻松地向非 Microsoft 的浏览器提供 XHTML,同时仍然告诉 Internet Explorer 将它作为 tag soup 处理。现代浏览器的访客和页面作者将完全受益于 XHTML,而受 Internet Explorer 牵制的访客则仍然可获得大部分内容。适当地设置 Multipurpose Internet Mail Extensions(MIME)媒体类型并不是向旧的浏览器提供 XHTML 所能采用的惟一途径,但它却是往正确方向上迈出的一大步。

    参考资料

    学习

    WordPress 2.7 新特征预览

    WordPress 新版本的开发进度越来越快了,可能还有好多博客还没有来得及升级到 WordPress 2.6 版 Features Planned for WordPress 2.7 这篇文章就已经开始向我们介绍 WordPress 2.7 新的特性。以下为文章的译文:
    WordPress 2.6 仅仅发布了两个星期,但是已经有很多关于 WordPress 下一个版本的讨论。 WordPress 2.7 将会包含一些令人兴奋的特征,这些功能既来自原有的开发计划也有来自 IRC 上的讨论,新版本可能会在2008年底放出。

    下面是一些将会在 WordPress 2.7 中出现的新的特征:

    • Comments API – 对我来说,这是最让人兴奋的功能, 它将允许开发者创建离线的留言管理应用,也就是说我们能够以此开发出一些桌面版的客户端,可以对留言进行编辑、审核、回复、删除等操作。
    • Keyboard shortcuts for comment moderation – 此功能将帮助用户迅速处理留言,用户可以自定义快捷方式。比如,按 Ctrl + S 删除垃评论,按下 Ctrl  + A 审核留言等。
    • Theme Update API – WordPress 2.5 以后的版本已经在插件管理上变得很容易,你可以自动收到插件更新提示并自动更新到最新版本。 新版的 WordPress 将会弥补主题和插件上的差距,届时我们将会看到主题更新甚至一键升级。
    • One Click Plugin Installs – 一键安装插件将使插件安装变的更加容易。这个功能通过 One Click Plugin 这个插件完成,而这个插件正是去年插件大赛的冠军。
    • WordPress core updates – 这是很多用户期待已久的应用,通过更新内核你可以轻松的升级 WordPress 到最新版本,这和 WordPress Automatic Upgrade 这个插件完成一样的功能。
    • Default Sitemaps – WordPress 2.7 将内置网站地图生成器, 可以为你的博客自动生成 Google XML sitemaps 。 Google Sitemaps Generator 目前是实现这一功能的最好选择,不过到时候这个优秀的插件可能就要退休了。
    • Admin Panel Comment Replies – 这个插件将帮助你在控制台完成留言回复。当然现在已经有很多这方面的插件,例如 WP AJax Edit CommentsBetter Comments ManagerAbsolute Comments
    • Comment Threading – 这个功能使用户直接回复留言者的留言, WordPress 现在已经有能力在不修改数据库的前提下实现留言回复。这个功能也可以通过 Brian’s Threaded Comments 插件完成。
    • Subscribe to Comments –  WordPress 团队的开发计划中还包括了一个允许订阅评论的开发计划,但是是否实现已久还在讨论中,所以可能不会出现在 WordPress 2.7 中。 当然 Subscribe to Comments 也可以完成这项任务。
    • Widgets for Dashboard and Write Box – 这项应用允许用户自由安排在控制面板和编辑器中的 widgets 以便提升效率。
    • Batch Editing of Posts – 用户可以对他们的文章进行群编辑。不过这方面的应用现在还没有一个比较详细的介绍。

    WordPress 2.7 发布以后将会有很多优秀的插件退休,因为它们的功能将被直接添加到 WordPress 内核中,事实上我们本来应该更加注重 WordPress 自身的功能并让博客变得更加容易。更多的功能和新的特征请查阅 WordPress codex

    QQ for Linux

    腾讯公司正式发布Linux版QQ,这个特殊版本的QQ支持最新的一些Linux发行版本,包括但不仅限于以下版本:SuSE 9 或更高,Ubuntu 7.10或更高,Fedora Core 8或更高。QQ for Linux也可以在其他符合软硬件环境的Linux发行版本上运行,但是不能保证运行完全没有问题。

    QQ for Linux基本界面和风格和window版本都是相同的,但是QQ for Linux目前只能提供最基本的IM聊天功能。

    Linux操作系统是Windows操作平台以外最重要的个人操作系统。作为免费的开源操作系统,Linux一直以系统开放、功能强大而得到众多开发者的青睐,并成为众多企业级应用的主流操作系统之一。

    百度日本域名Baidu.co.jp正式启用 任命井上俊一为百度日本总裁

    百度日本分公司近日正式启用了Baidu.co.jp域名与Baidu.jp 共同提供搜索服务(中国大陆暂无法访问)。
    在此之前,百度日本曾因Baidu.co.jp域名问题与该域名之前的所有者交涉,随后获得了日本政府获胜裁定,但由于一些原因,裁定后就一直没有了消 息。据记者获悉,百度日本自2008年7月10号正式获得了Baidu.co.jp域名的非物质财产所有权,自 7月31日正式启用。
    百度今日宣布任命井上俊一为百度日本总裁,此任命从宣布之日起正式生效。
    “井上先生在日本具有长达10年从事互联网搜索业务的经历,不仅深刻了解日本互联网和搜索引擎市场的发展状况,而且拥有广阔的国际化视野和丰富的国际化企业管理经验。他的技术和产品经验,必将为百度日本带来新的活力。”百度董事会主席兼首席执行官李彦宏表示。

    井上先生1998年起在著名搜索引擎Excite日本担任首席技术官,2004年加入雅虎日本,历任搜索事业部部长、主管搜索业务的副总裁,负责雅虎日本所有的搜索产品,为雅虎在日本市场上成为市场占有率最高的搜索引擎做出了重要贡献。

    “作为日本互联网搜索产业的领军人物,井上先生的加盟是百度日本业务发展迄今为止最重要的里程碑事件,极大增强了百度在日本市场上吸引更多一 流人才、提供更好的产品与服务的信心,也必将促进百度日本各项业务得到更加迅猛的发展。”百度负责国际业务的市场和商务拓展副总裁任旭阳表示。

    此次Baidu.co.jp域名的正式启用更符合日本国民的日常习惯,将极大的对百度在日本市场的推进产生积极影响。日前刚有消息称百度日本总裁人选将浮出水面。记者对百度日本近日的诸多动作将保持高度关注。

    Source Forge 宣布2008年度社区选择奖

    SourceForge宣布了2008年度社区选择奖
    最可能改变世界的项目:Linux
    最佳项目、最佳企业项目和最佳教育项目皆为OpenOffice.org

    最有可能成为下个10亿美元收购项目:phpMyAdmin
    最佳多媒体项目:VLC
    最佳游戏项目:XBMC
    最佳新项目:Magento
    最有可能被起诉侵犯专利的项目:Wine Is Not an Emulator
    最有可能让用户被过时的行业协会为保护死亡的商业模式起诉的项目:eMule
    最佳系统管理工具:phpMyAdmin
    最佳开发者工具:Notepad++

    搜索Cuil开张首日瘫痪 搜索界三分天下

    谷歌公司几名前员工28日推出新搜索引擎Cuil,对抗老东家谷歌。Cuil创始成员说,Cuil在搜索深度和广度上均超过谷歌。 但一些网络专家对Cuil的前景持谨慎态度。“Cuil”一词源于古爱尔兰语,发音同英文单词“cool”,意为“求知”。Cuil黑色主页上说,它覆盖 的网页超过1200亿个。Cuil公司设在美国加利福尼亚州门洛帕克市,由风险资本投资者筹资3300万美元组建。

    首日“瘫痪”
    Cuil“开张”第一天“生意火暴”,吸引了众多网民前来“捧场”。28日上线当天由于访问量过多,导致Cuil服务器一度陷入瘫痪状态,一部分访问者输入关键词搜索后,网页上显示“访问量过大,暂无结果”的字样。

    四大天王

    Cuil由Googlebase前首席技术官安娜·帕特森(上图)与她的丈夫科斯泰罗联手创办,他们的两位亲密助手拉塞尔·帕威尔和路易斯·蒙尼尔同样也曾是谷歌的资深员工。

    帕特森来头最大,她在此前曾一手建立起功能强劲的搜索引擎Recall,并在2004年被谷歌连人带网站高价收购。2006年,更喜欢独自高飞的帕特森辞职,并开始创建Cuil。而协助IBM构建新型搜索引擎WebFountain的丈夫科斯泰罗也成为她最有力的帮手。

    拉塞尔·帕威尔是大型搜索目录TeraGoogle前工程师。路易斯·蒙尼尔是早期搜索引擎AltaVista的首席技术官,曾是协助构建eBay搜索引擎的业界老将。

    三分天下

    目前的搜索界仍处于“三分天下”的状况。在英国,谷歌6月占有的份额为82%,雅虎和微软分别为5%和4%。在美国,谷歌5月份拥有62%的份额,雅虎和 微软分别以21%和8.5%的份额紧随其后。Cuil还将面临eoma、Vivisimo、Snap等竞争对手的挑战。

    酷点

    数据库

    Cuil索引数据库包含1200亿个网页,至少3倍于谷歌。按照帕特森的说法,谷歌常常忽略访问量小或默默无名的网页。

    Google表示能浏览1万亿个网页链接,但考虑到部分网页内容相似或影响搜索结果质量,因而没有把它们全部编入索引,仍自称拥有最大的索引数据库。

    搜索显示

    Cuil的搜索结果以更杂志化的方式排列,结果页面上将显示更多图片和工具条,用户可以点击工具条了解更多与搜索关键字相关的内容。搜索排名方式专注于分析网页内容。

    Google显示传统的条块状文字链接,但提供新闻、视频、本地、图片等专门搜索服务,以网页受欢迎程度进行排名。

    隐私权

    Cuil称最大特色在于,它希望通过承诺不保留用户搜索历史和上网行为的信息来吸引用户。

    Google以及其他搜索引擎都保留用户资料,这些引起了隐私权保护机构的强烈不满。

    中文服务

    Cuil开通初期阶段,将主要搜索和分析美国英语网页。今年晚些时候将使欧洲各大语种用户也能用上Cuil服务。目前没有中文网页。

    Google中文页面新增生活搜索服务,可以在房屋、工作、餐饮、票务和电影等方面进行专门搜寻。

    前Google工程师开发新搜索引擎“Cuil”

    硅谷一家名不经传的小公司“Cuil”近日自称推出了互联网上最大的搜索引擎,其索引页面的数量比Google还要大三倍。这家公司的总裁Anna Patterson此前曾在Google工作,但是她在2006年离开了公司,并和她的丈夫和几位朋友共同创建了Cuil搜索引擎(Cuil发音为“酷”,源自于盖尔语,意为“知识”),她的丈夫Tom Costello此前帮助IBM构建了新型搜索引擎WebFountain,而另外另外工程师Russell Power和Louis Monier则是Google的TeraGoogle项目前工程师。
    在界面上Cuil搜索引擎并没试图模仿Google,但是也不具备图片、视频搜索能力。但Cuil相信,通过其特有的识别方法和结果展示页面,它也能一枝独秀。Cuil的搜索结果页面提交就像是一本杂志的内容,而不只是内容的叠加。Cuil也承诺将不保留用户的搜索历史,以保证用户的隐私。

    Cuil搜索引擎目前获得了3300万风险投资,他们宣称索引数量已经超过1200亿个网页,是Google的三倍左右。不过Google没有公开其索引页面的数量,所以Google的实际索引数量仍不得而知。Patterson表示,3年前Google索引的页面数量是82亿个页面。

    在Cuil对外公开索引页面数量之后,Google上周五在官方博客中透露,他们索引的页面数量在1万亿左右。不过Google并不会把所有索引到的页面都放到搜索结果中,因为这样会削弱搜索结果质量

    访问:cuil

    谷歌中国内测音乐搜索

    Google将推音乐搜索业务的传闻由来已久.这也是谷歌在全球范围内的首个MP3服务,谷歌MP3搜索业务已确定的一个商业模式是,与合作伙伴进行广告分成,这借鉴了谷歌中国其他业务的一些经验.目前,谷歌中国一个重要任务是继续加快合作伙伴的开拓,加大音乐资源的积累.

    查看了Google.comrobots.txt ,其中增加了几行内容,这些行在之前是不没有的:

    Disallow: /musica
    Disallow: /musicad
    Disallow: /musicas
    Disallow: /musicl
    Disallow: /musics
    Disallow: /musicsearch
    Disallow: /musicsp
    Disallow: /musiclp

    这也可以证明了Google可能的确要出音乐搜索了。但是具体什么时候正式开放就不知道了。

    “谷歌MP3搜索将为用户提供最佳搜索结果,只提供一个结果,音乐质量很高,不会像其他搜索引擎一样让用户感到无从选择.”据消息人士透露,正版将是谷歌MP3搜索的主打招牌,但该服务是否对用户永久免费,以及是否会对音乐格式做一些加密,这些问题都有待揭晓.

    搜狗推出卫星地图服务

    据搜狐网报道,搜狗地图正式发布“搜狗卫星影像地图”服务。据了解,这是目前国内第一个应用了最新数据的卫星图片产品,首次发布21个城市的高清晰影像服务,其中涵盖全部七个奥运城市。

    据搜狐网介绍,使用搜狗卫星影像地图无需下载,打开网页版搜狗地图即可自由切换。通过搜狗地图提供的卫星影像服务,使用者可以清楚地看到地面上的建筑、 汽车、树木,甚至是道路上的标线,据知情人士介绍,“最高分辨率达到了0.5米/像素,已经是世界商用卫星图片服务的极限。”通过这项服务,网民甚至可以 轻易地分辨出地上的小汽车是二厢车还是三厢车,更可以快速寻找到自己家的屋顶。在搜狗卫星影像服务中,用户依然能够进行地图搜索的相关操作,诸如放大缩小 图像、对位置进行临时标注、测距、截图,还可以随时与传统地图切换,使用公交、自驾线路查询等基本功能轻松指引出行路线。

    Google公布互联网最新索引数量:1,000,000,000,000个网页

    连Google也不得不承认互联网真的是很大很大的东西,到现在为止,他们已经索引了一兆(百万的平方)的网页数,数量比银河系的星体还多出一倍.
    Google的索引在1998年开始工作,当时他们收集了2600万个页面,2000年就突破了10亿,到10年后的2008年,Google的数据库变成了全球最庞大的索引之一.

    1,000,000,000,000个网页

    1,000,000,000,000个网页

    DNS漏洞攻击代码已经公布 危险迫在眉睫

    Infoworld 报道,著名黑客HD Moore已经率先公布了可用代码.利用这段代码可以对DNS服务器进行投毒,将一条恶意纪录植入目标服务器,该服务器将随机发起域名查询,此时攻击者可以提供伪造的响应,将域名服务器中的纪录指向其特定站点.这个漏洞攻击可以默默的改变用户的升级服务下载恶意软件,IOActive研究者Dan Kaminsky很早发现漏洞并且无意中这周公布了漏洞使得开发出攻击代码.infoworld.com网站也提醒了这个攻击导致的网络钓鱼欺骗的问题.

    通过这个网址http://metasploit.com/dev/trac/changeset/5579可以看到国外黑客发布的DNS漏洞攻击代码。

    Google发布Knol

    Google周三推出了Knol挑战维基百科,让用户写自己擅长的东西.
    Knol产品经理塞德里克-杜邦表示:“我们深信,这种著述方法让读者相信这些内容.”Google从去年十二月开始对该产品进行测试.Knol的发布工具与博客页面的工具类似,但是Knol鼓励作者将内容缩减到一页,而不是按时间数序的很多页面.

    杜邦说:“我们不希望最后的声音获胜,这对一个忙碌的专业人士是很困难的.”Google希望按照受欢迎程度排列,以便鼓励竞争.

    与维基百科按话题区分不同,Knol的重点是个人用户或用户群.Knol不编辑信息.只要作者不批准,用户不能修改信息,也不能写新信息,用户可以通知Google内容是否客观.

    Google与《纽约人》签约,让Knol的作者们都可以使用一个该杂志著名的漫画人物,作者们还能够在页面上做广告并获得收入分成.杜邦说:“我们希望Knols将填补网络上的一些空白.”

    Knol

    Google终于发布了knol,但是不知道这会不会像维基一样被河蟹呢?

    .org域名将首先使用DNS安全扩展协议

    基于目前互联网爆出的DNS漏洞问题,ICANN近日批准了一项符合公众利益的重要决定,.org域名将首先转移为使用DNS安全扩展(DNSSEC)协议的顶级域名.
    DNS自身的缺陷最早被发现于1990年,但是一直没有相关的问题解决方法,最新的“cache投毒”方法据称可以有效伪造DNS信息,利用DNS缓存服务器来达到劫持网站的目的.
    DNSSEC 发展于1997年1月,开发周期长达11年,DNS安全扩展(DNSSEC)协议创建的目的是为了解决原DNS协议中的漏洞,使之不再 容易遭受攻击。不过因为DNSSEC会产生额外的数据开销而得不到普及。根据早期的协定,如果要使用DNSSEC,必须将之覆盖整个互联网。而且,有关隐 私和法律方面的疑虑涌现出来,使之无法获得普及。

    不过,.org域名实际上并不是最需要考虑到域名,但是鉴于一些国家已经拥有了自己的顶级域名,这不是ICANN所能控制的,可以简单而 快速从 DNS转移到DNSSEC的顶级域名目前只有.org。不过如果ICANN可以控制全面的互联网访问权限,那么全部域名转移也不是不可能。至于ICANN 和美国政府是否可以值得信任,则是另外一个问题。

    从.org域名的转移我们可以看到,尽管步伐缓慢,不过DNS将最终转移到DNSSEC上。

    谷歌拟2亿美元收购Digg网站 谈判已近尾声

    周二有消息称,谷歌将以2亿美元左右的价格收购Digg网站.
    多处消息显示,在过去的6个星期中,谷歌再次与Digg展开了并购谈判.而且,目前谈判已接近尾声,预计交易规模在2亿美元左右.如果交易成功,Digg 将被融入到谷歌的新闻服务中.早在今年3月份就有消息称,谷歌有意并购Digg,但被Digg CEO杰伊·阿德尔森(Jay Adelson)否认.
    目前,双方的谈判已接近尾声,有望在未来2至3周内达成交易,但不排除谈判破裂的可能性.

    Digg的大部分营收来自3年前与微软达成的一笔交易,如果出售给谷歌,与微软的协议将被终止.Digg曾获得1130万美元的风险投资.

    《连线》:DNS 漏洞细节被泄露,攻击即将开始

    尽管 Dan Kaminsky 努力掩盖他所发现的 DNS 严重漏洞的细节,Matasano 安全公司的一个员工还是在他的博客上泄露了这些资料,虽然文章被立即删除,但已经有人拿到了这些资料,并发表在别的地方。Kaminsky 在他的博客上发表了一个紧急消息,赶快打补丁,别睡觉,使用 OpenDNS…

    Kaminsky_by_quinn

    HD Moore,Metasploit  的作者说,黑客们正在加紧制作攻击工具,今天的晚些时候会有攻击出现。本月初,IOActive 的 Kaminsky 公布了 DNS 系统的一个非常严重的漏洞,该漏洞会导致攻击者轻松地伪造任何网站,银行网站,Google,Gmail 以及其它 Web 邮件网站。

    Kaminsky 是在同多个 DNS 系统商共同开发安全补丁的时候发现了这个漏洞。Kaminsky 在记者会宣布了这个由多家厂商共同开发的 DNS 补丁,并呼吁 DNS 服务器所有者立即更新他们的系统。

    但 Kaminsky 在宣布这个漏洞的时候,没有透露相关技术细节,以便 DNS 系统管理员知道其严重性,Kaminsky 承诺会在下月的 Las Vegas 黑帽安全大会上透露漏洞细节,在这之前,他给 DNS 系统管理员预留了一个月的时间升级系统。Kaminsky 同时恳求那些安全专家不要试图猜测漏洞的细节,但很多人将他的恳求当作一个挑战。

    德国的安全专家 Halvar Flake 最先发表了漏洞细节,Kaminsky 曾被要求私下里公布细节,帮助那些系统管理员升级系统,同时,一些系统管理员以及安全专家指责 Kaminsky  是在拿那些过去的众所周知的 DNS 漏洞炒作。

    Matasano 的创始人Thomas Ptacek  也曾置疑过 Kaminsky 的发现,然而当 Kaminsky  私下里向他透露过漏洞细节之后便不再出声。Ptacek 并没有参与漏洞细节的公布,但作为 Matasano 的创始人,他仍然发表了一个声明为这件事道歉

    Kaminsky 发现的 DNS 漏洞会让黑客在 10 秒之内发起一个“缓存毒药攻击”,使 DNS 服务器将用户引导到恶意网站。Kaminsky 说,这是一个非常严重的 Bug,会影响到任何网站,Kaminsky 不打算向 Matasano 追究到底细节到底是如何泄露的,但呼吁人们立即升级 DNS 系统。

    本文国际来源:http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html
    中文翻译:COMSHARP CMS

    Google自爆数据中心基础设施

    Google一向很少对外透露其数据中心的工作,但5月28日,Google伙伴Jeff Dean在Google I/O会议的听众前,轻轻撩起了Google公司基础设施的神秘面紗。

    一方面,Google用的是一般的服务器、处理器、硬盘、软驱等等。另一方面,Dean似乎认为1800台服务器也是非常普通、不值得一提。而Google公司使用的软件,能在半秒之內回应700至1000台服务器的搜索請求,则完全是另一回事。

    Google从未透露他们究竟拥有多少台服务器,但Dean认为至少不下数十万台。Dean表示,每個机柜里存放了大约40台服务器。而根据某项估 计,Google目前在全球有36個数据中心,以每个中心有150个机柜计算, Google的服务器至少超过20万台,而实际数字还要比这大得多,且每天都在增加中。

    不论真正的数字有多少,Google的成就也实在惊人,部分原因是他们推翻了电脑业的传统做法。当所有的超大型数据中心,如纽约股票交易所或航空公司的联合订位系统都是采用许多主流服务器和软件系统的时候,Google的数据中心绝大部分却是自身的技术建设而成。

    有些制造和出售服务器的公司虽然不以为然,但Google显然相信自己的技术命运最好操纵在自己手中。Google搜索产品与使用者经验副总裁搜 Marissa Mayer在5月29日的演讲中提到,共同创办人Larry Page鼓励员工对“不可能的事情”保持一种健康的不敬。也就是说,别太相信有什么不可能的事情。

    要维持如此大规模的运作,Google必须对每一台机器都抱有一种随时可牺牲的态度,服务器制造商喜欢宣传他们的主机质量优越、具有高度承受故障或当机的能力,但Google仍然宁愿把钱投资在冗余软件系统上。

    Dean表示:“我们的观点是,拥有两倍数量但比较不可靠的硬件,胜过数量一半但比较可靠的硬件。你必须为软件提供可靠保障,如果你有1万台主机在运作,每天一定会有一些意外。”

    Dean说,每次新业务上线最能显示出硬件的脆弱。一般每个新业务上线的第一年,通常会发生1000次个别主机的故障、数千次硬盘故障;一次电力输送 问题,会导致500至1000太主机失效约6小时;20次机柜损坏,每次会造成40至80台主机下线;5次机柜摇晃,会导致一半的网络封包在传送过程中遗 失;整个业务至少一次重新上线,在两天之内的任何时间,影响5%到主机。整个业务中还有一半的几率会过热,可能导致5分钟内让几乎所有服务器当机,恢复则 需要花费1到2天地时间。

    虽然Google用一般的硬件组装其服务器,却不用传统的封装,他们要求英特尔提供特制的主机板。Dean表示,Google目前在每40台服务器的机柜外,都包了一层外壳,这是Google自行开发的设计,而不是服务器厂商提供的外壳。

    Dean表示,Google使用了几种服务器组装的方式,有些配备了很多硬盘,有点则数量比较少。还有一些大范围的差异,他说:“我们不同的数据中心都有一些差异,但数据中心内部不会。”

    对于服务器本身,Google偏好使用多核心晶片。许多习惯追求运算速度的软件公司其实很难适应多核心的晶片,但Google沒有这种问题。他们在技术上早就必须适应横跨数万台电脑的结构,因此他们已经进入平行运算的世界。

    Dean说:“我们真的很喜欢使用多核心主机。对我们而言,多核心主机就像很多相互连接、性能优越的小机器,对我们来说相对好用。”

    虽然Google对搜索和其他服务都要求快速回应,其平行运算能在单一指令的执行相对较慢时产生快速回应的结果。这对于多核心处理器和多线程模式设计者是一大鼓励。Dean說:“单线程的表现对我们来说无关紧要,我们有很多平行化的问题。”

    那么Google要如何处理这些一般的硬件问题呢?用软件。

    Dean说明了Google软件的三个核心要素:GFS(Google档案系统)、BigTable和MapReduce演算法。虽然Google资助了许多有助于其开展的开放源代码的计划,这些仍然属于专有软件。

    Dean表示,三者中级别最低的GFS几乎在所有主机中运作,负责储存资料。某些GFS的化身是“许多petabyte大小”的档案系统。目前有超过200个业务在执行GFS,其中许多都包含数千台主机。

    GFS把一块储存的资料(通常是64MB),至少放在三台称为chunkserver的主机內;假如chunkserver发生故障,主服务器便负责吧资料备份到一个新的地方。Dean說:“至少在储存层级,主机故障完全由GFS系统处理。”

    一窥Google数据中心自行定制的40台服务器机柜。基础建设大师Jeff Dean在Google I/O大会上展示了这张照片。