@Yadomin 解包出来的结果表示黑神话没用 lua ，脚本全用 C# 做的。

@hefish 当你的系统组件允许其他人扩展的时候，并且还要支持事务、并发读写的时候唯一解决方案就是类似注册表的东西，因为这玩意最好的解决方案就是一个树形数据库。即使在 Linux 上各 Desktop （如 gnome 等）都有自己的配置中心，这就是他们的注册表。
现在 Windows 的 packaged app 更是有注册表虚拟化，相互不影响，可以说最大的痛点已经解决了。而各种不明所以的 GUID 也在伴随着从 COM 转向 WinRT 的现代化而在慢慢减少。

@AX5N 你可以直接在 watch 那里加个表达式 *((unsigned char*)地址) 来看的。。

我猜你用的是 macOS 。macOS 上 chromium 更新失败后重启就会掉 cookies 。

先说调试器
1. 从内核态到用户态 app 全都能调试，而且还能远程调试别的机器（无论 Windows 还是 Linux 还是 macOS ），外加还能调试各种系统的 coredump ，这一点上首先就无敌了。
2. 在运行时 eval 任意的表达式，甚至牵扯到各种调用的复杂表达式都没问题。
3. 支持 hot reload ，是的，哪怕是 C/C++ 程序都能 hot reload ，调试运行过程中改几行代码可以直接瞬间应用更改，不需要重启 app 直接生效。
4. 支持倒着往前调试，比如你单步调试一不小心跳过去了，这个时候你用 VS 的话可以倒着单步回去，如同时光机一样。
5. 支持混合调试 C++ 和 C#，碰到有 FFI 的代码你可以从 C# 单步进 C++ 代码，也可以从 C++ 代码单步进 C# 代码。
6. SourceLink 支持直接加载来自网络的代码，比如你可以直接用 SourceLink 把你的代码和 GitHub 关联起来，别人调试你的程序的时候直接自动从 GitHub 加载源代码就能调试。

再说索引引擎
1. 拥有地表最快的 C/C++ 索引引擎，没有之一。毕竟 VS 最开始就是靠这玩意起家的。
2. 复杂模板/各种类型 trait 的推导能力也是顶级，clion/clangd 很多推不出来的玩意扔给 VS 就一点问题没有。
3. 我之前做 WinRT 开发，由于有个魔鬼模板展开导致给 std::hash<T> 整出来了 2000+ 个 overload ，VS 的补全引擎后台吃我 100% CPU 花了 10 多分钟给出来了完整结果；我试着换成了 clangd ，结果 clangd 遇到 std::hash 试图补全的时候整个进程直接崩溃异常退出了。

@NevadaLi pve 自带的那个只是 vm 管理工具，而 Windows Admin Center 是整个集群的服务器管理工具，vm 管理只是其中的一个功能。

@NevadaLi Windows Admin Center 是装在网关上用来管理集群的，这个网关的资源你得给够。反正我给了 2 核 4G 的资源给它用起来非常流畅。

关于 GPU 虚拟化，如果你用 Hyper-V 的话则可以通过 GPU-PV 来启用 GPU 分区和虚拟化，这样一块 GPU 就可以被多台虚拟机共享了。
不过 Linux 需要用微软那个 WSL2 的 kernel ，不然没有 GPU 驱动无法调用 Hyper-V 虚拟化出来的 GPU 。

@NevadaLi Windows Admin Center 了解一下，现在的 Windows Server 早就不需要 rdp 进去管理了。

@buynonsense 区别还是很大的。
安卓上非系统应用不具备后台访问剪贴板的权限，只有内置的系统应用才能做到无缝的剪贴板共享体验。
这个剪贴板共享不仅支持文字还支持图片，比如电脑上截屏完了手机可以直接粘贴，手机上收到验证码或者网址啥的复制之后电脑上直接粘贴。还有类似 airdrop 那样的功能，手机电脑之间一键互相传文件，而不需要打开任何 app 来做这件事情，简单的选中文件在菜单里选分享就可以。再有就是电脑上接打电话、收发消息、查看和管理通知都是没啥问题的。还可以把手机摄像头作为电脑摄像头来用等等。
至于 app 投屏反而是最不常用的功能。

我的 Windows on ARM 的 surface pro 11 也完全没有出现过这个问题，现在放一晚上耗电甚至连 5%都不需要。

建议在三星、荣耀，或者搭载了 ColorOS 的安卓手机里选，因为他们都在系统层面集成了 Windows 的 Phone Link 服务，能够做到和 macOS 与 iOS 一样体验的联动。

@billccn 纯粹是 x86 自己的电源管理做的烂。arm 的话即使是 Windows 现代待机也完全没这种情况，我手上的高通 X Plus 机器待机上个一天掉电连 5% 都不到。

@flysont USharp 不支持 UE5 ，但是解包的结果发现游戏科学自己给 USharp 适配了 UE5 ，并且还做了主机端的移植。

@ijrou 然而黑猴就是在 UE5 上用了 C# 啊。
UE5 只是官方没提供 C# 支持，但不妨碍社区里有各种把 C# 带到 UE5 里的方案，比如 USharp UnrealSharp UnrealCLR 等等。
况且前几天黑猴被解包从二进制层面确认是用的就是 C#，你再怎么不想承认也改变不了他们用的就是 C# 的事实。解包的程序集列表里甚至存在对 UnityCoreModule 和 ILRuntime 的引用，两者都是 C# only 的东西。
多了解一下不是坏事。

@DIMOJANG 日本用 pixel 的原因是之前联合运营商搞过活动办卡送 pixel 。现在活动没了也没有人会买 Google 的新机器。

三星四纳米，评价为电子垃圾。

@james122333 问题就在于错误/异常这种东西恰好不应该通过多返回值来解决，因为错误和正常是互斥的。go 硬是把一个需要用 sum types 表达的东西用 product types 表达了出来。
正确设计应该返回 Result | Error 作为结果，而不是 Result * Error 。

Go 的错误处理繁琐是一回事，更重要的是设计从根本上就是错误的。

result, err := foo()

一个函数是否发生错误只可能有两种情况，要么发生错误没有结果，要么不发生错误有结果。而 go 的设计直接给你来了个有无结果和有无错误的迪卡尔积，搞出来 4 种情况。
再有，如果你不去手动判断 err 是否为 nil ，则这个可能发生的错误就会直接被无时掉，意味着 go 的错误模型是默认无视掉所有错误。
这种用于错误处理设计不管出现在哪个语言里都是逆天的存在，与其说是错误处理，不如说它就是返回了个 tuple ，而实际上并不存在任何的错误处理机制。