或许是应该抛弃以太网口了？我其实只有在初装系统和调试路由器的时候才会用到它。

喜欢 Thinkpad 的一大原因是有用户手册可以看 还有就是 Trackpoint

@CEBBCAT 至少 1080 就行了 2w 以内

@behanga 感觉更可能是图片啥的，毕竟一个 linux kernel image 也才几十 MB

@iwtbauh # 54
你说的很有道理啊，可惜我的开发环境和部署环境不是同一个 distro。比如我在 arch 上依赖 ffmpeg 某个 shared lib 写了程序 在部署环境的 debian 里跑不起来 debian 官方可能都不提供我依赖的这个 lib 版本。

@est 嗯 谢谢提醒 自己写的哪些项目分别有哪些依赖都在自动化脚本里 如果有哪个出了问题 grep 下就知道哪些需要重新 link 之后重新编译有 bug 的库 然后 link 一下就完了 不需要全部重新编译 我觉得问题应该不大。

感觉学到了很多哈 谢谢大家 如果大家有各种奇妙的关于这问题的链接都可以 po 出来

@iwtbauh 我觉得是有道理的 但是 linux 上的版本问题就算被解决了 但是还是感觉很奇怪 因为如果上层都各自用各自的版本了，那干嘛还要 shared library。 反而为了解决这些版本问题增加了复杂度 感觉不值得。不过像 @w01230 说的这种内存特别紧缺的是很有用的。而且还有像 glibc 这种不知道是有历史包袱还是故意为之的情况存在。所以我觉得看情况，像我能用 static 的时候就尽量用 static。虽然最终出来的 executable 里还是有 so 只要解决了生产环境的兼容问题 我就能接受了。

话说这个问题原来在 YC 上就有讨论 感觉水很深呐
http://harmful.cat-v.org/software/dynamic-linking/
https://news.ycombinator.com/item?id=9629663

@hikkikuma1991 长知识了 具体为啥必须要动态链接 大概是因为这个 https://skarnet.org/software/nsss/nsswitch.html

仔细想了下。像底层库更新这种情况的话，用动态库确实可以不用让依赖它的库重新打包。如果接口和行为没有改变的话是很不错的，但是也是可能带来兼容性问题。比如，底层库做了个 breaking change，那后续的库如果不改动的话也不能跑了。目前这种情况主要是包管理器来做依赖检查，然后决定你不是能更新某个底层库的。所以我觉得各有利弊吧。

我二了

@thedrwu 有道理

@Osk 哈哈 package-lock.json

@wbing 如果编译成 static library 的话也是不用重新编译的 只是打包一下

@doun 我很喜欢 go 呀 但是有很多有现有 c 库的情况就很尴尬。没太试过用 go 调用 c 不知道好不好

哦 我是觉得相对它的收益 成本有点高。作为库的使用者，得保证开发和生产环境的这些依赖版本都一致。还是很痛苦的。

@heww 目前都没有遇到这类问题呢…
private 的项目都在自己的 gitlab 上，连上 vpn 就可以 go get
CI 的问题，最简单粗暴的方法是把 vendor 推进去。这样其实也无所谓用 glide 还是 dep 了
如果不想推 vendor 的话，我会反过来想。为啥开发的时候可以 go get 但是 CI 却不行？能不能把两者环境统一一下？如果实在不行，能不能做 repo 的缓存？

@heww 是吗？没写过大项目不太了解 dep 说会以后会放到官方 toolchain 里 如果没有依赖 glide 的某些高级 feature 的话不妨就直接使用将来的趋势？
https://github.com/Masterminds/glide#golang-dep
https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/