@timothyye 我自己花了一下午拼了个多旋翼小飞机，升空 5 秒直接坠毁。再看看别人家的固定翼都弄出来了。

没用的，多线程硬盘写入就只会更慢。

手残党表示拼个小破车都走不了直线，看了眼 mod 发现大佬都在里面开高达了。
然后就还是喜加一吧，还是不给自己找虐了。

不能。
盗版不盗版看的不是介质，看的是你有没有合法授权。
你用 OEM，和你在 JetBrains 家用学生账号一样，都是不符合授权的行为。
都是盗版。

@iTvX Windows Update 里面自带的那些驱动多数都是厂商拿去做过认证的，但基本不会是最新的，只是保证能用，而且稳定而已。

机器学习马上就快跟当年的前端开发一样了。
自己跑了俩 Demo 就能出去骗工作，骗到一个是一个。

一个做路由的，竟然敢在 HTTP 请求里面插广告，说明从骨子里都烂透了。
你们居然还敢相信这样的团队。

不用整这些没用的，也用不着模拟。只要有人发钱，我可以一直蹲在家不出门。

1 不是。比较的是 Windows 上装 Windows 虚拟机，或者 Linux 上装 Linux 虚拟机的效率。不是 Windows 上装 Linux 虚拟机这种 Guest 和 Host 不同系统的情况。
2 不会，Docker 镜像是分层的，每层都是只读的。只有你在修改某个文件的时候会复制出来一份。

没用。
你只能用 Windows Docker，那还不如直接用 Windows 安装。
除非你换到.NET Core，不然没什么用的。

真正有用的就这么三个：
沟通用 Slack 或者 Teams 选一个，微信一类的根本就不是为了交流沟通工作用的，设计方向就有问题。
开会 Zoom 或者有钱上 WebEx，效果吊打其它。有的甚至开个会都能串台你敢信？
项目 Teambition 或者 Trello 都可以，但你也可以试试 Jira，这东西唯一的缺点就是贵。

对于大部分开发来说，其实最好的是每周规定一两天必须在公司办公，用来保证和同事之间的沟通效率。其他时间可以自行选择在家或者去公司。
在家的话也要保证一定的时间内，比如上午十点到下午三四点完全在线。如果同事有事可以立刻找到人语音视频会议。剩下的你自己愿意晚上写代码就晚上写，愿意早上写代码就早上写。
不然虽然八小时工作制，但还要花两三个小时在路上。多出来的那些时间干点啥不好。

@fancy111 对，卫生间一定要监控上，不然很多人带薪拉屎。

所以说为啥不用 zoom，专业的事还是用专业的软件做吧。

onenote 最大的问题不是 license，而是微软对他的定位。
放弃了 Desktop 版本，强推 UWP。但是 UWP 的又没法打开本地笔记文件，微软的 OneDrive 很多时候非常卡，而且又不是所有人都喜欢把自己的笔记放在云服务上。
然后那个笔记文件用多了就变得巨大，同步起来简直是灾难。
但是从使用角度，没什么比 onenote 更好用的东西了。

目前一直用的就是 VNote 写 markdown，然后 markdown 弄到 Git 库里。自建 Gitlab 或者直接 Github 都行。VNote 可以很大程度上解决 markdown 插入图片等各种不适，纯粹的 markdown 也可以直接用各种东西直接生成 blog 页面。
缺点就是你只能在 PC 上写。

用这个玩意前提是团队有一定的合作概念，需要一些培训才行。
Teams 对标的是 Slack，不是微信也不是 Jira 什么的。没用过这类软件的人基本都会把话题直接当回复用。但只要培训了基本的用法，这类软件远比 IM 好用得多。
至于使用上，微软有直接在应用宝推广过 App 吗？而且微软的服务器确实是慢，不过比 Slack 好一些就是了。

@mrcn 不是
因为 C++不像 Java 或者 JavaScript 一类的直接使用源码（字节码也算直接使用源码了）它用的是针对平台特化的二进制。所以没办法像其它语言一样直接拉同样一份库就能用。你得针对不同平台甚至不同 STL 编译出一份来。也没有像 Maven 或者 NPM 一样的东西，不然同一份代码你得编译几十上百份二进制存进去。
我了解到的，主流的都是在你公司内部部署一个包管理系统，因为特定某个产品支持的平台一般都是有限的，所以你可以只放有限的几份上去。
你说的这个并不是主流做法，版本控制系统设计来是针对纯文本的，它的 diff 并没办法很好的处理二进制。你也不应该把二进制提交到代码库里。
正常做法是，你开发了一个版本的代码，CI 编译成针对某个或者某几个平台的二进制并生成版本号，然后 CI 把这些二进制传送到二进制管理系统里。
使用这些东西的项目，会在编译期由 Build Automation 系统去二进制管理系统里面查询对应版本号（你可以把架构直接写到版本号或者 product id 里）的二进制，并下载回来解决依赖。
至于你说的代码版本和二进制版本的对应关系，CI 系统会有记录。而且很多时候你也会把这个代码版本记录到二进制的包里，或者直接打到文件属性上。
不要把二进制放到代码库里还有个原因，就是你只放二进制的话没有编译环境记录的。CI 系统会记录每次编译使用的环境变量，编译参数，而且还有 log 可以查。而且你会把 pdb 一类的东西也放到二进制管理系统里。你在代码库里提交一个二进制，甚至都不一定能和代码对应的上。到时候出了问题查起来就是灾难了。

C++的依赖管理有几种。
vcpkg，conan。或者包进 nuget 里。我们自己用的一个魔改过的 Gradle。
其实改个 Gradle 插件是最简单的，或者 Conan 也可以。直接用 Artifactory 存编译好的二进制。你在编译的时候需要的依赖都会拉取对应版本到本地，解压链接进去。如果本地有的话那就直接用缓存。
自己控制好版本和 Arch 依赖关系就可以了，改个现有的系统的话，这些基本都有办法解决。
其他的不推荐，特别是你这种做法。到时候部署版本出了问题，你都没办法追踪依赖版本。而且根据环境不一样，有的时候你编译的二进制也不一定一样。这时候你再去追踪调试就更没谱了。
依赖最好是固定好的，对于 C++来说，不要去直接依赖代码。除非你是 boost 那样直接复制进去就能用的，不然全部都依赖二进制。然后这些二进制如果是开源的最好你要么直接依赖官方发布的二进制，要么全部自己编译。而且记录好编译环境参数等信息。有些项目在编译的时候会读入环境变量，这种你更没法控制发布版本了。
所有你依赖的库，全部都依赖其二进制。然后编译过程中通过依赖管理系统去下载这些二进制，让依赖管理系统去解决版本号，Arch，冲突等等问题。不要自己手动去解决。
你现在这种做法不出问题就罢了，真的你哪个依赖库有问题导致发布版本出错，查都没得查。