@creedowl 所以我说“要看哪个虚拟机”。KVM 早就可以了
GPU 虚拟化应该更早，不过这个应该是老黄限制只能在专业卡上用。但是 GPU 虚拟化我理解应该是指的是把一个物理 GPU 分成多个 vGPU 给多个用户（包括 remote 用户）用，这个对于一般用户而言并不是最强烈的需求
如果是单个 GPU 直接给虚拟机用，这个叫 GPU passthrough，KVM 已经可以用了。缺点是得稍微折腾一下，并且 host 和 VM 不能共享同一个 GPU （不过可以在 VM 运行前把 GPU 绑过去，关了之后再绑回 Host，不过这个 X 是没法直接用的，Linux 的 Optimus 又不是特别成熟）
我现在已经不觉得 VMWare 这种不开源收钱功能还不好用的虚拟机配叫虚拟机了

@liuy1994g 实际上一张 dGPU + CPU 自己的 iGPU 就行（就是笔记本以前流行的 Optimus 标配），我因为有这个需求，所以挑 CPU 挺受限制的 ... 只能买带 iGPU 的，Ryzen 拜拜 ...

@creedowl 看你说的是哪个虚拟机，KVM 理论上是可以的

虽然理论上新版 macOS 用不了新 N 卡，不过你换实体机照样用不了，俩公司就是不对付

啥叫 “没有为虚拟机系统配置图形控制台”，QEMU 还有中文提示么，而且没控制台不是应该什么都没有么怎么还有个提示，哪来的

-display none 换成 -display gtk

我也是 k3，然而并没有 type c 设备 ...

HR 是怎么问你的，难道是“你是软件工程毕业的，那么你为什么要来做前端呢？”
我觉得这种措辞的话，实际上和“你是软件工程毕业的，那么你为什么要来做后端呢？”“你是软件工程毕业的，那么你为什么要来做算法呢？”是一样的，都是问你方向这么多，为什么偏爱前端而不是其他方向
我也被问过，不过和楼主的方式有些不同，意思更明确，我理解是面试者需要评估一下你对这个行业的“热情”。毕竟一个人的经历很大程度可以推出性格和做事方式

Disclaimer: 软件工程毕业，之前在某个 HR 非常出名的厂做过前端，现在转了

@wevsty 这个是正解（虽然这个貌似不叫“多重继承”

xmonad 表示没有存在感 ...

另外 VSCode Remote 是不开源的。我个人虽然反对逢微软就反，但是这个事情依然给我一种微软把 VSCode 开源拿来钓鱼，鱼上钩了就给你套回闭源环境的感觉

客观来讲 VSCode 似乎被大家广泛黑的只有 Electron 一个黑点（除了是微软出的这种无理取闹以外），并且我觉得这不是 VSCode 的原罪。所以其实这个饵还是下了血本的，然而依然改变不了钓鱼的本质

VSCode 这个饵我吃了，该占的便宜要占。Remote ？抱歉，坚决不上钩

话说 VSCode 图标就是俩圈，真的挺适合挂钩上的

@Deardrops 我昨天半夜迷迷糊糊过了一遍主楼几个链接和一堆回复之后似乎就忘了顶楼提过试过 submodules 和 repo 之类的了，写回复的时候以为楼主没仔细了解过，抱歉。

关于顶楼提到的几个问题，submodules 没仔细了解过所以不好评价，但是 repo 我觉得还不错，文档缺失实际上是大多数开源项目的通病，就算是明星项目也很难保证文档是全的（更何况文档多了甚至会有人抱怨太 overwhelming 不知从何下手），冷门项目更难说，所以在看免费 /开源方案的时候就有必要做好 DIY 的准备。我个人觉得重要的是学习整个工作流的思想。另外一个适合自己的方案很多时候是拼出来的，如果 repo 能满足批量 push 和 pull 的功能，那其实就可以考虑把这一小部分集成进自己的工作流里面。按照“重新造一个新轮子”的逻辑执行，其实不一定比 battle tested 的旧轮子效果好。按照这个逻辑还可以推导出：Chrome 太占内存了重新造一个，python 性能太慢了重新造一个，cpu 太热了要不明天去海边整点沙子也自己造一个把 ...

单独开分支存放 WIP 内容确实会造成额外的操作，但是这个额外操作是能*换来*一点好处的。比如我上个回复提到的对实时性的控制：假设有一个理想化的方法，解决了网盘同步 .git 目录很麻烦的问题。现在我在 A 机器上改了一点东西，用网盘同步，然后（出于某种原因）立马切到 B 机器上，网盘可能不能做到立即同步，你得去轮询文件的同步状态 ... 但是通过 git 一通额外操作，是可以让你确定同步完成的。在用脚本做了一定的自动化之后可能就是一个命令的事，最后对用户的负担可能还要比用网盘同步然后轮询状态更小。

因为物理法则限制，没有网盘能做到立即同步，而如果要在一个特定的时间要求特定的一部分文件做到优先同步并且以某种方式通知之类的需求，用户依然得 somehow 把这个需求描述给计算机，这就是那些“额外操作”。

这里有一个问题就是，git 这个东西并非完全针对楼主的使用场景设计，它设计的这些额外操作其实在多人协作分布式开发开源软件（或者说就是 Linux Kernel ）的场景下才能做到最大的效率提升。所以楼主觉得麻烦，因为这个脚和鞋的尺码对不上。我个人的思路是可以考虑针对这一点做改进和增强，比如做一个脚本，把所有 unstaged/cached changes commit 到 WIP 分支，然后 push，写个编辑器插件，保存的时候自动运行，每台机器在打开项目的时候自动 pull。这个东西就是专门定制的，比如就没有考虑多人开发，如果把这个强行套到多人开发，只要出个 conflict，处理过程会比手动处理更麻烦，是没有带来方便的。

大致意思是最好不要期待有现成的方案，确实有不少，但是就像楼主说的有这样那样的问题，没有万能的。就算真有，哪天换个公司，换个条件，场景又变了，可能就没那么有用了

楼主你在机器上有自己的用户不？
建一个 ~/.local 目录，底下放 bin lib share 之类的，把 binary 下下来拷进去（有些可能需要自己编译一下，比如依赖 glibc/libstdc++ 版本过高啊，对路径有依赖啊之类的）
然后 PATH，LD_LIBRARY_PATH 之类的设置一下，除了安装麻烦一点，平常使用时 90% 情况下和系统包管理器安装是没有区别的，一些语言的包管理器比如 pip npm 之类的也是允许在 HOME 下装包的。
总之除了没法改默认 shell （这个只是登录时需要手动切一下），是完全用不着 root 的，根本不需要谁给权限，也不需要覆盖什么系统文件

当然还是可能工具出现奇葩 bug 把一个 core 占满这种情况，不过我觉得既然都人肉运维了，其实风险和不装没差别。就算是自动化运维，也难保自动化工具不出问题啊

@randyzhao 我这两天就正好有这样的需求，首先我是在 server 上开发，但是公司 server 有些小问题，比如三天两头挂或者下线维护，工具链不统一，一些服务和工具只有部分 server 可以访问，server 分布在全球网络状况不一样，特定的测试需要独占 server 被分配到其他 server 上等等。另外我在不同 server 上配置的环境也有一些区别，比如有的我配了完整的 VNC+VSCode，有的我配了 code-server，有的我配了 Emacs，有的我连 .vimrc 都没碰过，虽然我意识到问题之后在尽量做统一，不过不是三两天就能改的。有些工作也会在本地 Debian Desktop 上处理（然而 server 是 RHEL，并且使用的模式完全不同 ...）

第一，如果无法接受同步 .git 文件夹的话，那其实已经不是小项目了，就算没有 git 之类的东西，项目本身的文件数量也会造成不小的压力，所以并不完全是 .git 文件夹的问题。另外 git 有一个 pack 的特性（ https://git-scm.com/book/en/v2/Git-Internals-Packfiles ），可以把 .git 里面的 objects 打包成若干大文件，你看下你从 GitHub 上直接 clone 下的 repo，.git 文件夹下其实是没有几个文件的

第二，用过 git submodules 么？“一键批量 Push 和 Pull ”之类的根本不需要什么“新的工具”。虽然我觉得我不会选择 git submodules （所以这个例子只是描述类似的通用的方法）。Android 用了一套 Python 脚本叫 repo 做得更完善一点，虽然我觉得有点慢还依赖 Python 大概也是不会用的 - -

第三，一个 WIP 的 patch 不是必须 stash，也不是必须 commit，也不是只能放着不管——上面提到的 repo 工具提供了一个新思路，就是专门开一个 branch，把半成品 commit 上去，这个 branch 只有这一个 commit，只拿来当 （某种意义上） stash 的替代品，没有其他任何功能。这样就可以利用 Git 分布式 push 和 pull，当你迁移到另外一台机器上，pull & checkout，干活，完后 git commit --amend，push (这个需要 -f)，当然你觉得 push -f 不 clean 可以选择单独 commit，反正是专门的 branch 可以随便搞事，全 done 之后 squash 到一个 commit 就是。这是充分利用 git 的优势

第四，我觉得这个问题没有一个万能的方案，应该针对不同的情况具体分析。比如如果一个人不用 git 或者多种 VCS 混用，网盘的通用性就更有好处。我的很多私人数据一直是 syncthing 同步的，因为首先个人数据不止是软件项目，就算有一些很像软件项目，其实并不一定适合用 VCS 的方式来管理（比如 Word 文档和 Sketch 稿），所以我不能依赖 git 这一特定的系统，其次并不是所有的代码都会被 git 管理的，就算是 git 仓库，利用 git 做同步的优势其实也并不明显（特别是考虑到前段时间 GitHub 没有免费 private repo 的情况），另外 push pop 乃至于偶尔处理 conflict 都是额外的 overhead，网盘基本就是扔在那就不用管，至于同步速度之类的那是实现细节的问题，理念上来讲我觉得网盘还是占优的。

我自己还是遇到了一些问题，比如在家里用 desktop 改了东西想要立刻在 laptop 上面测试，syncthing 是没办法实时同步的。另外公司环境下是不能乱用软件的，尤其不能用第三方云服务。但是机器环境比我个人的还要复杂一点。我有一些替代方案：
NFS/sshfs/Samba，这个用好了可以很 versatile，首先家里 NFS 可以随时访问整个文件库这个大家都知道。我还会单独做一个共享用来放临时文件，包括一些 demo 啊截图啊之类的，这个还可以当 poor man's Airdrop 解决上面的实时性的问题（有实时性的需求一般都是需要额外操作的，git 和 Airdrop 都是，所以这个没有本质区别，还不依赖 Apple 的生(jiu)态(cai)圈）。
另外我还会把代码仓库在本地 mount 一份，这个可以直接在本地用 native 的方式操作远程文件（抽象真的是很神奇的东西）。在网络可以的条件下，对于中小型仓库而言性能的损失不明显（所以也是楼主问题的一个可能解决方案）。大仓库问题就比较大，就算开大缓存（这个会牺牲实时性，基本等于 read only 了） git status 都要半天，但是需要利用本地工具操作较多文件的时候还是有用的（比如里面有一堆的 pdf 或者 md 或者 office 文档，本地的阅读器是用着最顺手的）。
这个当然不局限于两台机器，所以你可以把做好的 test case，脚本或者 patch 放在里面，立马就可以在网络上任何机器上用。
在公司中心的代码仓库是限制 commit 的（我也没有用某台 server 做中心库），所以用上面说的开 branch 来替代 stash 的做法不是特别现实。我的解决方案是在 A 机器上改完之后本地 commit （不 push 也没法 push ），在 B 机器上把 A 机器的仓库地址添加为新的 remote，然后 git fetch A 机器的仓库，git cherry-pick FETCH_HEAD，更改就拉过来了。我觉得这个流程绝大多数人都用不到（一个中心库就能搞定），在我这确实解决了问题，所以说要根据自己需求定制。

C++11 已经不允许 COW string 了。

这种问题得从 C++ 特色去考虑：COW 在修改时会 invalidate 掉 iterator 和 reference

@kevinhwang Docker 本来就是专门针对 Linux 的

Windows 和 Mac 都有他们爹自己的技术，对于本来就是平台绑定的技术没有哪个平台支持不支持的问题，你这么认为只是你用得到用不到的问题

不能光怪媒体，媒体看着你们一个个骂的挺带劲但是又不掏钱，有什么办法呢，只能靠流量咯，也是要恰饭的嘛
付费阅读新闻的风这段时间才被 Apple 在国外吹起来，国内短期内根本行不通