@tianhehechu 纯虚拟机跑倒也不必 还是失去了很多便捷性的 Win 的话用 NTFS 的高级权限功能 给 Cursor 开个专门的用户 然后细分一下权限(类似 Chroot Jail 或者说 Cgroups) 基本就可以限制住绝大部分离谱操作了 毕竟就算想动注册表 其实也是要动 C:\Windows\System32 下的东西的 花一点时间配置一下 搞定一个后 其他 Agent 类应用也照猫画虎就行 之后就省心了 放开了让它随便跑 也就不用因噎废食了

不是兄弟 你都用 Cursor 了 还在意 950G 硬盘取约保护隐私吗 这是否有点…

哈哈就是吐槽一下别介意

我感觉现在用 AI 的话 最好还是限制以下 agent 的写入权限比较好
允许它读取所有地方 但写入操作只能在工作空间/项目空间中以及特定目录比如 TEMP 下进行
前者用隐私换便捷(李彦宏表示同意) 后者讨个心安(agent 乱修改和写入真是血克系统洁癖患者)

(毕竟 agent 写 bash 还行但 PowerShell 就很拉 优先建议 wsl 也不是没道理的
不然就是各种出错乱动%USERPROFILE%和%APPDATA%甚至环境变量都给你删了
最离谱的莫过于 AI 在项目里生成自动化用的 Python 代码 然后用管理员权限来执行 直接绕过写 shell 命令 调用你的 py.exe 把你盘给删了)

以前也喜欢感慨十年前如何 但当时与十年这词绑定的数字大多是 2007~2012 底色也大抵暗含着时光飞逝物是人非

而现在提起十年却是 2016 可能那时的技术栈或名词于现今而言 变动不多 Win10 已是主力 VSCode 开始常驻 nodejs 写后端 js 也有了 es6 py 的 2.7 也逐渐转向 3.5 而主力语言的 C++ 也逐步开始迁移去了 Rust 前端虽总说变化快 但 Vue/Angular/React 鼎力也已初步成型 太多了 这一切相较于 2015 年以前 像是一道坎

不过或许也只是人岁渐长了 下意识地不愿用新玩意儿 才有这样的错觉吧

这十年似乎键盘也没敲多少下 随手的一个回车后 瞥了一眼系统时间 2016 就跳到 2026 了 多少感觉有些恍惚了

想了想 2026 年新开的后端项目好像都不怎么用 js 了(项目情况允许的话基本都 rust 写 axum 或 loco 了

不过偶尔还是会用用 之前是 koa2 到 koa3 后面基本都 hono 了 express 略重而大项目反倒又不会去用它

对于 node 的话 很小的项目就 bun 全家桶 deno2 倒是用得少(虽然兼容性上来了也支持了 npm 包)
而因为 bun 的兼容 所以 node 虽然依然会定期更新 LTS 版 但几乎不怎么用来开发了
(基本只用 npm i -g 装一些 cli 以及跑别人的项目

有个同事倒是十分喜欢用 deno2 写 ts 写什么都用 ts 命令行工具 跨平台 GUI(Electron 浏览器扩展/油猴
就算一些一次性脚本代码 用 python 更快 但只要能用 ts 写的 决不写其他语言 虽然不太能理解 但能看出也是真爱了

nuphy 不是因为这事 被喷了很久之后 才分开有线和无线两部分给固件了么 有线部分 fork 的 qmk_firmware 传到了 nuphy-src 的 github 上 蓝牙和 2.4G dongle 的只提供固件更新 至少这样确实遵守了协议(不严谨地说)

我只好奇 现在客制化圈子里 大家都知道 QMK 都知道 VIA 但那些卖套件的卖成品的宣传支持 QMK 的 VIA 的 连固件都不给 买了才给 via 的 json 文件 然而没看到有复数个用户或者博主去指责或者提一嘴这事 感觉好像大家心照不宣一样

QMK 开源了 强盗们抢 QMK 的东西 强盗们抢完拿去卖 诶他们做过的事他们清楚 一开源肯定被抢 然后更低价卖 哪个强盗愿意呢 我们的指责或者说那一(几)文 License 里的东西 对于他们来说根本就没有任何一点的代价需要为此付出

最后一看原来全都是强盗 装都不装了属于是

无脑 G27U 不喜欢再换 1500 同价位就那几个除了戴尔 s2725qs 飞利浦有 27E2N5900RW

最简化问题

先达成共识 看 nuphy 官网的宣传页面 https://nuphy.com/collections/keyboards/products/gem80 里面的图有标注键盘特色功能(主要是支持 qmk/via 以及有物理切换 Mac/Win 的开关)
我用的是 nuphy air60 v2 同一家的产品 理论上 qmk 固件的内容跟 gem80 应该是差不多的
Win 模式的默认层是第 3 层(0~7 共 8 层) 此问题不需要更多层 所以只考虑 mac 模式的层(即 0 、1 、2 层)

如果我没理解错楼主题意 即 nuphy gem80 默认的 mac 模式的默认层(0 层)的 F1~F12 默认是 mac 上的特殊功能 比如 F1 是亮度减(对应 via 的"Screen-" 在 SPECIAL 里) F3 是 task(对应 via 的"Mac Task" 在 CUSTOM 里) 单按一下 F2 就能亮度加 而 Fn+F2 键才是真正输出"F2"
但楼主希望 F2 键按一下就是"F2" 而非"Screen+" 反而 Fn+F2 键才是亮度加
Mac 模式下键盘上的 Fn 其实就是 0 层里(临时)切换至 1 层的 via 键"MO(1)" 按住切换后再按 F2 就是 1 层的 F2 键上的内容

*解：所以最直接解法就是 在原本默认没有动过 via 配置的初始情况下 将 0 层和 1 层的 F1~F12 直接一一对调 就完成楼主的需求了

补充：nuphy 因为比较往 Mac 用户上靠 所以连默认模式都是 mac 键帽图标也是 mac 的快截效果键(如 Mac Search 这个 F4 上的放大镜图标) 所以 CUSTOM 里也提供了多个 Mac 专用快捷键
另外 nuphy 的 via 就是 qmk 那个 所以能实现的效果很完整 加上对 Mac 的高适配 因此改键的自由度很高 基本你想实现的都能改(非常复杂的需要改 qmk 固件 但是应该是用不到的)

b 站搜一下 via 多层改键的视频就好了(比如 BV1jv4y1o7pk 或 BV1RV4y197s4)

对比字体渲染效果 不是应该
相同字体(如小米字体 MiSans 俩系统都改字体)
相同网页(或能调排版的软件)调好 css 字体参数(大小间隔字重等等)
同一屏幕下(24 寸 4k 苹果 hidpi 微软 200%缩放)
用手机的微距镜头拍屏幕字体吗？(非截图)
把结果图放上来 一切不就清楚了

我对现今 macOS 了解不深 还停留在几年前的黑苹果印象 但当时就是同一屏幕下(24 寸 4k)双系统(虽然都是默认字体)
因为是普通 IPS 屏 没有 oled(紫边)或其他屏幕等像素排列之类的差异
感觉苹果 UI 很舒适很有计感和整体性 但别人提到的字体渲染问题 我感觉两者都足够清晰锐利 没有字体边缘的各种问题(不过我更喜欢苹果默认字体)
(可能印象模糊了 但 Win10 的 1909 到现在 Win11 的 23H2 我感觉新软件的高分屏缩放导致的问题愈发减少了 至少现在很舒适)
所以我的个人浅显的主观结论是 Win 的 200%缩放下字体没问题 retina 级别屏下与 masOS 差异不至于有一眼的差距

@caobug #22
有讲清楚了就好 能对别人有帮助还是很开心的 : )

Rust 文章的话 不太好写 写起来时很难兼顾到不同熟练度的 Rust 小伙伴（主要还是我自己能力有限）

举个例子
就像一开始其实我想**直接**用 `while true {}`和`loop {}`为什么不一样 来解释这问题的（前者迭代 0+次 后者 1+次）
但是这样会引入题目中没提到的 while 语句 以及它们另外的差异（ loop-break <value>能返回值而 while 恒为`()`之类的） 最后还得再迁移到 for 语句来解释

这样就有可能将问题复杂化了 而如果跳过中间例子直接说“const_expr 在 borrowck 阶段不求值” 不熟悉的小伙伴有可能一下子转不过来

且问题涉及 if 语句 所以最后决定用`if false {}`作例子来渐进地解释 比较好理解

Rust 文章同理 讲一个点 从多浅讲到多深 我就有点犯难了
有的知识点实在涉及太多 比如 Pin 感觉没十几页纸实在讲不清楚 一想就头都大了 0.o

@DianQK #21
嗯呐 这个确实就是关键所在

若我没记错的话 似乎 rustc 的编译流程会有两次的常量折叠/传播 一次是在前端的 MIR 中 另一次是在后端如 LLVM 中
（好像是前端优化一次能降低给后端的 IR 代码复杂度）

MIR 中支持常量传播应该是比较早前的事了（或许有相关公告） 似乎是支持控制流的（代码可能在 mir 部分的 const_prop.rs ？文件名应该长得差不多）
但并不知道是否支持“消掉 if const_expr”的行为
（我不知道这种分支优化的术语应该是什么 死代码消除 Dead Code Elim ？或者是叫 Sparse Cond Const Prop ？中文可能是 稀疏条件常量传播 之类的 或许也不准确）

但比较尴尬的是 常量传播是在 MIR 的优化阶段进行的 而 borrowck 是在 mir-opt 之前进行的（如果我没记错的话）

所以正如老哥你所说的 常量传播时应该已经有借用检查了
（以及我感觉理论上应该确实是能在借用检查前算 const 的 就是不知道最终会不会增加 MIR 部分编译的总耗时）

编译流程层面的改动影响对 rustc 而言还是挺大的（如 Polonius 也只是 borrowck 部分的平替） 所以短期内可能不会有相应优化了（个人感觉 不知道目前有没有人提对应的 RFC ）


以上的话并不严谨 我也暂时没能去进行校验 或许会有些错漏或过时（记忆有点旧了）

有条件的朋友或许可以补充下相关链接~

@DianQK #17
或许有些区别
简单点概况，NLL(Non-Lexical Lifetimes)的迭代进化(即下一代的 Polonius)应该依然并不能解决此问题。

因为楼主这问题本质上是 rustc 编译流程的限制。如图： https://blog.rust-lang.org/images/2016-04-MIR/flow.svg
根据**目前**的编译流程，Borrow Checking 发生在 MIR 阶段，此刻的 CFG(Control-Flow Graph)仅将`if true {}`识别为`if some_cond {}`。
故而`if true { <code> }`无法等价于`loop { <code>; break }`或`{ <code> }`，因为它们的 CFG 是不一致的。（参考引用 数据流分析中的 CFG ）
最后将类似`if false {}`这样的死代码消除的优化行为，是在 LLVM 的 codegen 优化阶段进行的，所以此前 borrowck 并不认识"true"或"false"。

在 Rust 2018(Rust 1.31)引入 NLL 后，生命周期的推断精度更高了，而下一代的 Polonius 会支持更复杂的控制流(Control Flow)。但是如上所述的原由，依然不能在此阶段进行条件求值，所以问题依在。

* NLL: https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#non-lexical-lifetimes
* 编译流程中的 MIR: https://blog.rust-lang.org/2016/04/19/MIR.html
* 数据流分析中的 CFG: https://github.com/rust-lang/rustc-dev-guide/blob/master/src/appendix/background.md#what-is-a-dataflow-analysis
* rustc 概览(包含各编译阶段): https://rustc-dev-guide.rust-lang.org/overview.html


我希望能由浅入深解释问题，但无法太深。前面的回答并无涉及到更多的编译器部分的具体内容，是因太冗长容易导致阅读阻力大，很少人愿意认真看(完)。（但即使现在这长度，似乎大家也习惯 tl;dr 了）

希望我有解释清楚。 : )

FIX: @buxiuxi 第 9 项忘 at 了

综上

6. 楼主的代码符合 Rust 的所有权规则吗？符合的，因为问题并不在所有权转移上，而是在编译期所有权检查时是否会进行具体求值的判断上。

7. @DianQK 所以**目前**而言不是 bug ，或许以后编译器更聪明效率更高了就支持此优化了。

8. @binhb @qdwang @rrfeng 的说法是对的。

9. 为啥这里 release 函数会释放 dog ？因为 fn release(self)的参数是 self ，跟 std::mem::drop()一样，调用时会获取其所有权，并在此函数结束后 drop 掉。

续上

3. 对于 Code 3 ，即楼主的第一次修改尝试，实际上等价于将 loop 和 break 去掉（因为此控制流总是执行），所以必然会执行赋值语句，故而编译通过(Ok)。

4. 对于 Code 4 ，即楼主的第二次修改尝试，依然可以将 loop 和 break 去掉，此时情况等价于 Code 0 ，所以一样编译不通过(Error)。

5. 对于 Code 5 ，即 @Kaiv2 提到的编译成功的写法，因为 break 进去 if 里了，情况就不一样了。此时控制流的逻辑只有两种情况：情况一，若不进入 if 语句里，则无限循环，那么就不会执行后面的使用 person 及 person.dog 的代码了，就没问题；情况二，进入 if 语句，则成功执行赋值，且最后必定 break 出去，执行后面的代码，依然没问题。所以这种不涉及对具体求值有依赖的控制流是能编译通过的。

回到原问题，person.dog 的各种赋值写法：
https://i.imgur.com/Bs5I6kb.png

0. 对于 Code 0 ，即上一条回复提到的本质问题，此处尽管写着 if true ，然而 Borrow Checker 并不默认此代码总是执行，而是认为可能执行也可能不执行。（当然，当 build release 编译优化阶段时，if true 就会被优化掉了，而所有权检查阶段并不会，或许是太耗时了）

1. 对于 Code 1 ，与 Code 0 本质一样，Borrow Checker 会认为此 for 语句可能不会执行，所以“Rust 的检测器似乎没有认真评估 for 中的条件”确实是对的，并不会在此阶段评估。

2. 对于 Code 2 ，因为有 else 分支且调用 unreachable!()，所以理论上后续使用 person 时必然已经经过 if 部分的赋值语句（因为 else 部分会 panic ，即不会执行后面代码）

直接简化问题，此问题本质上，与下面代码无法编译通过的原因是一致的：
https://i.imgur.com/IH475bN.png

**即在编译期 Borrow Checker 是不进行具体值计算的。**

如上面的 if 分支，在生命周期检查期间，并不知道 1 == 0 总为 false 且永不执行此代码块。故而在使用 name 时，无法得知所有权是否已被转移。
甚至将 1 == 0 直接换成 false ，此期间 Borrow Checker 依旧不知道 false 总不执行代码块，即认为是**有可能**调用 drop(name)触发所有权转移的。

@uni @lanlanye @sdsaaeee 我也是因为新的类型标注功能，在今年将 3.8 升到 3.11 了。

目前截至 2023 年 10 月份，对 3.11 而言，库的兼容程度比预想中的要好。

@Mohanson @youthfir 另外 PyTorch 2.1.0 Stable 版本昨天发布了，已经支持了 Python 3.11 ，或许可以考虑升级了~

[PyTorch 2.1: automatic dynamic shape compilation, distributed checkpointing]( https://github.com/pytorch/pytorch/releases/tag/v2.1.0)

[Support Python 3.11 #86566]( https://github.com/pytorch/pytorch/issues/86566)
e

@kneo 对于前者，是的，GIL 都在。

原话的完全句子是 _“目前的 Per-Interpreter GIL 子解释器仅供使用 C-API 创建，而暂时并不支持仅使用 Python 代码创建。所以编写纯 Python 代码时 GIL 对多线程并行的性能影响尚在。”_ （请原谅我的措辞不当）

Faster CPython 的 Plan 中有提到使用 Python 代码创建此类子解释器 [Enabling subinterpreters from Python]( https://github.com/faster-cpython/ideas/blob/0905dcc8ba76ff1f49b173437f4bc9359aa5ca19/3.13/README.md#enabling-subinterpreters-from-python) 。

对于后者，是今年 1 月份创建的 PEP 中 [PEP 703 Making the Global Interpreter Lock Optional in CPython]( https://peps.python.org/pep-0703/) 提到的，但是否真能在明年 3.13-rc 版赶出来，感觉持悲观态度，要实现 `--disable-gil` ，看起来难度并不低。

@Kirscheis 现在能类型标注的都会标上 但写 Python 又希望简短精炼 写起来总有种左灯右行的冲突
(type hints 冗长显眼 typeCheckingMode 开 strict 时外部库对类型标注支持又不好一片标红 看着血压拉满)