我更好奇的是 鉴于用 linux 本身就是为了熟悉服务器环境，结果你推荐别人去用一个服务器上都很少用的发行版 ( arch / manjaro )，这究竟是在想什么

印象派

鉴于你对抖音受众群的描述，你完全可以给黑猩猩做个短视频 app，里面就放一些 “如何快速摘香蕉” “如何打洞” 等（全世界）黑猩猩普遍不反感的内容，匹配上下滑动的交互 + 算法推荐，在黑猩猩物种里一炮而红。然后给下一个物种也可以这样，用于驯服这些物种

可以不会 solution，但要会评估 feasibility （和买个 solution 该出的价格）

竞争对手派来的卧底？

公司出电脑
公司装系统
公司出软件
你就是个键盘操作员
你失去了电脑主权
公司避免招惹商业软件官司

https://cn.nikkei.com/politicsaeconomy/politicsasociety/46128-2021-09-22-10-06-04.html
日本 65 岁以上老人创新高，1/4 仍在工作

@hxy100 #25 在中国 MIT 协议是没有法律威摄力的，而版权是受到中国版权法保护，虽然法律威摄力也很低，但比没有好。在嫖客视角下，MIT 协议的实际意义对嫖客太友好了，所以 you 需要在拿 MIT 协议吸引嫖客给出的美誉度的基础上增加第二层保护，意义是以版权法（的威摄力）去专治一小部分嫖得太过分的嫖客。

版权专治白嫖客，自然不会受到嫖客喜欢：因为它是一种能量，专门恶心你这种人

MIT 只是一层保护
你对你自己的东西可以追加第二层保护。MIT 协议并未禁止你打着 MIT 的旗号做着 非 MIT 倡导的事

如果是本地人好一点

可以

@nadia #143
H&M 店家是因为遇到等待试衣服的太多的情况，店里的试衣间不够用，所以才鼓励消费者别试了 赶紧下单，出店

等待试衣，这是消费者成本，但若试了不好再来退，有的消费者会退，有的消费者不会退；选择退货的消费者还要承担退货成本，其中有的人权衡之后会决定即使不合适 也算了不会退货。结果就是下次一定会试衣服试好再买。

增加试衣间，可以疏通人满为患的等待试衣服的情况 解决这个问题，但这是店家成本，有的店家会增加试衣间，有的店家不会增加试衣间（也就是不觉得这是需要解决的问题）反而大力鼓励消费者别试了 赶紧下单，出店

在相对和平的环境里
尊重女性
帮助弱小
绅士风度
给人台阶下
但并不虚伪

系统学习西方中世纪骑士精神

二手卖掉

它对蛋来说不是问题
它对鸡来说不是问题
它为什么对你来说要是个问题？

“次数多了分支线就很乱，怎么办”，如果关注的问题是这个，那么就你需要先列出你操作的分支名，然后会走向两种解决方式：
1 增加分支，**增加一个分支作为 ‘缓存分支’ **，即改变分支策略
2 分支不变，改变 merge 命令

如果是办法 1，那么解决办法会非常简单，你会把 ‘造成分支错乱’ 归因为提交错了分支线。

如果你需要前后三次提交（或无数次提交），将会导致分支错乱的原因是 你只有 2 个分支，自己的 branch -> main branch，这样 main branch 会很快被写入；将会导致分支清晰的原因是 你现在有 3 个分支，自己的 branch -> develop 分支 -> main branch 。这样因为多了一个分支，所以 develop 分支仍然会很乱（ develop 分支是 ‘缓存分支’，等于为 main branch 作了缓存），故而 main branch 会保持清晰。

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow 图示
https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests

如果是办法 2，那么，哈哈 ... 这根本不是 merge 命令的问题 ... 你需要重新归因，而不是拿出某个命令来就用。实际上它是 pull request 策略的问题，而不是 merge 策略的问题。它是人员责任划分的问题，不是 git 的问题：是责任划分来指导 pull request 策略和具体 git 操作，而不是相反。相反只有颠覆，而且是盲从般的颠覆

为什么 ‘包含完整的提交历史记录’ 会是一个需要避免的问题？ 你瞎搞之后丢记录了怎么办 行为艺术吗