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

@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，再不剂也会告诉你该怎么编译运行。请注意这些人和西农一样，同样是**开源贡献者**。然后你来告诉我这个东西本身很复杂，你没点技术水平就碰不得，你是不是同时也把他们的工作鄙视了个遍？

这个 thread 到了移除官方源之后所暴露出的问题，就压根跟什么开源都没有关系了，本质问题其实更 general：就是你公开做任何事情一定会遇到**（**是什么自己脑补，给一个定义：做事情的这个人感觉不够“理解”的人。我想不出一个合适又足够友好的词），没有做好面对**的心理准备，我建议就不要做。

**三定理：第一，**是普遍存在的，是宇宙的组成要素；第二，你无法完全消灭**，和**争论一般是没有意义的；第三，目前的**的保有量已经达到了一定基数，以至于一般你都会碰到**，并且经常还不少（互联网起了放大作用）
另外还有一个附加的推论：**不仅无法在全局上被消灭，就算是试图在一个有一定规模的社区中消灭（无论是哪个社区），都是不可行的

你做任何涉及到其他人的事情，都需要面对三点：
一是有关部门各种明文或非明文的流程和门槛（很多是中国特色）
二是由于自己的无知或疏忽导致的错误
三是**对你的质疑和攻击
这三点和你做的是商业还是慈善无关，只是如果你要做一件事情，我建议你做好面对这三点的心理准备，不然不如不做，人生开心最重要，没必要折腾半天给自己找罪受

当然有人会说，环境这么差（尤其是**这么多），不就没有人做事了？我们吃谁的去？答案很简单，爱咋地咋地，因为这是这个世界内在的矛盾与复杂性，我不认为有有效和通用的方法

@ReVanTis https://en.wikipedia.org/wiki/Appeal_to_novelty

VC/VS 啥时候成标准了 ...
首先，C++ 编译器的前端是逻辑很复杂的东西（特别还有一堆扩展），在维护的时候出 bug 不小心 break 掉之前的代码挺正常的，一般针对 C++ 编译器，有很多公开的和内部的 test suite 来尽量使这种事情不会发生，但是这显然并不是一个完全的保证。任何 C++ 编译器出 bug 都是很正常的事情，另外我不知道楼主听没听说过 bug-to-bug compatible 这个东西 ...

从更广义的角度讲，任何对于开发平台和依赖的迁移都应该评估可能造成的影响，这和标准不标准无关，任何语言的任何版本的编译器 /库更新都可能引入新的 bug

注意 C++ 这个语言的模式是 WG21 定标准，不同的 vendor 做实现，Bjarne 原来的实现早就不知道扔哪去了。你在不同的实现之间迁移的时候也会遇到类似的问题，同时还会遇到 extension 不兼容的问题（还会遇到 ABI 的问题 ...），包括看上去是同一个 extension，不同的 compiler 会有不同的实现。

还有一种模式是没有 spec，实现就是 de facto standard。TypeScript 貌似是这样。OCaml 这种尽管是偏学术的语言，但是好像还是没有 spec，并且可以有 breaking change ( https://github.com/gasche/ocaml-releases-change-explanation/wiki/4.05.0-changes-explanation)，一个其他语言用户见不到的奇观是
check.ocamllabs.io ——为了官方发布新版本的升级过程更平滑，有人专门做了一个网站来监控所有包在新版编译器上的构建状况，因为社区小，所以这个事情可行。但是仔细看其中大多数都是第三方库等周边生态导致的问题，编译器本身还是尽量保持稳定的。Haskell 虽然有个标准当摆设，但是谁都看得出 GHC 是 de facto standard，所以同理 ...（典型： https://gitlab.haskell.org/ghc/ghc/wikis/migration/7.10 ）。

LLVM 不算是用户直接接触的编译器，但是简单来说 LLVM IR 的兼容性就是随缘，尤其是对于非核心部分。OpenGL、OpenCL 和 SPIRV 等作为工业标准，标准是分版本发布的，各个 vendor 通过提 extension 的方式加私货，每个 extension 都有自己的 ID。实现上则用 版本号+extension 集合 的方式标识兼容性，Khronos 官方提供 Conformance Test Suite。我觉得这个做得是比 C++ 要更成熟一点的。

至于楼主的问题，我认为对于学生项目来讲，这个没有太大的问题。这里涉及到一个比较现实的问题是 MSVC 的编译器版本和开发环境版本是绑定的，你想用新的环境必须用新的编译器。这个不完全是个好事也不完全是个坏事。需要注意的是现在“开发环境和编译器版本绑定”已经是一个不限于微软的趋势了——越来越多的编程语言开始更多地在交互开发体验上发力，微软的 C# 本来做得就很优秀，但是后来通过开源的 Roslyn 更进了一步。C++ 社区则有 Clang 梦，不对，是 Clang 的伟大复兴，不对，应该叫 Clang 崛起 ... 总的来说是开发环境的工具越来越依赖于编译器自身的 API，这部分一般是没有兼容性保证的，并且挺容易 break 的。

一些优秀的 C++ 项目的编码规范里面规定的不仅仅有项目使用哪个 C++ ISO 标准开发，还有当前兼容的编译器**最小版本**，因为规定“使用 C++14 开发”之类的是没用的，你还得考虑编译器自身实现的问题

很多 C++ 项目本来就有跨平台的需求，这样所要面临的环境和工具链差异会更大，然而这些项目确实做到了。
你并不必需把你自己的项目也做成跨平台的，也并不必需使用标准 C++ 开发。但是我认为处理编译器和平台之间正常的兼容性问题是干活的程序员的必备能力之一，就像前端需要处理浏览器差异一样。

微软官方的解释： https://docs.microsoft.com/en-us/cpp/porting/overview-of-potential-upgrade-issues-visual-cpp

另外为什么没人黑一下 Python 呢？

@matsuz 说的是 @crella 明确拒绝部分 Linux 用户。

我不认为任何一个镜像源有这样的主观恶意

@FaiChou

第一这些资料大多数感觉是不知哪个地方先写出一个版本然后其他人抄的 ... 我不得不说我似乎低估了大家对已有内容进行演绎的能力与热情
第二就是我看他们这么热情啊，什么都不说也不好，从描述的作用来看，感觉有点像 ES6 标准里面的 *DeclarationInstantiation ( https://www.ecma-international.org/ecma-262/6.0/index.html#sec-functiondeclarationinstantiation)

貌似鸟哥也谈过这个？一看 09 年的文章了
但是我感觉这个应该是中文圈特有的术语，我找不到英文的对应 ... 如果是某个英文术语的翻译的话也很奇怪，太模糊了

最后，原则上讲，JS 现在有这种行为是因为历史原因加上后续语言上的一些设计选择。不是因为它是怎样实现的，V8 表现出这种行为是因为标准的规定，V8 必须实现标准，而不是因为它做了或者没做“预编译”。V8 实现中就算做了“预编译”，和标准也没有关系（如果标准没有规定的话）。并且 JS 这种高级语言的标准是不能单纯从实现的角度去理解的（ C++ 是反面 ...）

楼主发发配置，我来评估下能不能跑 VGA Passthrough ...
个人认为如果可行的话，比这个方案楼上所有的评论都要优越的多

换个角度想，为什么 debug 一定要用 F8 呢
楼主想办法把这个快捷键改掉，如果应用本身不允许改（说明做得垃圾）可以找一个软件方案，把特定应用里的特定快捷键 remap 到其他组合键
我 Mac 和 Windows 本都有，但是 Function keys 那一列都是选择的 Media key，因为平常用到的场景很少（ htop 算一个？），所以 HHKB 正适合

另外在 HHKB 上我主观是想规避 Fn 组合键的，主要问题是我至今没习惯数字键那一列的布局，从 5 之后到 ~ 之前那几个键，盲按很容易按错。Fn 方向键倒是没什么问题

怎么会需要 NAS ... NAS 是存储方案，不是备份方案
楼主这种需求，找一家（两家或以上最好）的云存储做云备份就可以，需要本地备份的话，买个硬盘盒，两个硬盘，写个脚本做两份冷备就可以
毕竟上 NAS 的话，你也要买至少两块硬盘，而 NAS 的硬件成本基本一定是比硬盘盒高的（ TB 硬盘盒除外）
如果有条件的话（机器有扩展性并且不在乎额外的噪音和重量），两块硬盘其中一块可以直接接到机器里面，方便一点

然后楼主该考虑的问题是脚本应该怎么写，各个终端的图片怎么合并到同一个位置
以及虽然是小概率事件，但是在有多份备份的情况下，可以考虑给每张照片加一个 checksum，因为有可能硬盘 /非 ECC 内存抽风损坏掉部分照片
然后你在每次进行备份的时候顺便验一下这个 checksum，并且跑一下 SMART Short Test，定期跑 SMART Long Test，及早发现问题

有安全考虑的话，上传到云端的，可以考虑 gpg 加个密（ Google Photos 这种就不太好办）
本地备份的加密可以考虑用全盘加密或者单个文件 gpg 加密
不过你用 gpg 加密了，恢复的时候，一般的文件管理器就没有办法直接预览，你可以考虑把整个文件夹移出来解密之后预览
全盘加密不存在这个问题，但是（软件全盘加密）代价是：目前没有能跨平台的 block 层加密实现（ VeraCrypt 不知道算不算，没用过。OpenZFS 的 Encryption 算半个），另一个是这个东西本身增加了复杂性，出问题（数据丢失）的风险更高一点。硬件全盘加密没用过，不评价。

黑 Python 新姿势？
好像是两个都黑了 ...

配置合适的话用 KVM+VGA Passthrough