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

更重要的是给后来者提供了一个案例，还记得当年的 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

我来用真实的故事告诉楼主什么叫散热不好

旁边这台机器，Ryzen 3 1200 （我其实很怀疑这个节点的人有没有听说过这个 SKU ...），原装散热器
但是，但是，因为机箱散热器高度限制，又急用，我就把风扇给拆下来了 ... 拆下来了 ... 留一个散热片
装好，开机，Prime95 开启
跑了五分钟
机箱很凉快，上面有个得有半张主板那么大的风扇，吹的风是凉的
一看 CPU 温度，95 度+

可惜手头只有个玻璃杯，要是有金属杯子，电水壶就可以扔了
原装的散热片上面是平的，真的很适合烧水

这么说吧，个人存储这个东西，从自身的可靠性角度上我只分成两类
一类是不可靠的，一类是可靠的

你买任何一个盘，都是不可靠的，因为没有**冗余**，就算 Exos，900P 和 P3700 也是
可靠存储就需要本身有冗余（ RAID/mirror ），定期做 SMART，定期 fsck/scrub

重要数据无论放在可靠存储还是不可靠存储上面，都需要备份，因为可靠存储依然不是 100% 可靠的，并且技术上的“可靠”并不能帮你应对被人偷了、房子烧了之类的风险，可靠存储最大的价值其实是高可用，也就是基本只要有电就能用，折腾一次以后就看看状态报告基本不用管了

不可靠存储则有随时坏掉的风险，坏掉之后需要重新买再替换，重新导入数据

然后我的假设是，一个理想的可靠存储，在我把它换掉之前，不出现致命问题（技术原因导致的不可用**或**数据丢失）的概率是 99.9%+
一个较好的不可靠存储（无冗余的专用 HDD、企业 SSD 和 Optane ），预期寿命内不出现致命问题**且**数据不丢失的概率是 98%
一个普通的不可靠存储（消费级桌面硬盘，消费级 SSD ），这个数字我假设是 94%
一个差一点的不可靠存储（移动硬盘，U 盘之类），这个数字假设是 92%，楼主担心的“返修 /翻新盘”大概也算在这里面

这个具体的数字当然没有任何依据，但是目的是反映一个大致的意思

另外一个理论（或者你可以称为阴谋论）是，同样的价格，人肯定更倾向于购买质量更好的产品。然而事实是，目前对于普通消费者来说，没有任何途径能够可靠地证明你买的产品质量确实是更好的。
楼主在这问怎么避开淘宝的坑，但是楼主有没有想过大家会怎么回答？
大家给你推荐个店铺？三个人推荐三个店铺，你去哪个？而且你怎么信任给你推荐店铺的人，以及他的推荐？ SSL 根证书都可能出问题，楼主现在纠结的就是这 2% 的问题，所以这个最多只能参考
或者看看能不能从硬盘厂商套出点信息来？硬盘这个东西我记得厂商最多能提供当前质保信息，你能公开查的就这么多，我没有听说过其他的渠道。自己最多多看下 SMART，然后跑个 SMART Long Test 和 badblocks 测试（对于大硬盘来说都是耗时很长的测试）
而且就算能 100% 确认不是返修盘，也不代表 100% 确认不会买来三个月就出问题。反过来说，你确认了 100% 是返修盘，也不代表 100% 确认买来三个月**就会**出问题。最多只能说如果是返修盘，那相比于全新盘，多出了 5% 的可能买来三个月会出问题
因为这个问题本身就没有答案（对于普通人来说），所以其实不会有“切题”的回答，所以不是大家“动不动”就怎样，楼主明确说了，有自己特定的需求，还想省钱。然而楼主又不想买到返修盘（所以是楼主先给自己加的戏 ... 至少楼主应该能意识到“现在不存在普通人能完全可靠地 买到 全新原厂产品的渠道或方式”这一点吧）
而楼主看完我这个帖子，思考下我这套民科理论，确实可以省下更多的钱

怎么省钱呢？

先接受我上面的假设，就是“现在不存在普通人能完全可靠地 买到 或鉴别 全新原厂产品的渠道或方式”，尤其在楼主还想“省钱”的前提下
那首先你在这问就是没用的，完全浪费时间
其次试图用任何普通人能使用的方式在购买前或购买后辨别“是否是返修盘”，实践中不可行，且意义不大
再次，对于不可靠存储，在保证基本的可靠性的前提下，价格、性能、容量、噪音、能耗甚至外观等其他参数优先于可靠性，因为在不可靠存储上追求可靠性意义不大——多个不可靠存储组成的简单冗余就可以把单个不可靠存储的可靠性爆成 bits。另外，在便携设备上追求可靠性意义也不大（“多个不可靠存储组成的简单冗余”这种可靠性方案也天然和可靠性冲突）。（我曾经想找 M.2 NVMe 的企业级 SSD （最起码带 PLP 的），很难找）。

然后，楼主不想买返修盘，其实不是因为全新盘本身能比返修盘好到哪去，而是心里的强迫症作祟
这就是最后一点：包括消费级 SSD 和 HDD 等很多消费级硬件现在都有向 worse is better 的方向发展的趋势，如果真的有强迫症，“消费级”这一点首先就能让你受不了

最后就是我们的结论了：消费级不可靠存储，在保证基本可靠性的基础上（**基本**可靠的渠道，如狗东），买能满足需求的，最便宜的

我认为淘宝上的某些商家也属于“基本可靠的渠道”，又由于其中部分商家的价格相对于其他渠道更为优惠，因此我选择了这个渠道

这不就省钱了么~

（另外，如果非要说“最可靠的渠道”的话，亚马逊海外购现在是在卖硬盘的。价格不一，不过就楼主的需求来看，貌似比狗东还要贵。此外我并不认为这一渠道是最可靠的，它仅仅是不一样，并不是更好。此外需要注意的是该渠道购买的商品可能没有售后服务（我没有查证过这一点））

1EB ... Backblaze 现在也才 750PB

楼主在想屁吃，深度学习从硬件再到数据的要求就注定了是一小撮人的工具啊

然后大家还都在折腾 ... 挺讽刺的

我去某论坛上搜的商家买的

硬盘本身靠不住，该备份的备份了，不用管这些乱七八糟的

@gromit1337 火 狐 浏 览 器 青 春 版

火狐浏览器 Pro
火狐浏览器 Note 70
火狐智慧互联网终端
火狐浏览器 Note 20

JS 节点的帖子貌似不会被显示在“全部”里面，是我的设置问题么？

首先，上一个帖子看了一下，我不是很明白楼主要弄懂什么东西，是 closure 这个通用的概念以及 closure 一般性的实现原理？还是某个特定的 ECMA 标准？还是 V8 这一个具体实现？

1. 这个问题没有意义。因为什么 Ignition 本来就是一个纯用来做 marketing 的名字，V8 的 codebase 里面名字包含 ignition 这个词的文件一只手就能数过来，代码里面也出现的不多，人家直接叫 “ interpreter ”。所以这个问题应该去问 V8 团队，而答案实际完全取决于你问的那个人当时拍的是左边的屁股还是右边的屁股（或者可能拍到了旁边同事的），和实际的实现毫无关系。楼主应该关注的是 bytecode interpreter -> baseline compiler -> optimizing compiler 的总体架构，而不是 Ignition 这个名字指的是哪个部分。V8 团队完全可以藏个彩蛋，在微软的某个 Demo 运行一段时间之后就禁用全部优化，然后把这个东西叫 Ignition，原因是可以“点燃微软的怒火”

非要说的话，https://v8.dev/docs/ignition 这里很明确了：Ignition is a fast low-level register-based interpreter. 楼主那个链接上也说了“ Ignition ’ s bytecode compiler ”，说明 compiler 是 Ignition 的一部分。

2. “好多资料”指什么资料？我貌似没看到过有资料这么说，官方解释直接去找 ECMA-262。标准貌似没对实现有这种要求

3. 问题不明，“预编译阶段” 算是个半通用没有明确定义的概念，“ Ignition 的编译” 是个实现细节。
按照我对标准的理解，最后一行在 evaluate 的时候会调用 foo，这次调用会产生一个 LexicalEnvironment，设为 bar，bar 里面有个 a，在 evaluate 那个 return 的时候会创建一个函数，这个函数对 bar 有引用，bar 对这个 a 有引用。
换句话说是运行时产生的 LexicalEnvironment，或者从反证法的角度，考虑这个例子：
for (var i = 0; i < Date.now() % 1000; i++) array.push(foo())
“问题 2 中的预编译阶段还是问题 1 中 Ignition 的编译”无论哪个都连该创建几个 LexicalEnvironment 都不知道，因此都不是。