在我们开始谈论缺点之前，我要确定的事实是过去 3 年来，我一直是一个忠实的 UC 浏览器用户。我真的很喜欢它的下载速度，超时尚的用户界面和工具上引人注目的图标。我一开始是 Android 上的 Chrome 用户，但我在朋友的推荐下开始使用 UC。但在过去的一年左右，我看到了一些东西让我重新思考我的选择，现在我感觉我要重新回到 Chrome。

不需要的通知

我相信我不是唯一一个每几个小时内就收到这些不需要的通知的人。这些欺骗点击的文章真的很糟糕，最糟糕的部分是你每隔几个小时就会收到一次。

我试图从通知设置里关闭他们，但它们仍然以一个更低频率出现。

新闻主页

另一个不需要的部分是完全无用的。我们完全理解 UC 浏览器是免费下载，可能需要资金，但并不应该这么做。这个主页上的新闻文章是非常让人分心且不需要的。有时当你在一个专业或家庭环境中的一些诱骗点击甚至可能会导致尴尬。

而且他们甚至有这样的设置。将 UC 新闻显示打开/关闭。我也试过，猜猜看发生了什么。在下图中，左侧你可以看到我的尝试，右侧可以看到结果。

而且不止诱骗点击新闻，他们已经开始添加一些不必要的功能。所以我也列出它们。

UC 音乐

UC 浏览器在浏览器中集成了一个音乐播放器来播放音乐。它只是能用，没什么特别的东西。那为什么还要呢？有什么原因呢？谁需要浏览器中的音乐播放器？

它甚至不是在后台直接播放来自网络的音频。相反，它是一个播放离线音乐的音乐播放器。所以为什么要它？我的意思是，它甚至没有好到可以作为主要音乐播放器。即使它足够好，它也不能独立于 UC 浏览器运行。所以为什么会有人运行将他/她的浏览器只是为了使用你的音乐播放器？

快速访问栏

我已经看到平均有 90% 的用户在通知区域挂着这栏，因为它默认安装，并且它们不知道如何摆脱它。右侧的设置可以摆脱它。

但是我还是想问一下，“为什么它是默认的？”。这让大多数用户很头痛。如果我们需要它，就会去启用它。为什么要强迫用户。

总结

UC 浏览器仍然是最大的玩家之一。它提供了一个最好的体验，但是，我不知道 UC 通过在浏览中打包进将越来越多的功能并强迫用户使用它们是要证明什么。

我喜欢 UC 的速度和设计。但最近的体验导致我再次考虑我的主要浏览器。

via: https://www.theitstuff.com/biggest-problems-uc-browser

作者：Rishabh Kandari 译者：geekpi 校对：wxy

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

Ansible Container 解决了 Dockerfile 的不足，并对容器化项目提供了完整的管理。

Image by : opensource.com

我喜欢容器，并且每天都使用这个技术。即便如此，容器并不完美。不过，在过去几个月里，一系列项目已经解决了我遇到的一些问题。

我刚开始时，用 Docker 使用容器，这个项目使得这种技术非常流行。除了使用这个容器引擎之外，我学到了怎么去使用 docker-compose 以及怎么去用它管理我的项目。使用它使得我的生产力猛增！一个命令就可以运行我的项目，而不管它有多复杂。因此，我太高兴了。

使用一段时间之后，我发现了一些问题。最明显的问题是创建容器镜像的过程。Docker 工具使用一个定制的文件格式作为生成容器镜像的依据：Dockerfile。这个格式易于学习，并且很短的一段时间之后，你就可以自己制作容器镜像了。但是，一旦你希望进一步掌握它或者考虑到复杂场景，问题就会出现。

让我们打断一下，先去了解一个不同的东西：Ansible 的世界。你知道它吗？它棒极了，是吗？你不这么认为？好吧，是时候去学习一些新事物了。Ansible 是一个允许你通过写一些任务去管理你的基础设施，并在你选择的环境中运行它们的项目。不需要去安装和设置任何的服务；你可以从你的笔记本电脑中很容易地做任何事情。许多人已经接受 Ansible 了。

想像一下这样的场景：你在 Ansible 中，你写了很多的 Ansible 角色 role 和 剧本 playbook ，你可以用它们去管理你的基础设施，并且你想把它们运用到容器中。你应该怎么做？通过 shell 脚本和 Dockerfile 去写容器镜像定义？听起来好像不对。

来自 Ansible 开发团队的一些人问到这个问题，并且他们意识到，人们每天编写和使用的那些同样的 Ansible 角色和剧本也可以用来制作容器镜像。但是 Ansible 能做到的不止这些 —— 它可以被用于去管理容器化项目的完整生命周期。从这些想法中，Ansible Container 项目诞生了。它利用已有的 Ansible 角色转变成容器镜像，甚至还可以被用于生产环境中从构建到部署的完整生命周期。

现在让我们讨论一下，我之前提到过的在 Dockerfile 环境中的最佳实践问题。这里有一个警告：这将是非常具体且技术性的。出现最多的三个问题有：

1、 在 Dockerfile 中内嵌的 Shell 脚本

当写 Dockerfile 时，你可以指定会由 /bin/sh -c 解释执行的脚本。它类似如下：

RUN dnf install -y nginx

这里 RUN 是一个 Dockerfile 指令，其它的都是参数（它们传递给 shell）。但是，想像一个更复杂的场景：

RUN set -eux; \
    \
# this "case" statement is generated via "update.sh"
    %%ARCH-CASE%%; \
    \
    url="https://golang.org/dl/go${GOLANG_VERSION}.${goRelArch}.tar.gz"; \
    wget -O go.tgz "$url"; \
    echo "${goRelSha256} *go.tgz" | sha256sum -c -; \

这仅是从 golang 官方镜像 中拿来的一段。它看起来并不好看，是不是？

2、 解析 Dockerfile 并不容易

Dockerfile 是一个没有正式规范的新格式。如果你需要在你的基础设施（比如，让构建过程自动化一点）中去处理 Dockerfile 将会很复杂。仅有的规范是 这个代码，它是 dockerd 的一部分。问题是你不能使用它作为一个 库 library 来使用。最容易的解决方案是你自己写一个解析器，然后祈祷它运行的很好。使用一些众所周知的标记语言不是更好吗？比如，YAML 或者 JSON。

3、 管理困难

如果你熟悉容器镜像的内部结构，你可能知道每个镜像是由 层 layer 构成的。一旦容器被创建，这些层就使用联合文件系统技术堆叠在一起（像煎饼一样）。问题是，你并不能显式地管理这些层 — 你不能说，“这儿开始一个新层”，你被迫使用一种可读性不好的方法去改变你的 Dockerfile。最大的问题是，必须遵循一套最佳实践以去达到最优结果 — 新来的人在这个地方可能很困难。

Ansible 语言和 Dockerfile 比较

相比 Ansible，Dockerfile 的最大缺点，也是 Ansible 的优点，作为一个语言，Ansible 更强大。例如，Dockerfile 没有直接的变量概念，而 Ansible 有一个完整的模板系统（变量只是它其中的一个特性）。Ansible 包含了很多更易于使用的模块，比如，wait\_for，它可以被用于服务就绪检查，比如，在处理之前等待服务准备就绪。在 Dockerfile 中，做任何事情都通过一个 shell 脚本。因此，如果你想去找出已准备好的服务，它必须使用 shell（或者独立安装）去做。使用 shell 脚本的其它问题是，它会变得很复杂，维护成为一种负担。很多人已经发现了这个问题，并将这些 shell 脚本转到 Ansible。

关于作者

Tomas Tomecek - 工程师、Hacker、演讲者、Tinker、Red Hatter。喜欢容器、linux、开源软件、python 3、rust、zsh、tmux。More about me

via: https://opensource.com/article/17/10/dockerfiles-ansible-container

作者：Tomas Tomecek 译者：qhwdw 校对：wxy

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

这是我第一次遇到无法翻译的漫画。

#! 是 Unix/Linux 里面用于指示脚本解释器的特定语法，位于脚本中的第一行，以 #! 开头，接着是该脚本的解释器，通常是 /bin/bash、/usr/bin/python 之类。

关于 #! 其英文名称为“shebang”，其中的“she” 来源于 “#”的发音 “sharp”，“bang”来源于“!”，故如此命名。

Linux 中国翻译组核心成员 GOLinux 提议将此专有名称翻译为“释伴”。

回到这幅漫画，作者的原意可能是：我！你！他！ ，以此类推，然后是她（she）！ 即 #!S。（附注：感谢万能的网友指出我没看懂的部分。）

via: http://turnoff.us/geek/shebang/

作者：Daniel Stori 点评：wxy

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

在之前的教程中，我们已经学习了在机器上安装 git。本教程，我们将讨论如何使用 git，比如与 git 一起使用的各种命令。所以我们开始吧。

• 推荐阅读：如何在 Linux 上安装 GIT (Ubuntu 和 CentOS)

设置用户信息

这应该是安装完 git 的第一步。我们将添加用户信息 (用户名和邮箱)，所以当我们提交代码时，会产生带有用户信息的提交信息，这使得跟踪提交过程变得更容易。要添加用户信息，命令是 git config：

$ git config --global user.name "Daniel"
$ git config --global user.email "[email protected]"

添加完用户信息之后，通过运行下面命令，我们将检查这些信息是否成功更新。

$ git config --list

我们应该能够看到输出的用户信息。

GIT 命令

新建一个仓库

为了建立一个新仓库，运行如下命令：

$ git init

查找一个仓库

为了查找一个仓库，命令如下：

$ git grep "repository"

与远程仓库连接

为了与远程仓库连接，运行如下命令：

$ git remote add origin remote_server

然后检查所有配置的远程服务器，运行如下命令：

$ git remote -v

克隆一个仓库

为了从本地服务器克隆一个仓库，运行如下代码：

$ git clone repository_path

如果我们想克隆远程服务器上的一个仓库，那克隆这个仓库的命令是：

$ git clone repository_path

在仓库中列出分支

为了检查所有可用的和当前工作的分支列表，执行：

$ git branch

创建新分支

创建并使用一个新分支，命令是：

$ git checkout -b 'branchname'

删除一个分支

为了删除一个分支，执行：

$ git branch -d 'branchname'

为了删除远程仓库的一个分支，执行：

$ git push origin:'branchname'

切换到另一个分支

从当前分支切换到另一个分支，使用

$ git checkout 'branchname'

添加文件

添加文件到仓库，执行：

$ git add filename

文件状态

检查文件状态 (那些将要提交或者添加的文件)，执行：

$ git status

提交变更

在我们添加一个文件或者对一个文件作出变更之后，我们通过运行下面命令来提交代码：

$ git commit -a

提交变更到 head 但不提交到远程仓库，命令是：

$ git commit -m "message"

推送变更

推送对该仓库 master 分支所做的变更，运行：

$ git push origin master

推送分支到仓库

推送对单一分支做出的变更到远程仓库，运行：

$ git push origin 'branchname'

推送所有分支到远程仓库，运行：

$ git push -all origin

合并两个分支

合并另一个分支到当前活动分支，使用命令：

$ git merge 'branchname'

从远端服务器合并到本地服务器

从远端服务器下载/拉取变更到到本地服务器的工作目录，运行：

$ git pull 

检查合并冲突

查看对库文件的合并冲突，运行：

$ git diff -base 'filename'

查看所有冲突，运行：

$ git diff

如果我们在合并之前想预览所有变更，运行：

$ git diff 'source-branch' 'target-branch' 

创建标记

创建标记来标志任一重要的变更，运行：

$ git tag 'tag number' 'commit id' 

通过运行以下命令，我们可以查找 commit id ：

$ git log

推送标记

推送所有创建的标记到远端服务器，运行：

$ git push -tags origin

恢复做出的变更

如果我们想用 head 中最后一次变更来替换对当前工作树的变更，运行：

$ git checkout -'filename'

我们也可以从远端服务器获取最新的历史，并且将它指向本地仓库的 master 分支,而不是丢弃掉所有本地所做所有变更。为了这么做，运行：

$ git fetch origin
$ git reset -hard master

好了，伙计们。这些就是我们使用 git 服务器的命令。我们将会很快为大家带来更有趣的教程。如果你希望我们对某个特定话题写一个教程，请通过下面的评论箱告诉我们。像往常一样， 欢迎您的各种意见和建议。

via: http://linuxtechlab.com/beginners-to-pro-guide-for-git-commands/

作者：Shusain 译者：liuxinyu123 校对：wxy

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

在每一个程序员、项目管理员、团队领导的一生中，这都会至少发生一次。原来的程序员早已离职去度假了，给你留下了一坨几百万行屎一样的、勉强支撑公司运行的代码和（如果有的话）跟代码驴头不对马嘴的文档。

你的任务：带领团队摆脱这个混乱的局面。

当你的第一反应（逃命）过去之后，你开始去熟悉这个项目。公司的管理层都在关注着你，所以项目只能成功；然而，看了一遍代码之后却发现失败几乎是不可避免。那么该怎么办呢？

幸运（不幸）的是我已经遇到好几次这种情况了，我和我的小伙伴发现将这坨热气腾腾的屎变成一个健康可维护的项目是一个有丰厚利润的业务。下面这些是我们的一些经验：

备份

在开始做任何事情之前备份与之可能相关的所有文件。这样可以确保不会丢失任何可能会在另外一些地方很重要的信息。一旦修改了其中一些文件，你可能花费一天或者更多天都解决不了这个愚蠢的问题。配置数据通常不受版本控制，所以特别容易受到这方面影响，如果定期备份数据时连带着它一起备份了，还是比较幸运的。所以谨慎总比后悔好，复制所有东西到一个绝对安全的地方并不要轻易碰它，除非这些文件是只读模式。

重要的先决条件：必须确保代码能够在生产环境下构建运行并产出

之前我假设环境已经存在，所以完全丢了这一步，但 Hacker News 的众多网友指出了这一点，并且事实证明他们是对的：第一步是确认你知道在生产环境下运行着什么东西，也意味着你需要在你的设备上构建一个跟生产环境上运行的版本每一个字节都一模一样的版本。如果你找不到实现它的办法，一旦你将它投入生产环境，你很可能会遭遇一些预料之外的糟糕事情。确保每一部分都尽力测试，之后在你足够确信它能够很好的运行的时候将它部署生产环境下。无论它运行的怎么样都要做好能够马上切换回旧版本的准备，确保日志记录下了所有情况，以便于接下来不可避免的 “验尸” 。

冻结数据库

直到你修改代码结束之前尽可能冻结你的数据库，在你已经非常熟悉代码库和遗留代码之后再去修改数据库。在这之前过早的修改数据库的话，你可能会碰到大问题，你会失去让新旧代码和数据库一起构建稳固的基础的能力。保持数据库完全不变，就能比较新的逻辑代码和旧的逻辑代码运行的结果，比较的结果应该跟预期的没有差别。

写测试

在你做任何改变之前，尽可能多的写一些端到端测试和集成测试。确保这些测试能够正确的输出，并测试你对旧的代码运行的各种假设（准备好应对一些意外状况）。这些测试有两个重要的作用：其一，它们能够在早期帮助你抛弃一些错误观念，其二，这些测试在你写新代码替换旧代码的时候也有一定防护作用。

要自动化测试，如果你有 CI 的使用经验可以用它，并确保在你提交代码之后 CI 能够快速的完成所有测试。

日志监控

如果旧设备依然可用，那么添加上监控功能。在一个全新的数据库，为每一个你能想到的事件都添加一个简单的计数器，并且根据这些事件的名字添加一个函数增加这些计数器。用一些额外的代码实现一个带有时间戳的事件日志，你就能大概知道发生多少事件会导致另外一些种类的事件。例如：用户打开 APP 、用户关闭 APP 。如果这两个事件导致后端调用的数量维持长时间的不同，这个数量差就是当前打开的 APP 的数量。如果你发现打开 APP 比关闭 APP 多的时候，你就必须要知道是什么原因导致 APP 关闭了（例如崩溃）。你会发现每一个事件都跟其它的一些事件有许多不同种类的联系，通常情况下你应该尽量维持这些固定的联系，除非在系统上有一个明显的错误。你的目标是减少那些错误的事件，尽可能多的在开始的时候通过使用计数器在调用链中降低到指定的级别。（例如：用户支付应该得到相同数量的支付回调）。

这个简单的技巧可以将每一个后端应用变成一个像真实的簿记系统一样，而像一个真正的簿记系统，所有数字必须匹配，如果它们在某个地方对不上就有问题。

随着时间的推移，这个系统在监控健康方面变得非常宝贵，而且它也是使用源码控制修改系统日志的一个好伙伴，你可以使用它确认 BUG 引入到生产环境的时间，以及对多种计数器造成的影响。

我通常保持每 5 分钟（一小时 12 次）记录一次计数器，但如果你的应用生成了更多或者更少的事件，你应该修改这个时间间隔。所有的计数器公用一个数据表，每一个记录都只是简单的一行。

一次只修改一处

不要陷入在提高代码或者平台可用性的同时添加新特性或者是修复 BUG 的陷阱。这会让你头大，因为你现在必须在每一步操作想好要出什么样的结果，而且会让你之前建立的一些测试失效。

修改平台

如果你决定转移你的应用到另外一个平台，最主要的是跟之前保持一模一样。如果你觉得需要，你可以添加更多的文档和测试，但是不要忘记这一点，所有的业务逻辑和相互依赖要跟从前一样保持不变。

修改架构

接下来处理的是改变应用的结构（如果需要）。这一点上，你可以自由的修改高层的代码，通常是降低模块间的横向联系，这样可以降低代码活动期间对终端用户造成的影响范围。如果旧代码很庞杂，那么现在正是让它模块化的时候，将大段代码分解成众多小的部分，不过不要改变量和数据结构的名字。

Hacker News 的 mannykannot 网友指出，修改高层代码并不总是可行，如果你特别不幸的话，你可能为了改变一些架构必须付出沉重的代价。我赞同这一点也应该在这里加上提示，因此这里有一些补充。我想额外补充的是如果你修改高层代码的时候修改了一点点底层代码，那么试着只修改一个文件或者最坏的情况是只修改一个子系统，尽可能限制修改的范围。否则你可能很难调试刚才所做的更改。

底层代码的重构

现在，你应该非常理解每一个模块的作用了，准备做一些真正的工作吧：重构代码以提高其可维护性并且使代码做好添加新功能的准备。这很可能是项目中最消耗时间的部分，记录你所做的任何操作，在你彻底的记录并且理解模块之前不要对它做任何修改。之后你可以自由的修改变量名、函数名以及数据结构以提高代码的清晰度和统一性，然后请做测试（情况允许的话，包括单元测试）。

修复 bug

现在准备做一些用户可见的修改，战斗的第一步是修复很多积累了几年的 bug。像往常一样，首先证实 bug 仍然存在，然后编写测试并修复这个 bug，你的 CI 和端对端测试应该能避免一些由于不太熟悉或者一些额外的事情而犯的错误。

升级数据库

如果你在一个坚实且可维护的代码库上完成所有工作，你就可以选择更改数据库模式的计划，或者使用不同的完全替换数据库。之前完成的步骤能够帮助你更可靠的修改数据库而不会碰到问题，你可以完全的测试新数据库和新代码，而之前写的所有测试可以确保你顺利的迁移。

按着路线图执行

祝贺你脱离的困境并且可以准备添加新功能了。

任何时候都不要尝试彻底重写

彻底重写是那种注定会失败的项目。一方面，你在一个未知的领域开始，所以你甚至不知道构建什么，另一方面，你会把所有的问题都推到新系统马上就要上线的前一天。非常不幸的是，这也是你失败的时候。假设业务逻辑被发现存在问题，你会得到异样的眼光，那时您会突然明白为什么旧系统会用某种奇怪的方式来工作，最终也会意识到能将旧系统放在一起工作的人也不都是白痴。在那之后。如果你真的想破坏公司（和你自己的声誉），那就重写吧，但如果你是聪明人，你会知道彻底重写系统根本不是一个可选的选择。

所以，替代方法：增量迭代工作

要解开这些线团最快方法是，使用你熟悉的代码中任何的元素（它可能是外部的，也可能是内核模块），试着使用旧的上下文去增量改进。如果旧的构建工具已经不能用了，你将必须使用一些技巧（看下面），但至少当你开始做修改的时候，试着尽力保留已知的工作。那样随着代码库的提升你也对代码的作用更加理解。一个典型的代码提交应该最多两三行。

发布！

每一次的修改都发布到生产环境，即使一些修改不是用户可见的。使用最少的步骤也是很重要的，因为当你缺乏对系统的了解时，有时候只有生产环境能够告诉你问题在哪里。如果你只做了一个很小的修改之后出了问题，会有一些好处：

• 很容易弄清楚出了什么问题
• 这是一个改进流程的好位置
• 你应该马上更新文档展示你的新见解

使用代理的好处

如果你做 web 开发那就谢天谢地吧，可以在旧系统和用户之间加一个代理。这样你能很容易的控制每一个网址哪些请求定向到旧系统，哪些请求定向到新系统，从而更轻松更精确的控制运行的内容以及谁能够看到运行系统。如果你的代理足够的聪明，你可以使用它针对个别 URL 把一定比例的流量发送到新系统，直到你满意为止。如果你的集成测试也能连接到这个接口那就更好了。

是的，但这会花费很多时间！

这就取决于你怎样看待它了。的确，在按照以上步骤优化代码时会有一些重复的工作步骤。但是它确实有效，而这里介绍的任何一个步骤都是假设你对系统的了解比现实要多。我需要保持声誉，也真的不喜欢在工作期间有负面的意外。如果运气好的话，公司系统已经出现问题，或者有可能会严重影响到客户。在这样的情况下，我比较喜欢完全控制整个流程得到好的结果，而不是节省两天或者一星期。如果你更多地是牛仔的做事方式，并且你的老板同意可以接受冒更大的风险，那可能试着冒险一下没有错，但是大多数公司宁愿采取稍微慢一点但更确定的胜利之路。

via: https://jacquesmattheij.com/improving-a-legacy-codebase

作者：Jacques Mattheij 译者：aiwhj 校对：JianqinWang, wxy

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

在这个数字世界中，我们通过互联网使用 Dropbox、Mega、Google Drive 等不同云存储分享我们的媒体、文档和重要文件。但是每个云存储都有两个主要问题，一个是大小和另一个安全。习惯 Bit Torrent 之后，大小已经不是问题了，但安全性仍旧是。

即使你通过安全的云服务发送文件，该公司也会注意到这些文件，如果这些文件是保密的，政府甚至可以拿到它们。因此，为了克服这些问题，我们使用 OnionShare，如它的名字那样它使用洋葱网络也就是 Tor 来匿名分享文件给任何人。

如何使用 OnionShare？

首先下载 OnionShare 和 Tor浏览器。下载后安装它们。

现在从开始菜单打开 OnionShare

点击添加并添加一个文件/文件夹共享。

点击开始分享。它会产生一个 .onion 网址，你可以与你的收件人分享这个网址。

从 URL 下载文件，复制 URL 并打开 Tor 浏览器并粘贴。打开 URL 并下载文件/文件夹。

OnionShare 的起源

几年前，Glenn Greenwald 发现他从 Edward Snowden 收到的一些 NSA 的文件已经被损坏。但他需要该文件，并决定通过使用 USB 获取那些文件。这并不成功。

在阅读了 Greenwald 写的书后，The Intercept 的安全专家 Micah Lee 发布了 OnionShare —— 一个简单的免费软件，可以匿名和安全地共享文件。他创建了一个程序，通过一个被匿名软件 Tor 加密和保护的直接通道来分享大型数据转储，使窃取者难以获取文件。

OnionShare 如何工作？

OnionShare 在 127.0.0.1 上启动了一个 Web 服务器，用于在随机端口上共享文件。它从有 6880 个单词的单词列表中选择任意两个单词，称为 slug。它使服务器可以作为 Tor 洋葱服务发送文件。最终的 URL 看起来像这样：

http://qx2d7lctsnqwfdxh.onion/subside-durable

OnionShare 在下载后关闭。有一个选项允许多次下载文件。这使得该文件在互联网上不能再次得到。

使用 OnionShare 好处

其他网站或程序可以访问你的文件：发件人使用 OnionShare 共享的文件不存储在任何服务器上。它直接托管在发件人的系统上。

没有人可以窥探共享文件：由于用户之间的连接是由洋葱服务和 Tor 浏览器加密的。这使得连接安全，很难窃取文件。

用户双方都是匿名的：OnionShare 和 Tor 浏览器使发件人和收件人匿名。

结论

在这篇文章中，我已经解释了如何匿名分享你的文档、文件。我也解释了它是如何工作的。希望你了解 OnionShare 是如何工作的，如果你对任何事情仍有疑问，只需留言。

via: https://www.theitstuff.com/onionshare-share-files-anonymously-2

作者：Anirudh Rayapeddi 译者：geekpi 校对：wxy

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