Results tagged “Google”

在 Alexa 上观测最近的一些数据的变化，发现了一个奇怪的域名: 1e100.net ，全球排名 45 。乍看上去，这个域名非常山寨，不过查询一下，发现这居然是 Google 的域名。Google 的名字是 Googol 这个单词拼错得来的，而 Googol 就是 10¹⁰⁰ 这个大数。1e100 = 1x10^100 = Googol (refer)。Twitter 上也有网友对此进行了提示。

这么看来，1e100 这样的域名风格倒是很 Google 化。从网上的反馈看，Google 有不少服务都在使用 1e100.net 这个域名，最多的应该是 Google Chrome 浏览器的 Safe Browsing 特性对地址的使用(对 Firefox 也有影响)，而且会启用较多的并发连接，所以会有网站对此带来的压力无法承受而屏蔽 Google 的这个服务(refer)，此外也让我想起以前 Google Chrome 早期的版本解析 DNS 多少有点慢，不知道是否有相关因果关系。Google 的其它产品包括 Google Toolbar、Google Analytics、YouTube 、FeedBurner 等服务也用这个域名。也有人发现 Google IPV6 地址也是通过这域名在进行测试。不过直接访问 1e100.net 是访问不到的，Google 通过子域名的形式进行使用。

按理说，这种不对外提供服务的地址，Alexa 没必要统计流量的，或许是他们的小失误倒是让我们了解到 Google 的一点有趣的信息。

--EOF--

更多参考：

• Why is goog using 1e100.net? 解释了为什么不是 10e100.net 。
• Google 的 Project 10¹⁰⁰ 项目。
• Google doppelgänger casts riddle over interwebs

更新：最新的消息说是 Google 不同数据中心间用来" identify servers, hinting that reverse DNS plays a role" ，关键词"Spanner"。

在看到 Google 的 公开信 后，我在 Twitter 上说"宁与玉碎不为瓦全。也好"。之后一直想写点什么，不过在这个时候，阐述对这件事情的看法，很难不被淹没到口水战里。

揣测 Google 这样做的动机与商业目的对我们大多数人来说没有什么实际意义，不如让我们把讨论的焦点放在这次事件背后的问题上：这次实际上是客观承认了"内容审查"（refer: Censorship）变本加厉的既定事实，也让更多人知道了这一现状对社会带来的负面作用。对互联网的不当隔离与审查是不符合普世价值的，尤其不符合人民群众对于"先进生产力的发展要求"，是民众无法认同与接受的做法。Google 对于互联网来说是先进生产力的绝对代表者，如果将其拒之门外，那么可以肯定这无助于社会的进步。

如果说出于政治目的的审查有其可解释性，但是为了"倒洗澡水而把孩子也倒掉"则是极其错误的做法(当然，表面上都是以一些类似"保护未来的花朵"为借口，这和过去那些重大对立冲突的导火索何其相似也)。这种错误的做法还包括前一段时间的 IDC 整顿、域名整顿等一系列事件乃至要推行网站白名单的传说，这些都是操作层面上的极度不当。"疏"与"堵"，历史给我们带来无数次的经验教训，后者无疑是饮鸩止渴。我不知道在皇帝的新装的那个故事中，喊出来那家伙其实什么也没穿的小孩受到了什么对待，也不知道皇帝是否再次上演新装的闹剧。是在我们这里，似乎这样的闹剧无时无刻都在上演。

上网十年，从一个乐观者变成了悲观者。历史有的时候是进一退二，有的时候是以退为进，还是让我再乐观一次吧，期待 Google 这次准备撤离会唤醒我们更多的思考，给我们带来哪怕是一点点的进步。

--EOF--

更新：

在审查过程中造成的直接和间接的经济损失似乎少有人关注，不知道是否有经济学人关注这一领域。如果有人算一笔经济账，恐怕会是个惊人的数字。而有关部门相信也是投入了大量人力物力的，这也是不小的资金开销。

Image via Wikipedia

技术爱好者大多都知道 Google 是使用 Linux 的大户，但是一直以来对于他们如何使用 Linux 却知之甚少，甚至内核开发社区对 Google 内部使用的情况也了解不多。LWN 上的这篇 How Google uses Linux 给我们带来了不少信息。

Google 使用 Linux 肯定有很多令人震惊的地方，第一个令人"惊讶"的是他们使用的代码管理工具：Perforce 。代码维护方式看起来也比较落后，当前维护的代码版本远远落后于开源社区内核版本，因为 Google 自己要维护大量的内部特性，每一个大版本发布周期是大约 18 个月，而内部特性的回归也要折腾6个月。因为版本滞后，所以有不少向后移植(Backporting)的工作要做，这个比例大约是 25%，还是不小的。

Google 内部大约有 30 个内核开发人员，而之所以外界很少看到 Google 对 Linux 的 Patch 代码，主要的原因居然是--担心代码不够优雅。我想这应该说的是大实话。我也遇到过很好的开发者对开源软件做了改进之后不愿意把代码贴出来，原因就是担心代码不好看，怕被笑话。

因为应用程序类型之故，对于 Google 来说，完全公平调度器(Completely Fair Scheduler)并不适合，采用了 O(1) 调度器，一般 16-32 核的机器要跑 5000 个线程左右。

Google 倒是喜欢用 Out-of-memory (OOM) killer 特性，这倒是出乎我的意料。Google 对于内存管理方面的改进或许是不小的突破: 通过伪 NUMA 模式来保证不同类型应用对内存的使用。除此之外，有大量的代码用于系统的监控，针对磁盘、网络等子系统或者是针对应用程序性能。

对于计划中的将实现的新特性，在一堆列表中看到了在 I/O 层对于高速 Flash 盘的支持计划。在文末，另一个有趣的技巧是，Google 喜欢把文件系统的元数据 Pin 到内存里以便提高读取响应时间。

或许将来能看到 Google 为 Linux 内核贡献更多代码，那会是一件很有意义的事情。

--EOF--

最近一直在考虑这个关于信息的"五分钟"的问题。搜索了一下，发现还很少有人考虑这个现象，思路还没有完全理顺，先抛几个观点等待大家的补充吧，期待能引发一些对信息处理的思考。

最早注意到这个现象是每次我 BLOG 更新之后，在大约 5 分钟左右，通过 Google 的 BlogSearch 就可以看到内容。这个倒很容易理解，因为我用的 Movable Type 在发布文章的时候会自动通知一下 Google 服务器。接到通知之后，Google 能够较快的把信息合并(Merge)到当前的索引中，但是应该还没加上非常严格的排序(Sort)，这是个很经典的处理技巧。

不过，Google 获得信息绝大部分是通过爬虫"抓取"，也就是"拉"(Pull)数据，只有少部分是用户"推送"(Push)的。这就导致 Google 在信息处理上节拍总要慢一点。Google 的目标是处理地球上的所有信息，无远弗届，但信息的及时性或许是最难解决的。

而 Facebook / Twitter / FriendFeed 等具备面向"实时信息流"(Real Time Lifestreaming)功能的网络应用，大部分信息都是用户"推送"上来的，所以也有天然的优势触及这五分钟之内的数据，并经过简单的局部计算之后呈现给用户。得到"即时"信息似乎是人的天性（另一个侧面的印证是人们无法摆脱手机而全部使用 IM 和电子邮件），所以五分钟之内的数据处理能力是对普通用户来说有着难以言明的吸引力。

"五分钟"只是个大致的说法，相信随着技术的发展，会缩短到三分钟，乃至更短。但这部分始终是 Google 无法完全覆盖的地方，技术没办法打败时间，这也是信息暗网的也无法解决的问题。最终我们发现，信息处理的巨人和信息处理的快刀手一起相处的比较融洽。

--EOF--

注：很明显，这个"五分钟"问题和我之前说的关于 I/O 的五分钟问题是不搭界的。