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 在国外吹起来，国内短期内根本行不通

说到虚拟机，从硬件虚拟化到容器级虚拟化到应用虚拟化，Linux 都支持的很好，并且很多都是免费开源的
唯一略占下风的是和 Windows/Mac 中的付费商业软件 Parallel Desktop/VMWare 对比的桌面虚拟机（这个倒和 Linux 桌面对普通人不友好的特性是一脉相承的）

我认为就跑虚拟机这一点来说，Linux 是理想的 host OS，这个在服务器领域已经是共识，在桌面领域我觉得也是一样（就算考虑到 Linux 没有 Parallel Desktop 这一点）。比如我现在就可以随时跑一个 Win10 的虚拟机玩游戏。这个据我所知在 Windows 和 Mac 上，不花额外的软件费用，使用现有的消费级 GPU 是无法做到的（ Parallel 之类的好像能做到虚拟 GPU，但是实现上还是类似 virtualgl 的做法，性能和 Linux 下面直接把 native 驱动装在 Guest OS 里面是没法比的）

@baojiweicn2 我只是专门挑坏处说的

我觉得 Go 轮子不少啊，楼主有这种感觉应该是和 Python，Java，JS 比吧
我认为一个编程语言，各方面都有一个能用的轮子，并且生产环境验证过，当你想用的时候能找到，这就基本够了
太多的轮子会增加选择成本，影响新入行的人的学习，加重”派系分化“，说是社区活力的体现，其实同时也体现了社区的不稳定，特别对于比较小众的语言，社区在特定方向上有限的精力被分散在不同的具体项目上，旁观者会发现轮子多而不精（是不是说得有些恐怖了）
你看 JS 都淘汰多少轮子了

@thautwarm 我应该加个狗头的

@darklowly 最后一段，楼主说的也是这个意思，如果你是弱校毕业，那么上限很可能也就这样了

这和你” 25 岁不具备足够的基础知识或许这辈子都很难具备了“本质上是一个意思

顺便，基础知识不过关的不只小公司，大公司也是

这 operator ... 没事跟 Haskell 学这些没用的歪门邪道

@charlie21 我认为 PC （我上一条回复里面所指代的 PC ）本来应该一扫六合一桶浆糊的，Mac 其实是恰好”幸存“下来的幸运者。

当然我对 Apple 在 Mac 换 x86 之前的历史了解甚少，但是我个人猜测，如果没有 iPod，如果 Mac 不换 x86，现在 Apple 还是不是”既做电脑又做电脑操作系统“的公司就很难说了，甚至还有没有这么一个公司都不好说

上世纪 Mac 本来就是长期与 PC 对垒的，美国当时有个王安电脑公司，也是不兼容 PC，90 年代垮了

所以问题我觉得更多是关于 Apple 自己的特殊性，而不是其他公司怎样怎样