给钱肯定还是要给的。

老人家自己有时间的话，自己在家做饭，不生病的话，花销没有那么大。

我爸妈都在五线城市生活，他们每月 2000 肯定够了，还有一部分是给小孩买零食的。

你看看你爸的花费，给个合适的金额。

> 结婚彩礼三金这些钱必须由我爸妈出,不然本来我们两个计划用来买房的钱

仔细分析这句话，这意思是彩礼你给了她，她是一分不会往小家庭带的，要不然怎么说没有买房的钱。

那彩礼钱不往小家庭带，那是给谁了呢。我觉得很大概率给他弟弟了，兄弟，这还没结婚呢，你已经在养他弟弟了。结了婚以后，且有罪受呢。

这不就是赚钱的意义吗？赚的钱不给孩子花，还想自己死了以后带进棺材啊。

python 中装饰器挺常见的，我发现给装饰器写个类型注解还是挺困难的。

主要的困难点在于，要求装饰器修饰的函数，类型要一致。多人开发的时候，这个保证有点难。

"不用 mac 的，注定只能度过一个相对失败的人生"

果粉也太逆天了吧，怎么能说出这种话。

您可能是正版音乐的受害者

https://i.imgur.com/bEfOCrm.png

https://m.weibo.cn/status/4156683695307365?mblogid=4156683695307365&luicode=20000061&lfid=4156683695307365

确实是你的问题.

打工人不一定能把每件工作都完成，做到了什么程度，什么进度，和相关人员同步，却是一种很重要的美德。

十几万的车是用来开的，50 万以上的车已经不是用来开的来，是用来装逼的。

放飞无人机这个，开出去装逼确实可以。

https://linkerd.io/2.14/features/load-balancing/

不同 pod 之间响应时间不同才是正常的情况吧。

linkerd 专门有个负载均衡算法叫做 EWMA, 根据 pod 的响应时间，提供不同的流量值。响应时间越快的 pod, 收到的请求也越多。我们实测过，这样整体 p99 会更好。

https://github.com/mosn/mosn/pull/2274

曾有人想把这个负载均衡算法在 envoy 中也实现一遍，可惜最后没 merge

有个类似情况是 tcp 连接在多个线程之间如何分配

https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

envoy 的博客中提到了，多个线程监听了一个端口之后，连接具体分配到哪个线程完全是内核决定的。内核的策略也不是平均分配的，而是尽量塞满一个线程，再往下一个线程分配。

As discussed briefly above, all worker threads listen on all listeners without any sharding. Thus, the kernel is used to intelligently dispatch accepted sockets to worker threads. Modern kernels in general are very good at this; they employ features such as IO priority boosting to attempt to fill up a thread’s work before starting to employ other threads that are also listening on the same socket, as well as not using a single spin-lock for processing each accept.

因为请求发送到同一个线程上，能最大程度地利用内存缓存和 cpu 缓存，这样从整体来看，性能是更好的。

error 没有栈信息，配合 pkg.errors 的 WithStack 使用，增加了开发者的心智负担。

例如以下调用链

func api()

func service()

func rpc()

api -> service -> rpc

rpc 返回了一个错误，一层一层最终返回给了 api, api 拿到错误后，需要记录日志，它想知道错误是哪里来的，此时就需要栈信息。

目前的解决办法，是 rpc 返回错误时，error 用 pkg.errors ( https://github.com/pkg/errors/blob/master/errors.go) 的 Wrap 包装一下，service 包装时，就不能用 wrap 了，需要用 WithMessage ，要不然会出现两份栈信息。

这要求开发者对代码的层次结构非常清楚，哪些函数是最底层，哪些是上层。

你想想，你刚接手了一个 5w 行的项目，读了三天代码之后开始写一些小 feature 。这时候你能了解清楚哪些函数是最底层吗？这样很容易就写错了，然后错误信息里面可能就有 N 份栈信息。

c 提供 2.0 版本

a 依赖 c 的 1.0 版本
b 依赖 c 的 2.0 版本

golang 中只有大版本变了，才允许多版本共存。

小版本不同的话，取最小版本

曾经百度空间也是很好的网站，但越做越差，最后下线了。气的某个安全大佬想找那个产品经理当面对线。

我在 14 ，15 年使用 CSDN 的时候，它也是算是很好的博客，有很多高质量的文章，基本没有广告。

经历过这些之后，我在也不相信第三方的博客了，谁也不能保证这样的网站能存活 50 年以上。

我的博客都是用 hugo+git 存储的，就算 github 黄了，买个服务器，搞个 nginx 很容易就起来了。缺点就是评论是存在 github 的 issue 中的，github 黄了，这些评论也没了。

我想起别人给我讲的趣事。

某公司在新加坡和深圳都有分部，深圳的人把活抢过来干了。

新加坡那边的人想看文档，发现只有中文的。就要求写英文的。

深圳这边的人直接回怼，you should learn some chinese.