漫画赏析：消沉的程序员 12
养一个孩子和维护一个软件，这两者真的是一样的吗？同样都是充满挑战吧！
译者简介：
GHLandy —— 生活中所有欢乐与苦闷都应藏在心中，有些事儿注定无人知晓，自己也无从说起。
via: http://turnoff.us/geek/the-depressed-developer-12/
作者：Daniel Stori 译者：GHLandy 校对：wxy
分类 观点 下的文章
使用开源工具探索气候数据的奥秘
如今你看地球上的任何地方，都可以找到天气变化的证据，每个月，无论是事实还是数据都在向我们诠释一点 —— 全球变暖。
气候学家如是告诫我们，如今的不作为，对于我们的将来可能是致命的。五角大楼的军事战略家最近警告当选总统的川普，向他申明如果不对气候变化有所动作，可能会造成威胁国家安全的灾难。愈趋减少的的水供应和微薄的降雨量会导致作物歉收，这将迫使大量的移民逃往世界各地，到那些可以维持他们生计的地方去。
遍览 NASA、美国国防部，以及其他机构针对气候的研究成果，我的心中有个疑惑。那就是是否有开源的工具，使对此感兴趣的人们能够自行去探索气候数据的奥秘，并总结出我们自己的结论。我在网上快速的检索了一下，然后找到了 Open Climate Workbench （开源气候工作台），这是 Apache 软件基金会旗下的一个工程。
Open Climate Workbench （缩写 OCW） 开发该软件，对来自 地球系统网格联盟 （缩写 ESGF）、 协调区域气候降尺度实验 （缩写 CORDEX）、美国全球变化研究项目的 国家气候研究 、 北美区域气候评估计划 ，以及 NASA、NOAA 和其他组织或机构的数据进行气候模型评价。
你可下载 OCW 的 tar 包 并将它安装到满足其条件的 Linux 电脑上。也可以使用 Vagrant 或者 VirtualBox 将 OCW 安装到虚拟机中，详见 OCW 的虚拟机指南。
个人觉得想要了解 OCW 是如何工作的，最便捷的方式就是到 区域气候模式评价系统 （缩写 RCMES），下载一个虚拟机镜像。
从 RCMES 的网站上看，他们旨在通过为一系列广泛而全面的观测（例如，卫星观测，重新分析，现场观测）和建模资源（例如，ESGF 上的 CMIP 和 CORDEX）提供标准化的访问，以及常规分析和可视化任务的工具（例如，OCW），来促进气候和地球系统模型的区域规模评估。
你需要在宿主机上安装 VirtualBox 和 Vagrant。通过它们，你就能看到一个超赞的 OCW 作业示例。RCMES 为下载、导入、运行虚拟机提供了详细的说明。当你的虚拟机开始工作时，你可以用以下身份登陆。
用户名：vagrant，密码：vagrant。
RCMES 数据样图
RCMES 网页上的教程能帮助你迅速上手该软件。他们的社区十分活跃，而且在寻找更多的开发者。 你也可以订阅他们邮件列表。
该工程的源代码部署在 GitHub 上，遵寻 Apache License, Version 2.0。
(题图源自： Flickr user: theaucitron (CC BY-SA 2.0))
作者简介：
Don Watkins（唐 沃特金斯） - 教育家，教育技术专家，企业家，开源支持者。教育心理学硕士，Linux 系统管理员，CCNA，使用 Virtual Box 实现虚拟化。twitter 关注 @Don\_Watkins。
via: https://opensource.com/article/17/1/apache-open-climate-workbench
作者：Don Watkins 译者：martin2011qi 校对：jasminepeng
Windows 赢了桌面，而 Linux 赢得整个世界
最坚决推行 Linux 桌面系统项目的城市正在转回 Windows 阵营，但 Linux 的命运已经不再与 PC 休戚相关。
慕尼黑的 Linux 项目只是开源软件故事中的一小部分
在实施从 Windows 系统迁移到 Linux 系统这一项目接近十年之久后，慕尼黑却突然走上了一条戏剧性的转弯。据说是到 2021 年，该城市的地方议会就会开始用 Windows 10 替换运行 LiMux (Ubuntu 的一种自定义版本)的 PC 机。
若是回到 15 或者 20 年前，人们可能会争论什么时候 Linux 将会在桌面上取代 Windows。例如，当 Ubuntu 于 2004 年问世时，它是带着 终结 Windows 的抱负 而被设计为标准的桌面操作系统的。
剧透：这一切并没有发生。
桌面上的 Linux 在今天占有约为 2% 的市场，很多人都认为它复杂晦涩。与此同时，Windows 则航行无虞，在 PC 市场笑傲群雄，天下十有其九。但在商业领域中总还有些许 Linux 桌面的身影，它仍被需要——尤其是对开发者和数据科学家而言。
但遗憾的是，它永远也不会成为历史的主流。
慕尼黑的 Linux 项目因其规模之大，引起了许多人的兴趣。几乎没有哪家大型组织会做出从 Windows 到 Linux 的迁移，一些个别的案例像 法国宪兵队和都灵市 曾有类似之举。然而，慕尼黑作为模范：在这一事件上的失败将会大大打击那些仍在 试图用 Linux 将 Windows 取而代之的信徒们。
但现实就是如此，绝大多数公司乐于去使用主流的桌面操作系统，因为它具有完整一致、用户友好这种优势。
工作人员所抱怨的问题中，有多少是归咎于 LiMux 软件以及多少是操作系统无端被责备的，已经不可计数。但重要的是，无论慕尼黑最后何去何从，Linux 的命运都已经脱离了桌面 —— 是的，Linux 在多年前就已经输掉了桌面战争。
但这对 Linux 来说无伤大雅，因为它赢得了智能手机之战，并且在云端和物联网之战上也是捷报连连。
你的口袋里，有七八成可能装的是一个 Linux 驱动的智能手机（Android 基于 Linux 内核）。你的身边，更是有成千上万 Linux 驱动的设备，虽然这些也许你甚至都没注意到。
像树莓派这样运行大量不同类型 Linux 的设备，正在创建一个充满热情和活力的开发者社区，并且提供给初创公司一种低成本的驱动新设备的方法。
大部分公有云也是以这样或那样的形式在 Linux 上运行的；即便是微软，也已经敞开大门，拥抱开源软件。无论你站在哪一个软件平台的立场，不可否认地，开发者和用户拥有更多丰富的可选项是一件好事，对决策来说，抑或是对创新来说，都是如此。
桌面的主导地位早已不再是当年模样了：它现在只是许多计算平台中的一个。事实上，PC 的软件也已经变得越来越不相关，因为更多的应用程序都在与设备和操作系统解耦，驻留在云中。
虽然慕尼黑传奇的曲折变换与 Linux 在桌面上的冒险耐人寻味，但它们却并未给你呈现出一个完整的故事。
同意? 还是不同意? 在下面添加你的评论来加入讨论吧！
（题图: Getty Images/iStockphoto）
via: http://www.zdnet.com/article/windows-wins-the-desktop-but-linux-takes-the-world/
作者：Steve Ranger 译者：Meditator-hkx 校对：wxy
漫画赏析： Vi 还是不 Vi，这是个问题
LCTT/comic 组成立之前，已有几篇 turnoff.us 漫画发布于 Linux.中国。随着之前的“消沉的程序员”系列漫画的汉化完成，LCTT/comic 翻译仓库也随之建立完成。
那么，本期是 GHLandy 给大家带来的 turnoff.us 上 “ Vi 还是不 Vi，这是个问题 ” 的汉化版漫画。如下：
上图展示了一个小伙子在有人注视自己工作的时候，使用 Vi 来编辑配置文件，装了一波十三。然后，在人离开后有赶紧拿起趁手的 Sublime 来使用。可能这幅漫画也是很多人的真实写照吧。
相信大家都有各自喜爱的文本编辑器，或者说是开发环境吧。就 GHLandy 本人，也就在文本模式下使用 Vim，然后 GUI 模式使用 Atom 和 notepad++。那么，各位小伙伴，你们各自使用的什么编辑器呢。
感觉这幅漫画要引发激烈争论，快来畅所欲言吧！
via: http://turnoff.us/geek/to-vi-or-not-to-vi/
作者：Daniel Stori 译者：GHLandy 校对：wxy
为什么（大多数）高级语言运行效率较慢
在近一两个月中，我多次的和线上线下的朋友讨论了这个话题，所以我干脆直接把它写在博客中，以便以后查阅。
大部分高级语言运行效率较慢的原因通常有两点：
- 没有很好的利用缓存；
- 垃圾回收机制性能消耗高。
但事实上，这两个原因可以归因于：高级语言强烈地鼓励编程人员分配很多的内存。
首先，下文内容主要讨论客户端应用。如果你的程序有 99.9% 的时间都在等待网络 I/O，那么这很可能不是拖慢语言运行效率的原因——优先考虑的问题当然是优化网络。在本文中，我们主要讨论程序在本地执行的速度。
我将选用 C# 语言作为本文的参考语言，其原因有二：首先它是我常用的高级语言；其次如果我使用 Java 语言，许多使用 C# 的朋友会告诉我 C# 不会有这些问题，因为它有值类型（但这是错误的）。
接下来我将会讨论，出于编程习惯编写的代码、使用 普遍编程方法 的代码或使用库或教程中提到的常用代码来编写程序时会发生什么。我对那些使用难搞的办法来解决语言自身毛病以“证明”语言没毛病这事没兴趣，当然你可以和语言抗争来避免它的毛病，但这并不能说明语言本身是没有问题的。
回顾缓存消耗问题
首先我们先来回顾一下合理使用缓存的重要性。下图是基于在 Haswell 架构下内存延迟对 CPU 影响的 数据：
针对这款 CPU 读取内存的延迟，CPU 需要消耗近 230 个运算周期从内存读取数据，同时需要消耗 4 个运算周期来读取 L1 缓冲区。因此错误的去使用缓存可导致运行速度拖慢近 50 倍。还好这并不是最糟糕的——在现代 CPU 中它们能同时地做多种操作，所以当你加载 L1 缓冲区内容的同时这个内容已经进入到了寄存器，因此数据从 L1 缓冲区加载这个过程的性能消耗就被部分或完整的掩盖了起来。
撇开选择合理的算法不谈，不夸张地讲，在性能优化中你要考虑的最主要因素其实是缓存未命中。当你能够有效的访问一个数据时候，你才需要考虑优化你的每个具体的操作。与缓存未命中的问题相比，那些次要的低效问题对运行速度并没有什么过多的影响。
这对于编程语言的设计者来说是一个好消息！你都不必去编写一个最高效的编译器，你可以完全摆脱一些额外的开销（比如：数组边界检查），你只需要专注怎么设计语言能高效地编写代码来访问数据，而不用担心与 C 语言代码比较运行速度。
为什么 C# 存在缓存未命中问题
坦率地讲 C# 在设计时就没打算在现代缓存中实现高效运行。我又一次提到程序语言设计的局限性以及其带给程序员无法编写高效的代码的“压力”。大部分的理论上的解决方法其实都非常的不便，这里我说的是那些编程语言“希望”你这样编写的惯用写法。
C# 最基本的问题是对 基础值类型 低下的支持性。其大部分的数据结构都是“内置”在语言内定义的（例如：栈，或其他内置对象）。但这些具有帮助性的内置结构体有一些大问题，以至于更像是创可贴而不是解决方案。
- 你得把自己定义的结构体类型在最先声明——这意味着你如果需要用到这个类型作为堆分配，那么所有的结构体都会被堆分配。你也可以使用一些类包装器来打包你的结构体和其中的成员变量，但这十分的痛苦。如果类和结构体可以相同的方式声明，并且可根据具体情况来使用，这将是更好的。当数据可以作为值地存储在自定义的栈中，当这个数据需要被堆分配时你就可以将其定义为一个对象，比如 C++ 就是这样工作的。因为只有少数的内容需要被堆分配，所以我们不鼓励所有的内容都被定义为对象类型。
- 引用 值被苛刻的限制。你可以将一个引用值传给函数，但只能这样。你不能直接引用
List<int>中的元素，你必须先把所有的引用和索引全部存储下来。你不能直接取得指向栈、对象中的变量（或其他变量）的指针。你只能把它们复制一份，除了将它们传给一个函数（使用引用的方式）。当然这也是可以理解的。如果类型安全是一个先驱条件，灵活的引用变量和保证类型安全这两项要同时支持太难了（虽然不是不可能）。这些限制背后的理念并不能改变限制存在的事实。 - 固定大小的缓冲区.aspx) 不支持自定义类型，而且还必须使用
unsafe关键字。 - 有限的“数组切片”功能。虽然有提供
ArraySegment类，但并没有人会使用它，这意味着如果只需要传递数组的一部分，你必须去创建一个IEnumerable对象，也就意味着要分配大小（包装）。就算接口接受ArraySegment对象作为参数，也是不够的——你只能用普通数组，而不能用List<T>，也不能用 栈数组.aspx) 等等。
最重要的是，除了非常简单的情况之外，C# 非常惯用堆分配。如果所有的数据都被堆分配，这意味着被访问时会造成缓存未命中（从你无法决定对象是如何在堆中存储开始）。所以当 C++ 程序面临着如何有效的组织数据在缓存中的存储这个挑战时，C# 则鼓励程序员去将数据分开地存放在一个个堆分配空间中。这就意味着程序员无法控制数据存储方式了，也开始产生不必要的缓存未命中问题，而导致性能急速的下降。C# 已经支持原生编译 也不会提升太多性能——毕竟在内存不足的情况下，提高代码质量本就杯水车薪。
再加上存储是有开销的。在 64 位的机器上每个地址值占 8 位内存，而每次分配都会有存储元数据而产生的开销。与存储着少量大数据（以固定偏移的方式存储在其中）的堆相比，存储着大量小数据的堆（并且其中的数据到处都被引用）会产生更多的内存开销。尽管你可能不怎么关心内存怎么用，但事实上就是那些头部内容和地址信息导致堆变得臃肿，也就是在浪费缓存了，所以也造成了更多的缓存未命中，降低了代码性能。
当然有些时候也是有办法的，比如你可以使用一个很大的 List<T> 来构造数据池以存储分配你需要的数据和自己的结构体。这样你就可以方便的遍历或者批量更新你的数据池中的数据了。但这也会很混乱，因为无论你在哪要引用什么对象都要先能引用这个池，然后每次引用都需要做数组索引。从上文可以得出，在 C# 中做类似这样的处理的痛感比在 C++ 中做来的更痛，因为 C# 在设计时就是这样。此外，通过这种方式来访问池中的单个对象比直接将这个对象分配到内存来访问更加的昂贵——前者你得先访问池（这是个类）的地址，这意味着可能产生 2 次缓存未命中。你还可以通过复制 List<T> 的结构形式来避免更多的缓存未命中问题，但这就更难搞了。我就写过很多类似的代码，自然这样的代码只会水平很低而且容易出错。
最后，我想说我指出的问题不仅是那些“热门”的代码。惯用手段编写的 C# 代码倾向于几乎所有地方都用类和引用。意思就是在你的代码中会频率均匀地随机出现数百次的运算周期损耗，使得操作的损耗似乎降低了。这虽然也可以被找出来，但你优化了这问题后，这还是一个 均匀变慢 的程序。
垃圾回收
在读下文之前我会假设你已经知道为什么在许多用例中垃圾回收是影响性能问题的重要原因。播放动画时总是随机的暂停通常都是大家都不能接受的吧。我会继续解释为什么设计语言时还加剧了这个问题。
因为 C# 在处理变量上的一些局限性，它强烈不建议你去使用大内存块分配来存储很多里面是内置对象的变量（可能存在栈中），这就使得你必须使用很多分配在堆中的小型类对象。说白了就是内存分配越多会导致花在垃圾回收上的时间就越多。
有些测评说 C# 或者 Java 是怎么在一些特定的例子中打败 C++ 的，其实是因为内存分配器都基于一种吞吐还算不错的垃圾回收机制（廉价的分配，允许统一的释放分配）。然而，这些测试场景都太特殊了。想要使 C# 的程序的内存分配率变得和那些非常普通的 C++ 程序都能达到的一样就必须要耗费更大的精力来编写它，所以这种比较就像是拿一个高度优化的管理程序和一个最简单原生的程序相比较一样。当你花同样的精力来写一个 C++ 程序时，肯定比你用 C# 来写性能好的多。
我还是相信你可以写出一套适用于高性能低延迟的应用的垃圾回收机制的（比如维护一个增量的垃圾回收，每次消耗固定的时间来做回收），但这还是不够的，大部分的高级语言在设计时就没考虑程序启动时就会产生大量的垃圾，这将会是最大的问题。当你就像写 C 一样习惯的去少去在 C# 分配内存，垃圾回收在高性能应用中可能就不会暴露出很多的问题了。而就算你 真的 去实现了一个增量垃圾回收机制，这意味着你还可能需要为其做一个写屏障——这就相当于又消耗了一些性能了。
看看 .Net 库里那些基本类，内存分配几乎无处不在！我数了下，在 .Net 核心框架 中公共类比结构体的数量多出 19 倍之多，为了使用它们，你就得把这些东西全都弄到内存中去。就算是 .Net 框架的创造者们也无法抵抗设计语言时的警告啊！我都不知道怎么去统计了，使用基础类库时，你会很快意识到这不仅仅是值或对象的选择问题了，就算如此也还是 伴随 着超级多的内存分配。这一切都让你觉得分配内存好像很容易一样，其实怎么可能呢，没有内存分配你连一个整型值都没法输出！不说这个，就算你使用预分配的 StringBuilder，你要是不用标准库来分配内存，也还不是连个整型都存不住。你要这么问我那就挺蠢的了。
当然还不仅仅是标准库，其他的 C# 库也一样。就算是 Unity（一个 游戏引擎，可能能更多的关心平均性能问题）也会有一些全局返回已分配对象（或数组）的接口，或者强制调用时先将其分配内存再使用。举个例子，在一个 GameObject 中要使用 GetComponents 来调用一个数组，Unity 会强制地分配一个数组以便调用。就此而言，其实有许多的接口可以采用，但他们不选择，而去走常规路线来直接使用内存分配。写 Unity 的同胞们写的一手“好 C#”呀，但就是不那么高性能罢了。
结语
如果你在设计一门新的语言，拜托你可以考虑一下我提到的那些性能问题。在你创造出一款“足够聪明的编译器”之后这些都不是什么难题了。当然，没有垃圾回收器就要求类型安全很难。当然，没有一个规范的数据表示就创造一个垃圾回收器很难。当然，出现指向随机值的指针时难以去推出其作用域规则。当然，还有大把大把的问题摆在那里，然而解决了这些所有的问题，设计出来的语言就会是我们想的那样吗？那为什么这么多主要的语言都是在那些六十年代就已经被设计出的语言的基础上迭代的呢？
尽管你不能修复这些问题，但也许你可以尽可能的靠近？或者可以使用域类型（比如 Rust 语言）去保证其类型安全。或者也许可以考虑直接放弃“类型安全成本”去使用更多的运行时检查（如果这不会造成更多的缓存未命中的话，这其实没什么所谓。其实 C# 也有类似的东西，叫协变式数组，严格上讲是违背系统数据类型的，会导致一些运行时异常）。
如果你想在高性能场景中替代 C++，最基本的一点就是要考虑数据的存放布局和存储方式。
作者简介：
我叫 Sebastian Sylvan。我来自瑞典，目前居住在西雅图。我在微软工作，研究全息透镜。诚然我的观点仅代表本人，与微软公司无关。
我的博客以图像、编程语言、性能等内容为主。联系我请点击我的 Twitter 或 E-mail。
via: https://www.sebastiansylvan.com/post/why-most-high-level-languages-are-slow
作者：Sebastian Sylvan 译者：kenxx 校对：wxy
Linux Deepin ：一个拥有独特风格的发行版
编者注：本文原文完成于 2014 年，现在的深度 Linux 发行版已经在此基础上获得更多改进，翻译分享此文是为了让大家看看国外的开源社区对一款来自中国的发行版是如何看的。
这是本系列的第六篇 Linux Deepin。这个发行版真的是非常有意思，它有着许多吸引眼球的地方。许许多多的发行版，它们仅仅将已有的应用放入它的应用市场中，使得它们的应用市场十分冷清。但是 Deepin 却将一切变得不同，虽然这个发行版是基于 Debian 的，但是它提供了属它自己的桌面环境。只有很少的发行版能够将它自己创造的软件做得很好。上次我们曾经提到了 Elementary OS 有着自己的 Pantheon 桌面环境。让我们来看看 Deepin 做得怎么样。
首先，在你登录你的账户后，你会在你设计良好的桌面上看到一个欢迎界面和一个精美的 Dock。这个 Dock 是可定制的，根据你放到上面的软件，它可以有着各种特效。
可以看到 Dock 上有着一个启动器图标，但是还有一个办法可以打开启动器，就是将指针移动到左上角。启动器界面优雅，并且可以分类浏览。
你可以做上面的截图中看到，启动器中的应用被分类得井井有条。还有一个好的地方是当你用鼠标点击到左下角，所有桌面上的应用将会最小化。再次点击则会回复原样。
如果你点击右下角，它将会滑出控制中心。这里可以更改所有电脑上的设置。
你可以看到截屏中的控制中心，设计得非常棒而且也是分类得井井有条，你可以在这里设置所有电脑上的项目。甚至可以自定义你的启动界面的壁纸。
Deepin 有一个自己的应用市场。你可以在这里找到绝大多数软件，并且它们很容易安装。应用市场也被设计得很好，分类齐全易于导航。
另一个亮点是 Deepin 的游戏。它提供许多免费的可联网玩耍的游戏，它们非常的有意思可以很好的用于消磨时光。
Deepin 也提供一个好用的音乐播放软件，它有着网络电台点播功能。如果你本地没有音乐你也不用害怕，你可以调到网络电台模式来享受音乐。
总的来说，Deepin 知道如何让用户享受它的产品。就像它们的座右铭那样：“要做，就做出风格”。它们提供的支持服务也非常棒。尽管是个中国的发行版，但是英语支持得也很好，不用担心语言问题。它的安装镜像大约 1.5 GB。你的访问它们的官网来获得更多信息或者下载。我们非常的推荐你试试这个发行版。
这就是本篇 Linux 发行版介绍的全部内容了，我们将会继续介绍其它的发行版。下次再见！
via: http://www.techphylum.com/2014/08/linux-deepin-distro-with-unique-style.html
作者：sumit rohankar 译者：Chao-zhi 校对：wxy