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

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

result, err := foo()

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

@ersic 不至于，mac 不具备开发 Windows 驱动程序的能力。

@coldle 你需要 https://inc.sysu.edu.cn/article/1050

@nekoneko 其实 rdp 是 tcp 和 udp 混合使用的，虽然也支持只走 tcp 。

之前偶然发现的：如果你是用的 LG 显示器的话，卸载掉那个 LG 的 OnScreen Control 也许可以解决鼠标卡顿问题。

微软其实有这个功能，但是只是企业版限定。当你有 Microsoft 365 企业授权之后，在 Bing 登录你的工作账号之后就能用搜索了。它会直接集成你们整个企业的内容进行索引，所以直接就能搜出任何内部资料，并且还会根据每个人的权限不同过滤展示不同的搜索结果，问 Copilot for Microsoft 365 问题也是直接从你们企业资料作为数据来源结合搜索一起出结果。

软件是一样的，但是根据你的 IP 地址来决定用什么服务。
国内的 Windows PC 带到国外去，修改区域后 Edge 自动变国外版，如果还是连着国内的网络的话怎么改区域都没用。

Edge 。
可以直接 ctrl+shift+e 打开侧边栏搜索。同时还有垂直标签页。

@chanwang 签名自身当然是不需要钱的，要钱的只是那个证书，有了证书你想给哪个程序签就能给哪个程序签，签名工具就在 SDK 里，如果只是测试你生成个自签名证书都能签，直接配个 CI 自动签完全没问题。
类比一下写 web 上了 https 你不也得买 SSL 证书进行签名，虽然有一些免费的证书提供商。这对于代码签名的证书而言是同理的，证书同样是从各种根证书发行机构购买，微软收不到你一分钱。而且哪怕不是驱动程序，即使是普通的程序签名在今天来看仍然是有必要的，本质上就是信用链的问题。哪个正经软件公司还没个证书了。
另外驱动的 WHQL 认证是你自己在符合条件的环境（指驱动要跑在哪个版本的系统上）上部署你的驱动然后跑 Windows HLK 测试套件，这也是免费的谁都能获取，然后把产生的结果文件上传等审核就行了。而且 WHQL 认证也不是必须的，非 WHQL 认证的驱动只是不推荐，而不是不能直接装。
至于说的收费的那些估计懒得自己搞直接找第三方服务提供商帮忙跑测试了。

@chanwang 要不要证书签名和能不能开源是两回事，买个证书后签名就是自己跑个签名工具的事情，这玩意到处都有卖的，都不用跟微软联系，跟 https 的 ssl 证书类似。

@sagaxu 那些 benchmark 都是在用空间换时间，当然内存占用大，对于内存占用水平而言没有参考意义，难道 c++的代码里直接在内存里打个表来优化性能，而别的语言的实现里没有这么做，导致 c++占用大就能说明 c++内存占用大了？

另外，.net 的内存占用一般要比 java 小一个数量级，比如 op 的测试代码原样翻译成 c# 后测试，

这是 .net：

https://i.imgur.com/fuoiEne.png

这是 java：

https://i.imgur.com/IOEaiX7.png

@hez2010 这样万一真的出了问题，结论也是：“这个问题非常的隐蔽，尽管我们已经使用了一切手段来避免问题的发生，但是还是发生了，这是没有办法的事情”。

一切现有的制度都是前面的教训总结下来的。
如果没有这么多流程的话，你轻松一行改完 commit 进去出事故了，那恭喜你喜提权责。
之所以有这么多的流程，一方面是为了尽可能把更改提前通知到所有人，另一方面也是为了把责任分散到整个团队，这样出问题了责任不会全都落在你一个人头上。

@yolee599 var 也不是通用类型。var 的类型是静态推导的，跟你直接写 int 和 string 没区别，编译的时候会被编译器自动替换成实际类型。

@geelaw 随手往注册表写了个 9w+长度的环境变量进去：


可以看到 powershell 能够正常读出来并算出来长度，而 cmd 读不出来直接变成空了，但是环境变量放在那里没有任何的问题并且生效了。
所以这个长度限制只是部分程序不支持那么长的环境变量，而不是系统本身不支持那么长的环境变量。

@geelaw 文档里写的这个限制是 practical limitation 。
环境变量长度没有任何限制，之所以文档里写了限制那只是因为某些软件只能使用那么长的环境变量，而不代表系统不支持。
同理，注册表实际上也并没有任何的长度限制，之所以文档里写了 key 的长度限制只是因为一些读写注册表的软件不支持那么长罢了。

@opengps 看提交大小反而是错的，我 mmap 一个 2T 的大文件提交大小立马变 2T ，但不见得他就真的占用了我 2T 的内存。

环境变量长度限制只是那个编辑器 UI 以及命令行工具 setx 限制的，系统层面并没有限制环境变量长度。
你可以绕过环境变量编辑器直接去注册表添加和修改环境变量。
当前用户的环境变量：HKEY_CURRENT_USER\Environment
系统的环境变量：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
想要多长就能多长