@industryhive malloc 视实现可能是内存池，由 libc 维护

几百核可还行，这发热量可能塞不到 1u 里去，会再多堆几台机器的，就变分布式系统了。

AOT/JIT 不是语言绑定的，Python 也有 pypy 是 JIT 运行时，js 方面 V8 更是重度使用 JIT 帮 Chrome 甩开其他浏览器八条街。
但目前 JIT 因发源较晚，发展程度不足。所以 JIT 理论上的优势未能充分发挥，目前来说还是 AOT 性能更高一筹。

主要是 Java 有冷启动的问题，一是需要载入内存的内容比较多，二是 JIT 有慢启动的情况，要有足够的信息才能更有效地优化。
这在个人主机里面就显得非常不 responsive
但服务器不在乎，单是把硬件全部检测完就远远超过 Java 的冷启动消耗，应用更是长期运行不会关的。
但又一重反转就是，现在的容器自动伸缩技术，依赖于启动速度，需要避免运行时依赖方便容器组装，所以可以看到放进容器里去的很多都是 golang 的。

顺便，我想问一下你怎么看 .net CLR 这种介于 AOT 和 JIT 之间的形式？（看到一说叫 NativeAOT ？）

usbeam 找域名列表（

决定下载服务器的似乎是 *.cm.steampowered[.]com
如有必要，可 steam://open/console 里输入 user_info 确认 IPCountry: CN
download_sources 可以看到下载地址。

@nodwang 对脚本进行签名；或者用 cmd 调用 powershell 并修改 Scope 级运行策略。

@markgor 优化是脏活累活，不靠经济利益驱动很难搞的，Oracle 确实有多得多的 SQL 优化器，据说其优化 pass 有 MySQL （分支前）的 10 倍以上。

这个数据量的话应当考虑从 price 而不是 product 开始 JOIN，即下面的 3.

还有两个思路
3. 把所有的 JOIN 的表换个方向。把 a LEFT JOIN b LEFT JOIN c 改成 c b a 。因为映射关系是从 price 开始一对一顺次映射到前几个表上去的，而且 price 表够小。
4. 改成 INNER JOIN，因为你必须要求了 price 存在。但应该和 2. 一样并没有效果。

我所知范围内，CouchDB 在写入时需要提供之前的 rev，类似 CAS 乐观锁。
应当是两个不同的机制，你提的这个问题我直觉上觉得更经典一些

@ysc3839 可以被自动化地反混淆

@icemanpro
@IsaacYoung 这两种静态内容的可以直接读 .data 提取。
就算加壳现场解密，也可以被 Procmon 秒破（直接读你的 syscall ）。

『字同』语言

@livid /go/promotions

GUI 分为三个部分，一个是 G，一个是 UI，一个是如何用 G 去做 UI
UI 设计是有专门的书籍的，甚至还专门细化出用户体验设计（简称 UE 或者 UX ）
G 的部分，计算机图形学。
至于如何用 G 去做 UI，哲学思想都一直在变，MVC 到 MVVM 中间经历了不少，我们能确保 MVVM 是最终形态了吗？

@binux 操作系统之上建立了 HTML+DOM+CSS 的方式，在这之上又建立了 MVVM 的数据流线。接口和库永远是可以封装的。

* 奇妙的优化：把数据库换成 Oracle （

且抛开这个
我先问一下 SELECT * FROM tbl_price price WHERE price.bookDate BETWEEN '2021-10-10' AND '2021-10-17' 有多少数据？耗时？

另外，逻辑上可行但依具体 SQL 实现不一定有效的优化：
1. 为 price 表冗余 productid spuid 和 skuid，并星形而非链形 JOIN 到多表来读 isActive （并行替换串行）
2. 不要先 JOIN 再 WHERE，而是 JOIN (SELECT * FROM tbl WHERE isActive=1 ) （本该被 SQL 优化器优化掉）

WHERE IN 似乎与 RIGHT JOIN 性能一致。俺怀疑 price WHERE 之后是个小表，应该小表驱动大表。

@toptyloo 我问的是如何，是怎么接到「当然」的？
1. 光学方案的话，首先不同的手机充满电的指示不同，不同的耳机盒也不能确保
2. 设备有电量接口的话…… 耳机盒有相应的 API 吗？
3. 我倒是刚想到了根据功率，应该是相对可靠的判据，但那样的话快充满时转涓流的技术方案是不是会导致充不满

不过如果限定在『反正我自己用，我只要支持我拥有的设备就行了』的话，光学方案倒也不是不行，也能解答你这个机器视觉判断耳机盒的问题。

话说回来我想到几个更难受的问题：
1. 顺序充电的话是不是会导致电量更低但后放上去的设备得不到及时充电？
2. 无线充电不会被屏幕（它里面显然有导体）影响吗？

你应该用 price WHERE ... 表驱动其他的，因为 price 表作了一个很窄的 WHERE，必要的话可以临时构造 SELECT * FROM price WHERE 表来驱动。
如果你 sku 有可能对应零个 price 的话这个 SQL 大部分的时间好像会花费在 JOIN 出来然后立马删掉。

@oxromantic 替换应是对前端透明的，不需要额外逻辑。
Tomcat 算是混合了一个编排工具？
编排工具如何返回它自身的信息应当是可以自定义的，而不是埋暗雷（但暗雷见得多了，Flask 也暗雷）。不过现在问题是科技树还没点到动态编译语言。

当然，如 #26，放 data 已经不 REST 了，本来的处理上就是 body 就是全部内容或者没有内容，甚至，尽管不那么典型，这个 URL 逻辑上是可以 cd 进去的（类似 WebDAV ）。
应当将这种状态和其他协议的 code/data 状态进行对应。gemini 更诡异一点（

@oxromantic 首先，PCF 似乎是 VMWare 的多个不同的东西的品牌名称？具体没搜到。k8s 是编排工具而不是容器。
其次，各类 load balancer 看上去也并不会抢 status code，而是尝试中间捕获 status code 来判断服务健康状况来安排重启和替换请求，这种情况下会修改的可不止是 status code，而是整个响应都会被替换。

@Deville 这就要 @鸦 karas 了