Liron 发布的文章

如果你要换一部手机或升级你的系统,备份你的数据就变得至关重要。我们存储重要数据的位置之一就是我们的短信/彩信,不管是感情价值还是实用价值,备份它们是很有用的。

然而,不像照片、视频或音频文件可以相对容易地传输和备份,备份短信/彩信比较复杂,通常需要使用第三方 app 或服务。

为什么要手动备份

尽管现在有很多不同的 app 能够帮你备份短信/彩信,你可能因为以下原因,考虑自己动手备份它们:

  1. app 可能不能在所有的设备和安卓版本上都工作。
  2. app 可能把你的备份数据上传到云端, 有破坏你的内容安全的风险。
  3. 通过手动备份,你可以完全掌握你的数据通过哪里,走向哪里,备份过程中减少被间谍软件窥视的危险。
  4. 手动备份相比其他方法更省时,更省力,更直接

怎么手动备份短信/彩信?

要手动备份你的短信/彩信,你需要在你的电脑上安装一个叫做 adb 的安卓工具。

现在,需要重点知道的是,安卓把短信/彩信通常存储在一个叫做 mmssms.db 的数据库里。

因为在不同设备上这个数据库的位置可能不相同,而且,其他短信 app 会创建它们自己的数据库,比如 GO SMS 会创建 gommssms.db 数据库, 所以你需要做的第一件事是搜索这些数据库。

打开命令行工具(我使用了 Linux Terminal, 你也可以使用 Windows CMD 或 PowerShell )并运行以下命令:

注意: 以下是完成该任务的一系列命令,再后面是每个命令用途的解释。

adb root
adb shell
find / -name "*mmssms*"
exit

adb pull /PATH/TO/mmssms.db /PATH/TO/DESTINATION/FOLDER

解释

一开始我们使用 adb root 命令来以 root 模式启动 adb - 这样我们就有了读取系统保护文件的权限。

adb shell 用来进入设备的 shell。

然后, find 命令用来搜索数据库。(在我的例子中,我发现数据库在 /data/data/com.android.providers.telephony/databases/mmssms.db)

建议:如果你的终端输出了太多无关的结果,可以试试使用 find 的参数来精简结果。(具体参数可以搜索引擎查下)

安卓短信/彩信数据库

然后我们使用 exit 命令回退到我们的本地系统目录。

最后,使用 adb pull 把数据库文件复制到我们电脑的一个文件夹里。

现在,当你想要还原短信/彩信时,不管是还原到新的设备还是新的系统版本, 只要再次搜索新系统中短信/彩信的具体位置,并用我们备份的数据库替换它即可。

使用 adb push 来替换它,例如:

adb push ~/Downloads/mmssms.db /data/data/com.android.providers.telephony/databases/mmssms.db

via: https://iwf1.com/how-to-manually-backup-your-sms-mms-messages-on-android/

作者:Liron 译者:willcoderwang 校对:jasminepeng

本文由 LCTT 原创编译,Linux中国 荣誉推出

巨头之间的终极对决:崛起的新星 Node.js 能否战胜巨人 Apache 和 Nginx?

我和你一样,都阅读过大量散布在互联网各处的意见或事实,其中有一些我认为是可靠的,而其它的可能是谣传,让人难以置信。

我读过的许多信息是相当矛盾的,有人深信 StackOverflow(比如这个另一个),而其他人展示了一个清晰的令人惊讶的结果,这在推动我自己去做测试来验证结论的过程中扮演了重要的角色。

起初,我做了一些思想准备,我认为我可以避免自己进行实际测试来校验结论的麻烦——在我知道这一切之前我一直这样认为。

尽管如此,回顾之前,似乎我最初的想法是相当准确的,并且被我的测试再次印证。这个事实让我想起了当年我在学校学到的爱因斯坦和他的光电效应的实验,他面临着一个光的波粒二重性的问题,最初的结论是实验受到他的心理状态的影响,即当他期望结果是一个波的时候结果就会是一个波,反之亦然。

也就是说,我坚信我的结果不会在不久的将来被证明二重性,虽然我的心理状态可能在某种程度上对它们有影响。

关于比较

上面我读过一份材料具有一种革新的方式,在我看来,需要了解其自然而然的主观性和作者自身的偏见。

我决定采用这种方式,因此,提前声明以下内容:

开发者花了很多年来打磨他们的作品。那些取得了更高成就的人通常参考很多因素来做出自己的抉择,这是主观的做法;你需要推崇和捍卫你的技术决策。

也就是说,这个比较文章的着眼点不会成为另一篇“哥们,使用适合你的东西就好”的口水文章。我将会根据我的自身经验、需求和偏见提出建议。你可能会同意其中一些观点,反对另外一些;这很好——你的意见会帮助别人做出明智的选择。

感谢 SitePoint 的 Craig Buckler ,重新启发了我对比较类文章的看法——尝试重新忘记自我,并试图让所有的读者心悦诚服。

关于测试

所有的测试都在本地运行:

  • 英特尔酷睿 i7-2600k,四核八线程的机器
  • Gentoo Linux 是用于测试的操作系统

用于基准测试的工具:ApacheBench,2.3 <$Revision: 1748469 $>

测试包括一系列基准,从 1000 到 10000 个请求以及从 100 到 1000 个的并发请求——结果相当令人惊讶。

此外,我还进行了在高负载下测量服务器功能的压力测试。

至于内容,主要是一个包含一些 Lorem Ipsum 的标题和一张图片静态文件。

Lorem Ipsum 和 ApacheBenchmark

我决定专注于静态文件的原因是因为它们去除了可能对测试产生影响的各种渲染因素,例如:编程语言解释器的速度、解释器与服务器的集成程度等等。

此外,基于我自身的经验,平均网页加载时间很大一部分通常花费在静态内容上,例如图片,因此关注哪个服务器可以节省我们加载静态内容的时间是比较现实的。

除此之外,我还想测试一个更加真实的案例,案例中我在运行不同 CMS 的动态页面(稍后将详细介绍)时对服务器进行基准测试。

服务器

正如我用的是 Gentoo Linux,你就知道我的 HTTP 服务器在一开始就已经经过优化了,因为我在构建系统的时候只使用了我实际需要的东西。也就是说,当我运行我的测试的时候,不会在后台运行任何不必要的代码或加载没用的模块。

Apache、Nginx 和 Node.js 的使用的配置对比

Apache

$: curl -i http://localhost/index.html

HTTP/1.1 200 OK
Date: Sun, 30 Oct 2016 15:35:44 GMT
Server: Apache
Last-Modified: Sun, 30 Oct 2016 14:13:36 GMT
ETag: "2cf2-54015b280046d"
Accept-Ranges: bytes
Content-Length: 11506
Cache-Control: max-age=600
Expires: Sun, 30 Oct 2016 15:45:44 GMT
Vary: Accept-Encoding
Content-Type: text/html

Apache 配置了 “event mpm”。

Nginx

$: curl -i http://localhost/index.html

HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Sun, 30 Oct 2016 14:17:30 GMT
Content-Type: text/html
Content-Length: 11506
Last-Modified: Sun, 30 Oct 2016 14:13:36 GMT
Connection: keep-alive
Keep-Alive: timeout=20
ETag: "58160010-2cf2"
Accept-Ranges: bytes

Nginx 包括几个调整:sendfile ontcp_nopush ontcp_nodelay on

Node.js

$: curl -i http://127.0.0.1:8080

HTTP/1.1 200 OK
Content-Length: 11506
Etag: 15
Last-Modified: Thu, 27 Oct 2016 14:09:58 GMT
Content-Type: text/html
Date: Sun, 30 Oct 2016 16:39:47 GMT
Connection: keep-alive

在静态测试中使用的 Node.js 服务器是从头定制的,这样可以让它尽可能更加的轻快——没有使用外部模块(Node 核心模块除外)。

测试结果

点击图片以放大:

Apache、Nginx 与 Node 的对比:请求负载的性能(每 100 位并发用户)

Apache、Nginx 与 Node 的对比:用户负载能力(每 1000 个请求)

压力测试

Apache、Nginx 与 Node 的对比:完成 1000 位用户并发的 100000 个请求耗时

我们可以从结果中得到什么?

从以上结果判断,似乎 Nginx 可以在最少的时间内完成最多请求,换句话来说,Nginx 是最快的 HTTP 服务器。

还有一个相当惊人的事实是,在特定的用户并发数和请求数下,Node.js 可以比 Nginx 和 Apache 更快。

但当请求的数量在并发测试中增加的时候,Nginx 将重回领先的位置,这个结果可以让那些陷入 Node.js 的遐想的人清醒一下。

和 Apache、Nginx 不同的是,Node.js 似乎对用户的并发数不太敏感,尤其是在集群节点。如图所示,集群节点在 0.1 秒左右保持一条直线,而 Apache 和 Nginx 都有大约 0.2 秒的波动。

基于上述统计可以得出的结论是:网站比较小,其使用的服务器就无所谓。然而,随着网站的受众越来越多,HTTP 服务器的影响变得愈加明显。

当涉及到每台服务器的原始速度的底线的时候,正如压力测试所描述的,我的感觉是,性能背后最关键的因素不是一些特定的算法,而实际上是运行的每台服务器所用的编程语言。

由于 Apache 和 Nginx 都使用了 C 语言—— AOT 语言(编译型语言),而 Node.js 使用了 JavaScript ——这是一种 JIT 语言(解释型语言)。这意味着 Node.js 在执行程序的过程中还有额外的工作负担。

这意味着我不能仅仅基于上面的结果来下结论,而要做进一步校验,正如你下面看到的结果,当我使用一台经过优化的 Node.js 服务器与流行的 Express 框架时,我得到几乎相同的性能结论。

全面考虑

逝者如斯夫,如果没有服务的内容,HTTP 服务器是没什么用的。因此,在比较 web 服务器的时候,我们必须考虑的一个重要的部分就是我们希望在上面运行的内容。

虽然也有其它的功能,但是 HTTP 服务器最广泛的使用就是运行网站。因此,为了看到每台服务器的性能的实际效果,我决定比较一下世界上使用最广泛的 CMS(内容管理系统)WordPress 和 Ghost —— 内核使用了 JavaScript 的一颗冉冉升起的明星。

基于 JavaScript 的 Ghost 网页能否胜过运行在 PHP 和 Apache / Nginx 上面的 WordPress 页面?

这是一个有趣的问题,因为 Ghost 具有操作工具单一且一致的优点——无需额外的封装,而 WordPress 需要依赖 Apache / Nginx 和 PHP 之间的集成,这可能会导致显著的性能缺陷。

除此之外,PHP 距 Node.js 之间还有一个显著的性能落差,后者更佳,我将在下面简要介绍一下,可能会出现一些与初衷大相径庭的结果。

PHP 与 Node.js 的对决

为了比较 WordPress 和 Ghost,我们必须首先考虑一个影响到两者的基本组件。

基本上,WordPress 是一个基于 PHP 的 CMS,而 Ghost 是基于 Node.js(JavaScript)的。与 PHP 不同,Node.js 有以下优点:

  • 非阻塞的 I/O
  • 事件驱动
  • 更新颖、更少的残旧代码

由于有大量的测评文章解释和演示了 Node.js 的原始速度超过 PHP(包括 PHP 7),我不会再进一步阐述这个主题,请你自行用谷歌搜索相关内容。

因此,考虑到 Node.js 的性能优于 PHP,一个 Node.js 的网站的速度要比 Apache / Nginx 和 PHP 的网站快吗?

WordPress 和 Ghost 对决

当比较 WordPress 和 Ghost 时,有些人会说这就像比较苹果和橘子,大多数情况下我同意这个观点,因为 WordPress 是一个完全成熟的 CMS,而 Ghost 基本上只是一个博客平台。

然而,两者仍然有共同竞争的市场,这两者都可以用于向世界发布你的个人文章。

制定一个前提,我们怎么比较两个完全基于不同的代码来运行的平台,包括风格主题和核心功能。

事实上,一个科学的实验测试条件是很难设计的。然而,在这个测试中我对更接近生活的情景更感兴趣,所以 WordPress 和 Ghost 都将保留其主题。因此,这里的目标是使两个平台的网页大小尽可能相似,让 PHP 和 Node.js 在幕后斗智斗勇。

由于结果是根据不同的标准进行测量的,最重要的是尺度不一样,因此在图表中并排显示它们是不公平的。因此,我改为使用表:

Node、Nginx、Apache 以及运行 WordPress 和 Ghost 的比较。前两行是 WordPress,底部的两行是 Ghost

正如你所见,尽管事实上 Ghost(Node.js)正在加载一个更小的页面(你可能会惊讶 1kb 可以产生这么大的差异),它仍然比同时使用 Nginx 和 Apache 的 WordPress 要慢。

此外,使用 Nginx 代理作为负载均衡器来接管每个 Node 服务器的请求实际上会提升还是降低性能?

那么,根据上面的表格,如果说它产生什么效果的话,它造成了更慢的效果——这是一个合理的结果,因为额外封装一层理所当然会使其变得更慢。当然,上面的数字也表明这点差异可以忽略不计。

但是上表中最重要的一点是,即使 Node.js 比 PHP 快,HTTP 服务器的作用也可能超过某个 web 平台使用的编程语言的重要性。

当然,另一方面,如果加载的页面更多地依赖于服务器端的脚本处理,那么我怀疑结果可能会有点不同。

最后,如果一个 web 平台真的想在这场竞赛里击败 WordPress,从这个比较中得出的结论就是,要想性能占优,必须要定制一些像 PHP-FPM 的工具,它将直接与 JavaScript 通信(而不是作为服务器来运行),因此它可以完全发挥 JavaScript 的力量来达到更好的性能。


via: https://iwf1.com/apache-vs-nginx-vs-node-js-and-what-it-means-about-the-performance-of-wordpress-vs-ghost/

作者:Liron 译者:OneNewLife 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

(题图来自:deviantart.net

打包在 Firefox Web 浏览器里面的地理位置服务即使浏览器关闭后也会在后台运行。

我们还没有从关于浏览器插件丑闻的消息中平复下来。插件原本目的是保卫隐私,但现在却把信息卖给了第三方公司。然而更令人愤怒的是其规模完全超出我们的预计。

MLS,即 Mozilla 位置服务,其可以让设备基于类似于 WIFI 接入点、无线电基站和蓝牙信标等基础设施确定其位置。

MLS 非常像是 Google 位置服务,后者是需要在 Android 设备上打开 GPS 并选择“高精度”模式时使用的服务。

那些曾经经历过 GPS 问题的人可能会知道这个模式是多么精确。

MLS 服务除了能够准确地确定您的位置以外,这个服务可以通过使用 WiFi 网络收集两种个人身份信息,包括愿意贡献到数据库的用户被扫描的 WiFi 设备的所有者

话虽这么说,Mozilla 也提到说你可以选择退出服务,但你真的可以退出吗?

当后台变成你隐私的展台

作为一个众包项目,为了维护和发展 MLS,Mozilla 事实上非常依赖于用户的贡献,因此他们开发了多种方法以便用户参与进来。

其中之一,就是被终端用户使用的一款名为 Stumbler 的 Android 应用程序:

Mozilla Stumbler 是一个开源的无线网络扫描器,它为我们的众包位置数据库收集 GPS、蜂窝网络和无线网络元数据。

这样一来,Stumbler 不仅仅是一个独立的应用程序,同时也是 Firefox 在 Android 设备上提供的一种为 MLS“贡献数据和增强功能”的服务。

该服务的问题在于它在后台运行,而大多数用户都不知道它,即使您可能已经禁用它

根据 Mozilla 提供的信息,要启用该服务,您需要打开“设置”菜单(在 Firefox for Android 版本中) -> 打开“隐私”部分 -> 滚动到底部以查看“数据选择”,最后,勾选 Mozilla 位置服务框。

Mozilla 定位服务尚未勾选,但 Stumbler 已开启

实际上,你会发现 Stumbler 服务运行在你的设备后台,这意味着它几乎不可见,因为它没有接口,即使 MLS 框未被选中,即使“数据选择”复选框都未选中,甚至 Firefox 浏览器本身已被关闭。

显然,停止 stumbler 的唯一方法是直接结束它。然而,这样做你首先需要一种方法来检测它的运行和结束,最终,这只是一个设备重启前的临时解决方案。

如何保证安全

为了避免 MLS 收集您的数据,仍然有一些方法值得您尝试一下,希望这些方法不会像在 Firefox for Android 中的MLS 复选框一样被 Mozilla 忽视。

您可以将您的无线网络 SSID 隐藏或者在 SSID 结尾添加“\_nomap”,例如将您的 SSID 从“myWirelessNetwork”更名为“myWirelessNetwork\_nomap”。这在向 Mozilla 的应用程序暗示,您不希望参与他们的数据收集活动。

对于 Android 上的 Stumbler 服务,由于是一个服务(而不是进程),您可能无法在运行的进程/最近的应用程序列表中看到它。 因此,使用专用应用程序关闭它或启用“开发人员选项”,并转到“运行服务” -> 点击 Firefox,最后,停止“stumbler”。


via: https://iwf1.com/is-mozilla-firefox-collecting-your-data-without-your-consent/

作者:Liron 译者:flankershen 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

kde-plasma-to-windows-10

通过一些步骤,我将告诉你如何把 KDE Plasma 5 桌面变成 Windows 10 桌面。

除了菜单, KDE Plasma 桌面的许多地方已经和 Win 10 桌面非常像了。因此,只需要一点点改动就可以使二者看起来几乎是一样。

开始菜单

让 KDE Plasma 桌面看起来像 Win 10 桌面的首要以及可能最有标志性的环节是实现 Win 10 的 ‘开始’ 菜单。

通过安装 Zren's Tiled Menu,这很容易实现。

安装

1、 在 KDE Plasma 桌面上单击右键 -> 解锁窗口部件 Unlock Widgets

2、 在 KDE Plasma 桌面上单击右键 -> 增添窗口部件 Add Widgets

3、 获取新窗口部件 -> 下载新的 Plasma 窗口部件 Download New Plasma Widgets

4、 搜索“Tiled Menu” -> 安装 Install

激活

1、 在你当前的菜单按钮上单击右键 -> 替代…… Alternatives…

2、 选择 "TIled Mune" ->点击 切换 Switch

KDE Tiled 菜单扩展

主题

弄好菜单以后,下一个你可能需要的就是主题。幸运的是, K10ne 提供了一个 WIn 10 主题体验。

安装:

1、 从 Plasma 桌面菜单打开“ 系统设置 System Settings ” -> 工作空间主题 Workspace Theme

2、 从侧边栏选择“ 桌面主题 Desktop Theme ” -> 获取新主题 Get new Theme

3、 搜索“K10ne” -> 安装 Install

激活

1、 从 Plasma 桌面菜单选择“ 系统设置 System Settings ” -> 工作空间主题 Workspace Theme

2、 从侧边栏选择“ 桌面主题 Desktop Theme ” -> “K10ne”

3、 应用 Apply

任务栏

最后,为了有一个更加完整的体验,你可能也想拥有一个更加 Win 10 风格的任务栏,

这次,你需要的安装包,叫做“Icons-only Task Manager”, 在大多数 Linux 发行版中,通常会默认安装。如果没有安装,需要通过你的系统的合适通道来获取它。

激活

1、在 Plasma 桌面上单击右键 -> 打开窗口部件 Unlock Widgets

2、在 Plasma 桌面上单击右键 -> 增添部件 Add Widgets

3、把“Icons-only Task Manager”拖放到你的桌面面板的合适位置。


via: https://iwf1.com/make-kde-plasma-5-desktop-look-feel-like-windows-10-using-these-extensions/

作者:Liron 译者:ucasFL 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

让我们回顾一下 Linux 社区最新的愿景——推动去中心化的应用来解决发行版的碎片化。

继上周的文章:“Snap、Flatpak 这种通吃所有发行版的打包方式真的有用吗?” 之后,一系列新观点浮出水面,其中可能包含关于这样应用是否有用的重要信息。

缺点

就这个话题在这里的评论,一个叫 Till 的 Gentoo 使用者,对于上一次我们未能完全解释的问题给出了一些新的观点。

对于上一次我们选择仅仅称之为膨胀的的东西,Till 从另一方面做了剖析膨胀将来的发展,这可以帮助我们更好的理解它的组成和其影响。

这些被称之为“捆绑应用”的应用程序能够工作在所有发行版上的机制是——将它依赖的库都包含在它们的应用软件之中,Till 说:

“捆绑应用装载了大量的并不被应用开发者所维护的软件。如果其中的某个函数库被发现了一个安全问题而需要更新的话,你得为每一个独立的应用程序安装更新来确保你的系统安全。”

本质上,Till 提出了一个重要的安全问题。但是它并不仅仅与安全有关系,它还关系到许多方面,比如说系统维护、原子更新等等。

此外,如果我们进一步假设:依赖的开发者们也许会合作,将他们的软件与使用它的应用程序一起发布(一种理想状况),但这将导致整个平台的开发整体放缓。

另一个将会导致的问题是透明的依赖关系变得模糊,就是说,如果你想知道一个应用程序捆绑了哪些依赖关系,你必须依靠开发者发布这些数据。

或者就像 Till 说的:“比如说像某某包是否已经包含了更新的某函数库这样的问题将会是你每天需要面对的。”

与之相反,对于 Linux 现行的标准的包管理方法(包括二进制包和源码包),你能够很容易的注意到哪些函数库已经在系统中更新了。

并且,你也可以很轻松的知道其它哪些应用使用了这个函数库,这就将你从繁琐的单独检查每一个应用程序的工作中解救了出来。

其他可能由膨胀导致的缺点包括:更大的包体积(每一个应用程序捆绑了依赖),更高的内存占用(没有共享函数库),并且,少了一个包过滤机制来防止恶意软件:发行版的包维护者也充当了一个在开发者和用户之间的过滤者,他保障了用户获得高质量的软件。

而在捆绑应用中就不再是这种情况了。

最后一点,Till 声称,尽管在某些情况下很有用,但是在大多数情况下,捆绑应用程序将弱化自由软件在发行版中的地位(专有软件供应商将被能够发布他们的软件而不用把它放到公共软件仓库中)。

除此之外,它引出了许多其他问题。很多问题都可以简单归结到开发人员身上。

优点

相比之下,另一个名叫 Sven 的人的评论试图反驳目前普遍反对使用捆绑应用程序的观点,从而证明和支持使用它。

“浪费空间?”——Sven 声称在当今世界我们有很多其他事情在浪费磁盘空间,比如电影存储在硬盘上、本地安装等等……

最终,这些事情浪费的空间要远远多于仅仅“ 100 MB 而你每天都要使用的程序。……因此浪费空间的说法实在很荒谬。”

“浪费运行内存?”——主要的观点有:

  • 共享库浪费的内存要远远少于程序的运行时数据所占用的
  • 而今运行内存已经很便宜了。

“安全梦魇”——不是每个应用程序的运行真正的要注重安全

而且,许多应用程序甚至从来没有过任何安全更新,除非在“滚动更新的发行版”。

除了 Sven 这种从实用出发的观点以外,Till 其实也指出了捆绑应用在一些情况下也有着其优点:

  • 专有软件的供应商想要保持他们的代码游离于公共仓库之外将更加容易。
  • 没有被你的发行版打包进去的小众应用程序将变得更加可行。
  • 在没有 Beta 包的二进制发行版中测试应用将变得简单。
  • 将用户从复杂的依赖关系中解放出来。

最后的思考

虽然关于此问题有着不同的想法,但是有一个被大家共同接受的观点是:捆绑应用对于填补 Linux 生态系统有着其独到的作用。

虽然如此,它的定位,不论是主流的还是边缘的,都变得愈发清晰,至少理论上是这样。

想要尽可能优化其系统的用户,在大多数情况下应该要避免使用捆绑应用。

而讲究易用性、尽可能在维护系统上少费劲的用户,可能应该会感觉这种新应用十分舒爽。


via: http://www.iwillfolo.com/linux-applications-that-works-on-all-distributions-are-they-any-good/

作者:Editorials 译者:Chao-zhi 校对:wxy

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

对新一代的打包格式开始渗透到 Linux 生态系统中的深入观察

最近我们听到越来越多的有关于 Ubuntu 的 Snap 包和由 Red Hat 员工 Alexander Larsson 创造的 Flatpak (曾经叫做 xdg-app)的消息。

这两种下一代打包方法在本质上拥有相同的目标和特点:即不依赖于第三方系统功能库的独立包装。

这种 Linux 新技术方向似乎自然会让人脑海中浮现这样的问题:独立包的优点/缺点是什么?这是否让我们拥有更好的 Linux 系统?其背后的动机是什么?

为了回答这些问题,让我们先深入了解一下 Snap 和 Flatpak。

动机

根据 FlatpakSnap 的声明,背后的主要动机是使同一版本的应用程序能够运行在多个 Linux 发行版。

“从一开始它的主要目标是允许相同的应用程序运行在各种 Linux 发行版和操作系统上。” —— Flatpak
“……‘snap’ 通用 Linux 包格式,使简单的二进制包能够完美的、安全的运行在任何 Linux 桌面、服务器、云和设备上。” —— Snap

说得更具体一点,站在 Snap 和 Flatpak (以下称之为 S&F)背后的人认为,Linux 平台存在碎片化的问题。

这个问题导致了开发者们需要做许多不必要的工作来使他的软件能够运行在各种不同的发行版上,这影响了整个平台的前进。

所以,作为 Linux 发行版(Ubuntu 和 Red Hat)的领导者,他们希望消除这个障碍,推动平台发展。

但是,是否是更多的个人收益刺激了 S&F 的开发?

个人收益?

虽然没有任何官方声明,但是试想一下,如果能够创造这种可能会被大多数发行版(即便不是全部)所采用的打包方式,那么这个项目的领导者将可能成为一个能够决定 Linux 大船航向的重要人物。

优势

这种独立包的好处多多,并且取决于不同的因素。

这些因素基本上可以归为两类:

用户角度

+ 从 Liunx 用户的观点来看:Snap 和 Flatpak 带来了将任何软件包(软件或应用)安装在用户使用的任何发行版上的可能性。

例如你在使用一个不是很流行的发行版,由于开发工作的缺乏,它的软件仓库只有很稀少的包。现在,通过 S&F 你就可以显著的增加包的数量,这是一个多么美好的事情。

+ 同样,对于使用流行的发行版的用户,即使该发行版的软件仓库上有很多的包,他也可以在不改变它现有的功能库的同时安装一个新的包。

比方说, 一个 Debian 的用户想要安装一个 “测试分支” 的包,但是他又不想将他的整个系统变成测试版(来让该包运行在更新的功能库上)。现在,他就可以简单的想安装哪个版本就安装哪个版本,而不需要考虑库的问题。

对于持后者观点的人,可能基本上都是使用源文件编译他们的包的人,然而,除非你使用类似 Gentoo 这样基于源代码的发行版,否则大多数用户将从头编译视为是一个恶心到吐的事情。

+ 高级用户,或者称之为 “拥有安全意识的用户” 可能会觉得更容易接受这种类型的包,只要它们来自可靠来源,这种包倾向于提供另一层隔离,因为它们通常是与系统包想隔离的。

* 不论是 Snap 还是 Flatpak 都在不断努力增强它们的安全性,通常他们都使用 “沙盒化” 来隔离,以防止它们可能携带病毒感染整个系统,就像微软 Windows 系统中的 .exe 程序一样。(关于微软和 S&F 后面还会谈到)

开发者角度

与普通用户相比,对于开发者来说,开发 S&F 包的优点可能更加清楚。这一点已经在上一节有所提示。

尽管如此,这些优点有:

+ S&F 通过统一开发的过程,将多发行版的开发变得简单了起来。对于需要将他的应用运行在多个发行版的开发者来说,这大大的减少了他们的工作量。

++ 因此,开发者能够更容易的使他的应用运行在更多的发行版上。

+ S&F 允许开发者私自发布他的包,不需要依靠发行版维护者在每一个/每一次发行版中发布他的包。

++ 通过上述方法,开发者可以不依赖发行版而直接获取到用户安装和卸载其软件的统计数据。

++ 同样是通过上述方法,开发者可以更好的直接与用户互动,而不需要通过中间媒介,比如发行版这种中间媒介。

缺点

膨胀。就是这么简单。Flatpak 和 Snap 并不是凭空变出来它的依赖关系。相反,它是通过将依赖关系预构建在其中来代替使用系统中的依赖关系。

就像谚语说的:“山不来就我,我就去就山”。

之前提到安全意识强的用户会喜欢 S&F 提供的额外的一层隔离,只要该应用来自一个受信任的来源。但是从另外一个角度看,对这方面了解较少的用户,可能会从一个不靠谱的地方弄来一个包含恶意软件的包从而导致危害。

上面提到的观点可以说是有很有意义的,虽说今天的流行方法,像 PPA、overlay 等也可能是来自不受信任的来源。

但是,S&F 包更加增加这个风险,因为恶意软件开发者只需要开发一个版本就可以感染各种发行版。相反,如果没有 S&F,恶意软件的开发者就需要创建不同的版本以适应不同的发行版。

原来微软一直是正确的吗?

考虑到上面提到的,很显然,在大多数情况下,使用 S&F 包的优点超过缺点。

至少对于二进制发行版的用户,或者重点不是轻量级的发行版的用户来说是这样的。

这促使我问出这个问题,可能微软一直是正确的吗?如果是的,那么当 S&F 变成 Linux 的标准后,你还会一如既往的使用 Linux 或者类 Unix 系统吗?

很显然,时间会是这个问题的最好答案。

不过,我认为,即使不完全正确,但是微软有些地方也是值得赞扬的,并且以我的观点来看,所有这些方式在 Linux 上都立马能用也确实是一个亮点。


via: http://www.iwillfolo.com/ubuntus-snap-red-hats-flatpack-and-is-one-fits-all-linux-packages-useful/

作者:Liron 译者:Chao-zhi 校对:wxy

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