Linuxeden Open Source Community: 四月 2017

2017年4月30日星期日

开源美图 2017 05 01

Linuxeden 开源社区 --

The post 开源美图 2017 05 01 appeared first on Linuxeden开源社区.

http://ift.tt/2qtTMdp

致敬！这些老外的开源技术养活了一票国产软件

Linuxeden 开源社区 -- 致敬！这些老外的开源技术养活了一票国产软件

现在各种国产软件已经牢牢占据了国内市场，无论是在浏览器、下载软件、压缩软件还是视频播放器等领域，都可以看到国产软件活跃的身影。诚然，国产软件在很多方面体验都不错，但之所以它们这么强，很大程度上是因为在核心技术方面，借用了相当多来自开源软件的技术。

大家对国产软件都相当了解，但对于国产软件背后的开源软件，又知道多少？今天，就一起来谈谈国产软件背后的开源软件吧。

养活了一票国产浏览器：Chromium

国内有很多“极速浏览器”，所使用的是 Chrome 同样的引擎，这点大家都相当了解。不过，对于 Chome 背后的开源项目 Chromium，大家了解的细节未必就这么多了。

Chromium 源于 Webkit，而 Webkit 则源于 DE 开源项目 ，兴盛于苹果公司的 Safari 项目，所以说起来 Chromium 和苹果还是有一些渊源的。但是，Chromium 又不仅仅是 Webkit，Chrome 只是继承了 Webkit 的 WebCore 部分，在 JS 引擎上使用了 Google 引以为豪的“V8”，还在 Webkit 上封装了一层 Webkit Glue。可以说，Chromium 对 Webkit 进行了相当程度的魔改 。

致敬！这些老外的开源技术养活了一票国产软件
Chromium 是一堆国产极速浏览器赖以生存的基本

不仅如此，Chromium 也已经转用了 Blink 内核，和 Webkit 的渊源就更加远了。 国内浏览器使用了 Chromium 的源码，因此现在不少也换用了 Blink 内核。

但是，国产浏览器继承的往往只是 Chromium 的内核和 JS 引擎，对其拓展支持部分，却大大被阉割。相较于 Chrome， 国产浏览器对各种扩展插件的支持都相当弱，往往只能安装修改后的扩展 ，这也许是出于商业上的原因。虽然国产软件对比 Chrome 默认多了很多功能，但扩展支持较弱这点，还是令可玩性大减。

国产播放器的大奶妈：FFmpeg

大家都喜欢用国产播放器看小电影，毕竟国产播放器的功能体验用起来真的不错，能够搜字幕，能够云播，最重要的还是支持格式比较全。但是，很多人并不知道，支持格式全这点，其实和国外的开源项目 FFmpeg 是息息相关的。

致敬！这些老外的开源技术养活了一票国产软件
FFmpeg 的解码器造就了无数万能播放器

FFmpeg 是一个和视频处理相关的开源项目，包含了丰富的多媒体解码库。国内的播放器之所以如此万能，很大程度上就是因为使用了 FFmpeg 的解码库。但是，FFmpeg 是基于 LGPL/GPL 开源的，这意味着如果某软件使用了 FFmpeg 的代码，那么这个软件涉及这些代码的部分，也必须开源。但是国内的风气嘛，你懂的，白拿了你的东西才不要守规矩。因此，国内的一些“XX 影音”被钉在了 FFmpeg 的耻辱柱上。

占了便宜还被踢出门：7-Zip

国内有很多免费的压缩软件，这些压缩软件的功能都挺不错，速度也可以，但内核往往也并非来自自己。国内压缩软件往往使用了 7-Zip 这款开源软件的内核，来实现众多压缩文件的支持。

7-Zip 这款开源软件的影响还是非常大的，首先它的效率很高。使用 7-Zip 编码的话，能够比 WinZip 和 WinRAR 提供更高的压缩率。另外它对各种压缩文件支持也非常好，主流的压缩文件基本都给予支持，当然一些商业的压缩格式例如 rar，就只能解压不能压缩。

由于 7-Zip 是开源的，所以它的内核被很多其他压缩软件所使用，国产压缩软件通常就是 7-Zip 的忠实拥簇。

致敬！这些老外的开源技术养活了一票国产软件
7-Zip 在国内不流行的一大原因可能是界面太简陋，但就是这样的风格，社会你 7 哥，人狠话不多

然而，7-Zip 也是一款使用了 LGPL 协议的开源软件，使用了 7-Zip 的源码，按理来说也必须开源。但国内的“X 压”等软件非但没有开源，还在压缩文件的文件头中故意加入无助于压缩的私货，让其他压缩软件无法解压。用了人家的代码还故意制造不兼容，对于这种行为，只想说一句，“我从未见过如此厚颜无耻之人”！

为老司机铺开康庄大道：eMule

如果你是有些年头的老司机，应该会知道 VeryCD 和电驴。VeryCD 这个站点提供了大量 eD2k 链接，通过旗下的“电驴”软件，就可以下载到各种资源。虽然现在 VeryCD 已经转型，但各大下载软件依然对 eD2k 链接有着良好的支持，各种 eD2k 资源，也是老司机们飙车时绕不开的路。

不过电驴和 eD2k 背后的 eMule“电骡”，大家或许就知之甚少了。其实 eD2k 协议最早起源于商业公司开发的 eDonkey（这才是正牌电驴）分享软件，有个德国人不满这软件，就自己开发了开源的客户端 eMule 电骡，也支持 eD2k 协议。国内的 VeryCD 把 eMule 电骡的开源代码魔改后，制造出了大家熟知的“VeryCD 电驴”。

致敬！这些老外的开源技术养活了一票国产软件
如果你没用过 eMule，你可能不是真正的老司机

和 eMule 电骡这个开源软件相比，其实 VeryCD 电驴阉割了相当多的东西。例如，不能直接在 KAD 网络上进行无限制的搜索，这意味着不能无限制地上各种车——现在流行的各种“种子搜索神器”，也只是阉割过的 KAD 搜索器罢了。现在 VeryCD 已经衰败，但 eD2k 仍长存于各大下载软件中，希望大家在开车的同时，也记得背后的 eMule 这位铺路人。

智能路由器的力量之源：OpenWRT

现在国内智能路由器可谓是如火如荼，智能路由器对比传统的路由器，功能的确强大很多。例如，可以外接硬盘当 NAS 用，还可以安装很多第三方插件，实现更强劲的功能。但是，智能路由器所依仗的 OpenWRT，却鲜为人知。

致敬！这些老外的开源技术养活了一票国产软件
没有 OpenWRT，就没有一众智能路由器

OpenWRT 是一款开源的路由器固件，扩展性强是 OpenWRT 最大的卖点——这也是智能路由器们的最大卖点。OpenWRT 源于 Linux，其强大的拓展性很大程度上也是得益于 Linux。不过和 Linux 一样，OpenWRT 的使用门槛也比较高，原版需要命令行操纵，没有一定的 Linux 和网络知识还真是无法驾驭。国内的路由器厂商把 OpenWRT 改造成界面更友好的固件，可以算是 OpenWRT 的改版。

不过，国内的智能路由器固件虽然上手容易，但对比 OpenWRT，还是有一些方面例如性能和可玩性方面，是有所不如的。对比 OpenWRT，智能路由器固件的性能和稳定性都要偏弱。特别是高流量时候的吞吐性能，差距会显得更加明显；而在扩展方面，由于技术和商业上的原因，可玩性也不如 OpenWRT。而且，国内智能路由器厂商使用了 OpenWRT，往往也不根据 GPL 协议继续开源，这些都是很值得批判一番的。

总结

在这个广告铺天盖地的商业社会，大家很少会听见开源软件的种种消息。闭源的商业软件搭造起了软件世界琳琅满目的繁华，但开源软件也未曾离开过栋梁的位置。诚然，国产软件的很多功能都相当容易上手，但在使用这些商业软件的时候，大家也应该记住背后默默奉献的开源项目，信息时代少了它们，也会失去很多光彩！

转自 http://ift.tt/2qjj4i6

The post 致敬！这些老外的开源技术养活了一票国产软件 appeared first on Linuxeden开源社区.

http://ift.tt/2pw0tfS

我编写了一个怪物 —— “消沉的程序员”漫画赏析

Linuxeden 开源社区 --

消沉的程序员 1

depressed-developer

很有意思吧，很多看到这样的漫画对话的程序员，应该感觉似曾相识吧。Bug 出现了？

消沉的程序员 2

depressed-developer

有点疑惑，有好像有点眉目，好像是感觉到哪里错了，是不是要重构。

消沉的程序员 3

depressed-developer

哎，终于发现错误了，感觉有点可笑，自己居然犯这样的错误，原来是那次急于提交代码造成的。

消沉的程序员 4

depressed-developer

是啊，在编程里一生戎马，代码编写无数，各种平台、规范等等，到头来也是满身的错误啊。该是技术不行吧！

消沉的程序员 5

depressed-developer

呀，快要消除错误了，可是，不对。相信事后的 Bug 和 Debug 会是程序员生活中的一个部分。

消沉的程序员 6

depressed-developer

每个新建的工程都是有美好的设想吧，可后来为什么总是渐行渐远？大多时候的自言自语，总是有人认为是在和代码对话吧？可没有身在其中，别人又怎么懂得！

消沉的程序员 7

depressed-developer

好吧，产品的上线，总是要经过无数次的创建分支，Bug 和 Debug 总还是程序员的永恒话题。其中，有些东西总免不了自己推翻自己，感觉要从头再来一样。

消沉的程序员 10

depressed-developer

为了某项专门的研究，学习一门相关的语言，不知道是不是值得？是不是先要思考其必要性呢？最后发现自己并不喜欢这门语言，导致怀疑自己的专业技能，这样大概不好吧！

消沉的程序员 11

depressed-developer

其实，本来是愉快的蹲个坑，却不自觉的陷入编码的思考。想想，不仅是程序员，很多人有都有类似此景的情况吧，明明在做着某事，却想着另外一件事。

后记

看至此处，各位朋友是不是感觉少了系列的第 8 和第 9 篇？起初，译者也这么想，后来问了作者 Daniel Stori 之后，才恍然，原来序号采用了八进制，按照作者说的，一个隐式的玩笑。明白了吗，朋友们？

大伙儿都习惯了日常的十进制。当常态处于优先级的时候，日常一些非常态就如同细枝末节，也就往往容易被人们忽略。大概就是这样吧。

译者： GHLandy，作者： Daniel Stori，via：Linux 中国

The post 我编写了一个怪物 —— “消沉的程序员”漫画赏析 appeared first on Linuxeden开源社区.

http://ift.tt/2oZ92yH

Python 是慢，但我无所谓

Linuxeden 开源社区 --

为牺牲性能追求生产率而呐喊

让我从关于 Python 中的 asyncio 这个标准库的讨论中休息一会，谈谈我最近正在思考的一些东西：Python 的速度。对不了解我的人说明一下，我是一个 Python 的粉丝，而且我在我能想到的所有地方都积极地使用 Python。人们对 Python 最大的抱怨之一就是它的速度比较慢，有些人甚至拒绝尝试使用 Python，因为它比其他语言速度慢。这里说说为什么我认为应该尝试使用 Python，尽管它是有点慢。

速度不再重要

过去的情形是，程序需要花费很长的时间来运行，CPU 比较贵，内存也很贵。程序的运行时间是一个很重要的指标。计算机非常的昂贵，计算机运行所需要的电也是相当贵的。对这些资源进行优化是因为一个永恒的商业法则：

优化你最贵的资源。

在过去，最贵的资源是计算机的运行时间。这就是导致计算机科学致力于研究不同算法的效率的原因。然而，这已经不再是正确的，因为现在硅芯片很便宜，确实很便宜。运行时间不再是你最贵的资源。公司最贵的资源现在是它的员工时间。或者换句话说，就是你。把事情做完比把它变快更加重要。实际上，这是相当的重要，我将把它再次放在这里，仿佛它是一个引文一样（给那些只是粗略浏览的人）:

把事情做完比快速地做事更加重要。

你可能会说：“我的公司在意速度，我开发一个 web 应用程序，那么所有的响应时间必须少于 x 毫秒。”或者，“我们失去了客户，因为他们认为我们的 app 运行太慢了。”我并不是想说速度一点也不重要，我只是想说速度不再是最重要的东西；它不再是你最贵的资源。

速度是唯一重要的东西

当你在编程的背景下说速度时，你通常是说性能，也就是 CPU 周期。当你的 CEO 在编程的背景下说速度时，他指的是业务速度，最重要的指标是产品上市的时间。基本上，你的产品/web 程序是多么的快并不重要。它是用什么语言写的也不重要。甚至它需要花费多少钱也不重要。在一天结束时，让你的公司存活下来或者死去的唯一事物就是产品上市时间。我不只是说创业公司的想法 — 你开始赚钱需要花费多久，更多的是“从想法到客户手中”的时间期限。企业能够存活下来的唯一方法就是比你的竞争对手更快地创新。如果在你的产品上市之前，你的竞争对手已经提前上市了，那么你想出了多少好的主意也将不再重要。你必须第一个上市，或者至少能跟上。一但你放慢了脚步，你就输了。

企业能够存活下来的唯一方法就是比你的竞争对手更快地创新。

一个微服务的案例

像 Amazon、Google 和 Netflix 这样的公司明白快速前进的重要性。他们创建了一个业务系统，可以使用这个系统迅速地前进和快速的创新。微服务是针对他们的问题的解决方案。这篇文章不谈你是否应该使用微服务，但是至少要理解为什么 Amazon 和 Google 认为他们应该使用微服务。

微服务本来就很慢。微服务的主要概念是用网络调用来打破边界。这意味着你正在把使用的函数调用（几个 cpu 周期）转变为一个网络调用。没有什么比这更影响性能了。和 CPU 相比较，网络调用真的很慢。但是这些大公司仍然选择使用微服务。我所知道的架构里面没有比微服务还要慢的了。微服务最大的弊端就是它的性能，但是最大的长处就是上市的时间。通过在较小的项目和代码库上建立团队，一个公司能够以更快的速度进行迭代和创新。这恰恰表明了，非常大的公司也很在意上市时间，而不仅仅只是只有创业公司。

CPU 不是你的瓶颈

如果你在写一个网络应用程序，如 web 服务器，很有可能的情况会是，CPU 时间并不是你的程序的瓶颈。当你的 web 服务器处理一个请求时，可能会进行几次网络调用，例如到数据库，或者像 Redis 这样的缓存服务器。虽然这些服务本身可能比较快速，但是对它们的网络调用却很慢。这里有一篇很好的关于特定操作的速度差异的博客文章。在这篇文章里，作者把 CPU 周期时间缩放到更容易理解的人类时间。如果一个单独的 CPU 周期等同于 1 秒，那么一个从 California 到 New York 的网络调用将相当于 4 年。那就说明了网络调用是多少的慢。按一些粗略估计，我们可以假设在同一数据中心内的普通网络调用大约需要 3 毫秒。这相当于我们“人类比例” 3 个月。现在假设你的程序是高 CPU 密集型，这需要 100000 个 CPU 周期来对单一调用进行响应。这相当于刚刚超过 1 天。现在让我们假设你使用的是一种要慢 5 倍的语言，这将需要大约 5 天。很好，将那与我们 3 个月的网络调用时间相比，4 天的差异就显得并不是很重要了。如果有人为了一个包裹不得不至少等待 3 个月，我不认为额外的 4 天对他们来说真的很重要。

上面所说的终极意思是，尽管 Python 速度慢，但是这并不重要。语言的速度（或者 CPU 时间）几乎从来不是问题。实际上谷歌曾经就这一概念做过一个研究，并且他们就此发表过一篇论文。那篇论文论述了设计高吞吐量的系统。在结论里，他们说到：

在高吞吐量的环境中使用解释性语言似乎是矛盾的，但是我们已经发现 CPU 时间几乎不是限制因素；语言的表达性是指，大多数程序是源程序，同时它们的大多数时间花费在 I/O 读写和本机的运行时代码上。而且，解释性语言无论是在语言层面的轻松实验还是在允许我们在很多机器上探索分布计算的方法都是很有帮助的，

再次强调：

CPU 时间几乎不是限制因素。

如果 CPU 时间是一个问题怎么办？

你可能会说，“前面说的情况真是太好了，但是我们确实有过一些问题，这些问题中 CPU 成为了我们的瓶颈，并造成了我们的 web 应用的速度十分缓慢”，或者“在服务器上 X 语言比 Y 语言需要更少的硬件资源来运行。”这些都可能是对的。关于 web 服务器有这样的美妙的事情：你可以几乎无限地负载均衡它们。换句话说，可以在 web 服务器上投入更多的硬件。当然，Python 可能会比其他语言要求更好的硬件资源，比如 c 语言。只是把硬件投入在 CPU 问题上。相比于你的时间，硬件就显得非常的便宜了。如果你在一年内节省了两周的生产力时间，那将远远多于所增加的硬件开销的回报。

那么，Python 更快一些吗？

这一篇文章里面，我一直在谈论最重要的是开发时间。所以问题依然存在：当就开发时间而言，Python 要比其他语言更快吗？按常规惯例来看，我、 google 还有其他几个人可以告诉你 Python 是多么的高效。它为你抽象出很多东西，帮助你关注那些你真正应该编写代码的地方，而不会被困在琐碎事情的杂草里，比如你是否应该使用一个向量或者一个数组。但你可能不喜欢只是听别人说的这些话，所以让我们来看一些更多的经验数据。

在大多数情况下，关于 python 是否是更高效语言的争论可以归结为脚本语言（或动态语言）与静态类型语言两者的争论。我认为人们普遍接受的是静态类型语言的生产力较低，但是，这有一篇优秀的论文解释了为什么不是这样。就 Python 而言，这里有一项研究，它调查了不同语言编写字符串处理的代码所需要花费的时间，供参考。

在上述研究中，Python 的效率比 Java 高出 2 倍。有一些其他研究也显示相似的东西。 Rosetta Code 对编程语言的差异进行了深入的研究。在论文中，他们把 python 与其他脚本语言/解释性语言相比较，得出结论：

Python 更简洁，即使与函数式语言相比较（平均要短 1.2 到 1.6 倍）

普遍的趋势似乎是 Python 中的代码行总是更少。代码行听起来可能像一个可怕的指标，但是包括上面已经提到的两项研究在内的多项研究表明，每种语言中每行代码所需要花费的时间大约是一样的。因此，限制代码行数就可以提高生产效率。甚至 codinghorror（一名 C# 程序员）本人写了一篇关于 Python 是如何更有效率的文章。

我认为说 Python 比其他的很多语言更加的有效率是公正的。这主要是由于 Python 有大量的自带以及第三方库。这里是一篇讨论 Python 和其他语言间的差异的简单的文章。如果你不知道为何 Python 是如此的小巧和高效，我邀请你借此机会学习一点 python，自己多实践。这儿是你的第一个程序：

import __hello__

但是如果速度真的重要呢？

上述论点的语气可能会让人觉得优化与速度一点也不重要。但事实是，很多时候运行时性能真的很重要。一个例子是，你有一个 web 应用程序，其中有一个特定的端点需要用很长的时间来响应。你知道这个程序需要多快，并且知道程序需要改进多少。

在我们的例子中，发生了两件事：

我们注意到有一个端点执行缓慢。
我们承认它是缓慢，因为我们有一个可以衡量是否足够快的标准，而它没达到那个标准。

我们不必在应用程序中微调优化所有内容，只需要让其中每一个都“足够快”。如果一个端点花费了几秒钟来响应，你的用户可能会注意到，但是，他们并不会注意到你将响应时间由 35 毫秒降低到 25 毫秒。“足够好”就是你需要做到的所有事情。免责声明: 我应该说有一些应用程序，如实时投标程序，确实需要细微优化，每一毫秒都相当重要。但那只是例外，而不是规则。

为了明白如何对端点进行优化，你的第一步将是配置代码，并尝试找出瓶颈在哪。毕竟：

任何除了瓶颈之外的改进都是错觉。Any improvements made anywhere besides the bottleneck are an illusion. — Gene Kim

如果你的优化没有触及到瓶颈，你只是浪费你的时间，并没有解决实际问题。在你优化瓶颈之前，你不会得到任何重要的改进。如果你在不知道瓶颈是什么前就尝试优化，那么你最终只会在部分代码中玩耍。在测量和确定瓶颈之前优化代码被称为“过早优化”。人们常提及 Donald Knuth 说的话，但他声称这句话实际上是他从别人那里听来的：

过早优化是万恶之源 Premature optimization is the root of all evil。

在谈到维护代码库时，来自 Donald Knuth 的更完整的引文是：

在 97% 的时间里，我们应该忘记微不足道的效率：过早的优化是万恶之源。然而在关键的 3%，我们不应该错过优化的机会。 —— Donald Knuth

换句话说，他所说的是，在大多数时间你应该忘记对你的代码进行优化。它几乎总是足够好。在不是足够好的情况下，我们通常只需要触及 3% 的代码路径。比如因为你使用了 if 语句而不是函数，你的端点快了几纳秒，但这并不会使你赢得任何奖项。

过早的优化包括调用某些更快的函数，或者甚至使用特定的数据结构，因为它通常更快。计算机科学认为，如果一个方法或者算法与另一个具有相同的渐近增长（或称为 Big-O），那么它们是等价的，即使在实践中要慢两倍。计算机是如此之快，算法随着数据/使用增加而造成的计算增长远远超过实际速度本身。换句话说，如果你有两个 O(log n) 的函数，但是一个要慢两倍，这实际上并不重要。随着数据规模的增大，它们都以同样的速度“慢下来”。这就是过早优化是万恶之源的原因；它浪费了我们的时间，几乎从来没有真正有助于我们的性能改进。

就 Big-O 而言，你可以认为对你的程序而言，所有的语言都是 O(n)，其中 n 是代码或者指令的行数。对于同样的指令，它们以同样的速率增长。对于渐进增长，一种语言的速度快慢并不重要，所有语言都是相同的。在这个逻辑下，你可以说，为你的应用程序选择一种语言仅仅是因为它的“快速”是过早优化的最终形式。你选择某些预期快速的东西，却没有测量，也不理解瓶颈将在哪里。

为您的应用选择语言只是因为它的“快速”，是过早优化的最终形式。

优化 Python

我最喜欢 Python 的一点是，它可以让你一次优化一点点代码。假设你有一个 Python 的方法，你发现它是你的瓶颈。你对它优化过几次，可能遵循这里和那里的一些指导，现在，你很肯定 Python 本身就是你的瓶颈。Python 有调用 C 代码的能力，这意味着，你可以用 C 重写这个方法来减少性能问题。你可以一次重写一个这样的方法。这个过程允许你用任何可以编译为 C 兼容汇编程序的语言，编写良好优化后的瓶颈方法。这让你能够在大多数时间使用 Python 编写，只在必要的时候都才用较低级的语言来写代码。

有一种叫做 Cython 的编程语言，它是 Python 的超集。它几乎是 Python 和 C 的合并，是一种渐进类型的语言。任何 Python 代码都是有效的 Cython 代码，Cython 代码可以编译成 C 代码。使用 Cython，你可以编写一个模块或者一个方法，并逐渐进步到越来越多的 C 类型和性能。你可以将 C 类型和 Python 的鸭子类型混在一起。使用 Cython，你可以获得混合后的完美组合，只在瓶颈处进行优化，同时在其他所有地方不失去 Python 的美丽。

星战前夜的一幅截图：这是用 Python 编写的 space MMO 游戏。

当您最终遇到 Python 的性能问题阻碍时，你不需要把你的整个代码库用另一种不同的语言来编写。你只需要用 Cython 重写几个函数，几乎就能得到你所需要的性能。这就是星战前夜采取的策略。这是一个大型多玩家的电脑游戏，在整个架构中使用 Python 和 Cython。它们通过优化 C/Cython 中的瓶颈来实现游戏级别的性能。如果这个策略对他们有用，那么它应该对任何人都有帮助。或者，还有其他方法来优化你的 Python。例如，PyPy 是一个 Python 的 JIT 实现，它通过使用 PyPy 替掉 CPython（这是 Python 的默认实现），为长时间运行的应用程序提供重要的运行时改进（如 web 服务器）。

让我们回顾一下要点：

优化你最贵的资源。那就是你，而不是计算机。
选择一种语言/框架/架构来帮助你快速开发（比如 Python）。不要仅仅因为某些技术的快而选择它们。
当你遇到性能问题时，请找到瓶颈所在。
你的瓶颈很可能不是 CPU 或者 Python 本身。
如果 Python 成为你的瓶颈（你已经优化过你的算法），那么可以转向热门的 Cython 或者 C。
尽情享受可以快速做完事情的乐趣。

我希望你喜欢阅读这篇文章，就像我喜欢写这篇文章一样。如果你想说谢谢，请为我点下赞。另外，如果某个时候你想和我讨论 Python，你可以在 twitter 上艾特我（@nhumrich），或者你可以在 Python slack channel 找到我。

作者简介：

Nick Humrich — 坚持采用持续交付的方法，并为之写了很多工具。同是还是一名 Python 黑客与技术狂热者，目前是一名 DevOps 工程师。

（题图：Pixabay，CC0）

via: http://ift.tt/2pnusc7

作者：Nick Humrich 译者：zhousiyu325 校对：jasminepeng

The post Python 是慢，但我无所谓 appeared first on Linuxeden开源社区.

http://ift.tt/2oNxdEa

FileZilla Client 3.25.2 发布，FTP 解决方案

Linuxeden 开源社区 --

FileZilla Client 3.25.2 发布了。FileZilla 是一个快速、可信赖的 FTP 客户端以及服务器端的开放源代码程序，具有多种特色、直观的接口。

更新内容：

SFTP components have been updated and are now based on PuTTY 0.69
Fixed potential stall during the final listing operation when finishing a queue which contained uploads

发布主页和下载地址：

http://ift.tt/13OgtXY

转自 http://ift.tt/2pkZel2

The post FileZilla Client 3.25.2 发布，FTP 解决方案 appeared first on Linuxeden开源社区.

http://ift.tt/2oNGyvJ

OpenELEC 8.0.3 发布，家庭影院 Linux 发行版

Linuxeden 开源社区 --

OpenELEC 8.0.3 发布了。OpenELEC 旨在作为媒体中心，是一个附带家庭影院的 Linux 发行版本，使用基于 XBMC 的软件。

更新内容：

修复在播放流时 Kodi 的崩溃问题。
修复一些非工作的屏幕保护程序，这仅在第一次安装非工作屏保程序时有效。
禁用 CONFIG_USB_UAS 以修复 RPi 版本上的一些外部硬盘驱动器的问题。
修复安装程序。
更新 libcec 以修复一些上游问题。
其他版本更新至 mesa-17.0.5, linux-4.9.25 (Generic/RPi*), mariadb-10.1.22, samba-4.6.3, connman-1.34, libsndfile-1.0.28.

下载地址：