第一，SNS化冲淡了微博带给用户的价值——快速的信息获取。信息从源头到达接收者，包括两个步骤：首先是传播，信息通过收听关系进入接收者的信息流；其次是提取，接收者从自己的信息流中提取有价值的信息。微博SNS化后，主要增加的是普通用户之间的互听关系，对于信息的传播没有多大助益；但是由于普通用户之间的互听关系的增加，用户的信息提取能力被大大削弱。SNS化以前，每天登陆微博15分钟，所要了解的信息基本上就可以掌握；SNS化以后，每天登陆1-2个小时，也很容易错过有用信息。当打开微博看到屏幕上无数好友的碎碎念的时候，我仿佛回到了人人一般……而事实上，在停用人人半年之后，我在最近又启用了人人——至少人人上的好友关系更全，信息共享也更私密。

第二，新浪在浪费自己的基因。众所周知，新浪的基因是媒体，新浪微博之所以在发展初期千里绝尘，远远甩开其他微博，原因也在于此。而现在转向SNS，实在是以及之短攻彼之长。SNS的核心价值，在于帮助用户经营其社交圈子，因此在SNS的运营过程中，通过各种手段来辅助用户交流甚至促使用户交流是很重要的。这样的能力需要足够的数据积累和分析，新浪作为后起之秀，根本无法与腾讯、人人、开心网相比。

篇幅有限，很多细节没法一一赘述。欢迎质疑，欢迎讨论。

后记：实际上这半年新浪微博已经出现了用户活跃度和黏度下降状况，但这种状况是否是因为SNS化造成的，目前不得而知。列出一些相关的链接，仅供参考。

微博用户活跃度和粘性下降 http://blog.sina.com.cn/s/blog_4c1892310100vxu3.html

http://blog.sina.com.cn/s/blog_6b68e9a80100w9pt.html

腾讯微博用户活跃度超新浪 http://reed077.blog.techweb.com.cn/archives/210.html

您可能也喜欢：

腾讯微博邀请码

分享几个腾讯微博邀请码

罗杰·迈克奈米:社交网络已经完结

分众折扣

无觅

写个评论

有关阿里巴巴集团与雅虎资产互换的传闻还在继续发酵。

路透社昨日援引知情人士的话称，作为与雅虎复杂交易计划的一部分，阿里巴巴集团计划将在香港上市的阿里巴巴网络有限公司(01688.HK，下称阿里巴巴)私有化，以此换回大部分雅虎手中持有的阿里巴巴集团股权。而雅虎最终或将拥有阿里巴巴集团一部分业务的股权。

《纽约时报》昨日的报道也提及阿里巴巴集团可能将B2B上市子公司作为回购雅虎持股计划的一部分，该交易还有可能涉及淘宝网和人人网。

不过上述报道均提到，将阿里巴巴私有化仅是当前讨论的提议之一，最终方案仍在商榷，而选择资产置换方案则意在免税。

交易或涉及多家公司

阿里巴巴9日宣布停牌，称因涉及公司控股股东正参与的交易有关，可能会影响公司并对价格存在潜在影响。阿里巴巴集团拥有阿里巴巴约73%股权，市值接近60亿美元。

目前，雅虎持有阿里巴巴集团39%的股权，估值130亿至140亿美元，阿里巴巴集团剩余股权则由马云等管理层持有31.7%，软银持有29.3%。目前的交易即是阿里巴巴集团拟回购这39%股权，而雅虎拟出售价值170亿美元的亚洲业务，其中包括阿里巴巴集团股权及雅虎日本35%股权，软银持有雅虎日本42%股权。

路透报道称，在私有化阿里巴巴的同时，阿里巴巴集团将通过银行贷款以及现金，加上资产互换回购25%的股权。《华尔街日报》此前援引知情人士的话称，阿里巴巴集团正向6家银行寻求贷款30亿美元，上述贷款预计将于本月敲定。

而据《纽约时报》的报道，根据潜在的交易条款，阿里巴巴集团和软银将创立新的子公司，并向其注入现金和运营资产。雅虎将获得这些实体的控制权，而作为交换，该公司将放弃其持有的多数阿里巴巴集团股票和所有雅虎日本股票。报道称，交易完成后雅虎将获得阿里巴巴三成股权。

不过，报道援引知情人士的话表示其他可行的运营资产包括人人网和淘宝网。目前软银持有人人网母公司千橡互动23.8%的股权。

资产置换意在免税

事实上，早在去年12月底，就有传闻称雅虎正在考虑通过“现金充裕剥离交易”，剥离该公司大部分亚洲资产，该交易在美国税收规定中不被看作是出售股份，交易方可以免税。因为据测算，如果直接出售170亿美元资产，可能需要缴纳40亿美元的税收。

而所谓“现金充裕剥离”，是指由第三方机构(在雅虎的案例中则指阿里巴巴或者私募机构)设立一个新公司，该公司66%的资产需是现金，33%的资产应为运营资产，然后用该公司来置换雅虎的亚洲资产，然后阿里巴巴集团将从雅虎拿回大部分股份，而雅虎将拿到大量现金和资产。按照美国税法，此类交易不被视为资产出售交易，因此不会被征税。

雅虎日本首席财务官Akira Kajikawa此前曾称，雅虎已经花了一年时间来研究如何出售股份。不过，雅虎在如何处理亚洲资产上的犹豫不决让股东颇为不满，而雅虎也在完成自己管理层的换血，以求改革。1月4日，雅虎任命PayPal前总裁汤普森为新的CEO，汤普森上月在电话会议中透露，考虑开发新的业务模式。

《纽约时报》称，上述复杂交易的难题在于，找到雅虎想要且亚洲伙伴也愿意购买的资产，但是通过阿里巴巴有限公司这个阿里集团旗下的资产，却可以省去额外的麻烦。

树说：经济低谷的时候退市，是上市公司一个不错的选择，尤其是对公司有信心，且现金充足的情况下，盛大是个不错的例子。他们管这个叫啥来着，剪羊毛。

您可能也喜欢：
阿里巴巴十年庆后的一些思考	阿里巴巴收购中国万网	阿里巴巴研发输入法，或年内推出	薇爱购推出“V友团”活动
无觅

写个评论

您可能也喜欢：
Microhoo-微虎搜索诞生	VS2010 Pro Power Tools	C#和C++混合编程的一些tips	微软发布Windows Mobile 7操作系统
无觅

写个评论

 
这是刘湛秋的一首诗，初三的时候看到的，很喜欢。今天浏览自己的博客的时候，又从老弟的留言里看到，读来依然很感动。
有些东西，是永恒的，就算经过很多岁月，依然能不经意地挑动你的心。
本来想发在人人上，感怀一下即将结束的研究生生活，踟躇甚久，最后还是存了草稿。
想想四年前，博客最热的时候，写一篇博客然后跟朋友们交流，很欢乐。如今却是浮躁了很多，状态了，微博了，却失了沟通了。

发在这里，权当纪念吧。

您可能也喜欢：
程序员写博客的利器—Google Prettify	换了空间	The 200th	说说新浪微博的SNS化
来自无觅网络的相关文章：
【告】博客恢复正常 (@cuike)	经营博客的十大秘诀 (@cuike)	牛B博客的用户体验分析报告 (@cuike)	博客赚钱网站的用户体验分析报告 (@cuike)
无觅

写个评论

作者：Uche Ogbuji (uche.ogbuji@fourthought.com), IBM首席顾问, Fourthought, Inc.

简介： 采用 XML 的人遇到的老问题是，在 XML 的设计中什么时候使用元素，什么时候使用属性。对于多数设计而言，这个问题很少有绝对的答案，但是开发人员也确实体会到缺乏明确的原则来帮助他们作出决策。本文中，Uche Ogbuji 就什么放在元素中什么放在属性中提供了一些指导原则。

发布日期： 2004 年 3 月 01 日

在 SGML 中，DTD 设计的几个经常要考虑的问题也遗留给了它的分支 XML。无论使用什么 XML 模式语言，您都需要问这样的问题：

• 什么时候使用元素，什么时候使用属性来表示信息位？
• 什么时候需要对元素排队，什么时候不需要考虑顺序？
• 什么时候需要对类似元素的序列使用包装元素？

根据我和 XML 用户打交道的经验，最常见的还是第一个问题。一些情况下答案是很明确的：

• 如果涉及到的信息本身能够用元素标记，就把它放在元素中。
• 如果信息适合采用属性的形式，但可能造成同一元素中有多个同名的属性，则改用子元素。
• 如果信息需要作为类似标准 DTD 的属性类型，如 ID 、 IDREF 或 ENTITY ，则使用属性。
• 如果信息不应该进行空白字符规格化，则使用元素。（XML 处理程序规格化属性的方式可能改变属性值的原始文本。）

不幸的是，设计决策很少能进行这种明确地划分。在灰色的区域中问题仍然是如何进行正确的选择。一般的答案是 没有单一正确的答案，取决于您的最佳判断。但这对于那些希望熟悉 XML 的人来说没有多少帮助。事实上，在某些情况下即使专家也不一定意见一致，但是这并不成为不能提供在元素和属性之间选择的一些基本原则的理由。

首先，我想提出曾经听到但 不建议这样做的两条原则。我曾经听过 统统使用元素这样的建议。理由包括 属性使事情变得复杂以及 属性会影响可扩展性等等不一而足。但是如果不使用属性，就抛弃了 XML 强大功能的一个重要方面，您可能最好是改用某种分隔文本格式。

我也听说过 如果是希望在浏览器中显示的那类材料，就使用元素内容。这个原则的问题是鼓励人们根据表示考虑 XML 的内容设计，这两种问题不应混在一起。本文中也提出了一条非常相似的原则，但我是根据内容的用途而不是表示来阐述的。

本文的其他部分将提出一些指导原则，建议在元素和属性之间进行选择时采用。

推荐的指导原则

我把这些指导原则分解成了一些规则，希望能够从总体上说明元素和属性之间的选择。没有哪个规则是绝对的，可以将其作为经验规则使用，如果确实需要完全可以打破这些规则。

核心内容原则

如果认为要处理的信息属于用 XML 表示或传达的基本资料，就将其放在元素中。对于供人阅读的文档一般是指向读者传达的核心内容。对于面向机器的记录格式一般是指直接来自问题域的数据。 如果认为该信息对于传递的主要信息而言是外围的或者附属性的，或者单纯用于帮助程序处理传递的主要信息，则使用属性。这样可以避免把核心内容与辅助资料混在一起。对于面向机器的记录格式而言，这一般是指来自问题域主数据上的特定于应用程序的符号。

比如，我曾经看到过许多 XML 格式――通常是业务中自动生成的――文档标题被放在属性中。我认为，像标题这样的文档信息基本组成部分应该作为元素内容。另一方面，我也常常看到这样的情况，内部用的产品标识符被作为元素放在产品的描述记录中。其中的一些情形采用属性更合适，因为特定的内部产品代码不会成为多数读者或者文档处理人员关心的主要目标，尤其是如果 ID 非常长或者采用难以理解的格式。

您也许曾经听说过这样的一条原则， 数据使用元素，元数据使用属性。上述两段实际上表达的是同样的原则，只不过使用了更加慎重、更加明确的语言。

知名的例外

我曾经小心地指出，这些设计原则是很灵活的，肯定会找到一些理由打破这些原则。此外，您还会发现需要在不同原则的取舍之间平衡。在许多标准 XML 词汇表中，都有一些设计决策有意地违背了本文提出的一些原则。这是一些例子。

• SVG 向量路径在单个属性中用一些空格分隔的数字表示，与 结构化信息原则 相抵触。之所以这样做是因为 SVG 对简洁性的要求很迫切，但是因为这样增加了 SVG 格式处理的复杂性而受到批评。
• 许多格式都允许在属性中使用级联样式表（CSS）样式（如 XHTML 1.0 和 XSL-FO）创建复杂的样式描述，混合使用多个面（ facet）和度量单位。这样做与 结构化信息相矛盾。有趣的是，在 XHTML 2.0 中这已经不再是一个问题了，因为这个版本只允许指定一个类标记来映射到单独的 CSS，不能再使用内联的样式属性。

结构化信息原则

如果信息用结构化的形式表示，特别是如果这种结构可能需要扩展，则使用元素。另一方面， 如果信息用原子记号表示则使用属性。元素是 XML 表示的结构之所以能够扩展的动力源。差不多所有的 XML 处理工具都围绕着这一事实设计，如果能够把结构化信息正确地分解到元素中，您就会发现处理工具可以与您的设计互补，从而提高的生产率并获得了可维护性。属性用于表示元素所表达信息的简单性质。如果违背了 XML 的基本结构，把结构化信息硬塞进属性，可能表面上您似乎获得了简练和便利，但可能要付出维护的代价。

日期是一个很好的例子，它有固定的结构，并且一般作为单个标记，因此作为属性非常合理（更适合用 ISO-8601 表示）。另一方面，我发现在个人姓名的表示中这一原则令设计者感到惊奇。我曾经看到许多放在属性中的姓名，但一直坚持个人姓名应该作为元素的内容。个人姓名有着令人吃惊的可变结构，在一些文化中，如果忽略了尊称或者姓名中各个部分的先后顺序，可能会造成混乱或者冒犯他人。个人姓名也很少作为原子标记，比如有时候会按照名称有时候则按照姓氏排序。还应该指出，如果把整个姓名完全塞进一个元素的内容中或者放在属性中一样会造成问题。因此：

<customer>
  <name>Gabriel Okara</name>
  <occupation>Poet</occupation>
</customer>

比下面这种表示强不了多少：

<customer name="Gabriel Okara">
  <occupation>Poet</occupation>
</customer>

我希望在将来的一篇文章中展开讨论关于姓名的处理。

可读性原则

如果信息是供人们阅读和理解的，则使用元素。一般而言，这一原则是把没有结构的信息放在元素内容中。 如果信息主要是方便机器理解和整理，则使用属性。一般来讲，这一原则是指把不是自然语言的信息标记放到属性中。

在一些情况下，人们可以解释所表达的信息但是需要机器正确地使用它们。URL 是一个很好的例子，人们已经学会了在 Web 浏览器或者电子邮件消息中显示的 URL，但是如果没有计算机获取引用的信息，URL 通常没有多少用处。一些数据库标识符也很容易理解（尽管已经建立的数据库管理最佳实践不鼓励使用带有业务意义的 ID），但是这类 ID 通常是机器处理的小道具。基于这些原因，我建议把 URL 和 ID 放在属性中。

元素/属性绑定原则

如果需要根据另一个属性改变它的值则使用元素。XML 在属性和包含它的元素之间建立了非常强的概念联系。属性提供了那个特定元素的一些特性或者修正。XML 处理工具往往都遵循这种概念，让一个属性改变另一个属性通常是可怕的想法。比如，如果要设计一种菜单格式，而且菜单上包括菜量，您可能认为这些信息对一般的菜单格式读者而言并不重要，因此应用 核心内容原则将其作为属性。第一种尝试就是这样：

<menu>
  <menu-item portion="250 mL">
    <name>Small soft drink</name>
  </menu-item>
  <menu-item portion="500 g">
    <name>Sirloin steak</name>
  </menu-item>
</menu>

按照 结构化信息原则，您决定不把菜量和度量单位放在一个属性中，而是使用一个元素，于是选择以下格式：

<menu>
  <menu-item portion-size="250" portion-unit="mL">
    <name>Small soft drink</name>
  </menu-item>
  <menu-item portion-size="500" portion-unit="g">
    <name>Sirloin steak</name>
  </menu-item>
</menu>

现在属性 portion-unit 修正了 portion-size ，而我已经提到这不是一种好主意。元素 menu-item 上的一个属性应该修正那个元素，而不是其他的内容。应该改变这种方案而采用元素：

<menu>
  <menu-item>
    <portion unit="mL">250</portion>
    <name>Small soft drink</name>
  </menu-item>
  <menu-item>
    <portion unit="g">500</portion>
    <name>Sirloin steak</name>
  </menu-item>
</menu>

在这个例子中，我结合使用了 核心内容原则 和 可读性原则，决定把数量作为元素内容而把度量单位放在属性中。 这是一种不那么固定的情形，其他的方案可能同样合适。这种方案也与最初的决策相抵触，本来按照 核心内容原则 菜量应该放在属性中。这说明有时候这些原则可能得出互相矛盾的结论，您必须根据自己的判断具体情况具体分析。

回页首

什么也不能代替学习和实践

XML 设计对于专业人员来说是一个问题，如果要从 XML 中获益就应该有志于研究 XML 的设计原则。许多开发人员承认编写代码能够从精心的设计中获益，但是对于 XML，他们却认为只要看起来能工作就够了。我曾经看到这种区别造成了真正的、痛苦的代价。学习那些合理的 XML 设计所能带给您的经验就是要注意这个问题。对专家设计的标准 XML 词汇表进行分析，记录下您自己的设计决策，评价每个决策在后续设计中的积极和消极影响。一旦取得了经验，您的直觉就会成为做出设计决策的最重要的工具。如果您发现自己在任何重要的领域使用 XML，您的努力也就获得了回报。

我计划在将来的文章中像本文一样继续讨论 XML 的设计原则。我还将在我的 Thinking XML 专栏 中继续简要地触及 XML 设计原则。如果您对 XML 设计有什么想法和问题，请在 Thinking XML讨论论坛 上发表。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
• 看一看知名的 Cover Pages，它提供了关于该主题的一些信息，集中在以下页面上： SGML/XML: Elements versus attributes, 1998 年 4 月和 SGML/XML: Using Elements and Attributes。
• 阅读 Elliotte Rusty Harold 的 Effective XML （Addison-Wesley, 2003）。根据我的体会，作者非常精通 XML 设计和最佳实践。您可以在线阅读部分章节，包括“ Store metadata in attributes”和“ Make structure explicit through markup”，它们都与本文的内容有直接的关系。
• 可以在 developerWorks XML 专区 找到更多 XML 资源。特别是在我的 Thinking XML 专栏中有时也触及一些问题。您还可以在 XML 实用技巧中找到许多这样的文章。
• IBM WebSphere Studio Application Developer 是一种支持使用各种不同的技术（如 XML、JSPTM、sevlet、HTML、Web 服务、数据库和 EJB ）构建多种应用程序的开发工具。
• 在 developerWorks Developer Bookstore上可以找到大量关于 XML 的书籍。
• 了解如何才能成为一名 IBM 认证的 XML 及相关技术的开发人员。

关于作者

Uche Ogbuji 是 Fourthought Inc.的顾问兼创始人，该公司是专为企业知识管理提供 XML 解决方案的软件供应商和咨询公司。 Fourthought 开发了 4Suite，这是一个用于 XML、RDF 和知识管理应用程序的开放源代码平台。Ogbuji 先生也是 VersaRDF 查询语言的主要开发者。他是一位出生于尼日利亚的计算机工程师和作家，在美国科罗拉多的博耳德生活和工作。可以通过 uche.ogbuji@fourthought.com和 Ogbuji 先生联

您可能也喜欢：
如何设计出色的ppt	数据库基准测试系统通用模型设计	Rokey-设计贴士	PostGreSQL多版本实现中的几个问题
无觅

写个评论

美国国债是如何形成的？这要从美元这种债务货币说起。所谓债务货币，就是指以举债的方式获得信用，并基于此信用发行的货币。

简单地说，美国向他国借来各种信用抵押品（黄金、货币、产品），然后以此作为抵押，发行美元。到一定的期限时，归还此抵押。

基本上，美国当前有多少国债，它便发行了多少美元。

那么中国购买了10000亿美元的美债，究竟意味着什么？

假设当前人民币兑换美元是6：1，中国一次性购入10000亿美元的美债，那么意味着中国拿来60000亿人民币，交给美国。

美国拿到这60000亿人民币以后，它就发行10000亿美元的新货币。

此时假如中国出口商品到美国，那么，美国就可以使用这10000亿新美元进行支付购买。

表面上看，是美国使用中国给的钱买中国的东西，中国亏大了。

实际上，中国确实是亏的。不过没有亏在这里。

我们继续上面的场景。假如我们卖了10000亿美元的产品给美国，此时我们将持有这10000亿美元，然后我们又从美国买了10000亿美元的电子产品。

这时候发生了什么？中美两国交换了价值10000亿美元的产品，此外什么都没有发生。

美元在这里，就是起到了一个最基本的交易手段作用。

那么我们拿给美国的60000亿人民币呢？美国会定期归还本金和利息，到一个期限后还清。

也就是说，我们在一段时间内抵押了60000亿人民币给美国，美国回报给我们一定的利息——借人民币，还美元。

这桩买卖划不划算，取决于利息的高低和美元相对于人民币是否贬值。

那么，为什么美国要支付利息给中国？理由是中国为美国提供了信用，进而使得美国可以发行美元以提高交易效率。也就是说，所有使用美元的人、公司和经济体实际上都受益于中国提供的信用，也就是说所有使用美元的人都应该支付此利息。而事实上，只有美国为此支付利息。因此，理论上当美元发行量够大的时候，美国每年的GDP会还不起美债的利息，然后美国会破产。

当然以上都是理想情况，就是说美国每一次美元发行都有相应的抵押品，而不是随意发行美元。

但实际上，美国做不到这一点。大名鼎鼎的”量化宽松“政策，使得美国可以光明正大地凭空印钞，然后美元贬值，从而将利息压力直接转嫁给别国——包括中国自己。这个东东，术语叫做”铸币税“。

综上所说，基本上你可以认为美国是借债少给利息、不给利息，甚至连本金都给你缩水的类型。这才是中国持有美国国债亏本的地方。当然如果某一天美元贬值到0，那中国也就血本无归了，这就真的亏大了。

货币发行权是最高的经济权力，这话一点都没差。

您可能也喜欢：
萨缪尔·摩尔斯	Facebook，F8大会，Web 3.0和新鲜的屎	春哥传第三话：艰难之战【下】	[图说]Oracle收购路线图
无觅

写个评论

在此我们假设商品只有一种，那么具有良好价值尺度功能的货币，在任何时间点购得的商品数量一致。

这种假设意味着货币既不能升值也不能贬值。

货币体系的可行性定义：在满足良功能的前提下，保持货币体系稳定。

金本位货币的定义。所谓金本位货币，是指以黄金为抵押发行的货币，货币可以按照一定比例兑换抵押物。

金本位货币的可行性定义：满足良功能，同时抵押品不会被兑换完。

Question：

金本位货币是否具有可行性？如果是，那么其限制条件是什么？

My Answer：

假设以100单位的黄金作为抵押，发行10000个单位的货币，同时社会总财富（含抵押品）为10100单位。

此时一单位货币兑换一单位商品，或兑换0.01单位的黄金。我们假定此时是稳定状态，即0.01单位的黄金，其价值==1单位商品。此时如果所有人将货币兑换为黄金，则货币作废，同时黄金全部被兑换，两清。

一年后，社会总财富增长10000单位，到20100单位。

此时如果增发10000个单位货币。一单位货币将仍兑换一单位商品，实现稳定币值。但一单位货币只能兑换0.005单位黄金。即1单位黄金==2单位商品。假设社会总财富预期仍将增长，则可认为当下黄金价值被低估，持有黄金将获益，因此黄金将被大量兑换，货币体系无法维持。

如果增发10100个单位的货币，则单位货币能兑换的商品不足一单位，意味着货币贬值。

金本位货币的可行性不足。在经济增长的前提下，要么持续贬值，要么体系崩溃。

债务货币的定义。债务货币是指通过举债方式，获得抵押品，并据此发行的货币。同样，货币可以兑换抵押品。债务货币不同于金本位的特点有二：一是债务规模可变，二是债务可能需要付利息。注意，这里如果抵押品不是黄金等只有价值而基本无使用价值的商品，则造成使用价值的损失。

Question：

债务货币是否具有可行性？

My Answer：

根据借债对象的不同，分为两种。一种是在本经济体内借债，一种是对外部经济体借债。

根据借债规模的不同，分为两种。一种是债务规模小于社会总财富，一种是债务规模等于社会总财富。

对内借债且债务规模等于社会总财富。此方案实际无法实现——一个经济体不可能将其所有财富用于抵押。不过实际上不采用抵押方式，而采用强制力保证货币的兑换，却是可行的，这就是法币，这里不赘述。

对外借债且债务规模等于社会总财富。此情况下肯定要付给借债方利息。因为抵押品由外部提供，所以币值稳定肯定可以保证（只需按社会总财富提供即可，当然这里假设借债方的抵押品足够）。假设借债方规模无限的情况下，此体系同样不会崩溃。理论上此体系可行。但是现实中基本不可行——抵押品不可能太多，利率常常超过社会财富增长速度，从而导致经济负增长。

对内借债且债务规模小于社会总财富。假设初期为平衡状态，即社会财富的一半被抵押。假设社会总财富20000，抵押10000，使用中10000，发行10000货币。一年后，使用中财富增长20%，即社会总财富为22000。此时如增发2000货币，即总流通货币12000，可维持币值稳定，且不增加举债规模，但这同金本位一样，会引起抵押品被挤兑。如增发1000货币，同时增加1000举债，则可维持币值稳定——但同样不可行，因为这样的话举债规模始终占社会总财富的一般，浪费太大。

对外借债且债务规模小于社会总财富。这个情况没什么意义，抵押失效。

债务货币和其类似体中，只有法币是理论上可行的。

您可能也喜欢：
抗通胀，不收货币万万不能	CQRS体系结构模式	地瓜熊老6的囧生活（2）	Rule 34 of Durex
无觅

写个评论

我不准备跟你解释原因，因为我决定趁着这屎还够新鲜的时候，把脑子里的一些东西记下来。

起因是早上看到了一篇文章，《从2011年F8大会看Facebook的野心》。于是又顺路关注了一下F8大会：http://tech.sina.com.cn/z/f82011/index.shtml。

简言之，Facebook继续推进他们在去年提出的Open Graph理念，将外部内容和服务整合进Facebook的页面。有点像百度提出的“框计算”。

此举很明智。理由如下：

1.只有给用户提供价值的产品和服务才能存活

2.SNS提供的基本价值是更新用户的社交信息，但这点价值不足以支撑任何一个SNS平台的存活

3.SNS必须不断获得更新、更深入的用户信息才能提升服务

4.分享新鲜事的热情下降以后，用户必然寻求有价值的信息和服务，而不是继续产生垃圾信息

5.引入外部内容和服务后，Facebook既能提供给用户更多有价值的信息和服务，又能获得更深入的用户信息

我记得李彦宏刚提出框计算的时候，就有那么一撮人叫嚣：炒概念，没技术含量，百度的搜索做得差。这种人，你把“给用户提供价值”这样明艳、活泼、有力的一坨屎放在他的面前，他都会勇敢地踩上去。你看百度像是打算好好做搜索的公司么？

百度明显就是要做社区的么！

我突然又想起一点，那就是即使同样提供有价值的内容和服务，那你以什么的样的形式提供，也是非常要紧的。比如说最近涌现出来的各种问答社区，何其地传统，何其地循规蹈矩，何其地像他娘的百度知道！

既然是问答社区，难道不应该像人类之间的问答一样么？一个框就够了，我输入问题，如果能找到答案，立即显示；否则，就立即把问题post出去，推给有可能知道答案的人。

所以你看，有两个很关键的点，一个是立即，一个是推送。

当然，现在的问答社区有点推送的模样，但是远远不够即时。我来请教个问题，不想等到黄花菜都凉了。

最后，我认为用户价值就是两点：第一，有用；第二，用得爽。

我觉得这个总结也是非常明艳、活泼、有力，像一坨新鲜的屎一样。

题外话：你看马克的手势，刚好和乔布斯的标准演讲手势相反，马克内敛、乔布斯开放。其实，乔布斯的意思是，你们赶快来用我的产品，所以他要用推的手势；马克的意思是，你们丫的都来我的平台帮我整内容啊，所以，他要用抱的手势。

您可能也喜欢：

罗杰·迈克奈米:社交网络已经完结

百度数据：3C电子商务平台的用户竞争主要发生于同类平台之间

说说新浪微博的SNS化

不再让你受伤害

无觅

写个评论