@dslwind 你这是散热器扣具设计不合理，压力不均匀，导致 CPU 插槽变形，接触不良

“每个月工资上缴老婆”
“前几天才知道我老婆接触网 du ，目前各种网贷欠下总额 20w”

唉……

p100 你搜搜实际使用体验。显存大是大，算力不行有什么用？ reddit 上就有人用 p100 出过图，效果并不好

二手卡默认是矿。只要价钱合适，矿就矿吧。到手先跑一遍各种测试，小烤一下温度正常，那就用吧。别手贱换硅脂，散热不正常就退。

40 卡不游戏也可以考虑，不炼丹的时候挖个矿回收一点成本也行。之后还可以出二手回血。

你这不是自购电脑用于工作，而是把自己的私人电脑用于工作。区别在于，工作电脑和私人电脑有没有分开。
如果能保证工作电脑上只有工作内容，那就算自购的电脑，要装深信服就装，要看数据就看。反正只有工作内容。离职直接抹盘重装，或者管理系统替你抹盘。

@byte10 “cherry-pick 问题多多，容易出现漏掉” backport 的时候我就是不想要某些 commit
另外，你用法可能错了，cherry-pick 是可以一次性指定一段范围的 commit ，会一个一个 pick 过去。和 rebase 效果类似但是方向相反。

@byte10 你看一下 git log 的可视化就知道了。merge 的优点是可以保存 feature branch 上的支线 commit 。

merge 产生的是一个“merge commit”，有多个父节点。这样的 commit 在 rebase 的时候非常蛋疼。也就是说，如果一个 branch 有过 merge ，那就基本告别 rebase 了。

rebase-and-squash 对人多的项目比较合适。因为开发人员水平不一，很多人的 feature branch 的历史都乱七八糟。squash 以后主分支上，一个 PR 对应一个 commit ，就非常干净。之后某个 release branch 需要 backport 的话也很方便，直接 cherry-pick 特定 commit 就行。

如果是 merge ，那就要保留对应的 feature branch 。backport 的时候直接从 feature branch 上 merge 。

通过 rebase 解决冲突，最终产物是树狀的历史。通过 merge 解决冲突，最终产物是网状的历史。

我个人是非常反对用 merge 。只用 rebase 和 cherty-pick 。因为有些 commit 可能是不想要的。所以 merge 不可取。release 分支上 cherry-pick 相应的 commit 。

merge 派和 rebase 派，选了一边就不能换。

原因你自己说了啊
反正最后你还是会买，那为什么要多给 2G ？

@KOMA1NIUJUNSHENG 这就是为什么我成了垃圾佬。捡垃圾既不花钱，又满足了配电脑的欲望。随便魔改超频不用担心搞坏。

@iloveayu #22 此言差矣。E5v3 和 v4 的默频性能差别非常小。然而 E5v3 有硬件 bug ，只要不加载微码，就可以把全核睿频拉到单核睿频。这也就是所谓的鸡血补丁。而且 v4 当年发布得晚，出货量少，导致二手价格比 v3 高很多。

@version #24 真以为玩洋垃圾的是因为没钱？
我也一句话怼爆你，我买手办花的钱，早就超过 mac studio 顶配的价钱了。就问你有没有 mac studio ，是不是顶配？

@Rorysky 打 8 代应该没啥难度，别说 i5 ，i7 都行。2697 v3 单核确实不如 8700k ，但是 8700k 只有 6 核，2697 v3 有 14 核。一个真核对一个超线程还是够打的。

如果你是打游戏的话那单核性能确实比较重要，因为老游戏多核优化太差。如果你追求的是高特效、光追、高分辨率，而不追求高 fps 的话，那 CPU 差一点也够用了。
但是现在新 CPU 也是堆核心数。所以用新引擎的游戏对多核优化也很好了。比如 Starfield ，2697 v3 的 fps 可以达到 Eyzen 5600 的水平。https://youtu.be/sN_VuVs9Hs4?t=


如果是生产力的话，那双路 X99 ，内存随便加。pcie 槽多，GPU 加速也随便加。除了电费高一点，没别的缺点。

@bclerdx 铅笔粉就是石墨粉。铅笔不含铅
锂基脂主要就是在金属-金属接触面上，不腐蚀金属和塑料，粘度合适。而且承压情况下的润滑性能依然优秀。

@yuanshrn 找工作第一规则：没签字就是没有。口头承诺都是放屁。
没有给书面 offer ，没有签字，就当没有 offer 。

找工作面试，彼此都是撒网捞鱼。求职者可以同时联系多家公司，公司也可以同时面试多个求职者。那就不存在耽误时间。
哪家公司 offer 下得慢，人才被别人抢走了，那是自己吃亏。
同理，因为哪个公司 offer 出得慢就傻等，那也是自己吃亏。
既然自负盈亏，害也是害自己，那就没什么好说的。

@louisxxx 1. 你爱用就用，尊重，祝福。
有钱买两台服务器，没钱雇个运维，没时间学一下 zfs 。
2. 如果你的文件要走 nfs ，你的架构一定是有问题。储存分离不是我说的，IO 密集应用未必适合储存分离架构。
iscsi 性能并不差，rdma 性能也不差。前端做 access control 然后反代后端储存服务器，直接走 HTTP 代理的性能也不差。

@louisxxx #4
是可以啊，我哪句说过网络和虚拟化的事了？

问题是 truenas 上除了 zfs ，还有多少服务你知道吗？这些服务又有哪个可能有漏洞你知道吗？ truenas 的防火墙怎么配你知道吗？一个要往公网上暴露的服务器，你用 truenas 这么个 nas 操作系统，有什么必要？

按你说的，需求主要就是 raid5 和 nginx 。又不是只有 truenas 能跑 zfs 。你用 Debian 装个 zfs 和 Nginx 不也可以吗？

除了 zfs ，linux mdraid 也可以用。你这是静态 HTTP 服务器，不是储存后端，对外提供图片下载，而不需要上传或处理数据。如果需要，那你应该重写你的需求。
这个需求不需要多好的数据留存率，只需要在线率。文件数据从后台部署就行了，不管你是用 FTP 还是 rsync 还是什么，反正能把文件放上去就行。

最后，就算要走网络又怎么啦？输出还不是网络。内网带宽和延迟放到公网上都是不值一提。走 rdma 的话还真未必就比本地磁盘性能差多少。

没听说过用 truenas 做静态 Web 服务器的
如果你只是想要 zfs 的话，Debian/CentOS 一样可以装 zfs for linux

@wuwukai007 首先，proxy_pass 是这么用的吗？这么个四不像的 cgi ，还用 GPT ？
然后，你这样碰到不存在的文件不就死循环了吗？


@laters 路径 hash 配合 proxy pass 就好了
hash 值可以对半分，分到 1 或者 2 上
如果 1 服务器拿到 hash 1 的请求，那就本地处理，有就有，没有就是 404.
如果拿到 hash 2 的请求，那就 proxy pass 给 2 ，2 说有就是有。

缺点就是只有一半的请求可以本地处理。

-----

但是，按这个思路再进一步，说明你用的负载均衡错了。你用 4 层负载均衡当然就是随机分配。但是如果你用 7 层的负载均衡，比如 Nginx 或者 haproxy 之类的，本来就支持根据 URL hash 分流，也就不存在以上问题。

@Rorysky “存在即合理”这话是这个意思吗？
除了哲学讨论，平时说这句话的人，十个里有十个都不懂这句话是什么意思。
说难听点，按你这个理解方式，杀人犯都是无罪的。既然存在杀人犯，那他杀人就合理，对吧？

@zhhmax zfs 的 snapshot 可以具体到某个 dataset ，hyperv 的 snapshot 只能具体到某个虚拟盘。
我上面说的，所有服务走 iSCSI 访问 nas 储存，一样可以实现你说的效果
而且 windowes 的储存池就是玩票用，和 zfs 的历史比还差得远。zfs 真坏了还能找到数据恢复服务。Windows 储存池坏了找谁？

你让 Windows 去管理阵列，本质上就是拿 Windows 当 nas 系统用。Windows desktop 并不是合适的 nas 系统，不适合跑任何服务。除非用 Windows server 。

“那么硬盘出故障后，迟几分钟或者几天知道有何不可。不会有人搭建好 nas 从来不去系统看一眼就等系统监控发出邮件通知再去进系统查看吧”
smart 的作用就是提前预警而不是等硬盘坏了才反应。
明明能自动化的监控，却指望靠人力去解决。我三天两头还得专门去看一眼 nas ？我除了装系统就不会去看 nas 了。


#37 你用盗版你还有理了。
“这里绝对不讨论任何有关盗版软件、音乐、电影如何获得的问题”