网络文章@202505
https://weibo.com/1670458304/Pu6Mp4XP0
最近我经常跑华南,深圳和广州,说实话,深圳是个好地方,但是精神上我觉得还是广州好,我在深圳的路上走,感受不到真爱的气息,那种生活的骚气,更多的是棒槌感,很专业的那种棒槌,没什么废话,你要什么,我要多少钱,这个城市有强烈的交易的味道,每个人都好像欠了十几个亿,强烈的现金流压力让深圳进入效率共振模式,凡是不合拍的都出局了,没什么感情,服务行业也没什么感情,但是很职业,他想知道你要什么,但也会给你一个报价,你同意就走下一步,不同意他会去找下一个人谈,由于没什么情绪价值,这个城市很包容,价值是这个城市的核心,感情不存在,先谈价值
但是到了广州,不一样,也有很多人想赚钱,比如餐厅,典型的比如那个餐巾纸,深圳和广州都是要收钱的,深圳的餐厅店主会跟你说,唉这个要收钱的喔,广州的老板也会说要收钱,但是会抱怨下材料有成本喔,关键是抱怨,体现了广州人在需求价值的时候还是有人性的,深圳没有人性,深圳是一个报价单城市,适合没什么情感波动的人去,也很公平,就是一个数字
另外深圳很干净,没有感情的那种感觉,像刚刚初始化的一个游戏,到处回响着你来挖宝啊,快来的生意,广州就没那么干净,有强子,会在你发呆的时候冒出来惹你,特烦,会造成某种波动,让你感觉你还是一个有感受的生物,你会感觉广州是一个有点意思的地方,就连地上的脏东西都能提现本地人的情绪,我就倒垃圾了,咋地了,广州人穿的拖鞋和深圳的也不一样,广州人穿拖鞋那是真穿,深圳这里穿拖鞋是下班穿,广州有自己的风格,深圳没有 ,深圳只有自己的模板,模板不是风格
当然两个地方都很好,太阳很好,作为盆地中年人,晒太阳是非常好的,只是说有人喜欢的风格不一样罢了,两个城市都是好地方,我仅仅是说下我的观察,
Rust turned out to be a great fit for DSQL. It gave us the control we needed to avoid tail latency in the core parts of the system, the flexibility to integrate with a C codebase like Postgres, and the high-level productivity we needed to stand up our control plane. We even wound up using Rust (via WebAssembly) to power our internal ops web page. 事实证明,Rust 非常适合 DSQL。它为我们提供了避免系统核心部分尾部延迟所需的控制能力、与 Postgres 等 C 代码库集成的灵活性,以及建立控制平面所需的高级生产力。我们甚至最终使用 Rust(通过 WebAssembly)为我们的内部操作网页提供动力。
We assumed Rust would be lower productivity than a language like Java, but that turned out to be an illusion. There was definitely a learning curve, but once the team was ramped up, they moved just as fast as they ever had. 我们原以为 Rust 的生产率会比 Java 这样的语言低,但事实证明这是一种错觉。学习曲线肯定是有的,但一旦团队的能力得到提升,他们就会像以前一样快速前进。
This doesn’t mean that Rust is right for every project. Modern Java implementations like JDK21 offer great performance that is more than enough for many services. The key is to make these decisions the same way you make other architectural choices: based on your specific requirements, your team’s capabilities, and your operational environment. If you’re building a service where tail latency is critical, Rust might be the right choice. But if you’re the only team using Rust in an organization standardized on Java, you need to carefully weigh that isolation cost. What matters is empowering your teams to make these choices thoughtfully, and supporting them as they learn, take risks, and occasionally need to revisit past decisions. That’s how you build for the long term. 这并不意味着 Rust 适合每个项目。现代 Java 实现(如 JDK21)可提供出色的性能,对许多服务来说绰绰有余。关键是要像做出其他架构选择一样做出这些决定:根据具体要求、团队能力和运行环境做出决定。如果您正在构建的服务对尾部延迟要求很高,那么 Rust 可能是正确的选择。但如果你是一个使用 Java 标准的组织中唯一使用 Rust 的团队,你就需要仔细权衡隔离成本。重要的是让团队能够深思熟虑地做出这些选择,并在他们学习、冒险以及偶尔需要重新审视过去的决定时为他们提供支持。这才是长期的建设之道。
(298) 全球第一网红 | 一遍撒钱 一边赚钱 | How? - YouTube
美国的老板考虑的东西就是不一样,从他说的那段话,我会花时间花精力花钱去培养一个是喜欢这个工作喜欢这份事业的人,哪怕是个小白,我也愿意花更多的时间去培养他,因为他真的会喜欢这份工作从而去做得更好,而相反的,我不会要一个有经验的,这里会那里也会,因为他可能不会喜欢这份工作,甚至保不准他会随时辞职, (热爱,可塑性)
他讲employee那一段的时候,真的句句都是真理, 初出茅庐但是富有passion + coachable + right cultural fit 的新手, 要比心高气傲带着10年经验的老油条好用!
https://weibo.com/5770151273/PtVhOAbSA
很多人都认为自己非常能吃苦,其实他们只是能吃体力上的苦,有几种苦他们还真的吃不下。比如说,独立思考吃脑力的苦,忍耐克制吃自律的苦,读书学习吃寂寞的苦,点头哈腰吃尊严的苦。可是恰恰是这四种苦,才真正分开了人跟人之间的差距。
https://weibo.com/1233486457/PpM1D1X3N
他进一步强调,随着AI工具处理更多低层次的编程任务,软件设计师的工作将更多地集中在设计上:"通过处理越来越多的低层次编程任务,软件设计师的工作将越来越多地转向设计。软件设计将变得越来越重要。这将占据开发人员时间的更大比例,这使得我们在大学里根本不教授软件设计这一点变得更加令人遗憾。"
这个观点揭示了一个悖论:尽管AI可能改变代码生成的方式,但它可能使真正的软件设计技能变得更加稀缺和宝贵。学校教授的技能可能正是将被AI工具取代的技能,而设计思维这一核心能力反而没有得到足够重视。
"我认为设计是一个分解问题。它是如何将一个大型复杂系统分解成可以相对独立实现的较小单元。当我做演讲时,我经常问人们,你认为计算机科学中最重要的理念是什么?对我来说,我认为是分解。这是贯穿我们在计算机科学中所做一切的关键。如何将大型复杂问题分解?这就是设计。"
John提出了处理复杂性的两种主要方法:一是完全消除复杂性,二是通过模块化设计隐藏复杂性。第一种方法是最强大的,但无法消除所有复杂性。第二种方法则是将相对复杂的事物放在一边,使得系统中的其他人不必意识到这种复杂性。
"好的软件设计会帮助我们应对复杂性。它既会给你消除复杂性的想法,也会通过模块化让大多数人不必意识到大部分复杂性的存在。"
这种思考框架帮助我们理解为什么某些设计决策比其他的更有效,它也解释了为什么适当的抽象和封装对于构建可维护系统如此重要。
他解释了这一现象的根源,特别是在顶尖大学的研究生中:"所有这些年来,一切对他们来说都很容易。他们总是在所做的一切中表现最好。在高中,他们比老师更聪明。在大学,也许和教授一样聪明,班上最优秀。他们头脑中冒出的第一个想法总是足够好,能获得优异的成绩。所以他们从来没有真正的动力去思考两次。"
John分享了自己设计TCL Toolkit时的经历,他花时间开发了两种不同的设计,最终选择了第二种:"在比较之后,我最终选择了第二个想法。老实说,这是我职业生涯中最好的想法之一。TickleTK受欢迎的原因之一是TK的API是一个非常简洁、简单而强大的API。而它是我的第二选择,是我脑海中出现的第二个想法。"
这个原则提醒我们,即使是经验丰富的设计师也应该挑战自己的第一直觉,探索替代方案,这往往会带来更好的结果。
"深度模块是我们对抗复杂性的杠杆。它通过提供非常简单的接口来实现这一点,使用该模块的人几乎没有认知负担,非常容易学习。但在模块内部,有大量的功能和复杂性对其他人隐藏。"John解释道。
他强调,深度模块捕捉了一种权衡:"基本上,这是接口复杂性和模块功能之间的权衡。你想要做的是,在最简单的可能接口下获得最多的功能。"
这个概念之所以强大,是因为它为评估设计决策提供了一个明确的标准。好的设计往往会创建深度模块,让使用者能够获得强大的功能,同时不必理解实现细节的复杂性。这种思维方式对于构建可维护和可进化的系统至关重要。
John谈到了在软件设计中一个被低估但至关重要的特质——共情能力,或者说能够从不同视角思考问题的能力。这一特质对于创建真正以用户为中心的设计至关重要。
"我认为一个真正优秀的设计师最重要的属性之一是,他们能够改变思维方式,从非常不同的视角思考问题。所以当我设计一个模块时,我会思考该模块的所有细节。但随后我可以改变思维方式,思考这个模块的用户,并意识到我不想了解那些细节。"
他进一步解释,这种能力不仅在工程环境中有价值,在社交环境中同样宝贵:"我认为这种技能在社交环境中有着巨大的价值,就像在工程环境中一样。能够从其他人的视角思考问题的能力。顺便说一下,我喜欢计算机科学的一件事是,人们认为我们是这些呆板、书呆子般的人,但我们在计算机系统中使用的许多想法实际上在社交系统中也有有趣的类比。"
克劳德 4 系统提示要点 — Highlights from the Claude 4 system prompt
我认识的最好的程序员 | Matthias Endler — The Best Programmers I Know | Matthias Endler
If there was one thing that I should have done as a young programmer, it would have been to read the reference of the thing I was using. I.e. read the Apache Webserver Documentation, the Python Standard Library, or the TOML spec. 如果说我作为一名年轻的程序员应该做一件事的话,那就是阅读我正在使用的东西的参考资料。例如,阅读 Apache 网络服务器文档、Python 标准库或 TOML 规范。
Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written. 不要去 Stack Overflow,不要问 LLM,不要猜测,直接查找源代码。很多时候,这些资料都会出人意料地通俗易懂、文笔优美。
https://weibo.com/5620754374/PrsmYbd12
上周看大卫翁老师讲中国播客的商业价值远逊美国,说到美国企业家和大公司几乎人手一个播客频道,把这个当做和C端沟通、树立品牌、宣讲理念的地方。我个人觉得播客因为深度、全面、细水长流,人很难在长篇输出里掩藏自己,所以能建立比较全面的认知,是一种branding。
但因为这个原因,我也认为这是永远无法类比的。中国的企业家、明星,想出名吗?想输出价值理念吗?我认为是不想的。
2019年之前,还是有“明星企业家”站在台前和大众沟通,总体来说氛围也是奋斗发财,有钱人在道德上不受特别的审视。2020之后,只有极少数行业能产生“明星企业家”了,其他企业家都轮流崩塌过,行业都高质量发展过,明星社死了一大半了,顶流就没几个还立在台前的,立在台前,必然不会说话。影响力的风险淋漓尽致,以至于影响力的好处无人问津。
顶流三缄其口,钱这个东西已经污名化了,怀璧之罪,无法自证清白。除了极少数行业,其他谁也不知道风险会什么时候降临,还能做活人的企业家不多了。一个掩藏不了自己想法的深度媒介,除了三不五时发新品的时候做一轮campaign,其他时候风险敞口太大了,没必要自我曝光。
这个无解,原因不多说。
这也是另一个吊诡的地方。一个全世界最崇尚读书、考试、奋斗、跃升阶层的地方,竟然不知道跃升完之后要干什么,无法画出受人尊重的、有持续性的、具体的、稳态的有钱人形象,来给小孩当奋斗榜样。于是“艰苦奋斗”就成为了一个有点tricky的表达,奋斗的过程是艰苦的,可以理解,但奋斗的目的不是继续艰苦啊?用什么picture去激励奋斗?
读了书干什么呢?
我觉得年轻人的迷茫里肯定是有这个潜在原因的,不调和
https://weibo.com/1932835417/PtloQ9k9i
马斯克是在胡搞。
最好的评论是:擦屁股只要厕纸的20%的面积,但是你要是按这个优化厕纸的面积,那你就会沾一手的屎。
分布式系统中的可转移故障 - Aleksey Charapko — Metastable Failures in Distributed Systems – Aleksey Charapko
In metastable failure, the extra unanticipated load activates a positive feedback loop that creates more load. This positive feedback loop is the sustaining effect that prevents the system from recovering when the initial trigger is resolved. We say that a system is in a metastable vulnerable state when it is possible to activate such a sustaining effect loop using a strong enough trigger. This state typically occurs at the higher system utilization, as the system has fewer spare resources to absorb the extra load of the trigger without activating the positive feedback mechanism. Opposite of metastable vulnerable state is a stable state, where the positive feedback loop is not possible, allowing the system to recover by itself when the extra load is removed. Note that a system in a stable state may still have a sustaining effect mechanism, but it is not strong enough to feed on itself and diminishes over time when the extra load is removed. 在代谢性故障中,额外的意外负载会激活一个正反馈回路,从而产生更多负载。这种正反馈回路是一种维持效应,当最初的触发因素被消除后,它将阻止系统恢复。我们说,当使用足够强的触发器就有可能激活这样一个维持效应环路时,系统就处于易变脆弱状态。这种状态通常发生在系统利用率较高的情况下,因为系统的备用资源较少,无法在不激活正反馈机制的情况下吸收触发器带来的额外负载。与易变脆弱状态相反的是稳定状态,在这种状态下不可能出现正反馈回路,当额外负载被移除时,系统可以自行恢复。需要注意的是,处于稳定状态的系统可能仍有一种维持效应机制,但这种机制的强度不足以自给自足,而且随着时间的推移,当额外负载被移除时,这种机制会逐渐减弱。
Current approaches for handling metastability often lack the full comprehension of the problem and its causes. For example, engineers often focus on the trigger that causes the failure and fail to realize the complicated positive feedback loops that are responsible for the scale of the failure. Fixing a trigger is a temporary solution that may only push the system higher into the metastable vulnerable zone and make the next crash even more severe. 目前处理惰性的方法往往缺乏对问题及其原因的全面理解。例如,工程师通常只关注导致故障的触发因素,而没有意识到造成故障规模的复杂正反馈回路。修复触发器只是暂时的解决方案,可能只会将系统推向更高的易陨落区,使下一次崩溃更加严重。
Unfortunately, replicating the failures and feedback loops is difficult, as many of the issues only manifest themselves at scale. This makes it ever so harder to fully understand the failures and develop efficient techniques for dealing with them. Furthermore, predicting the possibility of failure is difficult too. For instance, one can look for unexpected performance variations, and try to correlate them with other things going on in the system to learn the potential future triggers, but this still does not give the full predictive power of when a failure may happen. Improvements in our ability to predict and avoid metastable failures will also translate directly to efficiency gains because it will let us operate systems closer to their natural performance limits. 遗憾的是,复制失败和反馈回路非常困难,因为许多问题只有在规模化时才会表现出来。这就使得充分了解故障和开发高效的处理技术变得更加困难。此外,预测失败的可能性也很困难。例如,我们可以寻找意外的性能变化,并尝试将其与系统中正在发生的其他事情联系起来,以了解未来潜在的触发因素,但这仍然无法完全预测故障可能发生的时间。我们预测和避免可转移故障能力的提高也将直接转化为效率的提高,因为这将使我们的系统运行更接近其自然性能极限。
可代谢性与分布式系统 - 马克的博客 — Metastability and Distributed Systems - Marc's Blog
In Metastable Failures in Distributed Systems, Bronson et al correctly observe that these types of failure modes are well-known1 to the builders of large-scale systems: 在《分布式系统中的可转移故障》一书中,Bronson 等人正确地指出,这些类型的故障模式对于大规模系统的构建者来说是众所周知的 1 :
By reviewing experiences from a decade of operating hyperscale distributed systems, we identify a class of failures that can disrupt them, even when there are no hardware failures, configuration errors, or software bugs. These metastable failures have caused widespread outages at large internet companies, lasting from minutes to hours. Paradoxically, the root cause of these failures is often features that improve the efficiency or reliability of the system. 通过回顾十年来超大规模分布式系统的运行经验,我们发现了一类故障,即使在没有硬件故障、配置错误或软件错误的情况下,这类故障也会造成系统中断。这些可转移故障曾导致大型互联网公司出现大面积故障,持续时间从几分钟到几小时不等。矛盾的是,这些故障的根本原因往往是提高系统效率或可靠性的功能。
The disease is a serious one, but perhaps with the right techniques we can build systems that don’t have these metastable states. Bronson et al propose approaching that in several ways: 这种疾病很严重,但也许有了正确的技术,我们就能构建出不存在这些易变状态的系统。布朗森等人建议从几个方面着手:
We consider the root cause of a metastable failure to be the sustaining feedback loop, rather than the trigger. There are many triggers that can lead to the same failure state, so addressing the sustaining effect is much more likely to prevent future outages. 我们认为可代谢故障的根本原因是持续反馈回路,而不是触发因素。有许多触发因素会导致相同的故障状态,因此解决持续效应问题更有可能防止未来的故障。
This isn’t a controversial point, but is an important one: focusing on just fixing the triggering causes of issues causes us to fail to prevent similar issues with slightly different causes in future. 这不是一个有争议的观点,但却是一个重要的观点:只关注解决引发问题的原因,会导致我们无法防止今后出现原因略有不同的类似问题。
缓存、模式和不稳定系统 - 马克的博客 — Caches, Modes, and Unstable Systems - Marc's Blog
- Load testing typically isn’t enough to kick a system in the good loop into the bad loop, and so may not show that the bad loop exists. This is for a couple of reasons. One is that caches love load, and typically behave better under high, predictable, well-behaved load than under normal circumstances. The other is that load tests typically test lots of load, instead of testing the bad pattern for caches, which is load with a different (and heavier-tailed) key frequency distribution from the typical one. 负载测试通常不足以将好环路中的系统踢入坏环路,因此可能无法显示坏环路的存在。这有几个原因。一个原因是缓存喜欢负载,通常在高负载、可预测负载和良好负载的情况下比正常情况下表现得更好。另一个原因是,负载测试通常会测试大量负载,而不是测试缓存的不良模式,即与典型模式不同(且尾部更重)的关键频率分布负载。
Thinking about why CPU caches are good and (generally) immune to this problem is very instructive. It’s because of offered load. When you’re clicking away on your laptop, say designing a robot in CAD or surfing the web, you react to slowness by asking for less work. That means that slowness caused by empty caches reduces goodput, but also reduces offered load. The unbounded increase in concurrency doesn’t happen. 思考一下 CPU 缓存为什么很好并且(通常)不受这个问题的影响是很有启发的。这是因为提供了负载。当您在笔记本电脑上点击时,例如在 CAD 中设计机器人或上网时,您会通过要求减少工作来应对速度变慢。这意味着,缓存清空导致的速度缓慢会降低吞吐量,但同时也会降低提供的负载。并发性的无限制增长不会发生。
Good caches have feedback loops. Like back pressure, and limited concurrency. Bad caches are typically open-loop. This starts to give us a hint about how we may use caches safely, and points to some of the safe patterns for distributed systems caching. More on that later. 好的缓存有反馈回路。比如背压和有限并发。坏的缓存通常是开环的。这就开始提示我们如何安全地使用缓存,并指出了分布式系统缓存的一些安全模式。稍后会有更多内容。
通过图表改进基准 - 马克的博客 — Better Benchmarks Through Graphs - Marc's Blog
If we’re comfortable that graphs are a good way of modelling this problem, and random walks over those graphs4 are a good way to generate workloads with a particular shape, we can ask the next question: how do we generate graphs with the properties we want? Generating graphs with particular shapes is a classic problem, but one approach I’ve found particularly useful is based on the small-world networks model from Watts and Strogatz6. This model gives us a parameter p which, which allows us to vary between ring lattices (the simplest graph with a particular constant degree), and completely random graphs. Over the range of p, long-range connections form across broad areas of the graph, which seem to correlate very well with the contention patterns we’re interested in exploring. 如果我们确信图是模拟这一问题的好方法,并且这些图上的随机漫步 4 是生成具有特定形状的工作负载的好方法,那么我们就可以提出下一个问题:如何生成具有我们想要的属性的图?生成具有特定形状的图是一个经典问题,但我发现一种特别有用的方法是基于 Watts 和 Strogatz 的小世界网络模型 6 。该模型为我们提供了一个参数 p ,它允许我们在环形网格(具有特定常数度的最简单图形)和完全随机图形之间进行切换。在 p 的范围内,图的广泛区域会形成长距离连接,这似乎与我们有兴趣探索的争用模式密切相关。
In the procedure for creating these Watts-Strogatz graph, the targets of the rewirings from the ring lattice are chosen uniformly. We can make the degree distribution more extreme by choosing non-uniformly, such as with a Zipf distribution (even though Zipf seems to be a poor match for real-world distributions in many cases). This lets us create a Watt-Strogatz-Zipf model. 在创建 Watts-Strogatz 图的过程中,从环晶格中重绕的目标是均匀选择的。我们可以通过非均匀选择来使阶数分布更加极端,例如使用 Zipf 分布(尽管 Zipf 在很多情况下似乎与现实世界的分布不匹配)。这样我们就可以创建一个 Watt-Strogatz-Zipf 模型。
Good Performance for Bad Days - Marc's Blog
The core of what I tried to communicate is that, in my view, a lot of the performance evaluation community is overly focused on happy case performance (throughput, latency, scalability), and not focusing as much as we need to on performance under saturation and overload.
In fact, the opposite is potentially more interesting. For builders and operators of large systems, a lack of performance predictability under overload is a big driver of unavailability.
https://weibo.com/1401527553/HnKZrnXCu
作为一个讲文明懂礼貌说话温和的读书人,我偶尔也会表现得不太像读书人。
我有个老熟人,比我还温和,长得也面善。但他有个优势,他是东北人。虽然平时普通话说的特别好,但东北话也很流利。所以有朋友遇到无赖,比如欠钱不还什么的,就请他去出面,用东北话和别人交流。他一交流,事情就很容易交流好。
某个银行的人跟我说过,他们内部有看人下菜碟的培训。比如工作出错、理论上需要赔客户钱的时候,会根据客户的刺儿头指数来定赔偿金额。本来应该赔两万,如果发现是个好说话的,那就先赔五千试试,或者再拖一拖。如果发现是十级刺儿头,那么起码赔一万五,或者就赔足两万。
人类能演化到今天,贱是我们生存策略的一部分。当然有些人在有些时候能把这个贱压制住。但是啊,漫漫人生路,你这辈子一定会遇到贱人贱事。不止一个,不止十个,会遇到很多。同时呢,当人作为群体存在的时候,还可能出现群体性的贱,制度性的贱。所以,作为一个读书人,也应该学一学怎么面对贱人,怎么处理贱事。
在复杂系统中工作:我在谷歌工作时学到的东西 — Working on Complex Systems: What I Learned Working at Google
Recognizing whether a system is complicated or complex is really important. Indeed, we mentioned that complicated systems are by definition repeatable, while complex systems require unique and customized approaches. Therefore, if we try to apply a common solution to a complex problem, it may not lead to effective results. 识别一个系统是复杂还是复杂,这一点非常重要。事实上,我们提到过,复杂系统顾名思义是可重复的,而复杂系统则需要独特的定制方法。因此,如果我们试图用通用的解决方案来解决复杂的问题,可能不会取得有效的结果。
To summarize this section, complex systems: 本节总结复杂系统:
- Are difficult to understand just by looking at its parts separately. 单看其各个部分是很难理解的。
- Don’t always show their effects right away, consequences can be delayed. 它们的影响并不总是立竿见影,后果可能是延迟的。
- Don’t always improve as a whole when one part is optimized and changes can sometimes make things worse. 优化某个部分并不总能使整体得到改善,改变有时会使情况变得更糟。
- Can keep being influenced by past states, even after the original cause is gone. 即使在最初的原因消失后,仍会继续受到过去状态的影响。
- Can react to small changes with big or unexpected effects. 能对微小变化做出反应,从而产生巨大或意想不到的影响。
https://news.ycombinator.com/item?id=44008843
I think we are going to be seeing a vast partitioning in society in the next months and years. 我认为,在未来数月或数年内,我们将看到社会的巨大分化。
The process of forming expressions just is the process of conceptual and rational articulation (as per Brandom). Those who misunderstand this – believing that concepts are ready made, then encoded and decoded from permutations of tokens, or, worse, who have no room to think of reasoning or conceptualization at all – they will be automated away. 表达的形成过程恰恰就是概念和理性的表述过程(如布兰多姆所言)。那些误解了这一点的人–认为概念是现成的,然后通过符号的排列组合进行编码和解码,或者更糟糕的是,根本没有思考推理或概念化的余地–他们将被自动淘汰。
I don't mean that their jobs will be automated: I mean that they will cede sapience and resign to becoming robotic. A robot is just a "person whose work or activities are entirely mechanical" (https://www.etymonline.com/search?q=robot). 我不是说他们的工作将实现自动化:我的意思是,他们将放弃智慧,甘愿成为机器人。机器人只是一个 "工作或活动完全机械化的人"(https://www.etymonline.com/search?q=robot)。
I'm afraid far too many are captive to the ideology of productionism (which is just a corollary of consumerism). Creative activity is not about content production. The aim of our creation is communication and mutual-transformation. Generation of digital artifacts may be useful for these purposes, but most uses seem to assume content production is the point, and that is a dark, sad, dead end. 恐怕有太多的人被生产主义(这只是消费主义的必然结果)的意识形态所俘虏。创作活动不是内容生产。我们创作的目的是交流和相互转化。数字艺术品的生成可能对这些目的有用,但大多数用途似乎都认为内容生产才是重点,而这是一条黑暗、可悲的死胡同。
A very funny but tricky bug I came across recently (Still need to confirm in CI/CD env [[Bugfix] Fix avx512 unaligned store by dirtysalt · Pull Request #59035 · StarRocks/starrocks](https://github.com/StarRocks/starrocks/pull/59035))
if you write avx2 instruction like, compiler respects your intention and generates "unaligned store"
_mm256_storeu_si256((__m256i*)p, x);
however if you write avx512 instruction like, compiler maybe think you give a hint that `p` is aligned to 64B, and generates "aligned store"
_mm512_storeu_si512((__m512i*)p, x);
And according to gpt explanation, it's because definition of `__m512i` is
typedef long long __m512i __attribute__((__vector_size__(64), __aligned__(64)));
Here are the instructions that generated SIGSEGV
0x0000000029b7382e <+331>: je 0x29b7383d <starrocks::delta_decode_chain_int32_avx512(int32_t*, int, int32_t, int32_t&)+346> 0x0000000029b73830 <+333>: mov $0x40,%esi 0x0000000029b73835 <+338>: mov %rax,%rdi 0x0000000029b73838 <+341>: call 0x19824bf0 <__asan_report_store_n> => 0x0000000029b7383d <+346>: vmovdqa64 %zmm0,-0x180(%r13) 0x0000000029b73844 <+353>: vpxor %xmm0,%xmm0,%xmm0 0x0000000029b73848 <+357>: lea -0x100(%r13),%rax 0x0000000029b7384f <+364>: mov %rax,%rdx 0x0000000029b73852 <+367>: shr $0x3,%rdx 0x0000000029b73856 <+371>: add $0x7fff8000,%rdx
ETH Zurich Talk Jeff 2025.Apr14
Gemini Structure & Ways of Working
Many people in many locations:
- ~⅓ in San Francisco Bay Area
- ~⅓ in London
- ~⅓ in many other places:
- NYC, Paris, Boston, Zürich, Bangalore, Tel Aviv, Seattle, …
Time zones are annoying! “Golden Hours” between California/West Coast and London/Europe are important
Lots and lots of large and small discussions and information sharing conducted via Google Chat Spaces (I’m in 200+ such spaces)
RFCs (Request for Comment): semi-formal way of getting feedback, knowing what others are working on, etc.
Leaderboards and common baselines enable data-driven decision making about how to improve
- Multiple rounds of experimentation.
- Many experiments at small scale
- Advance smaller number of successful experiments to next scale
- Every so often (every few weeks), incorporate successful experiments demonstrated at largest experimental scale into new candidate baseline
- Repeat
https://weibo.com/1745358631/PpOLBuLNx
对于写作者来说,「阶级感」这个东西是无法靠想象力去弥补的。不说亲自经历过吧,你至少得亲自见过,才有可能写得出来。
因为不同的阶级之间遵循着不同的生活逻辑,而两边的人都认为自己的生活逻辑是「寻常」,这两套「寻常」很可能是完全相反的。
我第一次看《红楼梦》的时候,看到袭人的妈妈病重了,她要回家去,然后王熙凤过来亲自检查了一遍她的衣物首饰等等,我下意识地就以为王熙凤这是怕她夹带东西出去。
我就很困惑地去问朋友,这是为什么,贾府不是很有钱吗。朋友给我解释说,不是怕她偷东西,是怕她的衣物首饰不够富贵、体面、气派,她当时已经是按姨娘的规格回家去了,她代表的是贾府的脸面。
就这个逻辑和动机,你让我这个根本没看过大户人家怎么生活的人去想,不管怎么用力想,都是很难想得出来的。
想象力要有生活根基,没有根基的想象力就只是在纯胡说八道。