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

包管理：

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 号就隐藏起来了，于是造成这种隐患

端口 22 拒绝连接那个，可以按楼上说的把整个防火墙关掉试试，可能只是规则问题

然后可能还要检查下 sshd_config：
位置应该在 C:\ProgramData\ssh\sshd_config
看看 PasswordAuthentication 、PermitRootLogin 之类的，该改成 yes 的都改一改

其实不需要手动创建入站规则，安装 OpenSSH 可选功能的时候，Windows 会自动创建对应规则的：
https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse
https://learn.microsoft.com/zh-cn/windows-server/administration/openssh/openssh_install_firstuse

不过，我不确定是不是因为手动创建了规则会导致 Windows 不再自动创建规则，于是就无法 ssh 到 192.168.135.1
既然连接不上 192.168.135.1 ，那么连接 192.168.0.103 也没关系，反正 NAT 已经帮你转换好地址了

Permission denied 的问题，可能需要检查下注册表 HKLM:\SOFTWARE\OpenSSH 里面的 DefaultShell 指向了哪里，有可能指向了不存在的命令行解析器。根据其他人在 3 年前的描述：
https://learn.microsoft.com/en-us/answers/questions/109609/unable-to-access-the-win10-pc-with-openssh-install
可能是指向了 C:\Program Files\PowerShell\7\pwsh.exe
如果刚好你没安装 PowerShell 7 或者安装的 PowerShell 7 是 Windows 商店版本的，那可能会因为文件不存在而导致启动失败。

如果路径确实就是 C:\Program Files\PowerShell\7\pwsh.exe 并且没安装 PowerShell 7 ，那么从微软的 Github 页面下载安装就可以了：
https://github.com/PowerShell/PowerShell/releases/
务必安装 msi 版本的，64 位 Windows 不要选择 32 位版本的 PowerShell ，因为那样会安装到 Program Files (x86)

或者手动改成 cmd.exe 的路径也可以，如果习惯用 cmd 的话

换个做法，手指直碰触摸屏。

毕竟这是个平板电脑。

很简单，如果你认定了当前道路不适合继续走下去、越走越痛苦，必须换另一条路才行，那就换。

征求意见后，不少人劝留，然后过段时间你又觉得痛苦加倍，岂不是会在内心怪罪当初劝留的人？
说句实话，其实会有不少同行的内心是欢迎你转行的，因为等于少了竞争对手。

至于另一条路的前景，没有亲自探索过的话，哪里会知道风景如何？大多数计算机同行的网友同样未走过这条路，其实也是很难告诉你的。

专业写小说的人应该也有他们自己的论坛或者交流群吧，要不找一个进去问问？不过我个人觉得他们更倾向于劝退，因为你加入后，对他们而言等于是多了一个竞争对手，加剧内卷。
但倒是可以尝试用“试探”的形式去问，不要以第一人称的方式去问，或许能让他们稍微吐露真情。比如这样讲：“我的前同事失业后打算转行写小说了，经常在私下交流群内发草稿问我们写得怎么样，受不受欢迎，但我们不懂啊，应该怎么回答他？”然后把你想说的话套进去，看看大家的反应。

笔记本电脑也能用 ECC ，虽然型号不多。

找到一个：
https://www.servethehome.com/dell-precision-7540-with-intel-xeon-and-ecc-memory-review/

纠个错，ZFS 并非 Linux Only 的文件系统，BTRFS 才是 Linux Only 的。

ZFS 原本是 Sun Solaris 的文件系统，开源后被 FreeBSD 主动引入，随后才轮到 Linux

这个叫做“归属地接入”，不仅仅跨国漫游会用到，跨省漫游也会用到（虽然不少省份的地区运营商改成了拜访地接入）。

技术原理：
https://www.zhihu.com/question/31923127

V 站的站内讨论：
/t/836788
/t/923297

OPNsense
pfSense
BSD Router Project

这三个都是基于 FreeBSD 的，对于网络设备非常友好，连 Netflix 都专门用 FreeBSD 来做 CDN 。

尤其是 OPNsense 和 BSD Router Project ，很值得试一试
OPNSense 的防火墙设置比 pfSense 精细一点，我印象最深的是它自带地理位置区分
BSD Routing Project 就真的是做路由器该做的事（也就是真正意义上的硬路由），可以用它来试一试普通服务器当作路由器会是什么样的表现。