@efsg 您好，vi 和 nano 不喜欢可以尝试下 emacs :)

楼主的需求无非就是，方便地传输文件，方便地编辑文件，简单来说就是以本地文件的方式操作远程文件
那 SSHFS 就可以了啊

"图形化 SSH 工具"这个东西的存在就是很尴尬的事情，这种工具做得再好也不可能像本地文件系统一样和其他软件一起无缝的互操作，虽然它解决的问题是存在的，但是它选择了错误的层级来解决这个问题。我个人觉得这种工具是没有未来的

（然后话题转进到一个图形化的 SSH 连接工具，可以选择服务器，记忆用户名 ...

其实应该说，你正确调用 swap 的时候，把 std::swap 重载了
另外 C++20 之前调 std::swap 应该是不会调到你的 swap 去的

@alanlian 意思类似于：
Q：传输大文件用什么服务最吼？
A：顺丰快递
你感受一下

标准对 overload 的定义：“When two or more different declarations are specified for a single name **in the same scope**, that name is said to be overloaded.”
technically，你在使用 swap 的时候用了 overload resolution 的机制，overload resolution 在决定 candidate set 的时候会考虑 scope 和 ADL。不过 overload resolution 和 overloading 是两回事

这个不是重载的 std::swap，这个新函数应该是通过 ADL 被找到的

啊等等我好像搞混了，无视掉 #8 的评论吧 ... 我再看看

friend 好像是只能写在这吧 ...
这里 swap 是个成员函数，成员函数是可以不加 friend 访问自己的 private 成员的

之前好像没见过这么写 copy-and-swap idiom 的（不过 C++11 之后好像不用这个 idiom 也可以了

@icekingcy 请升级网络，FreeNAS 不背这个锅

噢对了，如果是 Windows 的话，有一个类似的功能叫 Shadow Copy

你可以使用带 snapshot 功能的文件系统，比如 ZFS
实例：FreeNAS 就是使用一个 ZFS Dataset 作为 ROOT 文件系统，每次升级之前会自动创建一个 Snapshot，并且会把这个 Snapshot 添加到系统启动菜单中。这样如果升级挂了可以重启进入之前的系统

在你创建了 snapshot 之后，你可以使用 zfs send 命令把它序列化，然后通过 zfs receive 命令将它 replicate 到另外一个 zpool 中（如果是两台机器，中间用 ssh 转发一下就可以）

当然我觉得实际情况是，移动硬盘比笔记本硬盘更容易挂（笑
所以 FreeNAS 原来的推荐是用两个 U 盘做系统盘，现在的推荐是用两个 SSD

另外一种方案是通过 ZFS 等软 RAID 方案，把笔记本硬盘和移动硬盘做一个 mirror，这样可以做到完全实时、无缝的同步，但是也要求时刻都插着移动硬盘

亮点还是有的，就是 Phil Schiller 那句"Oh it's so pro"
直接逗笑了

名字前两个字母已经告诉你了 ...

@CEBBCAT 楼主明显更习惯这么写 ...

你得学会带面试官的节奏

俩好像都挺监听的
880 能一千拿下么，是二手么

Mac 不是有 FileVault 么？
还可以用 ZFS Encryption，不过我不保证 ZFS 在非 ECC 内存上的数据完整性
x86 平台上合格的软件加密应该都可以利用 AES-NI，所以如果你的处理器支持 AES-NI，性能损失应该不大。

@FaiChou 这个其实很难说是一个 bug。“a 在第五行被回收了”也完全没有保证。

另外 GC 这个东西很难被定义，我至今没见过哪个语言成功地在自己的 spec 中把 GC 以确实有用的形式定义出来。
https://en.wikipedia.org/wiki/Tracing_garbage_collection#Determinism：Tracing garbage collection is not deterministic in the timing of object finalization. An object which becomes eligible for garbage collection will usually be cleaned up eventually, but there is no guarantee when (or **even if**) that will happen.
意思是就算一个对象实际不被引用，Tracing GC 依然可以**根本不回收**它

这个不仅仅是 wiki 这么说，Scheme 的 spec 更有意思：www.r6rs.org/final/r6rs.pdf 第一页就说了：No Scheme object is ever destroyed. The reason that implementations of Scheme do not (usually!) run out of storage is that they are **permitted** to reclaim the storage occupied by an object if they can prove that the object cannot possibly matter to any future computation ... "Permitted" 意思是 Scheme 实现可以根本没有 GC ...（关于 Scheme 对内存这个东西的定义后面还有更多的描述）

JLS 写得很模糊：When an object is no longer referenced, it **may** be reclaimed by the garbage collector. 但是 JLS 里面还隐藏了另外一个有趣的东西，就是 finalizer，紧接着上面一句话：“If an object declares a finalizer, the finalizer **is** executed before the object is reclaimed to give the object a last chance to clean up resources that would not otherwise be released.”，后面还有一节专门讲 finalizer 的同样说："Before the storage for an object is reclaimed by the garbage collector, the Java Virtual Machine **will** invoke the finalizer of that object."，但是后面又说“A finalizable object has never had its finalizer automatically invoked, but the Java Virtual Machine **may** **eventually** automatically invoke its finalizer.”

这个定义就算是把 may 去掉了也没用 ... 比如考虑我定义成对象 eventually 会被回收，但是同时实现成“无限长”之后会被回收，在实际情况中依然是一个非常受限的实现

这就相当于根本就没有办法从 spec 的角度 enforce 任何 GC 的行为。而我们一般意义上研究的 GC，从这个角度来说都属于编译器的“优化”，“优化”就是 spec 没有强制要求（实际上正常的 spec 不会有任何相关内容），而实现所添加的在保持 standard conformance 的同时为了增强某些方面性能做得的额外的 feature。这就是说为什么这个 Chromium 的 issue 是个 feature 不是个 bug。

有一个很有意思的例子就是 PTC (proper tail call)，同样是 R6RS 的要求：A Scheme implementation is properly tail-recursive if it supports an unbounded number of active tail calls.（在内存受限的前提下，这个其实等价于 tail call 的 space complexity 是 O(1) 的）
有意思的是，C/C++ 标准里至今没有这样的内容，但是主流的编译器都做了这样的优化。ES6 做了类似的要求（不过标准的表达有些区别），但是好像现在只有 JavaScriptCore 的实现是可用的？
当 PTC 这条不在标准里面的时候，它就属于编译器的一个优化，优化不仅仅是实现相关的，更是没有保证的，编译器可以选择做这个优化，也可以选择不做这个优化。C/C++ 标准没有 PTC 是一件十分细思恐极的事情——背后的 implication 是：我无法使用标准 C/C++ 的函数调用实现一个符合 Scheme 标准的解释器（ ES6 同理），我必须自己维护函数调用的 activation record （或者依赖于特定的实现提供了这样的优化的这个前提 (这就超出标准 C/C++ 的范畴了)），这会让实现 DSL 更麻烦。而如果使用 ES6 来写，在实现符合标准的前提下就没有这个问题，而至于 V8 不符合 ES6 标准，就是另外一个问题了 ...
需要注意的是虽然 PTC 有若干其实挺 well-known 的实现方式，但是标准（尤其是 Scheme 标准）并没有规定该怎样实现 PTC，它仅仅规定实现应该满足的一个 性质。和其他的优化一样，就算标准里面没有这个东西，实现者也可以选择做这样一个优化（确实也很有用），但是这东西最后能进到标准里面，前提之一是这个行为可以清晰地被定义。在实现这一行为的过程中，某些实现可能会让 tail call 在时间上更慢，某些实现则会在保证 PTC 的同时试图让 tail call 的性能最优，但是这些都不在标准规定的范围内。

西农的镜像源出了点问题，这个实际上就相当于“apt 出现了拉包速度无法超过 40KB，偶发”的这么一个 bug，出点 bug 很正常，就是能改就改，不能改影响又比较大就直接把这个 feature 给干掉（关站），都是很正常的事情。
Ubuntu 有点可以学习一个的东西，是更好的建设自己的 process，能不能及早的发现不合适的镜像源并且直接处理，apt 能不能做得更智能一点，尤其 Canonical 作为一个商业公司，又有向更多小白用户推广 Ubuntu 的目标，其实是有这个责任去完善的。

然后有人要说，Linux 就这个样子，Linux 桌面没救的。其实 Linux 桌面这个样子一定程度上是因为社区的力量不足，比如说现在 Linux 桌面有 4 分（ 10 分满分），因为只有 x 个人在贡献，为什么只有 x 个人呢，因为社区中**太多（还包括一帮觉得小白用户不要用 Linux，不要从网络更新源的泼冷水的人）。如果社区中**少一点，那或许就有 2x 个人贡献了，Linux 桌面没准就能提升到 5.5 分。但是我上面说了，和**争论是没有意义的，所以你拿别人没办法，不如自己闭嘴，最好去贡献一个

就这件事情而言，镜像站维护者不知由于何种原因（我倾向于不对动机做无根据的推测）有自己的疏忽，我觉得本身不是什么大事，不过看起来维护者并没有做好面对**的准备（相对来说网络资源之类的其实是小事），在这种情况下，我认为关站是正确的选择，甚至是双赢的结果——维护者可以不用操这个心了，而社区首先对这个镜像站没有特别大的依赖，并且就其他镜像站也有退出这一状况来看，一定程度上确保了官方收录的这些镜像站都有足够的硬件资源，并且有应对**的准备（甚至我相信很多已经有经验了）。

更重要的是给后来者提供了一个案例，还记得当年的 antd 彩蛋事件么？有人 argue 说 antd 是 MIT 协议的开源软件，所以不能骂他。事实是：MIT 协议只能保证别人无法追究彩蛋贡献者（甚至这个 commit 的 reviewer ）的法律责任，但是不能帮 antd 开脱舆论的指责（这个有点像 https://en.wikipedia.org/wiki/I%27m_entitled_to_my_opinion ）。这个事情更进一步的点在于，阿里通过 antd，确实收获了一定的利益——并不是只有钱才能叫“利益”，钱只能一定程度上量化利益，钱一直在贬值，人才、权力、声望、mindshare 之类的更接近真正的利益，一个开源项目的欢迎度当然也算。但是一个镜像源所能获得的利益是很少甚至是负的，类似的逻辑是否同样成立，这是一个值得思考的问题。

另外开源软件（其实也适用于免费软件），该主题里尤其是 Linux，是否有必要做到开箱即用，提高对小白用户的友好度呢？我个人认为是有的，我的论点不是从什么“每个人都曾经是小白”出发，而是现状是——目前确实有那么一群人在致力于做这件事情，Ubuntu 的主要维护者 Canonical 是，国内的 Deepin 也是，并且很多的开源软件，就算不是给一般用户使用的，都在致力于做到 sane default，再不剂也会告诉你该怎么编译运行。请注意这些人和西农一样，同样是**开源贡献者**。然后你来告诉我这个东西本身很复杂，你没点技术水平就碰不得，你是不是同时也把他们的工作鄙视了个遍？