想知道谁在裸泳吗?
饿了么走进历史：9个印象深刻的片段
今天饿了么App升级后，品牌名彻底没了，变成了淘宝闪购，App内已经几乎找不到饿了么的痕迹了。
陪伴这一代年轻人整整16年，比微信还要早3年的饿了么，变成历史的一部分，接力棒递给了淘宝闪购。今天就聊几个我对饿了么印象深刻的片段。
1、2009年，饿了么诞生于上交大，张旭豪深夜打实况足球，饿了，深夜打电话叫外卖，要么不接，要么不送，于是起心动念，决定做一个外卖网站。
2、饿了么属于PC时代的创业，早期采用的是极为原始的电话订餐+上门收钱+人工与餐厅对账结算的模式，2010年上线了Napos后台系统，餐厅可以通过这套系统管理订单，当时的商业模式是收取佣金和Napos的服务费。
3、为了推广系统绑定商家，因为当时很多餐馆都没有电脑，饿了么不得不二手市场批发廉价台式机，帮老板拉网线、装电脑。被戏称看似是送外卖的，背地里其实是“闵行区最大的二手电脑IT服务商”。
4、饿了么的域名是ele.me，这个域名让我想起了ofo小黄车的官方域名ofo.so，都是校园创业的典型。me是黑山的国家域名，so是索马里的国家域名，虽然很有趣，但都是不入流的域名后缀。
5、类似于扎克伯格的facemash，饿了么也是第一代“增长黑客”，早期为了在交大推广，直接破译了交大BBS论坛的代码，给论坛所有人自动发“站内信”推广，结果被BBS站长全站封杀，屏蔽了“饿了么”三个字。不过这件事也是反向营销，让全校都知道了有一个“被封杀的订餐网站”。
6、2014年，饿了么拿了大众点评8000万美元投资，结果2015年大众点评就和美团合并了，“盟友”突然变成了“最大的敌人”。
7、美团决定做外卖前，一度想的是“直接投饿了么”，但是美团抓取饿了么的数据，对饿了么进去的12个城市的订单量加以排序，发现排名前四的分别是上海、北京、广州和杭州，但是第5名却是福州。
因为福州在中国城市消费排名大概在30名左右，美团由此反向推导出一个关联性结论：“饿了么起码有25个城市都没做好”，这些都是美团的机会，于是美团果断切入外卖市场。这才是真正牛x的数据洞见啊。
8、外卖三国杀的时候，据说百度外卖其实是技术最强的，但因为战略失误，想要做高端白领，不做学生市场，迅速掉队，最后被饿了么5亿美金收购。
饿了么最看重百度的，据说是百度外卖的调度算法代码，对后来饿了么提升配送效率起了关键作用。另外美团王莆中原来就是百度外卖的，据说堪称1号员工。
9、2018年4年，阿里巴巴宣布95亿美金收购饿了么，是中国互联网历史上最大的一笔全现金收购案，至今未被打破。
美团当时对外透风，如果阿里不收，自己可能和饿了么合并，这帮助饿了么顺利卖出了95亿美金的天价，扶上马送一程，还是有感情的。
by @林氪 #科技圈大小事
今天饿了么App升级后，品牌名彻底没了，变成了淘宝闪购，App内已经几乎找不到饿了么的痕迹了。
陪伴这一代年轻人整整16年，比微信还要早3年的饿了么，变成历史的一部分，接力棒递给了淘宝闪购。今天就聊几个我对饿了么印象深刻的片段。
1、2009年，饿了么诞生于上交大，张旭豪深夜打实况足球，饿了，深夜打电话叫外卖，要么不接，要么不送，于是起心动念，决定做一个外卖网站。
2、饿了么属于PC时代的创业，早期采用的是极为原始的电话订餐+上门收钱+人工与餐厅对账结算的模式，2010年上线了Napos后台系统，餐厅可以通过这套系统管理订单，当时的商业模式是收取佣金和Napos的服务费。
3、为了推广系统绑定商家，因为当时很多餐馆都没有电脑，饿了么不得不二手市场批发廉价台式机，帮老板拉网线、装电脑。被戏称看似是送外卖的，背地里其实是“闵行区最大的二手电脑IT服务商”。
4、饿了么的域名是ele.me，这个域名让我想起了ofo小黄车的官方域名ofo.so，都是校园创业的典型。me是黑山的国家域名，so是索马里的国家域名，虽然很有趣，但都是不入流的域名后缀。
5、类似于扎克伯格的facemash，饿了么也是第一代“增长黑客”，早期为了在交大推广，直接破译了交大BBS论坛的代码，给论坛所有人自动发“站内信”推广，结果被BBS站长全站封杀，屏蔽了“饿了么”三个字。不过这件事也是反向营销，让全校都知道了有一个“被封杀的订餐网站”。
6、2014年，饿了么拿了大众点评8000万美元投资，结果2015年大众点评就和美团合并了，“盟友”突然变成了“最大的敌人”。
7、美团决定做外卖前，一度想的是“直接投饿了么”，但是美团抓取饿了么的数据，对饿了么进去的12个城市的订单量加以排序，发现排名前四的分别是上海、北京、广州和杭州，但是第5名却是福州。
因为福州在中国城市消费排名大概在30名左右，美团由此反向推导出一个关联性结论：“饿了么起码有25个城市都没做好”，这些都是美团的机会，于是美团果断切入外卖市场。这才是真正牛x的数据洞见啊。
8、外卖三国杀的时候，据说百度外卖其实是技术最强的，但因为战略失误，想要做高端白领，不做学生市场，迅速掉队，最后被饿了么5亿美金收购。
饿了么最看重百度的，据说是百度外卖的调度算法代码，对后来饿了么提升配送效率起了关键作用。另外美团王莆中原来就是百度外卖的，据说堪称1号员工。
9、2018年4年，阿里巴巴宣布95亿美金收购饿了么，是中国互联网历史上最大的一笔全现金收购案，至今未被打破。
美团当时对外透风，如果阿里不收，自己可能和饿了么合并，这帮助饿了么顺利卖出了95亿美金的天价，扶上马送一程，还是有感情的。
by @林氪 #科技圈大小事
连带着阿里前几天发布的同期财报，说说美团Q3财报的信息。
如果你们还记得，美团发布Q2财报时我也用了「血流成河」来做锐评——后来还被删了——我当时就说，Q2其实还没完全打起来，阿里真正入场是在7月之后，所以和Q3的预期值相比，Q2根本不能算惨。
美团的Q2利润大降89%，看起来很可怕，但至少还是正的，只不过少赚了100多亿，Q3直接由盈转亏，净亏160亿。
比较讽刺的是，因为市场已经很悲观了，预期亏损值在170亿到190亿之间，这个数字反而算是相对偏好的了。
但真正的问题还是出在营收没太大变化，2%的增长在互联网行业几乎等于停滞了，相当于美团掏光了家底，只能勉强守住自己的一亩三分地，维持住同样的市场规模，以前需要的成本和现在需要的成本，已是天人永隔。
说得更细一点，就是UE（每单经济模型）的结构性恶化，一通补贴大战的操作下来，单量越多，亏损越大，有点坟头蹦迪的味道，你们在夏天喝的哪里是奶茶，吸管明明插在美团的血袋里。
阿里的战损比——Q3亏掉差不多360亿——实际更高，但阿里的叙事要比美团「守住地盘」要好看许多，比如帮助淘宝的DAU反超拼多多就很符合市值管理的玩法。
而且阿里比美团要早一步调整UE，几个月前就放风说要从9月开始干预订单质量，这是什么意思呢，就是这场仗要怎么打、什么时候打、什么时候停，全都由阿里来决定，美团只能接团，无权开团。
🍠那边阿里的口碑似乎很差，每次列数据谈事实，都会有人觉得我是在踩美团，但说实话，美团确实需要创造亮点，否则真的没办法找到角度挽尊了，何况我平均每年在美团消费6位数，是美团靠我恰饭的，谢谢。
最关键的是，从核心本地商业（外卖+到店）的收入来看，美团Q3是674亿，同比甚至是下降了3%左右，前面说了，外卖算是守住了，那也应该是同步总体的微增趋势啊，怎么会下降的？
答案是到店业务这块被抖音偷家了⋯⋯抖音这老头子是真坏得很，趁美团在外卖业务上抗压的功夫，把到店团购吃得干干净净，今年预计是60%的增长，来到8000亿的成交额，可以参照的是，美团到店业务去年是1万亿。
只能说明枪易躲，暗箭难防，投资者社区都在等美团利空出尽，我也希望它能重振旗鼓，前几天在北京搞的低租金骑手公寓还挺不错的，但业绩才是最厚重的压舱石。
What does not kill me, makes me stronger.
by @阑夕ོ #科技圈大小事
如果你们还记得，美团发布Q2财报时我也用了「血流成河」来做锐评——后来还被删了——我当时就说，Q2其实还没完全打起来，阿里真正入场是在7月之后，所以和Q3的预期值相比，Q2根本不能算惨。
美团的Q2利润大降89%，看起来很可怕，但至少还是正的，只不过少赚了100多亿，Q3直接由盈转亏，净亏160亿。
比较讽刺的是，因为市场已经很悲观了，预期亏损值在170亿到190亿之间，这个数字反而算是相对偏好的了。
但真正的问题还是出在营收没太大变化，2%的增长在互联网行业几乎等于停滞了，相当于美团掏光了家底，只能勉强守住自己的一亩三分地，维持住同样的市场规模，以前需要的成本和现在需要的成本，已是天人永隔。
说得更细一点，就是UE（每单经济模型）的结构性恶化，一通补贴大战的操作下来，单量越多，亏损越大，有点坟头蹦迪的味道，你们在夏天喝的哪里是奶茶，吸管明明插在美团的血袋里。
阿里的战损比——Q3亏掉差不多360亿——实际更高，但阿里的叙事要比美团「守住地盘」要好看许多，比如帮助淘宝的DAU反超拼多多就很符合市值管理的玩法。
而且阿里比美团要早一步调整UE，几个月前就放风说要从9月开始干预订单质量，这是什么意思呢，就是这场仗要怎么打、什么时候打、什么时候停，全都由阿里来决定，美团只能接团，无权开团。
🍠那边阿里的口碑似乎很差，每次列数据谈事实，都会有人觉得我是在踩美团，但说实话，美团确实需要创造亮点，否则真的没办法找到角度挽尊了，何况我平均每年在美团消费6位数，是美团靠我恰饭的，谢谢。
最关键的是，从核心本地商业（外卖+到店）的收入来看，美团Q3是674亿，同比甚至是下降了3%左右，前面说了，外卖算是守住了，那也应该是同步总体的微增趋势啊，怎么会下降的？
答案是到店业务这块被抖音偷家了⋯⋯抖音这老头子是真坏得很，趁美团在外卖业务上抗压的功夫，把到店团购吃得干干净净，今年预计是60%的增长，来到8000亿的成交额，可以参照的是，美团到店业务去年是1万亿。
只能说明枪易躲，暗箭难防，投资者社区都在等美团利空出尽，我也希望它能重振旗鼓，前几天在北京搞的低租金骑手公寓还挺不错的，但业绩才是最厚重的压舱石。
What does not kill me, makes me stronger.
by @阑夕ོ #科技圈大小事
作为一贯看好美团的人，我感觉美团这次，可能真的危险了……
过去几年，我聊过200多个在美团工作过的朋友。
基于此，我一直是坚定看好美团的。比如，在抖音开始做本地生活，又做团购、又做外卖时，大多数人都觉得美团打不过，我也仍然看好美团。
为什么呢？
两个原因——
一是，字节只能做好团购，不可能做好外卖。
团购本质上是个广告业务。团购的模式是：商家上优惠、平台给流量、用户去商家兑现服务。
广告业务，是个链条很短的业务，实话说，复杂度没那么高。
谁有流量，谁就能做好广告。
拼流量，美团怎么可能拼得过抖音。
但是，外卖本质上可不是广告业务，更像是个服务型业务。
要做好外卖，除了要有流量、有商家，还要有骑手、管好骑手。
怎么分配订单？
怎么帮助骑手路线规划更合理？
怎么准确预测订单合理的配送时间？
怎么激励骑手？
怎么培训骑手？
这些问题都解决好，才能让用户在合理的时间收到外卖。
而要把这些问题解决好，需要的是漫长时间累积的系统开发、从上到下的管理体系、一批熟悉了整套体系的管理者。
这些积累，决定了美团在外卖业务上，会有远比其他企业更高的管理效率，而且任何人都难以在短时间内追上。
这是长链条业务的特点。
而字节，又是一个一直做短链条业务的公司，不可能有做好外卖这么个又复杂、又不挣钱业务的耐心。
所以，字节只能做好团购，不可能做好外卖。
第二个原因，则是团购对美团没那么重要。
美团主要的流量、大多数用户的使用习惯，还是来自外卖。
团购对于美团，虽然贡献了大量的利润，但是，美团也有其他的利润来源。
只要外卖的市场地位不被动摇，流量在、用户心智在，美团的市场地位就不会被动摇。
有流量，钱早晚有办法挣回来。
但是，
这次当阿里开始认真做外卖时，我对美团没有那么乐观了。
虽然乍一看，阿里不是第一次做外卖。
此前在外卖、社区团购等业务上，阿里一次次输给美团。
饿了么和美团打了那么多年，一直是万年老二。
甚至我怀疑，是美团希望饿了么活下去，才没有把饿了么彻底挤出市场。
因为，
在做外卖这个长链条业务上，阿里的管理效率、团队的执行力，同样拼不过美团。
当饿了么在管理效率上追不上美团时，也就意味着，双方抢规模时，如果要拿到同样的规模，饿了么的代价会比美团更大。
要获取和维持同样的规模，如果美团挣钱，饿了么很可能不挣钱。
如果美团选择不挣钱，那么饿了么注定赔钱。
对于外卖业务来说，需要持续赔钱才能拿到和守住的规模，是不会得到集团支持的。
可是这一次，阿里做外卖的目的和计算的方式，变了。
在一个多月前，我看到了一份关于阿里此刻如何思考外卖业务的材料。
里面让我印象深刻的是一个观点：
阿里这次做外卖，不仅在抢市场阶段可以亏钱，未来还可以持续亏钱。
因为这次阿里看的，并不是外卖业务本身的盈利情况。
阿里看的是外卖与电商的协同价值。
协同价值是什么意思呢？
简单说来，就比如：靠着外卖的服务，淘宝的日活每天增加了500万人。
这500万人，虽然是为了叫外卖来淘宝的。
但是既然来了，可能会再买个衣服、买个零食。
这些是如果没有外卖，用户很可能就不会发生的下单行为。
所以，外卖业务很可能会提高用户在淘宝电商的交易额。
这些交易，会为淘宝带来额外的收入。
这个时候，即便外卖业务本身是一直亏钱的，只要外卖业务亏的钱，少于为电商带来的额外收入，做外卖在阿里就是个划算的决策。
外卖业务就可以一直亏钱。
对美团来说，这是前所未有的危险信号：
此前所有人做外卖，都要和美团拼效率。
美团靠着严格的管理、方法论的沉淀，实现的管理效率，在互联网企业中很少有人能与其竞争。
而这一次，阿里与美团的竞争，因为有与电商的协同价值，效率上居然可以输。
只要接受在效率上可以输，游戏的规则就变了。
阿里要做好外卖，并不需要追平美团的效率——这也是几乎不可能完成的任务。
阿里只要让自己和美团的效率差距，缩小到一定范围内即可。
只是缩小差距，就没那么难了。
而一旦阿里成功，对于美团来说，会失去的不仅仅是外卖的市场份额，更是支撑了自己其他变现业务的主要流量来源。
此刻，我了解到，阿里正在做两件事：
第一，
阿里正在通过实验，测算外卖带来的日活，到底能为电商带来多少额外的交易和收入。
不知道你们有没有同样的感觉：
这次的双十一，在淘金币里，有大量动作是在尝试促使用户在外卖和电商之间流转。
这既是对外卖业务的扶持，也是阿里测算协同价值的需要。
第二，
阿里也在以前所未有的力度，提高自己的管理效率。
就拿对外卖与电商之间协同价值的测算为例吧。
此前，
阿里的测算业务价值方式，基本上靠“讲故事”。
只要一个用户，叫了外卖、又在电商多下了单，就可能被外卖团队算作自己给电商带来的增量。
但是很可能这个人多下单，是因为有更多需求、或者到了双十一。
而只要度量效果的方式，由团队自己定义，对于团队来说，讲故事永远会比实打实做业绩划算，管理效率也就无从提升。
而这一次，
在测算外卖与电商之间的协同价值时，阿里做了严格的AB测试。
有一部分随机的用户，看不到任何外卖的入口和活动。
他们的订单，会与其他能看到外卖的入口、活动的用户，做严格的对比。
去比较——有外卖和没外卖，电商订单到底能增加多少。
能够准确的度量效果、评价团队，是管理效率提升的第一步。
当阿里看清楚外卖与电商的协同价值。
当阿里找到执行路径，可以将自己的管理效率与美团的差距，缩小到小于协同价值的范围内。
对于美团来说，被阿里渐渐夺走外卖的市场，几乎是注定的结果。
因为，阿里基于电商协同价值发起的进攻方向，是美团无法防守的角度。
企业与企业之间有效的竞争，通常不是硬拼效率、硬拼预算，你花10亿、我要花20亿。
而是找到自己的优势。
看清楚自己有什么、对手没有什么。
基于此，找到最有利于自己的进攻方向，发起一场对手无法防御的进攻。
by @于冬琪 #你不知道的行业内幕
过去几年，我聊过200多个在美团工作过的朋友。
基于此，我一直是坚定看好美团的。比如，在抖音开始做本地生活，又做团购、又做外卖时，大多数人都觉得美团打不过，我也仍然看好美团。
为什么呢？
两个原因——
一是，字节只能做好团购，不可能做好外卖。
团购本质上是个广告业务。团购的模式是：商家上优惠、平台给流量、用户去商家兑现服务。
广告业务，是个链条很短的业务，实话说，复杂度没那么高。
谁有流量，谁就能做好广告。
拼流量，美团怎么可能拼得过抖音。
但是，外卖本质上可不是广告业务，更像是个服务型业务。
要做好外卖，除了要有流量、有商家，还要有骑手、管好骑手。
怎么分配订单？
怎么帮助骑手路线规划更合理？
怎么准确预测订单合理的配送时间？
怎么激励骑手？
怎么培训骑手？
这些问题都解决好，才能让用户在合理的时间收到外卖。
而要把这些问题解决好，需要的是漫长时间累积的系统开发、从上到下的管理体系、一批熟悉了整套体系的管理者。
这些积累，决定了美团在外卖业务上，会有远比其他企业更高的管理效率，而且任何人都难以在短时间内追上。
这是长链条业务的特点。
而字节，又是一个一直做短链条业务的公司，不可能有做好外卖这么个又复杂、又不挣钱业务的耐心。
所以，字节只能做好团购，不可能做好外卖。
第二个原因，则是团购对美团没那么重要。
美团主要的流量、大多数用户的使用习惯，还是来自外卖。
团购对于美团，虽然贡献了大量的利润，但是，美团也有其他的利润来源。
只要外卖的市场地位不被动摇，流量在、用户心智在，美团的市场地位就不会被动摇。
有流量，钱早晚有办法挣回来。
但是，
这次当阿里开始认真做外卖时，我对美团没有那么乐观了。
虽然乍一看，阿里不是第一次做外卖。
此前在外卖、社区团购等业务上，阿里一次次输给美团。
饿了么和美团打了那么多年，一直是万年老二。
甚至我怀疑，是美团希望饿了么活下去，才没有把饿了么彻底挤出市场。
因为，
在做外卖这个长链条业务上，阿里的管理效率、团队的执行力，同样拼不过美团。
当饿了么在管理效率上追不上美团时，也就意味着，双方抢规模时，如果要拿到同样的规模，饿了么的代价会比美团更大。
要获取和维持同样的规模，如果美团挣钱，饿了么很可能不挣钱。
如果美团选择不挣钱，那么饿了么注定赔钱。
对于外卖业务来说，需要持续赔钱才能拿到和守住的规模，是不会得到集团支持的。
可是这一次，阿里做外卖的目的和计算的方式，变了。
在一个多月前，我看到了一份关于阿里此刻如何思考外卖业务的材料。
里面让我印象深刻的是一个观点：
阿里这次做外卖，不仅在抢市场阶段可以亏钱，未来还可以持续亏钱。
因为这次阿里看的，并不是外卖业务本身的盈利情况。
阿里看的是外卖与电商的协同价值。
协同价值是什么意思呢？
简单说来，就比如：靠着外卖的服务，淘宝的日活每天增加了500万人。
这500万人，虽然是为了叫外卖来淘宝的。
但是既然来了，可能会再买个衣服、买个零食。
这些是如果没有外卖，用户很可能就不会发生的下单行为。
所以，外卖业务很可能会提高用户在淘宝电商的交易额。
这些交易，会为淘宝带来额外的收入。
这个时候，即便外卖业务本身是一直亏钱的，只要外卖业务亏的钱，少于为电商带来的额外收入，做外卖在阿里就是个划算的决策。
外卖业务就可以一直亏钱。
对美团来说，这是前所未有的危险信号：
此前所有人做外卖，都要和美团拼效率。
美团靠着严格的管理、方法论的沉淀，实现的管理效率，在互联网企业中很少有人能与其竞争。
而这一次，阿里与美团的竞争，因为有与电商的协同价值，效率上居然可以输。
只要接受在效率上可以输，游戏的规则就变了。
阿里要做好外卖，并不需要追平美团的效率——这也是几乎不可能完成的任务。
阿里只要让自己和美团的效率差距，缩小到一定范围内即可。
只是缩小差距，就没那么难了。
而一旦阿里成功，对于美团来说，会失去的不仅仅是外卖的市场份额，更是支撑了自己其他变现业务的主要流量来源。
此刻，我了解到，阿里正在做两件事：
第一，
阿里正在通过实验，测算外卖带来的日活，到底能为电商带来多少额外的交易和收入。
不知道你们有没有同样的感觉：
这次的双十一，在淘金币里，有大量动作是在尝试促使用户在外卖和电商之间流转。
这既是对外卖业务的扶持，也是阿里测算协同价值的需要。
第二，
阿里也在以前所未有的力度，提高自己的管理效率。
就拿对外卖与电商之间协同价值的测算为例吧。
此前，
阿里的测算业务价值方式，基本上靠“讲故事”。
只要一个用户，叫了外卖、又在电商多下了单，就可能被外卖团队算作自己给电商带来的增量。
但是很可能这个人多下单，是因为有更多需求、或者到了双十一。
而只要度量效果的方式，由团队自己定义，对于团队来说，讲故事永远会比实打实做业绩划算，管理效率也就无从提升。
而这一次，
在测算外卖与电商之间的协同价值时，阿里做了严格的AB测试。
有一部分随机的用户，看不到任何外卖的入口和活动。
他们的订单，会与其他能看到外卖的入口、活动的用户，做严格的对比。
去比较——有外卖和没外卖，电商订单到底能增加多少。
能够准确的度量效果、评价团队，是管理效率提升的第一步。
当阿里看清楚外卖与电商的协同价值。
当阿里找到执行路径，可以将自己的管理效率与美团的差距，缩小到小于协同价值的范围内。
对于美团来说，被阿里渐渐夺走外卖的市场，几乎是注定的结果。
因为，阿里基于电商协同价值发起的进攻方向，是美团无法防守的角度。
企业与企业之间有效的竞争，通常不是硬拼效率、硬拼预算，你花10亿、我要花20亿。
而是找到自己的优势。
看清楚自己有什么、对手没有什么。
基于此，找到最有利于自己的进攻方向，发起一场对手无法防御的进攻。
by @于冬琪 #你不知道的行业内幕
开始补税了。
补电商店铺的税，是这样的，从今年的第三季度开始，就是追缴。
但是不排除有可能税务局会倒查全年的，地方政策不一样，有的可能要补全年。
比如说大的电商平台，淘宝京东拼多多抖音微信，平台的销售数据会直接关联到税务平台。比方说你这个月卖了50万，客户只开了10万的票，但是平台是直接把这50万这个数据推送到了税务局的，那你就要补这40万的税，而不是开票的10万。
具体后面影响会怎么样，会不会影响电商平台的价格，暂时还是未知的。
但是往后线上线下不同价的局面可能会渐渐发生变化了。
朋友在义乌做电商，早上通电话说财务正在核查，他的公司大概要补200多万。
我倒是看到了几个方面：
1.纳税是必然，也是义务，时代的红利不可能一直有
2.地方财政真的很缺钱
3.反一味的线上价格内卷
4.不管是线上还是线下，除非做到头部或者超级Ip，生意就是越来越难做
by @浅仓南2010 #你不知道的行业内幕
补电商店铺的税，是这样的，从今年的第三季度开始，就是追缴。
但是不排除有可能税务局会倒查全年的，地方政策不一样，有的可能要补全年。
比如说大的电商平台，淘宝京东拼多多抖音微信，平台的销售数据会直接关联到税务平台。比方说你这个月卖了50万，客户只开了10万的票，但是平台是直接把这50万这个数据推送到了税务局的，那你就要补这40万的税，而不是开票的10万。
具体后面影响会怎么样，会不会影响电商平台的价格，暂时还是未知的。
但是往后线上线下不同价的局面可能会渐渐发生变化了。
朋友在义乌做电商，早上通电话说财务正在核查，他的公司大概要补200多万。
我倒是看到了几个方面：
1.纳税是必然，也是义务，时代的红利不可能一直有
2.地方财政真的很缺钱
3.反一味的线上价格内卷
4.不管是线上还是线下，除非做到头部或者超级Ip，生意就是越来越难做
by @浅仓南2010 #你不知道的行业内幕
用 LLM 写代码对架构清晰和代码质量的要求其实更高，因为 LLM 不是你的脑子，他不知道现在的架构里面有哪些坑，没有那些 Context，在短上下文的情况下一个歪掉的塔只会越盖越歪。
比如你的系统里面有一坨 legacy 导致了两条 parallel 实现，LLM 搞不清楚该在哪条上继续开发，就会变成一会在 legacy 上雕花一会去在正常流程上堆料，最后一团混乱。
你必须得非常清楚自己的架构，如果歪了赶快扶正，尽可能多地写文档。索性 LLM 很擅长做重构（大概率比你擅长），在多次 Review 的情况下会给你一个干净的结果，而且它也大概率比你会写文档。
所以，别用 LLM 糊屎，糊出来了屎也不是 LLM 的问题，是你的管理技术有问题。
比如你的系统里面有一坨 legacy 导致了两条 parallel 实现，LLM 搞不清楚该在哪条上继续开发，就会变成一会在 legacy 上雕花一会去在正常流程上堆料，最后一团混乱。
你必须得非常清楚自己的架构，如果歪了赶快扶正，尽可能多地写文档。索性 LLM 很擅长做重构（大概率比你擅长），在多次 Review 的情况下会给你一个干净的结果，而且它也大概率比你会写文档。
所以，别用 LLM 糊屎，糊出来了屎也不是 LLM 的问题，是你的管理技术有问题。
🖨 一招搞定！让旧打印机支持iPhone无线打印
🔗 项目来源: AirPrint_Bridge
🧭 实测总结
⚙️ 安装难度 ★★☆☆☆
📱 兼容性★★★★☆
💨 运行稳定性 ★★★★☆
💡 实用性 ★★★★★
由于最近小孩上学需要经常打印一些老师发的资料，在家打印文件时遇到个老大难问题——
我的那台老款打印机不支持 AirPrint，需要将文件通过Airdrop或者登录通讯软件转到电脑上再打印，操作相当繁琐😩。查了一圈资料后，我决定自己动手搭建一个 AirPrint 服务。没想到居然成功了！现在手机点一下就能直接打印，体验满分。
💻 测试环境
系统：macOS
打印机：惠普1136激光打印机
🧩 第一步：安装驱动 + 开启共享打印机
先确保打印机驱动已安装并能正常打印。
然后进入 系统设置 → 打印机设置，
打开“在网络上共享此打印机”。
（不共享，手机永远找不到！）
⚙️ 第二步：安装 AirPrint 脚本服务
因为打印机本身不支持 AirPrint，
所以我们用一个开源脚本来“桥接”服务。
打开终端（Terminal），CD进安装所需的文件夹，输入以下命令下载项目并回车
git clone https://github.com/sapireli/AirPrint_Bridge.git
cd AirPrint_Bridge或者使用 Homebrew 安装
brew tap sapireli/AirPrint_Bridge https://github.com/sapireli/AirPrint_Bridge.git
brew install airprint-bridge再赋予执行权限：
chmod +x airprint_bridge.sh🧪 第三步：测试是否可用
执行测试命令：
sudo ./airprint_bridge.sh -t输入电脑密码（输入过程不会显示，直接回车）。
此时脚本会启动临时服务，
打开 iPhone → 相册 → 分享 → 打印，
看看能不能找到打印机。
如果出现 ✅，恭喜你成功一半啦！
🚀 第四步：正式安装
在终端按下 Ctrl + C 终止测试，
然后执行：
sudo ./airprint_bridge.sh -i安装完成后，AirPrint 服务会自动运行，
以后手机、iPad 都能无线打印啦～📱✨
🗑 卸载方法
不想用了？在脚本目录执行：
sudo ./airprint_bridge.sh -u👨🏻💻 碎碎念
有其实折腾这个 AirPrint 服务之前，我还真犹豫过要不要直接换一台新打印机或者买个Airprint盒子。但折腾完之后发现老设备不一定过时，只是需要一点耐心。也再次证明：
能用代码解决的问题，都不是大问题 😎。
频道：@NewlearnerChannel
毫无意外的，淘宝闪购和饿了么，这一套班子、两块牌子，很快就要「二合一」。淘宝闪购，未来将成为阿里唯一的外卖+即时零售品牌招牌。
目前还没有官宣，只是已经有部分用户的饿了么App收到灰度更新，淘宝闪购四个大字占据了图标上的绝对主体，目测App的正式更名也只是时间问题了。
之所以说这件事情并不意外，是因为此前的双品牌结构看起来确实有些拧巴了，明明已经打通了供给和履约，对外依然有「淘宝闪购提供补贴，饿了么提供履约支持」这类要在两个品牌露出上端水的拗口解释。
不过可以理解的是，在打仗的时候，一切以战线为优先，而在「外卖大战」进入新一轮格局形势后，重新定位品牌的空间和价值，理所应当。
这是一个「自然而然，水到渠成」的选择。
我们可以稍微回顾淘宝闪购是怎么一步步在即时零售市场占据主体性的：
今年4月，淘宝站内原本服务于即时零售的「小时达」正式升级为「淘宝闪购」，并拿到了淘宝App的一级入口，全面接入饿了么供给和服务；
到了5月，淘宝闪购在小长假期间提前全量上线，开始发放大额红包以促日活，并火速签下了汪苏泷作为代言人；
再到7月，淘宝闪购拿出了500亿的巨额补贴，高调加入「外卖大战」，直接把京东和美团的Q3利润打成骨折；
最后是8月，蒋凡在财报会议上发出阶段性胜利的定调，宣布单日1.2亿订单的峰值，在外卖行业打出了「坐二望一」的地位；
⋯⋯
整个过程看起来大兴土木，其实只用了半年不到的时间，淘宝闪购的心智就已经立了起来。
比如在相关话题的评论区，网友已经普遍将「闪购」这个词默认为淘宝闪购，而不是更早提出闪购这个概念的美团闪购，这很有意思。
不是说美团做得不如阿里，恰恰相反，是美团在外卖上过于深入了，才会削弱闪购业务的品牌认知。
就像一个用户在美团外卖上分别点了一份麦当劳和一根充电线，他很难分得清楚，前者出自美团外卖的业务，后者出自美团闪购的业务，在他看来，这都是自己下了一单外卖。
但淘宝闪购之于淘宝，却不是这样的关系，淘宝是快递电商的模式，是要去拆包裹的，而淘宝闪购是骑手小哥送货上门，是淘宝新开通的外卖服务。
这就导致了，虽然淘宝闪购是一个更新的品牌，但是因为它没有历史包袱的混淆，在落地上更加丝滑流畅，便于理解。
理解了这个必然发生的结果，也就能够理解阿里需要扬长避短的考虑。
虽然有点暴论，但我还是想说，在被美团常年压着打的发展史里，饿了么已经印上了「万年老二」的钢印，甚至难洗刷一种战败主义的悲壮标签。
甚至行业内都有默认的传言，声称美团故意留着饿了么，是不想加深市场垄断的嫌疑。
所以这么些年来，市场来观察饿了么在阿里的盘子里——资产属性就一直大于业务属性，否则也不会隔三差五就出现要卖给抖音的小道消息了。
在历次所谓的「误报」辟谣里，阿里对于饿了么是优质资产的标准判断很明确：这是重要战略性业务。尤其花了18年积累下来的本地履约网络更是非卖品。
所以各路消息也说，收购方看重的也是后者，所以双方始终谈不拢，大家对于真正值钱的是什么，有着高度一致的看法。
所以自从开打「外卖大战」以来，其实可以看出饿了么品牌的对外表达是在逐步淡化的：一方面是它必须出现在整个体系里，输送供给、流量和配送等资源，另一方面它又不再是这个周期的品牌主角，时刻注意不要「抢戏」。
即使要讲故事，也不会是重新武装饿了么去和美团开战的剧本，这多少有些「我打宿傩」的幽默感，真正高燃的剧情，是淘宝拿着9亿月活下场，最后还给电商业务挣了1亿新增用户。
什么叫他妈的惊喜？这就是了。
其实从前段时间的骑手换装就能看出，新款工装已经由淘宝闪购占据了绝对核心的上身部分，而饿了么是和菜鸟、速卖通一起并列，主次分明。
哲学上的「忒修斯之船」就是如此造出来的，从一个铁钉开始逐渐替换，直至每一块甲板都是新的，那么这艘船，还是不是之前的忒修斯号？
显然，阿里站在了霍布斯而非亚里士多德的一边，霍布斯的唯物主义认为，物质构成大于符号意义，新船就应该用新的名字。
无论是马云提出的「回归淘宝」主战略，还是吴泳铭为淘宝设计的「大消费平台」愿景，用这个历经淬炼的国民级品牌，来为闯入增量市场提供确定性，都是相当聪明的一步棋。
除了适合构建外部的消费者心智以外，在内部组织的调度上，淘宝闪购这种一号位工程的名头，也远比饿了么要好使。
尤其是考虑到还和美团有着旷日持久的竞争，用淘宝背书，意味着恒产者有恒心，这在争取代理商的信任方面，百利无害。
据我所知，在暑期档的「外卖大战」期间，已经有一些代理商先表示，希望改用淘宝闪购作为店头物料，这对他们商业生态和合作拓展，都是有帮助的。
腾笼换鸟，笼不重要，重要的是，鸟要飞得更快。
by @阑夕ོ #科技圈大小事
目前还没有官宣，只是已经有部分用户的饿了么App收到灰度更新，淘宝闪购四个大字占据了图标上的绝对主体，目测App的正式更名也只是时间问题了。
之所以说这件事情并不意外，是因为此前的双品牌结构看起来确实有些拧巴了，明明已经打通了供给和履约，对外依然有「淘宝闪购提供补贴，饿了么提供履约支持」这类要在两个品牌露出上端水的拗口解释。
不过可以理解的是，在打仗的时候，一切以战线为优先，而在「外卖大战」进入新一轮格局形势后，重新定位品牌的空间和价值，理所应当。
这是一个「自然而然，水到渠成」的选择。
我们可以稍微回顾淘宝闪购是怎么一步步在即时零售市场占据主体性的：
今年4月，淘宝站内原本服务于即时零售的「小时达」正式升级为「淘宝闪购」，并拿到了淘宝App的一级入口，全面接入饿了么供给和服务；
到了5月，淘宝闪购在小长假期间提前全量上线，开始发放大额红包以促日活，并火速签下了汪苏泷作为代言人；
再到7月，淘宝闪购拿出了500亿的巨额补贴，高调加入「外卖大战」，直接把京东和美团的Q3利润打成骨折；
最后是8月，蒋凡在财报会议上发出阶段性胜利的定调，宣布单日1.2亿订单的峰值，在外卖行业打出了「坐二望一」的地位；
⋯⋯
整个过程看起来大兴土木，其实只用了半年不到的时间，淘宝闪购的心智就已经立了起来。
比如在相关话题的评论区，网友已经普遍将「闪购」这个词默认为淘宝闪购，而不是更早提出闪购这个概念的美团闪购，这很有意思。
不是说美团做得不如阿里，恰恰相反，是美团在外卖上过于深入了，才会削弱闪购业务的品牌认知。
就像一个用户在美团外卖上分别点了一份麦当劳和一根充电线，他很难分得清楚，前者出自美团外卖的业务，后者出自美团闪购的业务，在他看来，这都是自己下了一单外卖。
但淘宝闪购之于淘宝，却不是这样的关系，淘宝是快递电商的模式，是要去拆包裹的，而淘宝闪购是骑手小哥送货上门，是淘宝新开通的外卖服务。
这就导致了，虽然淘宝闪购是一个更新的品牌，但是因为它没有历史包袱的混淆，在落地上更加丝滑流畅，便于理解。
理解了这个必然发生的结果，也就能够理解阿里需要扬长避短的考虑。
虽然有点暴论，但我还是想说，在被美团常年压着打的发展史里，饿了么已经印上了「万年老二」的钢印，甚至难洗刷一种战败主义的悲壮标签。
甚至行业内都有默认的传言，声称美团故意留着饿了么，是不想加深市场垄断的嫌疑。
所以这么些年来，市场来观察饿了么在阿里的盘子里——资产属性就一直大于业务属性，否则也不会隔三差五就出现要卖给抖音的小道消息了。
在历次所谓的「误报」辟谣里，阿里对于饿了么是优质资产的标准判断很明确：这是重要战略性业务。尤其花了18年积累下来的本地履约网络更是非卖品。
所以各路消息也说，收购方看重的也是后者，所以双方始终谈不拢，大家对于真正值钱的是什么，有着高度一致的看法。
所以自从开打「外卖大战」以来，其实可以看出饿了么品牌的对外表达是在逐步淡化的：一方面是它必须出现在整个体系里，输送供给、流量和配送等资源，另一方面它又不再是这个周期的品牌主角，时刻注意不要「抢戏」。
即使要讲故事，也不会是重新武装饿了么去和美团开战的剧本，这多少有些「我打宿傩」的幽默感，真正高燃的剧情，是淘宝拿着9亿月活下场，最后还给电商业务挣了1亿新增用户。
什么叫他妈的惊喜？这就是了。
其实从前段时间的骑手换装就能看出，新款工装已经由淘宝闪购占据了绝对核心的上身部分，而饿了么是和菜鸟、速卖通一起并列，主次分明。
哲学上的「忒修斯之船」就是如此造出来的，从一个铁钉开始逐渐替换，直至每一块甲板都是新的，那么这艘船，还是不是之前的忒修斯号？
显然，阿里站在了霍布斯而非亚里士多德的一边，霍布斯的唯物主义认为，物质构成大于符号意义，新船就应该用新的名字。
无论是马云提出的「回归淘宝」主战略，还是吴泳铭为淘宝设计的「大消费平台」愿景，用这个历经淬炼的国民级品牌，来为闯入增量市场提供确定性，都是相当聪明的一步棋。
除了适合构建外部的消费者心智以外，在内部组织的调度上，淘宝闪购这种一号位工程的名头，也远比饿了么要好使。
尤其是考虑到还和美团有着旷日持久的竞争，用淘宝背书，意味着恒产者有恒心，这在争取代理商的信任方面，百利无害。
据我所知，在暑期档的「外卖大战」期间，已经有一些代理商先表示，希望改用淘宝闪购作为店头物料，这对他们商业生态和合作拓展，都是有帮助的。
腾笼换鸟，笼不重要，重要的是，鸟要飞得更快。
by @阑夕ོ #科技圈大小事
看到一个很有意思的数据对比：
中国市场避孕套的销售额去年是156亿人民币，同比下降17%，相较2019年的高点，更是萎缩了1/4以上；
同期中国市场情趣用品的销售额增长却高到离谱，每年稳定增长15%，去年交易额接近2000亿人民币，比起2019年翻了个倍。
报告结论很扎心，就一句话：
「这代人的性生活，不需要两个人了。」
by @阑夕ོ #你不知道的行业内幕
中国市场避孕套的销售额去年是156亿人民币，同比下降17%，相较2019年的高点，更是萎缩了1/4以上；
同期中国市场情趣用品的销售额增长却高到离谱，每年稳定增长15%，去年交易额接近2000亿人民币，比起2019年翻了个倍。
报告结论很扎心，就一句话：
「这代人的性生活，不需要两个人了。」
by @阑夕ོ #你不知道的行业内幕
今天看唐彬森的演讲，深刻地解释了为什么大公司会有「资源诅咒」
大公司的核心问题在于决策。
大公司高管上班考虑的是什么？领导的KPI、公司战略、怎么要资源。
他们解决问题的方式，往往是用钱、用渠道，而不是产品。
流量不够？百度申请一笔预算，打一波广告，马上就起来了。谁愿意去做那些苦哈哈的产品优化？
他们考虑的都是短线问题，不会考虑长线问题。
什么叫短线？向公司要资源、向领导做PPT。
什么叫长线？产品。
他去了趟以色列，发现这个国家啥也没有，但比周围那些有石油的国家都赚钱。
经济学上有个专业术语就叫"资源诅咒"。那些有资源的国家，像俄罗斯、巴西、阿拉伯那些国家，高科技产业反而发展不好。
为什么？因为挣钱太容易了。
就像大公司高管一样，要完成KPI，最好的办法就是申请预算，打广告，马上见效。
但那些做得好的国家，芬兰、日本、以色列，都是没资源的国家。
所以他跟团队说："穷人家的孩子早当家。"
人只有在资源极度紧缺的情况下，才会迸发出创造力。
资源太多的话，想的都是怎么花钱，怎么向领导申请预算。
互联网最牛的公司都不是靠钱做起来的，大公司都是靠钱砸死的，都是靠推广把产品搞死的。
雷军做小米的时候跟林斌说："我们小米要做营销，没有预算，零预算。"
这就是创业公司的文化，用零预算的方式把东西做起来，这才是团队的能力，这才是跟大公司竞争的唯一优势。
完整版
唐彬森：钱没用，小公司靠这个逆袭大公司 - ListenHub
https://listenhub.ai/episode/69074e2b28f1543f57ce556d
by @OrangeAI #科技圈大小事
大公司的核心问题在于决策。
大公司高管上班考虑的是什么？领导的KPI、公司战略、怎么要资源。
他们解决问题的方式，往往是用钱、用渠道，而不是产品。
流量不够？百度申请一笔预算，打一波广告，马上就起来了。谁愿意去做那些苦哈哈的产品优化？
他们考虑的都是短线问题，不会考虑长线问题。
什么叫短线？向公司要资源、向领导做PPT。
什么叫长线？产品。
他去了趟以色列，发现这个国家啥也没有，但比周围那些有石油的国家都赚钱。
经济学上有个专业术语就叫"资源诅咒"。那些有资源的国家，像俄罗斯、巴西、阿拉伯那些国家，高科技产业反而发展不好。
为什么？因为挣钱太容易了。
就像大公司高管一样，要完成KPI，最好的办法就是申请预算，打广告，马上见效。
但那些做得好的国家，芬兰、日本、以色列，都是没资源的国家。
所以他跟团队说："穷人家的孩子早当家。"
人只有在资源极度紧缺的情况下，才会迸发出创造力。
资源太多的话，想的都是怎么花钱，怎么向领导申请预算。
互联网最牛的公司都不是靠钱做起来的，大公司都是靠钱砸死的，都是靠推广把产品搞死的。
雷军做小米的时候跟林斌说："我们小米要做营销，没有预算，零预算。"
这就是创业公司的文化，用零预算的方式把东西做起来，这才是团队的能力，这才是跟大公司竞争的唯一优势。
完整版
唐彬森：钱没用，小公司靠这个逆袭大公司 - ListenHub
https://listenhub.ai/episode/69074e2b28f1543f57ce556d
by @OrangeAI #科技圈大小事
saka 老师前几周分享的这篇文章 https://skoredin.pro/blog/golang/cpu-cache-friendly-go 非常有意思，我虽然日常在 pahole 输出里看到 cacheline，但对其如何影响程序运行的理解也非常模糊。
不过更有意思的是，我已经见到三位工程师在 AI 的辅助下试图测试 “cacheline padding 带来六倍性能提升” 却没有成功，最后吐槽这是一篇错文、AI文。这里有一个有趣的知识屏障，如果不理解 cacheline 在何时会影响性能，那就可能无法写出正确的测试程序；但无法写出正确的测试程序又无法理解 cacheline 如何影响性能，知识死锁了。
你以为我想说原文的 “cacheline导致六倍性能差距” 的结论是正确的？不，那是错误的 有前提条件的，并非通用结论🤪
这些对我也是新知识，水平有限，施工区域谨慎阅读🤬
我的测试代码不用很多工程师和 AI 用的 go bench 方法，因为抽象程度太高了，在这种性能施工区最好就写一眼能看穿汇编的简单代码。
提供了两套变式， 通过命令行的 arg1 和 arg2 指定是否 padding 和是否用 atomic.AddUint64。
我本地的 cpu 0,1 是同一个核心，1,2 是不同核心，所以测试命令是
很多细节我依然在学习中，目前可以公开的情报是：（+表示前者性能更好，-反之）
1. "pad atom" vs "nopad atom": +7.3倍性能
2. "pad nonatom" vs "nopad noatom": +3.3倍
3. "pad atom" vs "pad noatom": -2.5倍
4. "nopad atom" vs "nopad noatom": -5倍
可以看到 atom (lock prefix insn)本身就造成大量的性能影响，而 pad 会进一步加重 cacheline false sharing 导致更极端的性能差距。原文里的六倍性能差距是在 atom + pad 的场景下的测试结果，但我觉得大部分场景根本不会这么极端。
核心绑定情况也会造成很大影响。如果绑核改为 0,1 cpu，它们是同一 core，测试结果是：
1. "pad atom" vs "nopad atom": +1.75
2. "pad noatom" vs "nopad noatom": +1.65
3. "pad atom" vs "pad noatom": -1.9
4. "nopad atom" vs "nopad noatom": -2.0
在这些测试里，经典的 perf topdown 方法在 L2->L3->L4 几乎完全失效，经常会看到 L2 的 tma_core_bound 40% 然后 tma_core_bound_group breakdown 是 0%、L3 的 tma_l3_bound 15% 然而 L4 的 tma_l3_bound_group 里面四个 0%。我的 cpu 型号是 x86 meteorlake，仔细看了 pmu metrics 定义之后我觉得这就是设计上的问题，L2 再往下没有保证，只能靠微指令法师的经验来跳跃性猜测和验证。
可以确定有用的 metrics 是
- tma_store_fwd_blk: atom vs noatom 性能差距的罪魁，lock prefix insn 阻止了 store forwarding (CSAPP $4.5.5.2) 导致性能大幅下降
- tma_false_sharing: cacheline 在多核心上共享时的 race。原文其实主要就是在讨论这个讨论的性能问题。
- tma_l3_bound: snoop hitm 的间接指标。
- L1-dcache-loads,L1-dcache-load-misses: cacheline racing 的间接指标。但由于 l1 miss 至少包含了 "cacheline 不在 L1" 和 "cacheline 在 L1 但是失效"，这个 miss 率其实很容易误导。
如何从 metrics 找到源码：
perf list 文档写得不全，直接看内核里的 pmu-events/.../mtl-metrics.json，比如说 perf record -M tma_false_sharing 很高，json 文件里这一项的 PublicDescription 就会写
然后采样
然后可以可以画火焰图和栈回溯，但我现在喜欢 perf annotate -l --stdio 直接看指令
看到 87% 的 false sharing 都是由于 inc %rcx 导致的。
讲完方法论终于可以回到主题了，cacheline 如何影响性能：如果是一个线程共享数据 A 在多核上并行 ++，核心1 修改了 A，那么核心2 的 L1 缓存的包含 A 的 cacheline 就会失效，这就是 false sharing。对于共享数据 A 来说这不可避免，但是如果有另一个 独立 数据 B 和 A 在同一个 cacheline，那么 A 在多核上刷存在感就会导致 B 的 L1 cache 失效，尽管 B 可能完全是一个单线程非共享数据。好的 cacheline 设计可以加上一段 padding 把 B 强制隔离出 A 所在的 cacheline，这样 A 刷新 cacheline 不会导致 B 的 cacheline 失效。
这些知识真的非常晦涩难懂，资料很少，AI 基本在帮倒忙，我感觉像是在星际航行，目睹所有令人惊叹的宇宙奇观，恍惚间就化入无穷。
不过更有意思的是，我已经见到三位工程师在 AI 的辅助下试图测试 “cacheline padding 带来六倍性能提升” 却没有成功，最后吐槽这是一篇错文、AI文。这里有一个有趣的知识屏障，如果不理解 cacheline 在何时会影响性能，那就可能无法写出正确的测试程序；但无法写出正确的测试程序又无法理解 cacheline 如何影响性能，知识死锁了。
你以为我想说原文的 “cacheline导致六倍性能差距” 的结论是正确的？不，那是
这些对我也是新知识，水平有限，施工区域谨慎阅读
我的测试代码不用很多工程师和 AI 用的 go bench 方法，因为抽象程度太高了，在这种性能施工区最好就写一眼能看穿汇编的简单代码。
package main
import (
"fmt"
"os"
"sync"
"sync/atomic"
"time"
)
const N = 100_000_000
type Counters interface {
Inc(idx int)
AtomicInc(idx int)
Result(idx int) uint64
}
type unpaddingCounters [8]uint64
func (u *unpaddingCounters) Inc(idx int) {
u[idx]++
}
func (u *unpaddingCounters) AtomicInc(idx int) {
atomic.AddUint64(&u[idx], 1)
}
func (u *unpaddingCounters) Result(idx int) uint64 {
return u[idx]
}
type paddingCounter struct {
val uint64
_ [56]byte
}
type PaddingCounters [8]paddingCounter
func (p *PaddingCounters) Inc(idx int) {
p[idx].val++
}
func (p *PaddingCounters) AtomicInc(idx int) {
atomic.AddUint64(&p[idx].val, 1)
}
func (p *PaddingCounters) Result(idx int) uint64 {
return p[idx].val
}
func main() {
var counters Counters
if os.Args[1] == "pad" {
counters = &PaddingCounters{}
} else {
counters = &unpaddingCounters{}
}
var inc func(idx int)
if os.Args[2] == "atom" {
inc = counters.AtomicInc
} else {
inc = counters.Inc
}
start := time.Now()
var wg sync.WaitGroup
for i := 0; i < 8; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for j := 0; j < N; j++ {
inc(i)
}
}()
}
wg.Wait()
fmt.Printf("Duration: %v ", time.Since(start))
for i := 0; i < 8; i++ {
fmt.Printf("Counter[%d]=%d ", i, counters.Result(i))
}
fmt.Println()
}
提供了两套变式， 通过命令行的 arg1 和 arg2 指定是否 padding 和是否用 atomic.AddUint64。
我本地的 cpu 0,1 是同一个核心，1,2 是不同核心，所以测试命令是
taskset -c 1,2 perf stat -d -- env GOMAXPROCS=2 ./go_cpu_perf pad atom很多细节我依然在学习中，目前可以公开的情报是：（+表示前者性能更好，-反之）
1. "pad atom" vs "nopad atom": +7.3倍性能
2. "pad nonatom" vs "nopad noatom": +3.3倍
3. "pad atom" vs "pad noatom": -2.5倍
4. "nopad atom" vs "nopad noatom": -5倍
可以看到 atom (lock prefix insn)本身就造成大量的性能影响，而 pad 会进一步加重 cacheline false sharing 导致更极端的性能差距。原文里的六倍性能差距是在 atom + pad 的场景下的测试结果，但我觉得大部分场景根本不会这么极端。
核心绑定情况也会造成很大影响。如果绑核改为 0,1 cpu，它们是同一 core，测试结果是：
1. "pad atom" vs "nopad atom": +1.75
2. "pad noatom" vs "nopad noatom": +1.65
3. "pad atom" vs "pad noatom": -1.9
4. "nopad atom" vs "nopad noatom": -2.0
在这些测试里，经典的 perf topdown 方法在 L2->L3->L4 几乎完全失效，经常会看到 L2 的 tma_core_bound 40% 然后 tma_core_bound_group breakdown 是 0%、L3 的 tma_l3_bound 15% 然而 L4 的 tma_l3_bound_group 里面四个 0%。我的 cpu 型号是 x86 meteorlake，仔细看了 pmu metrics 定义之后我觉得这就是设计上的问题，L2 再往下没有保证，只能靠微指令法师的经验来跳跃性猜测和验证。
可以确定有用的 metrics 是
- tma_store_fwd_blk: atom vs noatom 性能差距的罪魁，lock prefix insn 阻止了 store forwarding (CSAPP $4.5.5.2) 导致性能大幅下降
- tma_false_sharing: cacheline 在多核心上共享时的 race。原文其实主要就是在讨论这个讨论的性能问题。
- tma_l3_bound: snoop hitm 的间接指标。
- L1-dcache-loads,L1-dcache-load-misses: cacheline racing 的间接指标。但由于 l1 miss 至少包含了 "cacheline 不在 L1" 和 "cacheline 在 L1 但是失效"，这个 miss 率其实很容易误导。
如何从 metrics 找到源码：
perf list 文档写得不全，直接看内核里的 pmu-events/.../mtl-metrics.json，比如说 perf record -M tma_false_sharing 很高，json 文件里这一项的 PublicDescription 就会写
Sample with: OCR.DEMAND_RFO.L3_HIT.SNOOP_HITM然后采样
perf record -F9999 -g -e OCR.DEMAND_RFO.L3_HIT.SNOOP_HITM然后可以可以画火焰图和栈回溯，但我现在喜欢 perf annotate -l --stdio 直接看指令
0.42 : 4949aa: inc %rcx
: 42 inc(i)
87.08 : 4949ad: mov 0x18(%rsp),%rax看到 87% 的 false sharing 都是由于 inc %rcx 导致的。
讲完方法论终于可以回到主题了，cacheline 如何影响性能：如果是一个线程共享数据 A 在多核上并行 ++，核心1 修改了 A，那么核心2 的 L1 缓存的包含 A 的 cacheline 就会失效，这就是 false sharing。对于共享数据 A 来说这不可避免，但是如果有另一个 独立 数据 B 和 A 在同一个 cacheline，那么 A 在多核上刷存在感就会导致 B 的 L1 cache 失效，尽管 B 可能完全是一个单线程非共享数据。好的 cacheline 设计可以加上一段 padding 把 B 强制隔离出 A 所在的 cacheline，这样 A 刷新 cacheline 不会导致 B 的 cacheline 失效。
这些知识真的非常晦涩难懂，资料很少，AI 基本在帮倒忙，我感觉像是在星际航行，目睹所有令人惊叹的宇宙奇观，恍惚间就化入无穷。
刚从香港回来，腿已跑废，但一天就线上搞定了汇丰、中银、众安、天星、蚂蚁5家银行！
趁热分享流程和避坑经验，跟着这篇准备，包你稳过。
准备工作 (漏了就白跑，别问我怎么知道的):
证件: 身份证、港澳通行证，有效期都得大于6个月。
手机号: 必须开通国际漫游收验证码！上网是另一回事。
出入境记录: 抵港后，微信小程序“12367”下载PDF，只要有一次内地出境记录就行。
收卡地址: 提前翻译好中英文，地址太长学点缩写 (Building→BLDG)。
银行APP: 提前下好汇丰、中银、众安、天星，蚂蚁银行在支付宝小程序。
开户流程:
到香港找个信号好的地方开干。推荐顺序：先汇丰，再中银，最后搞定剩下的虚拟银行。
🚀 第一站：汇丰银行 (HSBC)
这家是老牌大哥，必须拿下。全程APP线上操作。
打开 HSBC HK APP，点“我没有任何账户”。
关键选择：“身处香港，没有香港身份证”。
账户类型选 “汇丰one”。
填信息：
开户用途：就选“储蓄/投资”，别整那些复杂的。
税务编号：就是你的内地身份证号。
收件地址：把你准备好的中英文地址填进去，注意字数限制。
上传资料：按提示拍身份证，然后用手机 NFC 功能把通行证贴在手机背后，它会自动读取芯片信息。
设置用户名密码，提交。
顺利的话，几分钟内就会收到审核通过的邮件。然后就等着收卡吧。
🥈 第二站：中银香港 (BOCHK)
中银也算是亲儿子，流程也挺顺。
打开 BOCHK APP，点“开立账户”。
身份选“中国居民身份证”，然后选 “我身处香港”。
开户方式选“我不在分行”，然后“即时开立”。
账户类型选 “自在理财”，这个也没存款要求。
上传资料：这里就要用到你之前准备的出入境记录PDF了。然后按要求拍身份证和港澳通行证。
人脸识别，找个亮堂点的地方。
填个人信息：职业如实写，开户理由选“投资理财”或“储蓄”。地址一定要详细到门牌号。
提交后也是很快出结果。
🎯 第三、四、五站：众安、天星、蚂蚁
这三家是虚拟银行，流程大同小异，放在一起说。基本就是填资料、上传证件、人脸识别三板斧。
有几个点注意下：
地址：同样要精确到门牌号。
税务身份：一般都选“仅为内地税务居民”。
税务号：填身份证号。
出入境记录：都要上传。众安银行比较灵活，可以开户成功，离港后再补充上传。
by @何夕2077 #你不知道的行业内幕
趁热分享流程和避坑经验，跟着这篇准备，包你稳过。
准备工作 (漏了就白跑，别问我怎么知道的):
证件: 身份证、港澳通行证，有效期都得大于6个月。
手机号: 必须开通国际漫游收验证码！上网是另一回事。
出入境记录: 抵港后，微信小程序“12367”下载PDF，只要有一次内地出境记录就行。
收卡地址: 提前翻译好中英文，地址太长学点缩写 (Building→BLDG)。
银行APP: 提前下好汇丰、中银、众安、天星，蚂蚁银行在支付宝小程序。
开户流程:
到香港找个信号好的地方开干。推荐顺序：先汇丰，再中银，最后搞定剩下的虚拟银行。
🚀 第一站：汇丰银行 (HSBC)
这家是老牌大哥，必须拿下。全程APP线上操作。
打开 HSBC HK APP，点“我没有任何账户”。
关键选择：“身处香港，没有香港身份证”。
账户类型选 “汇丰one”。
填信息：
开户用途：就选“储蓄/投资”，别整那些复杂的。
税务编号：就是你的内地身份证号。
收件地址：把你准备好的中英文地址填进去，注意字数限制。
上传资料：按提示拍身份证，然后用手机 NFC 功能把通行证贴在手机背后，它会自动读取芯片信息。
设置用户名密码，提交。
顺利的话，几分钟内就会收到审核通过的邮件。然后就等着收卡吧。
🥈 第二站：中银香港 (BOCHK)
中银也算是亲儿子，流程也挺顺。
打开 BOCHK APP，点“开立账户”。
身份选“中国居民身份证”，然后选 “我身处香港”。
开户方式选“我不在分行”，然后“即时开立”。
账户类型选 “自在理财”，这个也没存款要求。
上传资料：这里就要用到你之前准备的出入境记录PDF了。然后按要求拍身份证和港澳通行证。
人脸识别，找个亮堂点的地方。
填个人信息：职业如实写，开户理由选“投资理财”或“储蓄”。地址一定要详细到门牌号。
提交后也是很快出结果。
🎯 第三、四、五站：众安、天星、蚂蚁
这三家是虚拟银行，流程大同小异，放在一起说。基本就是填资料、上传证件、人脸识别三板斧。
有几个点注意下：
地址：同样要精确到门牌号。
税务身份：一般都选“仅为内地税务居民”。
税务号：填身份证号。
出入境记录：都要上传。众安银行比较灵活，可以开户成功，离港后再补充上传。
by @何夕2077 #你不知道的行业内幕
甚至还有技术报告。。。
https://soul-ailab.github.io/soulx-podcast/
https://soul-ailab.github.io/soulx-podcast/
一个约炮软件开源了个 tts, 这合理么？
https://github.com/Soul-AILab/SoulX-Podcast
https://github.com/Soul-AILab/SoulX-Podcast
GitHub
GitHub - Soul-AILab/SoulX-Podcast: SoulX-Podcast is an inference codebase by the Soul AI team for generating high-fidelity podcasts…
SoulX-Podcast is an inference codebase by the Soul AI team for generating high-fidelity podcasts from text. - Soul-AILab/SoulX-Podcast
1949年，杨振宁在芝加哥发现报纸刊登了一种填字游戏，分数最高的解谜者可以拿到5万美元的奖励。他和其他4名同学很是心动，凑了17美元报名费参加比赛。
一个月后，报纸告诉他们得了第一名，但还有并列第一的人，因此需要解一个更大的谜分出胜负。
但此时杨振宁已经到了普林斯顿做博士后，5名同学只能通过远程电话分工。杨振宁负责每天在学校的24小时图书馆借用一本大字典，穷举了所有符合条件的填字单词，为了5万美元的奖金，这样连续熬夜了一个礼拜。
有一次工作到后半夜，天都快亮了，实在很困，于是步行回到借宿的房子。
他在门口拿起刚寄到的一本纽约时报，进到客厅坐在椅子上打开翻阅，只见封面大字写着：“汤川秀树获得1949年物理学诺贝尔奖”，他突然愣住，一个内心的声音在脑海深处质问：
“杨振宁，你现在在干嘛？”
——2005年杨在上海交通大学的分享会提到的一件小事。
by @哈雷Halley #你不知道的行业内幕
一个月后，报纸告诉他们得了第一名，但还有并列第一的人，因此需要解一个更大的谜分出胜负。
但此时杨振宁已经到了普林斯顿做博士后，5名同学只能通过远程电话分工。杨振宁负责每天在学校的24小时图书馆借用一本大字典，穷举了所有符合条件的填字单词，为了5万美元的奖金，这样连续熬夜了一个礼拜。
有一次工作到后半夜，天都快亮了，实在很困，于是步行回到借宿的房子。
他在门口拿起刚寄到的一本纽约时报，进到客厅坐在椅子上打开翻阅，只见封面大字写着：“汤川秀树获得1949年物理学诺贝尔奖”，他突然愣住，一个内心的声音在脑海深处质问：
“杨振宁，你现在在干嘛？”
——2005年杨在上海交通大学的分享会提到的一件小事。
by @哈雷Halley #你不知道的行业内幕
既然很多即友想要听SPA测评和指南，那么我就根据我最近几年的经验说一下，如果有不对的多多包涵。
1，目前全国足浴店（门面）基本正规，但是每个城市都有几家有后台和背景的可以开92。
2，正规SPA（手法型）消费在150-300之间，价格和技师颜值绑定。某团和某音上面很多，随便找。
正规足浴一般就是几十块要一百多。如果是大城市，则会有大几百块的“商务足浴”，大概就是你读书的时候，学校里的班花校花穿着旗袍什么的给你洗脚。（正规）。
3，除了手法，再高级一点的则是“柔式”。柔式其实只能算是擦边，主要是“舒缓身心”。
一般做柔式的都是20多的年轻女技师，纤纤玉手触摸你的皮肤甚至是有意无意的碰触敏感部位。客人揩油也是很普遍的情况，但是由于不做“大活”，这种情况非常普遍，警察也不管。
但由于客单价高，往往成为一家足浴店主要的收入来源。
这个柔式的价位就比较高了，毕竟是出卖色相。不同的技师效果非常大。一般加店里的小哥可以朋友圈选妃。
4，至于很多狼友关注的打X机，这个不展开，如果没有当地熟人带，一般的店是不会主动推销的。（违法）现在国内严打的厉害，国内游南东莞北长春，结果今年长春也被扫光了。
以前东三省说是非常发达的产业，现在也几乎销声匿迹，所以我们才会在南方看到越来越多的东北技师。
而且，就算是有背景，SPA不可能开到92以上的大活，如果有人给你推销说冲卡可以XXX，都是骗子。
所以，现在全国除了SPA之外，还涌现出两大既不违法又擦边的活儿，就是女仆店和台球厅等等，这里面水也很深。
很难想象，稍微好的一点的女仆店，老板的收入可以到3-5万元一天，至于旅游陪玩什么，这个就不展开了。
by @Akira神小狼 #你不知道的行业内幕
1，目前全国足浴店（门面）基本正规，但是每个城市都有几家有后台和背景的可以开92。
2，正规SPA（手法型）消费在150-300之间，价格和技师颜值绑定。某团和某音上面很多，随便找。
正规足浴一般就是几十块要一百多。如果是大城市，则会有大几百块的“商务足浴”，大概就是你读书的时候，学校里的班花校花穿着旗袍什么的给你洗脚。（正规）。
3，除了手法，再高级一点的则是“柔式”。柔式其实只能算是擦边，主要是“舒缓身心”。
一般做柔式的都是20多的年轻女技师，纤纤玉手触摸你的皮肤甚至是有意无意的碰触敏感部位。客人揩油也是很普遍的情况，但是由于不做“大活”，这种情况非常普遍，警察也不管。
但由于客单价高，往往成为一家足浴店主要的收入来源。
这个柔式的价位就比较高了，毕竟是出卖色相。不同的技师效果非常大。一般加店里的小哥可以朋友圈选妃。
4，至于很多狼友关注的打X机，这个不展开，如果没有当地熟人带，一般的店是不会主动推销的。（违法）现在国内严打的厉害，国内游南东莞北长春，结果今年长春也被扫光了。
以前东三省说是非常发达的产业，现在也几乎销声匿迹，所以我们才会在南方看到越来越多的东北技师。
而且，就算是有背景，SPA不可能开到92以上的大活，如果有人给你推销说冲卡可以XXX，都是骗子。
所以，现在全国除了SPA之外，还涌现出两大既不违法又擦边的活儿，就是女仆店和台球厅等等，这里面水也很深。
很难想象，稍微好的一点的女仆店，老板的收入可以到3-5万元一天，至于旅游陪玩什么，这个就不展开了。
by @Akira神小狼 #你不知道的行业内幕
简单聊聊国庆吃的屎吧
首先明确下需求，我们要监控哪几个指标
1. RTO:TCP 连接的 RTO ，TCP 的超时重传的阈值，具体可以参见[RFC 0793](https://tools.ietf.org/html/rfc793) 和 [RFC 6298](https://tools.ietf.org/html/rfc6298)
2. 发送队列和接收队列长度
3. TCP 慢启动等指标
而且一个很核心的需求还是在于说，我们需要以 进程 为粒度去做 Metric 的 Group By，细化下来的可以有这样的效果
1. 单个进程的所有连接平均的 RTO 等指标
2. 单个进程Source-Target连接的 RTO 等指标
这个需求看起来可能会很无从下手，但是内核实际上是已经暴露出 metric 来供 Agent 采集了的
1. 对于 IPv4 连接，内核将 Metric 输出到
2. 对于 IPv6 连接，内核将 Metric 输出到
不过这里要注意的是，官方已经不推荐利用
在目前输出的 metrics 中，已经包含了一些关键的指标
1. 连接状态
2. 本地端口，地址
3. 远程端口，地址
4. 接收队列长度
5. 发送队列长度
6. 慢启动阈值
7. RTO 值
8. 连接所属的 socket 的 inode id
9. uid
10. delay ack 软时钟
具体可以参见 [proc_net_tcp.txt](https://github.com/torvalds/linux/blob/v4.10/Documentation/networking/proc_net_tcp.txt)
所以根据目前的一些指标，我们通过 inode→process 这一样一个路径便可以实现根据进程为粒度来对内核输出的 metric 进行二次聚合
但是这样做的弊端也很明显
1. 内核直接提供的 metric 信息还是太少，一些关于 RTT，SRTT 这样的指标还是没法获取，也没法获取 SACK 等一些特定事件（虽然走 netlink+tcp_diag) 能获取到一些信息，但是还是相对有限
2. 根据内核输出的 metric 无论是读文件，还是 netlink 轮询，都存在的问题是实时性和精度的问题，换句话说，我们在不考虑精度的情况下可以去做这方面的尝试
3. 如果是读文件，因为全局同一个 network namespaces 下都会写同一个文件，如果我们要强行去通过 [inotify](https://man7.org/linux/man-pages/man7/inotify.7.html) 来监听文件变化来做实时处理得话，首先能否实时处理还是一个问题，其次 inotify 给整个系统带来的开销还是不小的（在频繁变动的情况下）
所以如果有高精度的监控需求，可能还是优先考虑需要在协议层做一些手脚，在有包传输/连接变动的时候，触发特定的事件回调来做
目前一些能监控进程级别连接状态的工具，如 [nethogs](https://github.com/raboof/nethogs) 是依赖 [libpcap](https://github.com/the-tcpdump-group/libpcap)（这货也是 tcpdump 的核心）来根据包传输，连接建立等事件发生地时候触发特定的处理逻辑。而 libpcap 是基于 BPF (应该是没扩展之前的 cBPF）来在内核中打点做协议栈监控
所以考虑后续其余的一些自定义的监控的话，估计还是会考虑基于 eBPF 来做。不过估计不会像 Cilium 那种直接做一套全家桶。可能更类似于头条落地的 Sysprobe 那种专注于系统监控的东西。
首先明确下需求，我们要监控哪几个指标
1. RTO:TCP 连接的 RTO ，TCP 的超时重传的阈值，具体可以参见[RFC 0793](https://tools.ietf.org/html/rfc793) 和 [RFC 6298](https://tools.ietf.org/html/rfc6298)
2. 发送队列和接收队列长度
3. TCP 慢启动等指标
而且一个很核心的需求还是在于说，我们需要以 进程 为粒度去做 Metric 的 Group By，细化下来的可以有这样的效果
1. 单个进程的所有连接平均的 RTO 等指标
2. 单个进程Source-Target连接的 RTO 等指标
这个需求看起来可能会很无从下手，但是内核实际上是已经暴露出 metric 来供 Agent 采集了的
1. 对于 IPv4 连接，内核将 Metric 输出到
/proc/net/tcp2. 对于 IPv6 连接，内核将 Metric 输出到
/proc/net/tcp6不过这里要注意的是，官方已经不推荐利用
/proc/net/tcp 来获取连接级别的 metrics ，建议使用 [netlink](https://man7.org/linux/man-pages/man7/netlink.7.html) 来获取对应连接的 metrics在目前输出的 metrics 中，已经包含了一些关键的指标
1. 连接状态
2. 本地端口，地址
3. 远程端口，地址
4. 接收队列长度
5. 发送队列长度
6. 慢启动阈值
7. RTO 值
8. 连接所属的 socket 的 inode id
9. uid
10. delay ack 软时钟
具体可以参见 [proc_net_tcp.txt](https://github.com/torvalds/linux/blob/v4.10/Documentation/networking/proc_net_tcp.txt)
所以根据目前的一些指标，我们通过 inode→process 这一样一个路径便可以实现根据进程为粒度来对内核输出的 metric 进行二次聚合
但是这样做的弊端也很明显
1. 内核直接提供的 metric 信息还是太少，一些关于 RTT，SRTT 这样的指标还是没法获取，也没法获取 SACK 等一些特定事件（虽然走 netlink+tcp_diag) 能获取到一些信息，但是还是相对有限
2. 根据内核输出的 metric 无论是读文件，还是 netlink 轮询，都存在的问题是实时性和精度的问题，换句话说，我们在不考虑精度的情况下可以去做这方面的尝试
3. 如果是读文件，因为全局同一个 network namespaces 下都会写同一个文件，如果我们要强行去通过 [inotify](https://man7.org/linux/man-pages/man7/inotify.7.html) 来监听文件变化来做实时处理得话，首先能否实时处理还是一个问题，其次 inotify 给整个系统带来的开销还是不小的（在频繁变动的情况下）
所以如果有高精度的监控需求，可能还是优先考虑需要在协议层做一些手脚，在有包传输/连接变动的时候，触发特定的事件回调来做
目前一些能监控进程级别连接状态的工具，如 [nethogs](https://github.com/raboof/nethogs) 是依赖 [libpcap](https://github.com/the-tcpdump-group/libpcap)（这货也是 tcpdump 的核心）来根据包传输，连接建立等事件发生地时候触发特定的处理逻辑。而 libpcap 是基于 BPF (应该是没扩展之前的 cBPF）来在内核中打点做协议栈监控
所以考虑后续其余的一些自定义的监控的话，估计还是会考虑基于 eBPF 来做。不过估计不会像 Cilium 那种直接做一套全家桶。可能更类似于头条落地的 Sysprobe 那种专注于系统监控的东西。
IETF Datatracker
RFC 6298: Computing TCP's Retransmission Timer
This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of…
分层和解耦对我的诱惑太大了, 最近写业务有一些想法.
##
比方说一个服务有两种协议 http 和 grpc, 再加上一个 cli 吧, 算是三种完全不同的 UI 层了, 共享同一个 App 层的函数:
这个函数的参数已经够多了, 理论上来说, 我需要用一个 struct 来统筹一下, 比如叫 CreateOptions 的类型, 不过最核心的问题是, 这个 CreateOptions 类型在哪一层?
如果在下层 Model, 属于建模的一部分, 那么模型泄漏了, App 层知道得太多了; 如果放在当前 App 层, 那么下层又会依赖上层, 下层对上层的非接口耦合又让我感到不适, 依赖倒置原则说的可是接口.
当然直接使用领域模型的好处也是显然的, 简化参数就不说了, 首先我们有了更可靠的类型检查, 其次对于返回类型更加容易.
来说第二点, 看上面的代码里返回的是
第一种做法, 返回接口, 这种接口取决与更上层 UI 的使用; 比方说我们有两个 UI, 一个是 http 返回 JSON 一个是 grpc, 那么我们根据业务把 UI 层感兴趣的字段抽出来, 实现一个 interface:
这样这个 App 层的函数就变成了:
注意这时候虽然下层 App 依然要依赖上层 UI 定义的接口 InstanceProvider, 但是这是符合依赖倒置原则的, 没有任何的硬耦合.
然后 UI 层就可以放肆地调用接口定义的方法来填充自己的 Presentation Model, 而不用知道调用的真实的类型:
grpc UI 就不写了, 类似.
要注意 App interface 的定义也是在 UI, 而实现是在 App 层, 这是标准的依赖倒置, 就不说了.
另一种做法可能是传入一个接口对象, 比如叫 InstanceInterest:
然后传入 App 的函数:
在 App 层最后调用 InstanceInterest 的方法来通知上层; 此时的 App 的类型依然没有模型泄漏, 耦合也是下对上的接口, 很好.
我个人更倾向方案一, 方案二的这种
##
App 作为 Model 的客户端应该是很轻的一层, 但是我的主要问题是事务.
比方说具体的业务是要通过 Kubernetes SDK 去创建 Nginx, 同时管理好自己的元数据, 那么至少有两种流派:
第一种是先做事, 再创建元数据:
为了实现事务, 必须用 defer 处理"创建好容器但是写元数据失败"的情况; 当业务恶心的时候, App 层的实现简直不看入木.
或者, 第二种我们先写元数据:
这时候我们先建模, 上来先创建一个内存对象 nginx, 然后先存元数据再说, 最后再操作副作用.
如果我们再把 postCreateNginx 扔到单独的 goroutine 运行, 然后定义 nginx 对象的生命周期, 那就太美好了:
有限状态机可以搬出来了, 这时候事务已经被压缩到最小化, 你发现我们没有 defer 处理回滚, 因为事务只有一件事"写元数据", 而创建容器是单独的后台运行的, 运行后无论成功失败都记录到元数据里, 如果本身要做的事情特别多的话, 定义生命状态周期, 分步进行, 记录状态, 比一个巨大的事务可控得多.
而对上层和客户来说, 如果有一个 web ui, 这种异步模式也友好得多, 用户创建后能立刻看到自己创建的东西和状态, 而不是等浏览器响应等个两分钟, 都不知道是网络问题还是什么问题, 也不敢刷新怕重复创建.
DDD 里反复强调小聚合, 多做最终一致性, 这里也能有体现.
而且 App 层也会变得特别简单, "express user story", "simple invocations" 都能得以实现.
要是再 DDD 一点的话, 这里该上领域事件了, 或者 Event Bus, watever, remote 地处理的话, 那整个架构又可以 FaaS 化, 因为 event 驱动本身就很好 FaaS 化, 加上每个 event 的事务单一, 对于失败的创建, 无论是人工触发补偿或者回滚都没问题, 或者有有个 event center 做自动补偿回滚; 不过无论哪样, 我们的事务是能保证的, 也就是说不会出现 dangling container (容器在跑了但是没有记录下元数据) 或者 empty instance (元数据记录但是容器没有), 或者是一失败就 cascade delete 把啥都删了你都不知道怎么 debug; 精细化的生命周期管理, 小事务小聚合, 不管怎么做都好.
from https://gist.github.com/jschwinger23/38d8b5c7d35ba0b8bf58564357f8f448#file-layer-and-decouple-md
##
UI -> App比方说一个服务有两种协议 http 和 grpc, 再加上一个 cli 吧, 算是三种完全不同的 UI 层了, 共享同一个 App 层的函数:
type App interface {
func CreateInstance(name string, count, memory, cpu int, network, podname string, dns, env []string) *Instance
}
这个函数的参数已经够多了, 理论上来说, 我需要用一个 struct 来统筹一下, 比如叫 CreateOptions 的类型, 不过最核心的问题是, 这个 CreateOptions 类型在哪一层?
如果在下层 Model, 属于建模的一部分, 那么模型泄漏了, App 层知道得太多了; 如果放在当前 App 层, 那么下层又会依赖上层, 下层对上层的非接口耦合又让我感到不适, 依赖倒置原则说的可是接口.
当然直接使用领域模型的好处也是显然的, 简化参数就不说了, 首先我们有了更可靠的类型检查, 其次对于返回类型更加容易.
来说第二点, 看上面的代码里返回的是
*Instance, 其实就是模型泄漏了; 但是如果你真的要返回一个有信息量的东西而不仅仅是 ID 什么的, 也不是 mapstringinterface{} 这种不反射都不知道怎么遍历的东西, 那么工作量一下就大起来了.第一种做法, 返回接口, 这种接口取决与更上层 UI 的使用; 比方说我们有两个 UI, 一个是 http 返回 JSON 一个是 grpc, 那么我们根据业务把 UI 层感兴趣的字段抽出来, 实现一个 interface:
type InstanceProvider interface {
ProvideID() string
ProvideStatus() string
}
这样这个 App 层的函数就变成了:
type App interface {
func CreateInstance(name string, count, memory, cpu int, network, podname string, dns, env []string) InstanceProvider
}
注意这时候虽然下层 App 依然要依赖上层 UI 定义的接口 InstanceProvider, 但是这是符合依赖倒置原则的, 没有任何的硬耦合.
然后 UI 层就可以放肆地调用接口定义的方法来填充自己的 Presentation Model, 而不用知道调用的真实的类型:
func (ui *UI) CreateInstance(w http.ResponseWriter, r *http.Request) {
provider := ui.app.Create(r.FormValue("name"))
model := newHTTPPresentModel(provider)
fmt.Fprintf(w, model.toJSON())
}
grpc UI 就不写了, 类似.
要注意 App interface 的定义也是在 UI, 而实现是在 App 层, 这是标准的依赖倒置, 就不说了.
另一种做法可能是传入一个接口对象, 比如叫 InstanceInterest:
type InstanceInterest interface {
InformID(string)
InformStatus(string)
}
然后传入 App 的函数:
type App interface {
func CreateInstance(name string, count, memory, cpu int, network, podname string, dns, env []string, interest InstanceInterest) error
}
在 App 层最后调用 InstanceInterest 的方法来通知上层; 此时的 App 的类型依然没有模型泄漏, 耦合也是下对上的接口, 很好.
我个人更倾向方案一, 方案二的这种
value-result 模式太 C 了; 不过如果真的没那么介意模型泄漏的话, 也是可以忍受 App 层类型直接使用领域模型, 这里讨论的是"如果我一定不使用领域模型"怎么办.##
App -> ModelApp 作为 Model 的客户端应该是很轻的一层, 但是我的主要问题是事务.
比方说具体的业务是要通过 Kubernetes SDK 去创建 Nginx, 同时管理好自己的元数据, 那么至少有两种流派:
第一种是先做事, 再创建元数据:
func (a *App) CreateNginx(name string) NginxProvider {
virtualization, err := a.orchestrator.CreateVirtualization(...)
defer func() {
if err != nil {
a.orchestrator.RemoveVirtualization(virtualization)
}
}()
err = a.store.Save(virtualization)
return virtualization
}
为了实现事务, 必须用 defer 处理"创建好容器但是写元数据失败"的情况; 当业务恶心的时候, App 层的实现简直不看入木.
或者, 第二种我们先写元数据:
func (a *App) CreateNginx(name string) NginxProvider {
nginx := newNginx(name)
a.store.Save(nginx)
a.postCreateNginx(nginx)
return nginx
}
这时候我们先建模, 上来先创建一个内存对象 nginx, 然后先存元数据再说, 最后再操作副作用.
如果我们再把 postCreateNginx 扔到单独的 goroutine 运行, 然后定义 nginx 对象的生命周期, 那就太美好了:
func (a *App) postCreateNginx(nginx) {
if err := a.orchestrator.CreateVirtualization(nginx); err != nil {
nginx.UpdateStatus(Created)
} else {
nginx.UpdateStatus(CreateFailed)
}
}
有限状态机可以搬出来了, 这时候事务已经被压缩到最小化, 你发现我们没有 defer 处理回滚, 因为事务只有一件事"写元数据", 而创建容器是单独的后台运行的, 运行后无论成功失败都记录到元数据里, 如果本身要做的事情特别多的话, 定义生命状态周期, 分步进行, 记录状态, 比一个巨大的事务可控得多.
而对上层和客户来说, 如果有一个 web ui, 这种异步模式也友好得多, 用户创建后能立刻看到自己创建的东西和状态, 而不是等浏览器响应等个两分钟, 都不知道是网络问题还是什么问题, 也不敢刷新怕重复创建.
DDD 里反复强调小聚合, 多做最终一致性, 这里也能有体现.
而且 App 层也会变得特别简单, "express user story", "simple invocations" 都能得以实现.
要是再 DDD 一点的话, 这里该上领域事件了, 或者 Event Bus, watever, remote 地处理的话, 那整个架构又可以 FaaS 化, 因为 event 驱动本身就很好 FaaS 化, 加上每个 event 的事务单一, 对于失败的创建, 无论是人工触发补偿或者回滚都没问题, 或者有有个 event center 做自动补偿回滚; 不过无论哪样, 我们的事务是能保证的, 也就是说不会出现 dangling container (容器在跑了但是没有记录下元数据) 或者 empty instance (元数据记录但是容器没有), 或者是一失败就 cascade delete 把啥都删了你都不知道怎么 debug; 精细化的生命周期管理, 小事务小聚合, 不管怎么做都好.
from https://gist.github.com/jschwinger23/38d8b5c7d35ba0b8bf58564357f8f448#file-layer-and-decouple-md
说一个最近遇到的坑吧
我们一个测试服务，Spring Cloud 的，在下线后，节点无法从注册中心摘除，然后百思不得其解，最后查到问题，，
本质上是这样，POD 被摘除的时候，K8S Scheduler 会给 POD 的 ENTRYPOINT 发一个 SIGTERM 信号，然后等待三十秒（默认的 graceful shutdown 超时实践)，还没响应就会 SIGKILL 直接杀
问题在于，我们 Eureka 版的服务是通过 start.sh 来启动的，ENTRYPOINT ["/home/admin/start.sh"]，容器里默认是 /bin/sh 是 fork/exec 模式，导致我服务进程没法正确的收到 SIGTERM 信号，然后一直没结束就被 SIGKILL 了
解决方法其实很简单在 Deployment 上加了一个 lifestyle 中 pre stop 的hook。
pid=$(ps aux | grep spring | grep -v grep | awk '{print $2}')
kill -TERM $pid
然后在框架里捕获事件，在Eureka 上下线
当然在容器中的东西，还是建议用 exec 来做启动。。。不然后患无穷。。
我们一个测试服务，Spring Cloud 的，在下线后，节点无法从注册中心摘除，然后百思不得其解，最后查到问题，，
本质上是这样，POD 被摘除的时候，K8S Scheduler 会给 POD 的 ENTRYPOINT 发一个 SIGTERM 信号，然后等待三十秒（默认的 graceful shutdown 超时实践)，还没响应就会 SIGKILL 直接杀
问题在于，我们 Eureka 版的服务是通过 start.sh 来启动的，ENTRYPOINT ["/home/admin/start.sh"]，容器里默认是 /bin/sh 是 fork/exec 模式，导致我服务进程没法正确的收到 SIGTERM 信号，然后一直没结束就被 SIGKILL 了
解决方法其实很简单在 Deployment 上加了一个 lifestyle 中 pre stop 的hook。
pid=$(ps aux | grep spring | grep -v grep | awk '{print $2}')
kill -TERM $pid
然后在框架里捕获事件，在Eureka 上下线
当然在容器中的东西，还是建议用 exec 来做启动。。。不然后患无穷。。
- 安全地干掉 Windows Defender
- 关闭 SmartScreen
- 删除 Edge 浏览器
- 更新 Edge Webview2（很多软件都需要这个）
这个 开源项目 收集了 Windows11 设置、优化和一些脚本，禁用WindowsDF 只推荐联想那个小工具，最安全，不影响系统更新和完整。截图的工具叫做 Windows11 轻松设置，Google 一下就能找到。
via: @dejavuBlog @dejavuGroup
你每天拼命刷的Agent资讯，99%都在浪费时间。
几天前我听了一场AI圈大神Karpathy的分享，收获很多。
先说这个人。Karpathy是AI圈的传奇人物之一，OpenAI的创始成员，帮马斯克打造了特斯拉的自动驾驶系统。可以说，地球上没几个人比他更懂AI。
但就是这样一个顶级玩家，在这场分享里泼了AI的冷水，现在所有媒体都在吹“Agent元年”，可现实是，我们离那个能真正帮你干活的Agent，还远得很。
为什么？因为现在的AI，根本不智能。
Karpathy提了个特别有意思的比喻。他说，人们总喜欢把AI比作动物，觉得它能像动物一样学习、进化、拥有智慧。可这是个巨大的误会。
他举了个例子。
斑马，生下来几分钟就能跑，那是几十亿年进化写进DNA的结果，是本能。动物的智能，是大自然这台超级计算机，花无数世代打磨出来的“出厂设置”。
而AI呢？
我们只是把互联网上的文字、图片、代码统统喂进去，然后训练出一个能模仿人类表达的模型。
它没有真正的记忆，它的所有“知识”，都只是对人类数据的模仿。
所谓的“预训练”，本质上是我们工程师粗糙模仿进化的一种办法。跟自然界的鬼斧神工比起来，这种方法既笨又短视。
这也解释了，为什么今天的AI会给人一种看起来聪明、用起来不聪明的感觉。
你给它一段文字，让它总结，它做得很好。因为信息就在上下文窗口里，它可以精准地抓取内容，这个过程就像人类的短期记忆。
可当你关掉对话框，第二天再问同样的问题，它就全忘了。因为它没有把短期记忆存进长期记忆的机制。它所谓的“长期记忆”，只是那几千亿个固定的参数。
而在人类大脑中，“海马体”会在睡眠时把当天的记忆整理、归档、保存。AI没有这一环节，所以你没法“教”它任何东西。每次对话，都是从零开始。
除了记不住，它还学得很笨。
Karpathy分享了他自己创业做nanochat（一个轻量版ChatGPT）的经历。
他本以为AI代码助手能帮上大忙，结果发现几乎没用。
因为他在做的是一个完全新的产品，很多代码网上根本没有。AI助手只会生搬硬套它见过的标准答案，比如非要用某个熟悉的框架，结果搞得一团糟，还常常调出过时的API。
这说明，AI擅长做模式化、可重复的事情，但一旦碰到真正需要创造力的场景，那些世界上从未出现过的内容它就完全无从下手。
更关键的问题，在于它的学习方式。
我们都听过强化学习（RL），AlphaGo就是靠它击败人类的。
可Karpathy说，强化学习的效率其实极低。
他举了个通俗的例子。
你让AI做一道数学题，它写了一百步，最后你只告诉它：对，或者错。
如果答案对了，它就会把那一百步都当作“正确”，权重全部调高。可事实上，其中可能有一半都是瞎蒙的。
久而久之，它的学习过程就充满了噪音。
他还讲了一个真实的笑话。
有一次，一个AI系统为了拿高分，学会了输出一串乱码“dhdhdhdh”。
因为它的“考官”是另一个AI，而这串乱码刚好触发了评分系统的bug，被误判为满分。
这意味着，AI根本不理解什么是对。
这就是我们今天面对的AI真相：记性差，学得慢，没创造力。
所以Karpathy才说，别信什么Agent元年。
现在的AI，离真正的智能还差几个数量级。
他在特斯拉时学到一个特别有启发的原则，叫“The March of Nines”。
意思是：要做出一个90%准确率的自动驾驶系统不难，但从90%提升到99%、再到99.9%、再到99.99%，每多一个9，你都要付出十倍以上的努力。
因为每一个9，代表你要攻克那些极端、罕见、复杂到几乎无法预料的问题。
而今天的AI，还远远停留在第一个9的阶段。
by @MemeInformation #科技圈大小事
几天前我听了一场AI圈大神Karpathy的分享，收获很多。
先说这个人。Karpathy是AI圈的传奇人物之一，OpenAI的创始成员，帮马斯克打造了特斯拉的自动驾驶系统。可以说，地球上没几个人比他更懂AI。
但就是这样一个顶级玩家，在这场分享里泼了AI的冷水，现在所有媒体都在吹“Agent元年”，可现实是，我们离那个能真正帮你干活的Agent，还远得很。
为什么？因为现在的AI，根本不智能。
Karpathy提了个特别有意思的比喻。他说，人们总喜欢把AI比作动物，觉得它能像动物一样学习、进化、拥有智慧。可这是个巨大的误会。
他举了个例子。
斑马，生下来几分钟就能跑，那是几十亿年进化写进DNA的结果，是本能。动物的智能，是大自然这台超级计算机，花无数世代打磨出来的“出厂设置”。
而AI呢？
我们只是把互联网上的文字、图片、代码统统喂进去，然后训练出一个能模仿人类表达的模型。
它没有真正的记忆，它的所有“知识”，都只是对人类数据的模仿。
所谓的“预训练”，本质上是我们工程师粗糙模仿进化的一种办法。跟自然界的鬼斧神工比起来，这种方法既笨又短视。
这也解释了，为什么今天的AI会给人一种看起来聪明、用起来不聪明的感觉。
你给它一段文字，让它总结，它做得很好。因为信息就在上下文窗口里，它可以精准地抓取内容，这个过程就像人类的短期记忆。
可当你关掉对话框，第二天再问同样的问题，它就全忘了。因为它没有把短期记忆存进长期记忆的机制。它所谓的“长期记忆”，只是那几千亿个固定的参数。
而在人类大脑中，“海马体”会在睡眠时把当天的记忆整理、归档、保存。AI没有这一环节，所以你没法“教”它任何东西。每次对话，都是从零开始。
除了记不住，它还学得很笨。
Karpathy分享了他自己创业做nanochat（一个轻量版ChatGPT）的经历。
他本以为AI代码助手能帮上大忙，结果发现几乎没用。
因为他在做的是一个完全新的产品，很多代码网上根本没有。AI助手只会生搬硬套它见过的标准答案，比如非要用某个熟悉的框架，结果搞得一团糟，还常常调出过时的API。
这说明，AI擅长做模式化、可重复的事情，但一旦碰到真正需要创造力的场景，那些世界上从未出现过的内容它就完全无从下手。
更关键的问题，在于它的学习方式。
我们都听过强化学习（RL），AlphaGo就是靠它击败人类的。
可Karpathy说，强化学习的效率其实极低。
他举了个通俗的例子。
你让AI做一道数学题，它写了一百步，最后你只告诉它：对，或者错。
如果答案对了，它就会把那一百步都当作“正确”，权重全部调高。可事实上，其中可能有一半都是瞎蒙的。
久而久之，它的学习过程就充满了噪音。
他还讲了一个真实的笑话。
有一次，一个AI系统为了拿高分，学会了输出一串乱码“dhdhdhdh”。
因为它的“考官”是另一个AI，而这串乱码刚好触发了评分系统的bug，被误判为满分。
这意味着，AI根本不理解什么是对。
这就是我们今天面对的AI真相：记性差，学得慢，没创造力。
所以Karpathy才说，别信什么Agent元年。
现在的AI，离真正的智能还差几个数量级。
他在特斯拉时学到一个特别有启发的原则，叫“The March of Nines”。
意思是：要做出一个90%准确率的自动驾驶系统不难，但从90%提升到99%、再到99.9%、再到99.99%，每多一个9，你都要付出十倍以上的努力。
因为每一个9，代表你要攻克那些极端、罕见、复杂到几乎无法预料的问题。
而今天的AI，还远远停留在第一个9的阶段。
by @MemeInformation #科技圈大小事
