刚需 docker 的话，要么 Windows + docker in WSL ，要么直接纯 Linux

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

需要安静环境集中注意力

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

像是 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 可选

我在公司里会用 C++写命令行工具（哪怕是 Windows Only 的），这时候就可以放飞自我了，因为不用开源，我想怎么写就怎么写，甚至写出一大堆不符合 C++ Core Guidelines 的代码。反正这时候的目标只有一个：能跑不崩就行。

@cnbatch 顺便再补充个我是怎样迁就 BSD 的

首先，有个很重要的一点，BSD 全系列全部自带 C/C++编译器，我很喜欢这一特点。哪怕是 FreeBSD 的衍生版本，即使是变成了防火墙系统（比如 OPNSense ），依然都自带编译器。
其次，我发布的二进制文件未必涵盖 BSD 系统自己支持的硬件平台，但我希望其他人在这些平台里，可以顺利用自带编译器编译我的代码。这样就不需要额外安装其它语言的编译器了。
那么能用的语言就只有两种：要么 C ，要么 C++。
再结合我先前提到的，“想用到方便的语言特性”，只能选 C++。

语言选好了，接下来选标准。
到目前为止，FreeBSD 仍在受支持的最低版本是 12.x ，其中 12.0 自带的编译器是 LLVM 6.0, 最高能支持到 C++17 。直到 2022 年更新的 12.4 才升级到 13.0 ，可以稍微支持 C++20 。
所以当下这段时间我会继续使用 C++17 。等到 FreeBSD 12.x 停止支持了（今年年末），我再升级语言标准也不迟。

@Cu635 这里就有：
https://doc.rust-lang.org/nightly/rustc/platform-support.html
Tier 3 当中就有提到，RISC-V FreeBSD 并不支持，但 RISC-V Linux 却又是 Tier 2 支持，显然对 BSD 的支持并算不完善。
而 BSD 系统自己支持的平台比这个列表要多，虽然我个人并不可能每个支持的平台都编译一次二进制文件，但如果有人刚好有 BSD 支持的偏门硬件（而 Rust 不支持）又刚好想拿来编译一下，那么他就没办法做到编译了。

我并不喜欢给 BSD 使用者设限，因为我自己就是 BSD 使用者，尽管我跟对方所使用的 BSD 未必是同一种类。

我也更偏向用 C++，尤其是个人项目。

Windows Only 的项目除外，这时候我会根据实际需求选择 C# 或者 C++，不会定死只用一种。

个人项目跨平台时，我只能选 C++，因为我跨的平台相对“偏门”。不但有 Windows 和 Linux ，还有整个 BSD 系列——FreeBSD, NetBSD, OpenBSD, DragonflyBSD 这几种。
毕竟我既想用到方便的语言特性，又想二进制文件尽量小，不要“拖泥带水”挂靠 VM ，还要兼容 DragonflyBSD （尽管没什么人用，但我还是会给它编译出二进制文件）。这样下来可选范围非常窄，对我来说也就 C++最适合了。

自己手动转换基本上不可能，等于重新造一个 ICU (International Components for Unicode)，不如直接调库吧

@Satansickle 这时候需要注意大小写，以免产生误解
就像是 MB/s 一般认为表示 MBytes/s ，Mb/s 一般认为表示 Mbps
然后直接来个全小写的话，那么阅读的人怎么理解都不能算错

写全称最好，杜绝出现误解

桌面版 QQ 原先的显示方式可以避免这种情况，如果还记得原先 Q 群的群聊界面，就会知道每个人的 QQ 号码会显示在名称旁边，这样就算有人假冒都会很容易识破

然后手机版“气泡模式”变成桌面版默认聊天模式后，Q 号就隐藏起来了，于是造成这种隐患