分享

      北斗官网www.beidou.gov.cn消息，北京时间 2010年11月1日0时26分，我国在西昌卫星发射中心用“长征三号丙”运载火箭，成功将第六颗北斗导航卫星送入太空，这是我国今年连续发射的第四颗北斗导航系统组网卫星。

      此次发射的卫星和运载火箭分别由中国航天科技集团公司所属中国空间技术研究院和中国运载火箭技术研究院研制。这是长征系列运载火箭的第133次飞行。

      这次的亮点之一，笔者认为，是中国卫星导航系统管理办公室在发射中首次在运载火箭上使用了北斗卫星导航系统标志。蓝色圆形标志包含有北斗七星、司南、网格化地球等元素以及北斗卫星导航系统的中英文名称。这个设计好，老祖宗的司南、北斗和现代的数字地球都不能忘了，立意首先要高远才有进一步发展的空间。官方的表述当然更加冠冕：“表明北斗系统星地一体，为全球提供高精度、高可靠的定位、导航和授时服务的行业特点，展示其开放兼容、走向世界、服务全球的建设宗旨。”

      很有意思的是，各种官方媒体报道包括中新社和北斗网都没有说明这次卫星的类型。但是从发射兵器长三丙来看，笔者认为，这次发射的是北斗二代同步轨道4号星（COMPASS－G4） 。

      至此，北斗二代总共发射的六颗星为：同步轨道卫星四颗，顺序为COMPASS－G2、COMPASS－G1、COMPASS－G3、COMPASS－G4；中轨星一颗 COMPASS－M1；倾斜同步轨道一颗：COMPASS-IGS1。

分享

分享

【陈怀临注：Flipboard一夜飘红。其秒杀业界的根本就是：做一个最完美的系统；最简单的系统。。。BTW，此外为转载。原文可参阅互联网：-）。】

Flipboard真是一个奇迹。如果你有iPad或是对平板电脑感兴趣的话，那你很可能听说过Flipboard。Flipboard正如它自己所标榜的那样，是“社会化杂志”。它是一款免费的应用程序，让人们能够在一个比杂志更像杂志的界面上，浏览多个SNS服务和RSS订阅。在众多iPad程序中，Flipboard取得了很多第一。

苹果公司第一次接到深夜电话，请求他们不要再推荐这个应用程序了。因为Flipboard的服务器己经不堪重负。

它也是第一批将邀请系统融入App Store机制的应用之一。官方数字尚未公布，但是我觉得它会打破一些记录，比如程序首次发布五分钟内的下载量。

自打我安装Flipboard之后，我完全改变了获取信息，以及和朋友进行交互的方式。根据Flipboard创始人Mike Mccue的说法，在近期我们将看到一些很重大的改进，最重要的一个是缓存能力，这将减轻服务器的压力，给用户提供更流畅的体验。

作为开发者，你想达到Flipboard这样的成就吗？

我们可以从它的创始人、发布过程以及应用本身学到很多东西。我根据自己的想法，列出了以下几条：

一、简单：注意到Flipboard上基本上没有按钮选项吗？对，因为确实没有。简单得不能再简单了。我用过上百款应用程序，有时候真不知道开发者在想什么。似乎这些人认为，加上了无数复杂的选项和功能以后，人们就会更喜欢他们的程序。但想法和现实之间的差距太大。无论何种程序，你应该保证它能满足某种诉求。可以是娱乐，或是一个实用工具，无论是什么，只要人们想要使用就有价值。接下来使它极尽简单。如果你在犹豫是否加入一个或多个可选项，毫不犹豫的丢弃吧。你需要做的就是保持简单。如果一个用户第一次打开你的程序后，20秒钟内没有理解如何使用，他们很可能会删除它。让它淹没在茫茫30万个程序堆里。

二、可扩容：Mike通过深刻的教训学到了这一点。当他们将要发布这个程序的时候，他问总工程师需要多少台服务器。总工程师给了他一个数字，Mike说：“OK，在正式发布的时候，增加一倍的数量。”但是，由于Flipboard获得了社区对它前所未有的大量宣传，服务器数量很快就不够了，于是服务器就崩溃了，他们不得不用“邀请”的手段来限制新用户，这对苹果来说确实是一件新鲜事，对于Flipboard团队也是意料之外。这里的教训是，如果你作为一个开发者，对自己的产品充满自信，也相信别人会喜欢它，应该考虑到数秒内就会有成千上万的下载量。如果你不相信你的产品有那么好，那就别发布它。

三、创造力：我不打算去谈论这个应用背后的创新能力，后面我再仔细地说说。我指的创造力是如何解决由于服务器原因带来的下载问题和糟糕的用户体验。邀请系统的加入很有创造力，而且这种方式不会激怒用户群，同时使用户有继续使用下去的动力。这需要极大的创造力，因为这个方案以前很少被采用。这有些夸大，因为我只能想象他们团队看到自己的服务器在数分钟就宕掉时所感到的压力。

四、即兴：这是上一点的继续，但仍值得单独提出来。AppStore每天都有大量的程序提交和下载，加上苹果令人讨厌的政策，你可能为自己招致灾难。有太多变糟的可能性，在Flipboard这件事情中，变糟的事情恰恰因为它做的太好，导致了太多的下载。这里的教训是，作为一个开发者，在遇到技术挑战的时候，你需要即兴发挥。另一个好例子是AppsFire和Appstream，在过去的几周内是最受欢迎的五个iPad应用之一（它甚至超过了Flipboard）。关于他们的故事，请读这里。

五、坚持：Flipboard从它发布第一个版本以来，始终坚持升级和更新数据。这可能是大家不太了解的地方。你不仅仅是开发出一个应用，通过审批，然后就坐下睡大觉，再然后开始数钱。你得吸引一个社区，保持社区的兴趣和不断创新。正如我所说，Flipboard的新版本很快就出来了，有着缓存的特性，这是我从第一天就希望做到的。像这样不断的改进，让我一直保有兴趣，忠诚。

六、引爆流行：我觉得不是每个程序都能做到像Flipboard这样爆炸式的流行。我个人从来没有见过有什么应用可以得到如此之多的网络领军人重要评价。过去的一个月里面，如果你不曾写过有关Flipboard的报道，会显得你特立独行。Flipboard团队显得没有准备，这点不应受到批评，因为像这样大受欢迎的事儿，没有其他应用曾做到过，但是如果你准备放出程序，这就是一堂值得学习的课。永远不要低估互联网的传播能力。最糟糕的情况，可能比你预想中还糟糕十倍。

七、灵感：这是迄今为止能从Flipboard中学到最重要的东西。如果你正为了挣外快而身处这个平台之中，勤奋在多数情况下都管用，但要成功，灵感很重要。Mike讲了自己如何想到这个概念的。其实他当时并没有考虑到商业模式。那时，他刚卖掉他之前创办的公司，正四处旅行。在飞机上读了好多杂志，突然他灵光一闪，想到“为什么不把这种体验带到电脑上去呢？”这个想法最初是想作用于网络阅读，可能会用到HTML5技术，当时还没有iPad。现在iPad就正如Mike曾经宣称过的那样“就像假期到了一样，我们互相打招呼：iPad日快乐”。很明显，iPad是这个产品完美的平台。一旦开发团队决定在iPad上面进行开发，就全力投入，几乎没有休息时间了。

个人魅力

Flipboard在它第一轮的融资中获得了100万美金，当一些著名的记者和博客在Flipboard发布之前采访了Mike之后，都说Mike的个性（和眼光）起了很大作用。我不想把人物个性添加为第八条。但抛开产品不谈，一个人能够让说服投资人为自己筹集资金，最终达到Flipboard的成就，说明他本身就有着很好的人际交往能力。《华尔街日报》的记者KaraSwisher曾告诉我，Mike拥有令人着迷的眼神，这显然不会有什么坏处。

谈谈广告

在提到商业模式的时候，Mike言语出色的谈到网络广告产业，并把它跟杂志行业对比。总之，网络广告和网页内容在吸引读者的注意力上有冲突。对于出版商、广告商、读者来说不是好消息。杂志的广告方式清晰而有结构，这让阅读广告时眼睛感到舒服而且更容易产生消费欲望。

Mike指出，如果要为的读者提供两种形式的杂志，一种有广告，另一种则没有。读者们往往会选择有广告的那种。读者喜欢在杂志上阅读精美的广告，它们更有趣，更吸引人。在网络上，广告让页面载入变慢，让读者不再注意文章的内容，而且让读者感到烦躁。Mike说要让Flipboard实现杂志的广告概念和方式。

分享

分享

莱克斯科技(北京）有限公司 LYX Solutions Inc. 创建于2005年。作为专业的内容和应用安全设备提供商，LYX积累了多年内容与应用安全产品研发和市场运作经验。莱克斯科技主要产品有Netoray NSG上网行为管理系统、Netoray TOG 流量管理系统和ClearNet NA（易网析）网络行为审计系列产品，已经为内容和应用安全领域树立了新的产品质量水平，在国内各高校，运营商，大中小型企业及各、能源领域中拥有了强大的客户群体，并赢得了用户的高度肯定。

尽管其宣传是性能最好的上网行为管理产品，不过从其产品的功能和规模来看，目前可能还达不到电信公司的要求，做的最多的大型客户也就是省级运营商和天津大学客户。双向流量估计能达到5～6个G。应该比网康和深信服还是要强的了…

莱克斯科技没有风投（VC），据了解，该公司在加拿大有石油背景的资金支持。主要股东和CEO是一位留学生，加拿大Alberta 大学计算机专业毕业，专业是Team Building。尹志超先生曾是中国最早一批Linuxer之一，在创建莱克斯科技之前，他是一个热情的开源社区活跃爱好者。他具有多年高科技行业工作经验并持有多项专利，创建莱克斯科技之前应该有两、三年管理经验。另外的一个股东兼首席架构师是一位来自大陆的华人，邢越，非常聪明的一个人，80年代末北京市高考第六名，北大和莫斯科大学学士，硕士，Alberta大学博士，多年国际知名网络公司经验。公司的核心团队由来自IBM、Juniper、HP华为等著名企业的精英组成。莱克斯科技是北京市高新技术企业、双软认证企业、获得2007国家创新基金重点资助、第二届“春晖杯”留学生创新大赛一等奖。

从市场竞争上来看，该公司的Netoray 和ClearNet系列产品竞争对手太多，专业厂商如网康，深信服等。所以，由于竞争激烈、对手众多，一个网络安全方面的初创公司要想有所作为，只能立足技术和创新，该公司的数据流并行处理（ECS）和USAP平台的效率非常高，为产品打下了非常好的基础。但在v5.6和以前的产品化方面较弱一些，还是明显看到研发的痕迹。最近发布了6.0版本，据说在产品化方面做了很多的工作，尤其是按照OSI七层结构设计的管理系统让人耳目一新。而且其多角色管理特点更是能够和目前OA系统整合，更好地体现出互联网管理系统的管理特点。但是面对这么多的专业厂商，要想突围出来，尤其考验管理团队的能力。

分享

分享

这是IETF会议第一次在中国召开，会议的举办单位是清华大学。IETF是国际互联网协会（ISOC）领导下的全球互联网技术开发和标准制定的唯一组织。在中国举办IETF大会对推动中国参与国际互联网技术开发和标准化工作有着非常重要的战略意义。

IETF 79: November 7-12, 2010, Beijing, China
•2010-11-01 (Monday): Registration cancellation cut-off at 17:00 PT (01:00 Tuesday, November 02 UTC).
•2010-11-05 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local Beijing time. (02:00 PT, 09:00 UTC).
•2010-11-07 – 2010-11-12: 79th IETF Meeting in Beijing, China.
•2010-12-10 (Friday): Proceedings submission cutoff date by 17:00 PT (01:00 Saturday, December 11 UTC), upload using IETF Meeting Materials Management Tool.
•2011-01-05 (Wednesday): Proceedings submission corrections cutoff date by 17:00 PT (01:00 Thursday, January 6 UTC), upload using IETF Meeting Materials Management Tool.

分享

分享

ITU的SDH/Sonet技术发展遇到了瓶颈，不能满足日益增长的数据业务需求了，于是自然而然的想到找一个取代技术。而ethernet, IP/MPLS发展得如火如荼，各种新技术层出不穷，可惜，很多地方不适合做电信级传输网，于是ITU就想到对MPLS进行改良，用改良后的MPLS来做packet transport network，这就是T-MPLS。

可是ITU没料到的是，由于T-MPLS对MPLS的改动有点伤筋动骨，导致了跟MPLS的不兼容，触及到了IETF MPLS阵营的核心利益，就好像我辛辛苦苦搞了一个发明专利出来，你一声不响的拿过去，改头换面，准备推广赚钱，我自然是不答应。结果就是T-MPLS还没大面积推广，就受到了IETF的强烈抵制。于是在争吵与妥协中，ITU和IETF联合工作组MEAD成立了，MPLS-TP诞生。

联合工作组MEAD中，IETF占据了强势主导地位。制定标准的过程中也不忘了利用自己的特权攻击一下ITU，RFC5704把这种行径暴露无疑，我电脑上的RFC 5704我给它还取了一个后缀，整个文件全名是RFC 5704—扯皮.txt,其实不是扯皮，是IETF攻击ITU.现摘抄几段：

2.4章我把它称为“争权”

A code-point such as an IEEE Ethertype is allocated to a design authority such as the IETF. It is this design authority that establishes how information identified by the code-point is to be
interpreted to associate appropriate invariants. Modification and extension of a protocol requires great care. In particular, it is necessary to understand the exact nature of the invariants and the consequences of modification. Such understanding may not always be possible when protocols are modified by organizations that don’t have
the experience of the original designers or the design authority expert pool. Furthermore, since there can only safely be a single interpretation of the information identified by a code-point, there must be a unique authority responsible for authorizing and documenting the semantics of the information and consequential
protocol actions.

In the case of IP and MPLS technologies, the design authority is the IETF. The IETF has an internal process for evolving and maintaining the protocols for which it is the design authority. The IETF also
has change processes in place [RFC4929] to work with other SDOs that require enhancements to its protocols and architectures. Similarly, the ITU-T has design authority for Recommendation E.164 [E.164] and
allocates the relevant code-points, even though the IETF has design authority for the protocols (“ENUM”) used to access E.164 numbers through the Internet DNS [RFC3245].

It is a recommendation of this document that the IETF introduces additional change mechanisms to encompass all of the technical areas for which it has design authority.

2.5章我把它称为“隐式攻击“

It may be tempting for a designer to assert that the protocol extensions it proposes are safe even though it breaks the invariants of the original protocol because these protocol variants will operate
as ships in the night. That is, these protocol variants will never simultaneously exist in the same network domain and will never need to inter-work. This is a fundamentally unsound assumption for a
number of reasons. First, it is infeasible to ensure that the two instances will never be interconnected under any circumstances. Second, even if the operators that deploy the protocols apply
appropriate due diligence to ensure that the two instances do not conflict, it is infeasible to ensure that such conflicting protocols will not be interconnected under fault conditions.

3.1章我把它称为”显式攻击”

A recent example where another SDO created a protocol based on misunderstandings of IETF protocols is T-MPLS. T-MPLS was created in ITU-T in an attempt to design a packet-transport method for
transport-oriented networks. This is an example of the success that IETF protocols have enjoyed, and ITU-T’s interest and selection of MPLS is a compliment to the IETF work. Quite late in the ITU-T
design and specification cycle, there were a number of liaison exchanges between the ITU-T and the IETF, where the IETF became increasingly concerned about incompatibility of IETF MPLS procedures
and technologies with ITU-T T-MPLS [RFC5317]. Extensive discussions took place regarding interpretation, definition, and misunderstandings regarding aspects such as MPLS Label 14, MPLS swap
operation, TTL semantics, reservation of additional labels, and EXP bits. If ITU-T had worked with IETF from the start in developing T-MPLS, these problems could have been avoided. A detailed analysis
of the T-MPLS case is provided in Appendix A.

顺便提一下，这个RFC的三个作者都是IETF的，其中两个是Cisco的，一个是IAB(Internet Architecture Board)的：）

分享

分享

【陈怀临注：我在听到这个消息的时候，感觉是：要不信谣；不传谣。。。固然，华为公司辟谣了。如果我是任平，我就天天打高尔夫，或者像陈首席一样，做点比挣钱的境界略微高一点点的事情。。。好像政治家都希望自己的子女远离政治；难道资本家就不理解这一点？拿着股份就够了。干嘛要去天天operation。多累呀。。。任正非应该是个聪明人；当然，聪明人也可能犯错。或者是他儿子有这个抱负。。。从我的个人观点，华为的成败有两个坎：1.接班人的问题；2. IT业转型的问题。没处理好，华为的风险就极大。。。目前来看，华为是中国高科技的一个代表。华为乃华为人之华为；华为乃中国之华为；华为乃天下人之华为。希望华为能顺利。。。】

　　华为声明全文：

　　感谢大家对华为公司的关心和厚爱。

分享

分享

虽然现在云计算应用主要以由Amazon EC2为代表的IaaS（基础设施即服务）服务和由Salesforce CRM为代表的SaaS（软件即服务）服务为主，而PaaS（平台即服务）服务则处于比较“小众”的阶段，但是由于PaaS服务在开发环境、管理、伸缩、整合率和经济性等方面的优势，使得其的未来非常值得看好，所以基于YunTable的PaaS服务YunEngine诞生了。在功能上，YunEngine参考了Google App Engine，但与Google App Engine支持Python和Java两种语言，以及提供图像处理、邮件、Memcache和任务队列等多种服务不同的是，YunEngine暂时只支持Java，和Web与数据存储这两个基石级的功能，它的目标是作为一个平台来支撑企业级Java应用的运行，其后端是一个YunTable的集群。还有，值得注意的是，YunEngine应该是国内第一个提供Java语言支持的PaaS，下面将分别对YunEngine的基本架构和路线图进行介绍。

YunEngine的架构

图1. YunEngine的架构图

由于现在YunEngine还处于初创期，其架构显得非常简单，主要由AppServer节点和YunTable集群这两部分组成。

AppServer节点

这个节点主要由一个或者多个Jetty服务器组成，通过这个服务器能很好地支持基于Java Servlet API的Web应用，包括最新 Servlet 3.0。为什么选择Jetty而不是更常用的Tomcat呢？因为在代码方面，Jetty不仅更模块化，而且总量较少，所以在定制化方面非常有优势，这点对YunEngine的未来发展而言非常关键。

现在，Jetty服务器除了运行Web应用之外，还内置一个支持后端数据库为YunTable的JPA（Java Persistence API）实现，名为“YunJPA”。当运行在Jetty中的Web应用需要调用JPA的功能来执行数据处理相关操作时，Jetty会给这个应用生成一个基于YunJPA的EntityManager接口，应用会通过使用这个接口来访问后端的YunTable集群，从而完成和数据处理相关的操作。

YunTable集群

在AppServer节点之后，用于存储数据的，就是一个运行YunTable系统的集群，其主要包括两种类型的节点：其一是Master节点，主要用于管理整个集群，其功能包括数据库表的创建、数据备份的管理和Region节点的容灾等，并且在一个集群中只会存在一个；其二是Region节点，其功能较简单，主要用于存储数据，而且一个集群中会有多个。

路线图

到现在为止，基于大概半个月左右的开发，Web和数据存储这两个核心功能都已经基本实现了，接下来，按照计划，YunEngine将会有下面这几个重要的里程碑（Milestone）。

表1. YunEngine的路线图

最后，熟悉Google App Engine人都知道，其实已经出现了类似AppScale的开源项目，那么为什么要重新发明“轮子的轮子”呢？原因是：由于AppScale有很多核心技术都是依赖第三方，比如，数据库方面采用了Cassandra和Voldemort等，它所做的主要只是拼装而已，所以从长期而言，其可发展性不佳，因为不同的第三方产品和技术，它们在接口和内部机制等方面都会有所不同，如果硬要在将它们完美地整合在一起，这将会是极其艰难的，而YunEngine由于其最核心的，同时也是技术上难度最大的存储功能都是控制在自己手中，所以有信心对YunEngine进行不断地优化和修改，以使其更出色和更稳定。如果大家对YunEngine的未来有什么意见和兴趣的话，可以在本贴中进行进一步地讨论，还有，谢谢大家一直以来对我的支持。

分享