cnbatch

不听，甚至戴上降噪耳机把降噪等级调到最强

需要安静环境集中注意力

非自建一样可以被叫去喝茶，认定要不要去喝茶的决定权又不在用户手上

像是 express vpn 、nordvpn 这些，他们的宣传广告向来主要是“隐藏 IP 、保护隐私”，非墙国家的用户才是他们的主要服务对象，比如不想网站知道自己的 IP 地址（连接 VPN 后，出口 IP 就不是自家的），在用户连接了公共 WiFi 后再透过 VPN 上网（不信任公共 WiFi ，而 VPN 有加密可以保护这段过程传输的数据），这才是原本的服务场景。

至于爬墙，那还是用专门的梯子技术吧。

根本原因在于长期不开源。

当下流行的 Top 10 编程语言，全都是开源的。无论榜单标准是 TIOBE ，还是 IEEE Spectrum ，或是直接看 GitHub 的语言排名，全都不例外。

C# 最初也不开源，但最终开源了。Delphi 呢？至今仍然闭源吧。第三方的 Delphi 开源兼容品，地位不就类似于 C# 未开源时的 mono 嘛。
C# 闭源时，mono 都没法推动 C# 火起来。更不用说至今仍在闭源的 Delphi 了。

@cnbatch 手误，“贝尔电话公司早就被拆散了”应为“AT&T 公司早就被拆散了”

@holy_sin C 以及 C++连“官方”编译器都没有，更别说官方包管理器了

其实很长时间以来，包管理是由操作系统自己的软件包管理器负责的，系统的软件包管理器同时就是 C/C++的包管理器。这原本是很方便的优势。
只不过 Linux 发行版特别多，无法保证想用的包全都能出现在所有发行版当中。
再加上 Windows 和 macOS 完全不做这种事，想要管理那就只能靠第三方软件（例如 vcpkg ，尽管也是微软的，但并不是预装在 Windows 当中）。
于是，优势成了劣势。

难怪不少语言索性自带包管理工具。

如果 C 以及 C++背靠大公司，那么或许还能有个集大全的包管理器。可惜现实并不能。当初诞生 C 以及 C++的贝尔电话公司早就被拆散了，ISO 委员会也没资源去干这样的事。
真想要做，那就必须两个 ISO 委员会（ C 语言的 9899 和 C++的 14882 ）同时协调着做，难度就更高了（时间会浪费在官僚式扯皮当中）。

FreeBSD 的驱动问题应该能修好的，就看 FreeBSD 开发组什么时候能够拿到硬件实物做测试

我自己的 NAS 同样是基于 FreeBSD 的（衍生版，附带 WebUI ，为了方便出门在外时用手机远程检查状态），机箱内所有硬盘都是 ZFS ，系统盘也不例外

同样为了防止 bit rotate ，不但有 ECC 内存（这才是关键），并且不使用 SLOG 和 L2ARC 。慢就慢吧，不管再怎么慢，顺序读取都有三四百 MB/s 。
只要机械硬盘是 raidz 组的一部份，那就基本不用怕翻转错误，raidz 可以纠错的。独立单硬盘的出错才麻烦。专门给二级缓存再加 SSD raid1 有点奢侈，我小机箱放不下那么多╮(╯-╰)╭

是不是开着远程桌面？

我曾经遇到过同样的现象，后来排查发现原来是“远程桌面”导致的

（以下描述带有我个人的使用习惯，请谨慎参考）

包管理：

Windows 用 vcpkg
FreeBSD 用系统自带管理器
Linux 尽量用系统自带管理器，实在没办法了才用 vcpkg


C++版本：

部份版本变化还是很大的，按分组来算（以下是我个人划分），那就是
第一组 C++98 、C++03
第二组 C++11/14/17
第三组 C++20/23
每一组内部的变化不算特别大，很容易平滑升级；组与组之间的变化比较大，可以当成新语言来学习


跨平台：

只要不是涉及到驱动层面、调用系统专属 API 的话，大多数纯命令行工具的跨平台不算痛苦，因为有不少第三方库包装得比较好，把平台差异抹平了

图形界面程序比较麻烦，主要是因为 Linux 割裂但又不完全割裂。如果不考虑 Linux ，只考虑 Windows 、BSD ，那就会轻松很多。Windows 不用多说，可以直接静态编译出单个 exe 到处用。BSD 也类似，静态编译出来后，同系列上下游都能用。同系列上下游是指 FreeBSD → GhostBSD 这种上下游衍生关系，不是 FreeBSD→NetBSD 这种的跨系列。
（此处只针对单纯的 GUI 界面程序，不涉及游戏 3D 绘图）

还有其它选择，比如 XFS 和 BTRFS
不过 BTRFS 没 ZFS 那么稳定就是了，也许只剩 XFS 可选