@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 的。

其实分布式锁并不一定非得 lua 才能实现，我目前是把自己项目的 redis 换成了 garnet ，单纯就是把 redis pod 下掉然后换成 garnet ，其他啥也没动，一切正常。

虽然不知道 jetbrains 软件的运行的情况（毕竟我不用 jb 全家桶），我 M1 Pro 的 macOS 更新到 14.4.1 之后连 dock 和桌面都会随机卡死，尤其是从 launchpad 启动个软件的时候直接 dock 和桌面失去响应。

@sujin190 单线程的测试设置了 pipeline=1 ，意味着一次请求返回之后才会进行下一次请求。而多线程的 pipeline 设置的 1024 ，能够充分利用计算机资源。

我也跑过，用的 mentier_benchmark ，同样是 redis 自己出品的 benchmark 工具。

单线程：


多线程：


无论单线程还是多线程 garnet 都比 redis 更快。

你在公司里工作时间内所有的产出都属于公司。

手持日行 S23 ，用系统自带的睡眠功能把微信 QQ 以及国内那一大堆支付购物和短视频软件的后台活动限制掉，充一次电能用一天半到两天。如果不限制那些 app 的后台，不到 8 个小时就没电了。

1.24 还是太旧了，我这里用 1.29 。
k8s 经常会有 API 响应的破坏性变更，如果你用的版本太老了会导致一大堆操作 k8s 相关的库失效，因为他们没法解析新版本 k8s api 的响应里的 json 。

卸载掉所有的 explorer 第三方插件再看看。
这些插件的原理都是直接用逆向工程 hook explorer 的内部私有函数地址，然后 dispatch 到他们插件自己的代码上来实现各种功能的。explorer 哪怕只要稍微修改了代码使得内部的函数偏移之类的变化了，就会导致通过非法手段注入进来的第三方插件出现非法地址访问等等从而造成 explorer 崩溃。
只是退出插件没有用的，因为插件依然会试图注入 explorer ，只不过 dispatch 后的功能没启用罢了。