接上，可能简单但是更有效的做法就是看同样喜欢一本书的书友还看什么书，有些推荐系统就是这样的。但是这个就不需要人工智能了。

我觉得没那么简单。有时候喜欢的书就是那种感觉，连我自己都不知道，又或者一本书我喜欢的可能就几个点，你让程序来跑他咋知道哪几个点是我喜欢的？比如说修仙四万年，这是唯一一本我看的修仙文，问题是他其实又不是典型的修仙文。

当然也许目前人工智能可以帮忙筛选就是了。也算是有点用。

目前没啥问题，连续用了两个多礼拜没关机。

@Higurashi 多谢，我试试看

@wolfie 7 楼 其实我觉得，如果比较严格实行 8 小时工作日的话，改成 4*9 未尝不可。

我现在也觉得多一天能好一些，倒不是说多休息一天，而是立刻就有一天能够处理比如 ZF 、医疗、保险这些只有工作日才能处理的事情。但是这也取决于其他机构是否也是 4 天工作制，如果大家都是那对我来说意义就仅限于多一天可以做点自己的事情了，而在有娃有家庭的大背景下这也是有一定意义的。

@dudubaba 大概退休后还有可能

想写底层的东西，比如专心下去研究操作系统等等，奈何没这能力和耐心。主要还是精力不足，精力不足带动耐心不足，恶性循环。

等到我这个岁数，时间就走的更快了。。。

可能要安装地毯，一层不行装两层。该做的都做了就行了。还有就是尽量多带出去发泄精力，什么小区下面让他运动一下晚上能消停不少。

@GeruzoniAnsasu 多谢，果然基础知识重要

@GeruzoniAnsasu 多谢分享，求问这些知识哪里能系统学习到？比方说文件系统 api ，ip 的数据结构，以及 mmap 和之后说的各种优化？

直播打老游戏，选一个类别全部打

实时渲染估计也蛮难的，怎么个实时法。我个人还是比较喜欢分开来，但是合体的就他家做的最舒服。此外他家支持的语法也多。

@Macolor21 也是，看来还是冲突最麻烦。那么是否应该尽量从项目架构上去避免冲突？比如说尽量避免多人修改同一个文件的情况出现？虽然未必现实。。。

@Macolor21 #12
新手求问，如果能够让每个 feature branch 在合并之前都自动进行 rebase ，是好是坏？

@jsq2627 求问一下这样是否可行？

假如某 feature 需要多人共同开发，于是事先约定大家新建、改动什么文件，保证不会互相干扰，于是从 main 分出 feature_branch ，并又分成多个个人的 feature_individual_branch ，最后开发完成之后合并进 feature_branch ，如何？

如果互相之间有干扰，比如说有个配置文件多人需要共同编辑，那看来只能指认其中一人为 feature reviewer ，把这些共同的文件承担下来了。

我之前恰好看过几篇文章，似乎是推荐先 rebase

休息吧，我感觉我这五六年都没有真正休息过，想休息也没机会休息了。