如果你经常看国外的大片，你应该会喜欢带字幕版本而不是有国语配音的版本。我在法国长大，童年的记忆里充满了迪斯尼电影。但是这些电影因为有了法语的配音而听起来很怪。如果现在有机会能看原始的版本，我想，对于大多数的人来说，字幕还是必须的。我很高兴能为家人制作字幕。给我带来希望的是，Linux 也不乏有很多花哨、开源的字幕编辑器。总之一句话，文中Linux上字幕编辑器的列表并不详尽，你可以告诉我哪一款是你认为最好的字幕编辑器。

1. Gnome Subtitles

当有现有字幕需要快速编辑时，Gnome Subtitles 是我的一个选择。你可以载入视频，载入字幕文本，然后就可以即刻开始了。我很欣赏其对于易用性和高级特性之间的平衡。它带有一个同步工具以及一个拼写检查工具。最后但同样重要的的一点，这么好用最主要的是因为它的快捷键：当你编辑很多的台词的时候，你最好把你的手放在键盘上，使用其内置的快捷键来移动。

2. Aegisub

Aegisub 已经是一款高级别的复杂字幕编辑器。仅仅是界面就反映出了一定的学习曲线。但是，除了它吓人的样子以外，Aegisub 是一个非常完整的软件，提供的工具远远超出你能想象的。和Gnome Subtitles 一样，Aegisub也采用了所见即所得（WYSIWYG:what you see is what you get）的处理方式。但是是一个全新的高度：可以再屏幕上任意拖动字幕，也可以在另一边查看音频的频谱，并且可以利用快捷键做任何的事情。除此以外，它还带有一个汉字工具，有一个kalaok模式，并且你可以导入lua 脚本让它自动完成一些任务。我希望你在用之前，先去阅读下它的指南。

3. Gaupol

另一个操作复杂的软件是Gaupol,不像Aegisub ，Gaupol 很容易上手而且采用了一个和Gnome Subtitles 很像的界面。但是在这些相对简单背后，它拥有很多很必要的工具：快捷键、第三方扩展、拼写检查，甚至是语音识别（由CMU Sphinx提供）。这里也提一个缺点，我注意到有时候在测试的时候也，软件会有消极怠工的表现，不是很严重，但是也足以让我更有理由喜欢Gnome Subtitles了。

4. Subtitle Editor

Subtitle Editor和 Gaupol 很像，但是它的界面有点不太直观，特性也只是稍微的高级一点点。我很欣赏的一点是，它可以定义“关键帧”，而且提供所有的同步选项。然而，多一点的图标，或者是少一点的文字都能提供界面的特性。作为一个值得称赞的字幕编辑器，Subtitle Editor 可以模仿“作家”打字的效果，虽然我不确定它是否特别有用。最后但同样重要的一点，重定义快捷键的功能很实用。

5. Jubler

Jubler是一个用Java编写并有多平台支持的字幕编辑器。我对它的界面印象特别深刻。在上面我确实看出了Java特点的东西，但是，它仍然是经过精心的构造和构思的。像Aegisub 一样，你可以再屏幕上任意的拖动字幕，让你有愉快的体验而不单单是打字。它也可以为字幕自定义一个风格，在另外的一个轨道播放音频，翻译字幕，或者是是做拼写检查。不过，要注意的是，你需要事先安装好媒体播放器并且正确的配置，如果你想完整的使用Jubler。我把这些归功于在官方页面下载了脚本以后其简便的安装方式。

6. Subtitle Composer

Subtitle Composer被视为“KDE里的字幕作曲家”，它能够唤起对很多传统功能的回忆。伴随着KDE界面，我们充满了期待。我们自然会说到快捷键，我特别喜欢这个功能。除此之外，Subtitle Composer 与上面提到的编辑器最大的不同地方就在于，它可以执行用JavaScript，Python，甚至是Ruby写成的脚本。软件带有几个例子，肯定能够帮助你很好的学习使用这些特性的语法。

最后，不管你是否喜欢，都来为你的家庭编辑几个字幕吧，重新同步整个轨道，或者是一切从头开始，那么Linux 有很好的工具给你。对我来说，快捷键和易用性使得各个工具有差异，想要更高级别的使用体验，脚本和语音识别就成了很便利的一个功能。

你会使用哪个字幕编辑器，为什么？你认为还有没有更好用的字幕编辑器这里没有提到的？在评论里告诉我们吧。

via: http://xmodulo.com/good-subtitle-editor-linux.html

作者：Adrien Brochard 译者：barney-ro 校对：Caroline

本文由 LCTT 原创翻译，Linux中国 荣誉推出

供图: Shutterstock

有多种技术在竞争成为实现Linux内核热补丁的最优方案。

没人喜欢重启机器，尤其是涉及到一个内核问题的最新补丁程序。

为达到不重启的目的，目前有3个项目在朝这方面努力，将为大家提供内核升级时打热补丁的机制，这样就可以做到完全不重启机器。

Ksplice项目

首先要介绍的项目是Ksplice，它是热补丁技术的创始者，并于2008年建立了与项目同名的公司。Ksplice在替换新内核时，不需要预先修改；只需要一个diff文件，列出内核即将接受的修改即可。Ksplice公司免费提供软件，但技术支持是需要收费的，目前能够支持大部分常用的Linux发行版本。

但在2011年Oracle收购了这家公司后，情况发生了变化。 这项功能被合入到Oracle自己的Linux发行版本中，只对Oralcle自己提供技术更新。 这就导致，其他内核hacker们开始寻找替代Ksplice的方法，以避免缴纳Oracle税。

Kgraft项目

2014年2月，Suse提供了一个很好的解决方案：Kgraft，该内核更新技术以GPLv2/GPLv3混合许可证发布，且Suse不会将其作为一个专有发明封闭起来。Kgraft被提交到Linux内核主线，很有可能被内核主线采用。目前Suse已经把此技术集成到Suse Linux Enterprise Server 12。

Kgraft和Ksplice在工作原理上很相似，都是使用一组diff文件来计算内核中需要修改的部分。但与Ksplice不同的是，Kgraft在做替换时，不需要完全停止内核。 在打补丁时，正在运行的函数可以先使用老版本或新内核中对应的部分，当补丁打完后就可以完全切换新的版本。

Kpatch项目

Red Hat也提出了他们的内核热补丁技术。同样是在2014年初 -- 与Suse在这方面的工作差不多 -- Kpatch的工作原理也和Kgraft相似。

主要的区别点在于，正如Red Hat的Josh Poimboeuf总结的那样，Kpatch并不将内核调用重定向到老版本。相反，它会等待所有函数调用都停止时，再切换到新内核。Red Hat的工程师认为这种方法更为安全，且更容易维护，缺点就是在打补丁的过程中会带来更大的延迟。

和Kgraft一样，Kpatch不仅仅可以在Red Hat的发行版本上使用，同时也被提交到了内核主线，作为一个可能的候选。 坏消息是Red Hat还未将此技术集成到产品中。 它只是被合入到了Red Hat Enterprise Linux 7的技术预览版中。

...也许 Kgraft + Kpatch更合适?

Red Hat的工程师Seth Jennings在2014年11月初，提出了第四种解决方案。将Kgraft和Kpatch结合起来, 补丁包用这两种方式都可以。在新的方法中，Jennings提出，“热补丁核心为其他内核模块提供了一个热补丁的注册接口”， 通过这种方法，打补丁的过程 -- 更准确的说，如何处理运行时内核调用 --可以被更加有序的组织起来。

这项新建议也意味着两个方案都还需要更长的时间，才能被linux内核正式采纳。尽管Suse步子迈得更快，并把Kgraft应用到了最新的enterprise版本中。让我们也关注一下Red Hat和Canonical近期是否会跟进。

via: http://www.infoworld.com/article/2851028/linux/four-ways-linux-is-headed-for-no-downtime-kernel-patching.html

作者：Serdar Yegulalp 译者：coloka 校对：tinyeyeser

本文由 LCTT 原创翻译，Linux中国 荣誉推出

近来我一直在与某资深开源开发团队中的多个成员缠斗，尽管密切关注我的人们会在读完本文后猜到是哪个组织，但我不会在这里说出这个组织的名字。

怎么让某些人进入 21 世纪就这么难呢？真是的...

我快 56 岁了，也就是大部分年轻人会以为的我将时不时朝他们发出诸如“滚出我的草坪”之类歇斯底里咆哮的年龄。但事实并非如此 —— 我发现，尤其是在技术背景之下，我变得与我的年龄非常不相称。

在我这个年龄的大部分人确实变成了爱发牢骚、墨守成规的老顽固。并且，尴尬的是，偶尔我会成为那个打断谈话的人，我会指出他们某个在 1995 年（或者在某些特殊情况下，1985 年）时很适合的方法... 几十年后的今天就不再是好方法了。

为什么是我？因为年轻人在我的同龄人中很难有什么说服力。如果有人想让那帮老头改变主意，首先他得是自己同龄人中具有较高思想觉悟的佼佼者。即便如此，在与习惯做斗争的过程中，我也比看起来花费了更多的时间。

年轻人犯下无知的错误是可以被原谅的。他们还年轻。年轻意味着缺乏经验，缺乏经验通常会导致片面的判断。我很难原谅那些经历了足够多本该有经验的人，却被长期的固化思维蒙蔽，无法发觉近在咫尺的东西。

（补充一下：我真的不是保守党拥护者。那些和我争论政治的，无论保守党还是非保守党都没有注意到这点，我觉得这颇有点嘲讽的意味。）

那么，现在我们来讨论下 GNU 更新日志文件（ChangeLog）这件事。在 1985 年的时候，这是一个不错的主意，甚至可以说是必须的。当时的想法是用单独的更新日志条目来记录多个相关文件的变更情况。用这种方式来对那些存在版本缺失或者非常原始的版本进行版本控制确实不错。当时我也在场，所以我知道这些。

不过即使到了 1995 年，甚至 21 世纪早期，许多版本控制系统仍然没有太大改进。也就是说，这些版本控制系统并非对批量文件的变化进行分组再保存到一条记录上，而是对每个变化的文件分别进行记录并保存到不同的地方。CVS，当时被广泛使用的版本控制系统，仅仅是模拟日志变更 —— 并且在这方面表现得很糟糕，导致大多数人不再依赖这个功能。即便如此，更新日志文件的出现依然是必要的。

但随后，版本控制系统 Subversion 于 2003 年发布 beta 版，并于 2004 年发布 1.0 正式版，Subversion 真正实现了更新日志记录功能，得到了人们的广泛认可。它与一年后兴起的分布式版本控制系统（Distributed Version Control System，DVCS）共同引发了主流世界的激烈争论。因为如果你在项目上同时使用了分布式版本控制与更新日志文件记录的功能，它们将会因为争夺相同元数据的控制权而产生不可预料的冲突。

有几种不同的方法可以折衷解决这个问题。一种是继续将更新日志作为代码变更的授权记录。这样一来，你基本上只能得到简陋的、形式上的提交评论数据。

另一种方法是对提交的评论日志进行授权。如果你这样做了，不久后你就会开始思忖为什么自己仍然对所有的日志更新条目进行记录。提交元数据与变化的代码具有更好的相容性，毕竟这才是当初设计它的目的。

（现在，试想有这样一个项目，同样本着把项目做得最好的想法，但两拨人却做出了完全不同的选择。因此你必须同时阅读更新日志和评论日志以了解到底发生了什么。最好在矛盾激化前把问题解决....）

第三种办法是尝试同时使用以上两种方法 —— 在更新日志条目中，以稍微变化后的的格式复制一份评论数据，将其作为评论提交的一部分。这会导致各种你意想不到的问题，最具代表性的就是它不符合“真理的单点性（single point of truth）”原理；只要其中有拷贝文件损坏，或者日志文件条目被修改，这就不再是同步时数据匹配的问题，它将导致在其后参与进来的人试图搞清人们是怎么想的时候变得非常困惑。（LCTT 译注：《程序员修炼之道》（The Pragmatic Programmer）：任何一个知识点在系统内都应当有一个唯一、明确、权威的表述。根据Brian Kernighan的建议，把这个原则称为“真理的单点性（Single Point of Truth）”或者SPOT原则。）

或者，正如这个我就不说出具体名字的特定项目所做的，它的高层开发人员在电子邮件中最近声明说，提交可以包含多个更新日志条目，并且提交的元数据与更新日志是无关的。这导致我们直到现在还得不断进行记录。

当时我读到邮件的时候都要吐了。什么样的傻瓜才会意识不到这是自找麻烦 —— 事实上，在 DVCS 中针对可靠的提交日志有很好的浏览工具，围绕更新日志文件的整个定制措施只会成为负担和拖累。

唉，这是比较特殊的笨蛋：变老的并且思维僵化了的黑客。所有的合理化改革他都会极力反对。他所遵循的行事方法在几十年前是有效的，但现在只能适得其反。如果你试图向他解释这些不仅仅和 git 的摘要信息有关，同时还为了正确适应当前的工具集，以便实现更新日志的去条目化... 呵呵，那你就准备好迎接无法忍受、无法想象的疯狂对话吧。

的确，它成功激怒了我。这样那样的胡言乱语使这个项目变成了很难完成的工作。而且，同样的糟糕还体现在他们吸引年轻开发者的过程中，我认为这是真正的问题。相关 Google+ 社区的人员数量已经达到了 4 位数，他们大部分都是孩子，还没有成长起来。显然外界已经接受了这样的信息：这个项目的开发者都是部落中地位根深蒂固的崇高首领，最好的崇拜方式就是远远的景仰着他们。

这件事给我的最大触动就是每当我要和这些部落首领较量时，我都会想：有一天我也会这样吗？或者更糟的是，我看到的只是如同镜子一般对我自己的真实写照，而我自己却浑然不觉？我的意思是，我所得到的印象来自于他的网站，这个特殊的笨蛋要比我年轻。年轻至少 15 岁呢。

我总是认为自己的思路很清晰。当我和那些比我聪明的人打交道时我不会受挫，我只会因为那些思路跟不上我、看不清事实的人而沮丧。但这种自信也许只是邓宁·克鲁格效应（Dunning-Krueger effect）在我身上的消极影响，我并不确定这意味着什么。很少有什么事情会让我感到害怕；而这件事在让我害怕的事情名单上是名列前茅的。

另一件让人不安的事是当我逐渐变老的时候，这样的矛盾发生得越来越频繁。不知怎的，我希望我的黑客同行们能以更加优雅的姿态老去，即使身体老去也应该保持一颗年轻的心灵。有些人确实是这样；但可惜绝大多数人都不是。真令人悲哀。

我不确定我的职业生涯会不会完美收场。假如我最后成功避免了思维僵化（注意我说的是假如），我想我一定知道其中的部分原因，但我不确定这种模式是否可以被复制 —— 为了达成目的也许得在你的头脑中发生一些复杂的化学反应。尽管如此，无论对错，请听听我给年轻黑客以及其他有志青年的建议。

你们——对的，也包括你——一定无法在你中年老年的时候保持不错的心灵，除非你能很好的控制这点。你必须不断地去磨练你的内心、在你还年轻的时候完成自己的种种心愿，你必须把这些行为养成一种习惯直到你老去。

有种说法是中年人锻炼身体的最佳时机是 30 岁以前。我以为同样的方法，坚持我以上所说的习惯能让你在 56 岁，甚至 65 岁的时候仍然保持灵活的头脑。挑战你的极限，使不断地挑战自己成为一种习惯。立刻离开安乐窝，由此当你以后真正需要它的时候你可以建立起自己的安乐窝。

你必须要清楚的了解这点；还有一个可选择的挑战是你选择一个可以实现的目标并且为了这个目标不断努力。这个月我要学习 Go 语言。不是指围棋，我早就玩儿过了（虽然玩儿的不是太好）。并不是因为工作需要，而是因为我觉得是时候来扩展下我自己了。（LCTT 译注：围棋的英文也是“Go”）

保持这个习惯。永远不要放弃。

via: http://esr.ibiblio.org/?p=6485

作者：Eric Raymond 译者：Stevearzh 校对：Mr小眼儿

本文由 LCTT 原创翻译，Linux中国 荣誉推出

Intel 开源技术中心的 Ben Widawsky 发布了一款新的试验性工具，可以在 Linux 下调整 Intel GPU 的主频，名字自然就叫做 intel\_freequency。

Intel HD Graphics 的主频其实已经可以通过 Linux 内核的 sysfs 接口来强制调整，不过使用该工具会更加方便易用。

intel\_frequency 工具支持读取 GPU 的当前/最小/最大主频、设置为不同的主频级别，以及固定最大主频。这个工具并没有提供超出通过 sysfs 所能做到的更高的主频和更多功能。

这个 intel\_frequency 工具可以用于性能测试、检查稳定性问题和调试等等。

目前该工具还没有添加到 Intel GPU 工具包中，不过已经可以通过补丁来得到了。

Hello，大家好！我是——邪恶君子！

今天，给大家分享一下解决源码包编译安装 LEMP 环境下开启 OpenSSL 功能问题的过程。前几天，在访问页面时，突然报错，要求开启 openssl 功能。那怎么办呢，首先想到的是 yum 安装，但是，安装后还是没解决，因为 LEMP 的环境是源码包编译安装的，所以，还需要编译安装 openssl。

经过邪恶不懈的努力，终于找到了解决办法，而且真的成功了，下面就给大家分享一下！

首先，要确保 LEMP 环境是源码包编译安装的，并且要清楚 PHP 的安装目录在哪里。

其次，可以通过 yum 源的方式或者源码包编译安装 OpenSSL、OpenSSL-devel 两个包。

然后，进入到 PHP 解压出来的目录里面，我这里的目录是 PHP-5.4.24。在 PHP 目录下，会有一个 ext 的扩展目录，进入里面，找到并进入 openssl 的目录。这时，我们所在的目录是：/root/php-5.4.24/ext/openssl

这个目录下会有如下文件，看图：

然后，执行 /usr/local/php5/bin/phpize 命令（在执行前要确保已安装 m4 和 autoconf 两个工具，否则会报错）。

注意：这里是我的phpize路径，根据自己的安装路径执行；如果找不到，使用 whereis phpize 查找。如果执行时报错无法找到 config.m4 文件，那么就把目录下面的 config0.m4 重命名 config.m4，因为 config0.m4就是config.m4 的模版。

如果命令成功执行完毕，那么目录下面就会自动多出个 configure 文件，这时，只需要编译安装就行了。过程如下：

# ./configure --with-openssl --with-php-config=/usr/local/php5/bin/php-config
# make && make install

耐心等候，安装完成后，会在当前的modules目录下面多出一个openssl.so文件；然后在php.ini配置文件最后面加上如下一行内容：

extension=openssl.so

然后，重启nginx服务和php-fpm，就可以了！

至此，在源码编译安装LNMP环境下开启openssl功能成功解决！

如果有在操作中遇到啥问题，可以留言交流一下，共同学习，共同进步！

Personal Home Page：http://linux.cn/space/16475

在 ChromeOS 和 Linux 的斗争过程中，两个桌面环境都有强有弱，这两者到底怎样呢？

只要稍加留意，任何人都会相信，Google 在桌面领域绝不是“玩玩而已”。在近几年，我们见到的 ChromeOS 制造的 Google Chromebook 相当的轰动。和同期人气火爆的 Amazon 一样，ChromeOS 似乎势不可挡。

在本文中，我们要了解的是 ChromeOS 的概念市场，ChromeOS 怎么影响着Linux 的份额，整个 ChromeOS 对于Linux 社区来说，是好事还是坏事。另外，我将会谈到一些重大问题，以及为什么没人针对这些问题做点什么。

ChromeOS 并非真正的Linux

每当有朋友问我说 ChromeOS 是否是 Linux 的一个发行版时，我都会这样回答：ChromeOS 之于 Linux 就如同 OS X 之于 BSD。换句话说，我认为，ChromeOS 是 Linux 的一个派生操作系统，运行于 Linux 内核的引擎之下。而这个操作系统的大部分由 Google 的专利代码及软件组成。

尽管 ChromeOS 是利用了 Linux 的内核引擎，但是和现在流行的 Linux 分支版本相比，它仍然有很大的不同。

其实，ChromeOS 的差异化越来越明显的原因，是在于它给终端用户提供的包括 Web 应用在内的 app。因为ChromeOS 的每一个操作都是开始于浏览器窗口，这对于 Linux 用户来说，可能会有很多不一样的感受，但是，对于没有 Linux 经验的用户来说，这与他们使用的旧电脑并没有什么不同。

比方说，每一个以“依赖 Google 产品”为生活方式的人来说，在 ChromeOS 上的感觉将会非常良好，就好像是回家一样，特别是这个人已经接受了 Chrome 浏览器、Google Drive 云存储和Gmail 的话。久而久之，他们使用ChromeOS 也就是很自然的事情了，因为他们很容易接受使用早已习惯的 Chrome 浏览器。

然而，对于 Linux 爱好者来说，这样的约束就立即带来了不适应。因为软件的选择是被限制、被禁锢的，再加上要想玩游戏和 VoIP 是完全不可能的。对不起，因为 GooglePlus Hangouts 是代替不了VoIP 软件的。甚至这种情况将持续很长一段时间。

ChromeOS 还是 Linux 桌面

有人断言，ChromeOS 要是想在桌面系统的浪潮中对 Linux 产生影响，只有在 Linux 停下来浮出水面喘气的时候，或者是满足某个非技术用户的时候。

是的，桌面 Linux 对于大多数休闲型的用户来说绝对是一个好东西。然而，它必须有专人帮助你安装操作系统，并且提供“维修”服务，就如同我们在 Windows 和 OS X 阵营看到的一样。但是，令人失望的是，在美国， Linux 恰恰在这个方面很缺乏。所以，我们看到，ChromeOS 正慢慢的走入我们的视线。

我发现 Linux 桌面系统最适合那些能够提供在线技术支持的环境中。比如说：可以在家里操作和处理更新的高级用户、政府和学校的 IT 部门等等。这些环境中，Linux 桌面系统可以被配置给任何技能水平和背景的人使用。

相比之下，ChromeOS 是建立在完全免维护的初衷之下的，因此，不需要第三者的帮忙，你只需要允许更新，然后让他静默完成即可。这在一定程度上可能是由于 ChromeOS 是为某些特定的硬件结构设计的，这与苹果开发自己的PC 电脑也有异曲同工之妙。因为 Google 的 ChromeOS 伴随着其硬件一起提供，大部分情况下都无需担心错误的驱动、适配什么的问题。对于某些人来说，这太好了。

然而有些人则认为这是一个很严重的问题，不过滑稽的是，对 ChomeOS 来说，这些人压根就不在它的目标市场里。简言之，这只是一些狂热的 Linux 爱好者在对 ChomeOS 鸡蛋里挑骨头罢了。要我说，还是停止这些没必要的批评吧。

问题的关键在于：ChromeOS 的市场份额和 Linux 桌面系统在很长的一段时间内是不同的。这个局面可能会在将来被打破，然而在现在，仍然会是两军对峙的局面。

ChromeOS 的使用率正在增长

不管你对ChromeOS 有怎么样的看法，事实是，ChromeOS 的使用率正在增长。专门针对 ChromeOS 的电脑也一直有发布。最近，戴尔（Dell）也发布了一款针对 ChromeOS 的电脑。命名为 Dell Chromebox，这款 ChromeOS 设备将会是对传统设备的又一次冲击。它没有软件光驱，没有反病毒软件，能够提供无缝的幕后自动更新。对于一般的用户，Chromebox 和 Chromebook 正逐渐成为那些工作在 Web 浏览器上的人们的一个可靠选择。

尽管增长速度很快，ChromeOS 设备仍然面临着一个很严峻的问题 - 存储。受限于有限的硬盘大小和严重依赖于云存储，ChromeOS 对于那些需要使用基本的浏览器功能之外的人们来说还不够用。

ChromeOS 和 Linux 的异同点

以前，我注意到 ChromeOS 和 Linux 桌面系统分别占有着两个完全不同的市场。出现这样的情况是源于 Linux 社区在线下的桌面支持上一直都有着极其糟糕的表现。

是的，偶然的，有些人可能会第一时间发现这个“Linux特点”。但是，并没有一个人接着跟进这些问题，确保得到问题的答案，以让他们得到 Linux 方面更多的帮助。

事实上，线下问题的出现可能是这样的：

• 有些用户偶然的在当地的 Linux 活动中发现了 Linux。
• 他们带回了 DVD/USB 设备，并尝试安装这个操作系统。
• 当然，有些人很幸运的成功完成了安装过程，但是，据我所知大多数的人并没有那么幸运。
• 令人失望的是，这些人只能寄希望于在网上论坛里搜索帮助。他们很难通过主流的计算机网络经验或视频教程解决这些问题。 -于是这些人受够了。后来有很多失望的用户拿着他们的电脑到 Windows 商店来“维修”。除了重装一个 Windows 操作系统，他们很多时候都会听到一句话，“Linux 并不适合你们”，应该尽量避免。

有些人肯定会说，上面的举例肯定夸大其词了。让我来告诉你：这是发生在我身边的真事，而且是经常发生。醒醒吧，Linux 社区的人们，我们的推广模式早已过期无力了。

伟大的平台，糟糕的营销和最终结论

如果非要找一个 ChromeOS 和 Linux 桌面系统的共同点，除了它们都使用了 Linux 内核，那就是它们都是伟大的产品却拥有极其差劲的市场营销。对此，Google 认为自己的优势是，它能投入大量的资金在网上构建大面积存储空间。

Google 相信他们拥有“网上的优势”，而线下的问题不是很重要。这真是一个让人难以置信的目光短浅，这也成了Google 最严重的失误之一。而当地的 Linux 零售商则坚信，对于不怎么上网的人，自然不必担心他们会受到 Google巨大的在线存储的诱惑。

我的建议是：Linux 可以通过线下的努力，提供桌面系统，渗透 ChromeOS 市场。这就意味着 Linux 社区需要在节假日筹集资金来出席博览会、商场展览，并且在社区中进行免费的教学课程。这会立即使 Linux 桌面系统走入人们的视线，否则，最终将会是一个 ChromeOS 设备出现在人们的面前。

如果说本地的线下市场并没有像我说的这样，别担心。Linux 桌面系统的市场仍然会像 ChromeOS 一样增长。最坏也能保持现在这种两军对峙的市场局面。

via: http://www.datamation.com/open-source/chromeos-vs-linux-the-good-the-bad-and-the-ugly-1.html

作者：Matt Hartley 译者：barney-ro 校对：Mr小眼儿

本文由 LCTT 原创翻译，Linux中国 荣誉推出