6 月 18 号才发货，好歹也得设备拿到手上再讨论吧。

wsa 之前是因为 Amazon 跑路了，应用提供商跑了那 wsa 自然根据协议也不能继续提供上面的软件。现在有腾讯来接手了就能继续提供 wsa 了。

跟什么语言没关系，哪怕是搜英文现在 Google 出来的搜索结果也很差，要么是不相关的要么是老旧的，与此同时 Bing 出来的搜索结果质量明显甩开 Google 几条街。
比如你搜索 postgresql in operator ，Google 出来的不是远古版本官方文档，就是长得像但实际上完全不相关的 QA ，要么就是第三方文档。而 Bing 出来的虽然也有第三方文档，但内动都是相关的，出来的官方文档也是最新版本的，旁边的 QA 以及 AI 总结也都是符合主题的。

Google：

Bing：

flutter 做的应用其实一眼就能看出来：
1. flutter 的滚动计算是基于帧的而不是时间的，因此在不同设备上体验不同，而且会出现不跟手的情况（微信的公众号订阅列表用了 flutter ，在部分设备上甚至会出现滚动倒转的问题）
2. flutter 的动画完全不匹配系统的原生动画，有时候你在系统里修改了动画方案等等到了 flutter 由于是自绘的根本不会遵守你修改后的方案；不同版本的系统动画其实也不一样，flutter 就没法体现出来差异性

软件是一样的，但是会根据你的 IP 地址来动态切换。

Project Panama 生动形象的展示了对于 Java 而言，修改语言来支持一些功能到底是多么难的事情。
就现在那个 FFM API ，查找导入符号全靠运行时动态查找，数据布局全靠 API 在运行时动态定义，传入 Java 这边的回调也得先反射拿到 MethodHandle 再传递，然后在 native 和 managed 两边传递数据先复制过去再复制回来。就不说到处复制带来的严重效率问题，光那一大堆的运行时动态 API ，Java 这是不打算让 FFM API 在 AOT 下用了？还是说 AOT 之后要带个解释器用来处理 FFM 的各种符号绑定、数据布局和调用约定问题？

我是直接买了个正版的卡巴斯基，反正安全软件是需要的，买哪个都是买（系统自带的 WD 对性能影响太大），最重要的是它带了个广告拦截功能。卡巴斯基的广告拦截是直接利用驱动在系统的网络协议栈上扫描流量进行过滤，对安装的任何软件都生效，因此 Google 再怎么作恶更新 manifest API 阻止广告拦截插件对我这个方案来说都不会产生任何影响。

@Huelse 我接下来要说的不是国内的情况。
首先是各家运营商对新用户都有很大的返现福利等等，一个用了一阵子换另外一个可以便宜很多，而且号码不会换。
就算不更换运营商，同一个运营商下的不同套餐（指套餐的品牌，而不是数据流量的多少）也是需要换卡的，有的时候需要移动数据更多就会换到移动数据更便宜的套餐上，有的时候需要电话更多就会换到电话更便宜的套餐上，有的时候需要境外漫游就会换到境外漫游便宜的套餐上。
至少我两年半内已经更换了有 4 次了，在家里躺床上就能办完的手续没必要非得在工作日跑运营商网点来办。

@Huelse 没用过 eSIM 的都觉得 eSIM 是伪需求，用过了就知道这玩意有多方便了。换套餐换卡换营运商直接在线办理，办完了之后立即生效。

MagicOnion 其实挺不错的，听说是走的 grpc 但是没用 protobuf 。

运行 dotnet-gcdump 会强制进行一次完整的 gen 2 GC ，建议你考虑一下升级 .NET 和 StackExchange.Redis 的版本。
.NET 5 已经终止支持了，建议直接升级到 .NET 8 观察，.NET 因为向后兼容做得很好升级就是改个版本号的事情。
另外从不 Unsubscribe 也可能是原因之一。

主要是 snap 如果好用的话那也就算了，就当是类似 app store 一样的玩意也不错。
然而问题就在于这玩意又慢 bug 又多。

用了几天 Arc 的感受就是，想要 Arc 的原生 UI ，但是又想要 Edge 的功能性。这世界上就没有一个浏览器既有 Edge 的功能性又有 Arc 的原生 UI 吗？

@pkoukk 这不是用筷子喝汤，这是面前给你摆一碗咖喱拌饭但餐具只有吸管。

@lvlongxiang199 C# 和 Java 两个带 GC 的语言都有析构函数。
尽管析构函数的调用时机不确定，但也是对于释放不属于 GC 的资源的一种保底机制。如果开发者忘记调用了例如 socket class 的 close 函数，那也可以由析构函数代替开发者调用来做到保底防止资源泄露。而 close 函数里可以顺便调用 GC 的 finalizer suppressing API 表示当前 class 不需要再执行析构函数，于是如果开发者自己已经调用了 close 了，则析构函数就不会被执行。

@CEBBCAT spec 里这么写了那也就是说设计如此，尽管这样也一样会导致开发者对于资源释放场景不得不写出多余的代码来让代码正确工作。

假设现在设计个锁，用 defer 来释放锁：

for ...
AcquireLock()
defer ExitLock()
// do something
result = ...

本应简简单单就搞定的东西，你也不得不写成：

for ...
result := func() {
AcquireLock()
defer ExitLock()
// do something
return ...
}()
// use result

于是但凡要用 defer 的时候都要想一下 scope 对不对，做 go 的代码生成的时候还得防御性的把但凡需要 defer 的地方都塞到一个匿名函数里来用，然后通过匿名函数的返回值来向外传递那一小块儿代码的执行结果（参考 https://v2ex.com/t/1036033 的 tryErr 部分的 codegen ）。

上面这还只是个简单的例子，如果你在 AcquireLock 和 ExitLock 之间用到了大量来自当前 block 之外的变量的话，在匿名函数里使用那些变量还会导致编译器需要捕获变量到闭包从而发生大量的拷贝。“只用两行”只是写代码时最简单情况的假象，而编译器要为了这两行做大量的工作包括不限于插入更多的控制流、捕获变量到闭包等等，这又是一个隐藏的性能陷阱。

这种情况只能说，要么是 defer 被我滥用了所以 defer 不适合用来做通用的资源释放；要么这是语言设计有问题留给用户来做 workaround 。

那你是没有遇到 go 的 defer 在作用域上的坑，比如这段代码：
package main

import "fmt"

func main() {
for i := 0; i < 5; i++ {
defer foo()
fmt.Println(i)
}
}

func foo() {
fmt.Println("foo")
}
会输出
0 1 2 3 4 foo foo foo foo foo ，而不是 0 foo 1 foo 2 foo 3 foo 4 foo

而别的语言的无论是 RAII 还是 try-finally 还是 using ，作用域都是显然的，会在当前 scope 结束的时候被调用。
这也就导致你没法直接用 go 的 defer 来做退出锁之类的操作，因为全都被 go 给你放到函数最后去了。

你只需要在组策略里把自动更新改成只下载不自动安装就行了。
这样既可以不关更新还能控制什么时候安装。

@wxf666 我测的单线程是 1 client 1 thread 1 concurrency 1 pipeline 的。