其实没有什么秘密，也没有什么道德，你觉得不能说的只是有些东西让你觉得不能说比较好，而后你就遵循着这种不知道哪里来的道德感活到现在。

不外乎优化一下模型，就是懒得弄而已，以后编不下去了加个 if 就是个卖点

老板之所以当老板是因为它想当老板挣钱，它干一样的活挣得和你工人一样怎么可以？
反过来你当工人通过互联网得到的产业发展信息比老板还多，还教它不要裁员了，它还怎么挣你的钱？

@Puteulanus 目前是这么解决的，但还是麻烦，另外如果同时能得到两个下载地址相当于镜像可能能更快一点

如果领导要见你第二次绝对不会因为你能喝酒，只能见一次的领导喝成猴子也没用。在自己熟悉的舞台上跳舞，机会太多了，把握不了的机会留给别人

在 docker 里面跑 frp 然后 docker run --restart=always

感觉什么东西做久了都不易被替代，但不一定给你加薪。找工作和学技能还是用工资来拟合比按技能拟合方便。

实际上脑子跟不上手，发现在平板上用笔戳键盘一天能推进的进度比坐电脑前用手打还多

感谢各位，暂时用 rar a -m1 -ol -mt4 -ms'gz' -rr1 target.rar sourcefolder 这个代码压到硬盘，看解不出来再用别的方法。感觉用 Btrfs 做系统，rar 的 rr ，或者压缩后分卷计算特征码并对每卷做 par2 都是可行的。

@JohnBull 两个服务器间没网，只是复制到硬盘 rsync 和 CP 一样吧。

就原服务器空间不够，不能原位压缩再转移压缩完的文件。如果能在解压缩时用较短的时间判断完整性，出错的话只处理错误的部分文件就最好了，也避免中间低质量硬盘长时间多次读写增加额外的问题。

@wizardyhnr 看着不错，下次试试

@liaohongxing 就是两个机房的服务器数据转移，背面板供电应该足的，公共设备可能是 USB 线拉扯或硬盘随机质量问题，也没条件插额外电源

@lucifer9 这样按总文件分包是不是坏一个文件所有压缩包全坏的？我想最好是按文件逻辑分包，如果坏了就只需要重新处理坏掉的部分。感觉就是 find 先列出所有文件在外面安排好再分批压缩，但不知道有没有更简单的方法

@Android9487 暂时只能在 ntfs 上，rsync 感觉也解决不了复制过程中硬件问题产生的这种随机问题。

@flynaj 谢谢，我看看 linux 下 RAR 能不能带恢复记录

另外一个想法是 tar 压缩时以完整文件为单位分成多个压缩文件可能比压成整个大文件错误恢复时简单一些，不知道有没有现成的轮子。
还有就是总觉的这种硬盘长时间写入会不稳定，因为中间有压缩，让系统管理缓存的话磁盘会一直低速地写入，感觉应该每缓存 1G 左右后整体写入，也不知道这样有没有轮子用

在网卡前面接个自己的路由？

感觉 frp 的 mux 慢是算法的问题

pyinstaller 打包在 import 时可能要具体到函数，用 form requests import get, res = get('https://www.baidu.com', proxies={"http": "socks5://127.0.0.1:5500", "https": "socks5://127.0.0.1:5500"}) 可能就行了

后面 ai 应用方面估计会需求一堆人，不如买套动捕 vtb 出道

这是防谁？ linux 用 ext4 windows 根本挂载不上去；反过来一样的。怕格式化的话两边系统权限卡一下不给用户挂载硬盘权限不一样的