GFS: Evolution on Fast-forward

转载自ACM Queue – GFS: Evolution on Fast-forward

A discussion between Kirk McKusick (known for his work on BSD Unix, including the original design of the Berkeley Fast File System) and Sean Quinlan (served as the GFS tech leader for a couple of years and continues now as a principal engineer at Google) about the origin and evolution of the Google File System.

The discussion starts, appropriately enough, at the beginning—with the unorthodox decision to base the initial GFS implementation on a single-master design. At first blush, the risk of a single centralized master becoming a bandwidth bottleneck—or, worse, a single point of failure—seems fairly obvious, but it turns out Google’s engineers had their reasons for making this choice.

可能和我们想象中Google的分布式系统设计原则完全对立的一个决定,是如何产生的呢?这段对话就是从这个有趣的话题开始的。

整个对话在两个对文件系统有着深刻理解的业界专家之间展开,从分布式体系的设计思路及其演进、吞吐和延迟的取舍、性能瓶颈的解决策略,以及GFS和 BigTable之间相辅相成的内在联系。印象中这还是Google第一次在公开场合提及大量GFS的运作方式和实现策略的细节,强烈推荐给做分布式系统的技术人员!


GFS: EVOLUTION ON FAST-FORWARD
A DISCUSSION BETWEEN KIRK MCKUSICK AND SEAN QUINLAN ABOUT THE ORIGIN AND EVOLUTION OF THE GOOGLE FILE SYSTEM.

During the early stages of development at Google, the initial thinking did not include plans for building a new file system. While work was still being done on one of the earliest versions of the company’s crawl and indexing system, however, it became quite clear to the core engineers that they really had no other choice, and GFS (Google File System) was born.

继续阅读GFS: Evolution on Fast-forward

探究Google的Iterative Web App软件架构

Google的软件架构向来是最吸引广大开发者的眼球并被人们乐此不彼的津津乐道,尤其是那些运作在Google最杰出服务背后的软件架构。

Google在2004年“愚人节”推出的Gmail服务可以说是Google众多服务中,除搜索外最杰出的典范之一。Gmail在过去五年多的时间里,也经历了一个持续发展和演进的过程。新功能的推出和用户体验的改善或许是大家谈的最多的,但其底层架构的变迁却并不常常能被用户切实感受到。其实,正是因为Gmail底层架构的不断升级,才支撑其众多新特性和功能的更快开发并上线。

早在2007年10月,Gmail的官方Blog上就曾经发表过一篇关于其架构变迁的文章“Code changes to prepare Gmail for the future”,其中提到:
继续阅读探究Google的Iterative Web App软件架构

Twimoby is ready for closed-beta test

Twimoby (follow us on Twitter) is a web service mainly focus on mobile twitter experience. At present it is only tested on Nokia S60/Symbian platform.

Features:

  • No client needed. Just use the built-in Email client in your phone to access most of the twitter services. (need IMAP support in the Email client, S60 confirmed)
  • Public timeline / Friends timeline subscription.
  • Keyword watch (Twitter search) subscription. (under implementation)
  • Automatic update, without user activities. (need phone support, S60 confirmed)
  • Notification for new message. (need phone support, S60 confirmed)
  • Show recent messages on idle screen. (need phone support, Nokia E-series confirmed)
  • Send your twitter message just like regular SMS or Email. (under implementation)
  • Reply on message directly to act as @someone. (under implementation)

In Plan: (only for some operators)

  • TRULY message push support. Only connect and fetch when new messages shown up, without persistent or periodic connection. Greatly save your network cost and extend the battery life.

Tweets shown on idle screen:
Tweets on Idle Screen

Write new tweet:
Write new tweet


We are currently looking for testers for our first closed-beta test. If you have a smart-phone of Nokia S60 3rd, have some twitter basis, and want to participate, please reply on this post. We are expecting your participation!

Source code of FontRouter is released under Apache License 2.0

FontRouter is an open font rasterizer plug-in (also called “font driver”) for Symbian. It is started about 4 years ago, initially for improving the Chinese font support on Symbian.

With more than 3 years’ development, FontRouter extended its functionality to language-neutral & UI-independent and give user more controls over font mechanism on Symbian, such as loading 3rd-party font file, font substitution, size adjustment.

For some personal reasons, FontRouter project was discontinued for more than one year, but many users still kept writing to me for suggestion and bug report in these days. Since I can’t face their expectation, I decided to open source and wish it a better future.

As discussed and reconsidered carefully, I released the source code under Apache License 2.0, but not GPL. I hope someone or even some commercial company could continue or derive from this project and present a quality production for the Symbian community.

If you are considering continuing this project or deriving from it, please mail to me, and I will give my support.

SUPPORT WILL ONLY BE OFFERED TO OPEN SOURCE CONTINUATION OR DERIVATION.

At present, source code is hosted on Google Code: http://code.google.com/p/fontrouter/

FontRouter将于近期开源,期待后继有人

由于很长时间没有继续维护和开发FontRouter,却时常有网友发信来询问近况和报告问题,让我觉得很对不起大家长期以来的关注和支持。为了不让这个有用的小工具就这样默默死掉,希望后续有人能继续其开发,造福广大Symbian玩家,遂决定将其开源。初步考虑以GPL协议发布源代码。(如果有更适合的开源协议也欢迎建议)

如果有人愿意继续其开发,我将尽我所能的提供支持!

UPDATE: Source code of FontRouter is released under Apache License 2.0

S60待机界面原来并非不能扩展

之前在Nokia开发者论坛上看到的较为正式的解释是:待机(“Active Idle”或“Active Standby”)界面插件在3rd FP1及之前的版本中是无法由第三方开发的,因为它们被限制为只能从ROM中加载。就我对ECOM的了解,插件调用者确实可以通过内置的ROM Resolver限定只从ROM中加载插件,因此当时我也就相信了这些所谓的“专家答复”。

不过,今天在ipmart论坛发现的一个软件使我重新开始质疑上述陈述。这个软件是一位高手从E71中提取出来的程序,引起我关注的一点是其中包含了一个“Active Idle”插件,它在我的E90上完全可以正常工作。出于好奇,我解开这个sis文件看了看,发现插件部分完全是一个标准的plug-in。也就是说它并没有采用“stub升级”,“偷换原有插件”等手段达到添加新插件的目的,而是光明正大的将自己注册为一个标准的ECOM插件。

看来Nokia开发者论坛上那些打着官腔的回复恐怕并不那么“官方”和“专业”,为了兜售其API Partner计划也不用连坑蒙拐骗的伎俩都祭出来了吧……

有空来反汇编一下,看看能不能自己写一个Active Idle的插件玩玩。

Java集合中的泛型为什么不能Upcasting?

典型的例子是:List<Object> objects = (List<Object>) new List<String>()

可能很多人(包括我在内)起初都会认为这是无法理解的。那么请看下面的代码:

objects.add(new Integer(7));

假设前述的类型转换成立,那么这个objects实例中不就可以加入新的Integer项了?这等于是破坏了List<String>的约束。由于这个反例的存在,所以上述类型转换是不被Java所允许的。

PC-Lint终于迎来了9.0版本

从2001年的8.0、8.0a一直走到2008年的8.0x,PC-Lint v8一共延续了超过7个年头,估计不是考虑到26个英文字母的后缀都即将耗尽,Gimpel还舍不得用v9的版本号……

粗略看了一下v9的发布说明,相比v8确实有长足的进步(其实我想说的是,v8实在是发展的太落后了……)。不错,很好,很强大!

·终于加入了众望所归的线程分析,可检查锁使用的正确性以及可能缺少锁保护的变量。不过说实话我对这个特性尚持保留态度,因为多线程竞争分析在C/C++中是一个相当复杂的技术,还是等到试用之后再作评论。

·通过预编译头大幅提升复杂项目的检查速度。早该这么做了,PC-Lint对大型工程的检查速度实在不敢恭维。

·栈空间使用统计,可以汇总出单个应用的最大栈空间需求,只要程序中不存在递归并且是具有流程确定性的。赞一下这个功能,在嵌入式开发中尤其实用!

继续阅读PC-Lint终于迎来了9.0版本

C语言小技巧:带扫尾工作的宏

前两天为了在C下编写一个类似Erlang式消息传递的框架,需要定义一个receive宏,使得coroutine处理函数的编写可以类似这样:

int foo()
{
    ...
    receive(msg)
    {
        // Deal with the message
    }
    ...
    receive(msg)
    {
        // Deal with another message
    }
    ...
}

因为foo()函数以coroutine方式执行,所以消息的及时释放就显得尤为重要了,receive()之后紧接的代码块就是这个消息的生存周期,完成之后需要立即对消息进行释放。这就对receive宏的编写提出了一个特别的要求:包含扫尾工作。

继续阅读C语言小技巧:带扫尾工作的宏