@0o0O0o0O0o 这类的我还真见过，之前公司内网瞎解析，搞个了个 http://go 的短链 ，别人直接发 go/xxx 一时还真蒙蔽了

很多插件一时爽，一直装一直爽。

@AllenHua 好吧，我承认我现在更尬了，😅😅😅

@icy37785
@shawndev

其实我想说这个算不算是后缀为 1 的顶级域名😅

先震惊一下：震惊，某号称 21 世纪的终端必须联网登陆后才能使用!!!

看了下介绍感觉还不错，安装后发现必须要用 Github 登陆才能用，只能说 🐶 听了都摇头。

感觉楼主是想给自己不想花时间研究某项东西找借口，因为自己没花多少精力也出活了，借此去贬低那些花很多时间去研究某项东西的人。没必要这样，真的，欠下的债早晚都要还的。

我也遇到过这个问题，实在太恶心了，不晓得谁设计的这个功能，居然还默认开启了，我特么居然还硬是忍了半年多…

@hsfzxjy 是个好东西，之前也有用过 patchelf 这类的工具，不过这相当于又增加了一个依赖项（或者说心智负担😂），折腾的多了现在喜欢纯粹、直接，所见即所得，拒绝黑盒😂

@waruqi 嗯嗯，听说过 xmake ，据说还不错，不过确实是没见几个基础库用过😂。之前玩过 autolools/make/cmake/vcpkg/conan/自研 /brew/blade/bazel ，听说最近 c++ 20 又有引入了 module ，也不知道以后还会有啥... 反正隔壁的 go mod 是真的香是真的...

@ivyliner 我说的 all in homebrew 是指 MacOS/Linux 所有工具都 brew 安装，经过一年的努力，已经把 apt 安装的包都替换完了。但是 c++ 开发环境不适合用 homebrew 这种玩具了，还是 google 的 bazel 或者 fb 的 buck 比较靠谱，除编译器外，其它都很容易与系统库解绑，全链路源码编译+全链路静态链接，这块跟 golang 差不多了。

@Nitroethane @lingxi27 可能开始确实说的有点绝对了，这个得拆开来看
1. 从工具角度来说，apt 引入动态链接二进制就是省了磁盘大小 /分发带宽，工具不存在极致性能考量。
2. 但是从服务角度，动态库确实提供了一些足够 solid 的属性，典型的像以 jemalloc 为代表的通过链接顺序 hook glibc 的符号的操作，确实很方便，但这不代表静态链接 jemalloc 达不到同样效果。
3. 个人觉得动态库这么猖狂的原因，还是因为 c/c++没有包管理工具，导致大型开源项目只能先根据 autotool/...独立编译为动态库，而后将动态库跟主项目捆绑，从而导致了万恶的预编译的诞生，最后美其名曰：提高了编译速度。

@Nitroethane 你说的这个我明白，但生产真的有人（赶）这么搞吗😂，重新编译都能被 abi 问题搞得死死的，直接替换 so 那是真的艺高人胆大

好不好用不知道，11 月 29 号的时候给官推跟回了个 `Yeah, sticking to Vscode then`，然后每天都能收到点赞是真的...

@12101111 给 homebrew 开了两年光了，实在是折腾不动了，后面有精力再研究下老哥们提到的 nix/gentoo 大法，不过说到底还是一开始没踩对坑...

@Jooooooooo 趁年轻，还是早点转 go/rust 比较好，c/c++ 但凡有个靠谱的 modern build system ，也不至于到现在连个靠谱的 modern build system 都没有

@wtl 刚看了下描述，感觉是个好东西，不过前年开始就 all in homebrew 了，同样可以做到对系统库接近 0 依赖（主要还是 glibc 不容易做掉），而且它最大的好处是同时支持 Linux/MacOS ，而且 rootless 。

@jim9606 国内公司谁管这些版权啥的啊 😂，主要是 c++ 编译工具链做的一坨 X ，每次产物都 bundle 几十个 so 文件，每天能跑起来就谢天谢地了，之前遇到个动态库版本导致的 abi 问题，硬是 toubleshooting 了一个双月 💔

@Buges 😮‍💨，给大佬们反馈过，没采纳，想来是有很多坑吧，或者懒得折腾了。

而且线上部署打包的时候都是把所有 so 都 bundle 上（包括 glibc 这种系统库），加起来产物大小是静态链接的好几倍，反而导致上线特别慢，完全颠覆了设计预期了，想想就来气...