贴错了 163 的那个，重新再发：
https://www.163.com/dy/article/IT0C1TKN0544M61U.html

真的确定银行柜员工作简单？这里有两个网址给 OP 参考：
/t/931539
https://www.163.com/dy/IT0C1TKN0544M61U.html

有点好奇，写代码时跟 Visual Studio 相比（ Windows 版），体验怎么样？
几年前我用过 vscode 写 C# ，并不算好用，代码补全能力很差，quick fix 基本不存在，不知道现在“进化”得怎么样

@rabbbit 差不多。但凡想要用 LGPL 的库却又不想开源自家源码，那就只能动态链接，用动态库形式。

@totoro52 不完全是“硬盘贵”的缘故，还有许可证的原因。

最麻烦的一点，桌面环境本身并不自带中文输入法，需要发行版自己处理。
如果发行版没预装中文输入法，那就只能全手动安装，一点都不方便。

@iGmainC NAS 系统承载虚拟机，那得看虚拟机放在哪个种类的硬盘，如果是 SSD 那还没什么。

要是放在机械硬盘（即使是阵列），那么速度就会很慢了，体验回退到十几年前的机械硬盘时代。机械硬盘的 4K 读写非常糟糕，跑虚拟机是能跑，只不过对于日常测试来说嘛……假如用来跑编译，或者测试时需要上传一大堆小文件、读取一大堆小文件，就可以重新体会到什么叫做“拖后腿”

公司环境的话，哪怕是做测试，NAS 最好独立一套，不要用来跑其它服务。就是前面楼层提到的一个字：稳。
这台服务器可以安装 esxi 用来做程序、服务的测试，但不要把 NAS 也丢给它负责。

同一台机弄成 ESXi + NAS ，正是不少家用 DIY NAS 玩家最喜欢的 All in One ，别名 All in Boom 。
为什么别名叫 All in Boom ？来个故障开机失败（尤其是过保二手货，出现大故障一点都不奇怪），直接全部完蛋。
All in One 家里玩玩可以，公司就不该这样了。

这台二手机，要么只做 NAS ，要么只跑测试，不应该混着用。如果做不了 NAS ，那就直接跑测试吧。

@wweerrgtc 准确来说，是国产界面做得好看，显然这个桌面并不是 Gnome

如果是工作需要并且能够用 C# 的话，建议先用 C# 应付着，微软有现成代码手把手教学：
https://learn.microsoft.com/zh-cn/windows/uwp/security/microsoft-passport-login
https://learn.microsoft.com/en-us/windows/uwp/security/microsoft-passport-login

如果时间充裕，或者并非工作相关，那就参照这个 C# 版本调用 cppwinrt 改写成 C++版本吧，微软并没有现成代码可供参考，只有 API 文档，例如：
https://learn.microsoft.com/en-us/uwp/api/windows.security.credentials.keycredentialmanager
换句话说，参照 C# 教程，对照 cppwinrt 的 API 说明，逐行改写。

如果 OP 确实想入行，其实是有相对更“传统”的：金融高频交易

同样需要对操作系统底层很了解，对于算法、语言本身也要很了解。懂点金融则更好。

同做 .NET ，其实跨国外企有许多内部程序是用 .NET 来做的，毕竟是用“Windows Server 活动目录域”管理整个公司，某些程序用 .NET 会容易很多。而国外用 .NET 用得多，这也是原因之一。

不妨尝试下找找国内的外企，它们对英语的要求不会特别高，起码比申请移民低得多。

@slideclick 类比不合适，看得出对于语言的印象还停留在 C89 、C++98 时代，然后用旧时代的印记忽视新进展再来对比新产品，这就是引战。


我自己工作就是写 C# 的（就是大家说“写起来优雅、上限可以很高”的那个），但想要精确控制资源释放的话，仍然是 C++更为方便。我是踩过坑的，有部份程序我并不用 C# 来做，而是用 C++ 去做。

尽管我不是前面楼层那些细分行业，也用不上那些专业知识，但并不妨碍我使用 C++。


最后 C++还有一个优势，源码级跨平台横跨 Windows 、BSD 、Linux ，只要底层 library 能够在包管理器当中找得到（或者自己编译并不难），那么移植起来非常简单，也不用考虑 runtime 怎么搞，更不用考虑语言是否支持特定硬件平台，只要编译器能够编译就行了。

我个人就是 BSD 使用者，制作出来的部份程序需要跨 Windows 、BSD 运行（然后顺便编一个 Linux 版本），只有 C 和 C++可以使用内置编译器简单地编译，最起码的我会把编译前置步骤弄得比 Golang 之类的更简单，让小众硬件平台的 BSD 环境也能顺利编译（恰好，那些新语言并不支持小众平台的 BSD 环境）。

插个楼，刚才有人提到说什么“Java 替代 C++”，纯粹是引战的，看看那个人自己发的主题贴就知道： /t/1021175

从这个 iperf 的测试来看，似乎是同一个监听端口与对端 IP 两个端口分别建立两个连接时，只有第一个限速，后面的都不限速。

如果是这样，那就试试这个做法：
假设是用手机连回家用 plex 看电影，那就先用这台手机分享 WiFi 热点，用另一个设备（例如平板）接入这个 WiFi 连回家打开 plex 看电影，此时大概率是限速连接。先放着不动。
然后再打开手机上的 plex 试试打开家里的电影，只要上面那个 plex 没关掉，那么现在应该是第二条连接，或许能达到流畅高速度。
如果连接确实流畅了，那就可以关掉平板的 plex 。


更进一步的，可以在家宽这边开两个不同的 iperf server ，监听不同的端口，然后再在另一台设备用两个 iperf （都是单线程）同时测速，看看会不会有限速。
如果这样也能做到一个限速一个不限速，那就更好办了。开热点后随便起个长连接，比如 ssh ，或者限速 1K 的 iperf ，接着再开 plex 。

既然这个随身 WiFi 都有 LAN 口了，那么家里那台无线路由器可以直接改成 AP 模式