About the Internet Explorer 7 User Agent

*    On Windows XP SP2, IE7 will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
*    On Windows 2003 Server, IE7 will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2)
*    On Windows Vista, IE7 will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)






并发性 - Erlang有着非常经量级进程,它可以动态的改变内存需求。进程没有共享内存和异步消息传递机制。Erlang为应用程序提供了,大量并发进程的支持。而在对于操级系统本身而言,没有并发需求。

分布式 - Erlang也被设计运行于分布式环境。一个Erlang虚拟机被称为一个Erlang节点。一个Erlang节点可以在另一个Erlang节点上建立并行运行的进程,可能用于其它的操作系统。进程位于不同的节点,可是通信方式与本节点的进程间通信方式是的一样的。

健壮性 - Erlang有着多种原始错误检测机制,可以用来构建容错系统。如,一个进程可以监视其它进程的状态,甚至另一个进程可能运行于其它节点上。分布式系统中的进程可以被配置成无效,以迫使它自动迁移到恢复节点上。

软实时性 - Erlang提供软实时性,即在毫秒级别做出反应。在这种系统下,长时间的垃圾回收的时延是不被允许的,所以Erlang使用增量式垃圾回收技术。

代码热升级 - 很多系统无法停下来,来做软件维护,如银行系统。Erlang允许程序代码在程序运行的时候被修改。旧代码可以同步的被替换成新代码。在转输的过程中,无论是旧代码还是新代码,可以共存。这样可以在不打忧机器正常运行的同时,升级并纠正BUG。

增量式代码加载 - 用户可以控制代码加载的详细方式。在嵌入式系统中,所有代码通常在引导的时候被加载的。在开发系统中,代码需要时才加载,甚至当系统运行时加载。如果只是测试遗落的BUG,那么只有有BUG的代码才需要被加载。

外部接口 - Erlang进程与外界通信,使用的是与Erlang进程间通信所使用的相同的消息传递机制。这个机制也常常用于主机操作系统,与使用其它语言开发的程序之间的交互。如果考虑到效率的话,还会用到一些比较特殊的概念,如:直接将C语言连入Erlang运行时系统中。

How do you explain cloud computing to your grandma?

Once upon a time I worked at an Asynchronous Transfer Mode (ATM) switch startup. Over a delicious Christmas punch my grandma asked me what I did for a living that I could afford such extravagantly inexpensive gifts. Always so subtle. I explained I worked on an ATM switch. Mistake. She sniffed, said that’s nice, and asked my why the Automated Teller Machine ate her bank card that morning. No matter how hard I tried I couldn’t convince her I didn’t work on bank ATMs. To all future job interrogations I waxed off, protesting I do boring software stuff that nobody cares about.

Not put off in the least, grandma asked me last night to explain this cloud computing thing she keeps hearing about at her church club. Afraid of being another victim of the distortion field surrounding cloud computing, I instead referred her to Kent Langley’s excellent overview of the subject in Cloud Computing: Get Your Head in the Clouds. It does a good job demystifying the very confusing concept of cloud computing. It has nice diagrams, definitions, examples and is a great place to start.

She agreed that she had learned a lot, but one thing still troubled her: what’s the difference between cloud computing and utility computing? They seem to be the same to her. Always so perceptive. She felt sure if she could drive this point home she would score big points with her church group. Oh the pressure.

I steadied myself and explained 3Tera’s take is that cloud computing is for service users and utility computing is for service builders. Cloud computing is essentially about the surrender of control. Users of a service like Salesforce.com don’t care how the site is implemented. They don’t care about how it scales, deals with failure, or any of the other 1000s of little details you have to care about when running a complicated operation. Users just want their service to work when they need it. Utility computing customers on the other hand require fine control over their resources because they are the builders of services like Salesforce.com. Cloud computing is built on utility computing. You couldn’t build a Salesforce.com on Google whereas you could build it on top of 3Tera or Amazon.

StorageMojo thinks all this cloud/utility nonsense is just foggy thinking. Real computing will stay local because the cost of network access is too high. Memory and CPU are plentiful and cheap while bandwidth is neither. Distributed computing 1990s style will still rule the day.

Mike Nygard thinks there’s A Cloud for Everyone in the future. Latency matters and “Keeping your endpoints on your own network at least lets you control your own latency.” Security matters and pushing your precious data into the hands of strangers isn’t secure. Yet we see SalesForce, Google Docs, Basecamp, SugarCRM, and hosted email all flourishing so is privacy really a concern for newer generations trying to get stuff done?

HP’s Patrick Eitenbichler thinks “utility computing refers to a business model, while cloud computing describes the underlying IT architecture” with the real decision point being “utility/cloud computing vs. purchasing your own IT assets.”

Geva Perry writing for GigaOM essentially agrees with Mr. Eitenbichler saying: Utility computing relates to the business model in which application infrastructure resources — hardware and/or software — are delivered. While cloud computing relates to the way we design, build, deploy and run applications that operate in a virtualized environment, sharing resources and boasting the ability to dynamically grow, shrink and self-heal.

Krish tries to condense that down to: cloud computing is software as a service (where companies run their own software) and utility computing is hardware as a service (where you can run your own software).

Margaret Rouse makes a good case for cloud computing being just a better marketing concept for utility/grid/cluster/distributed/parallel computing.

Bits or Pieces smartly ignores saying the word cloud but my impression is they think providing Software as a Service on a utility computing basis is the game changing innovation.

James Urquhart defines the cloud to include: SaaS, PaaS (e.g. force.com) and HaaS (e.g. Amazon, Mosso, etc.). SaaS is in clearly in play today, HaaS is being experimented with, but PaaS may be the most interesting facet of the cloud in the long term.

Keystones and Rivets finds that “The Cloud” is grid computing wrapped up in a service offered by data centers.

Confident I must have answered her original question, I asked “Now, doesn’t that clear things up grandma?”

Grandma sniffed, said that’s all very nice, but she still wanted to know why the ATM ate her bank card! I groaned and said “Goodnight grandma. I’ll call again next week.” “Excellent,“ she Cheshire smiled, “next week my church group is going to tackle if social networks are really monitizeable.”