@villivateur 是啊，如果有一个不基于 Electron 的 VSCode 的话我会倾向于使用那个想象中的版本。

支持，天下苦 Electron 久矣

软件的新版本或许很容易延续很久，然而同一个版本的软件用很多年比较难。BibTeX 算是相当古老的软件了，最近的稳定版本是 2010 年 3 月，而且学术写作会经常使用。

从实用角度来说以文件的形式同步 OneNote 笔记到 OneDrive 是相当不可行的。

OneDrive 上通常的文件冲突会导致保存多个副本，或者选择一个副本保存而另一个副本删除，这无法处理多个修改的合并，为了解决该问题，Office 文档有自己的一套和 OneDrive 同步的方法。对于 OneNote 来说这是相当必要的，因为 OneNote 笔记并不是一整个文件，而是一堆文件夹和文件之间相关连组织的（一个分区是一个文件）。如果用普通文件同步的方式同步 OneNote 笔记，会有两个问题：

1. 多处修改的时候数据结构错乱，导致笔记本损坏——同理，你也不应该用 OneDrive 同步 Git 仓库，因为多处修改之后可能导致 Git 内部数据结构错乱而完全不能使用。
2. 修改一个页面导致整个分区需要重新同步。

另外移动笔记本最好不要直接移动文件，应该用 OneNote 的 Share or Move ，以及把分区 Move or Copy 的功能。

如果你想获得云端笔记本的本地版本，可以打开之后导出。

除了用响度均衡还可以用音量混合，但是我不记得 Windows 是否会记忆音量混合的比例了（可能是基于窗口 /进程的，那样的话就不能记忆；如果是基于文件名，则可以记忆，但我不记得是否会记忆）。

@kuxuan #35 我感觉楼主说的时薪单位是人民币 🤣 因为 35*16*22*12/6.5 = 22744.6154

占位符功能是 Windows 8 引入，Windows 10 去掉后又重新引入的。

因为 Photoshop 使用了保存、删除、重命名的安全保存操作序列——如果直接写文件，可能会出现 Photoshop 写到一半崩溃，导致文件完全损坏的情况。

Windows 文件系统隧穿功能只能保持长短文件名、创建日期，不能保持硬链接，参考：
https://devblogs.microsoft.com/oldnewthing/20050715-14/?p=34923

从符号上推测诸 y_i 是数（投影的长度，带符号），然后 y_i = x_i^T u 右边是列向量的转置乘列向量，即 1x1 矩阵。虽然我个人觉得把 1x1 矩阵和数等同会带来很多混乱，但这似乎是习惯了。

注意数和数相乘，就是数和自己的转置相乘，因此 (x_i^T u)(x_i^T u) = (x_i^T u)^T (x_i^T u) = u^T x_i x_i^T u ，这就是最后一个等号，其目的大概是提取左右公因式 u^T 和 u 。

os.walk 没有定义顺序，因此不存在一个特别的顺序，你可以先把所有的结果拿出来，再自行排序。

很可能 os.walk 的实现就是调用文件操作的 API ，通常这个 API 不容许任何复杂的排序逻辑。

例如，Windows Explorer 里面的排序就是 explorer 自己做的。

@ColorfulBoar #10 🤔 我是不是识别出来你是谁了？

@mgrddsj #13 DRM 防截图在 Windows 上就是 app 告诉 Windows 在截图得时候阻碍自己被截图，即 @crab #16 说的那个 API ，就行了。并且不存在“DRM 实现不好得电脑”，只存在“DRM 实现不好的软件”。

远程桌面可以绕过这个 API 的限制，和虚拟机一样，在客户端（宿主机）截图的时候，远程桌面客户端（虚拟机程序）不会通知服务器（客机）。我并不知道 Windows 8 以来用来测试的 nested session 版远程桌面（即提供 Windows 应用商店应用开发时模拟器测试的基础设施）是否也能，不妨一试。

@v2genesis #5 您的 could have 翻译更符合汉语习惯，赞！

DeepL 的翻译错误，是方式的数量而不是数据的数量。正确的解析是

主语 Posterior probabilities
谓语动词 state
宾语的中心语 the relative numbers
宾语中心语的修饰 of ways
修饰 ways 的关系从句
- 从句主语 each conjectured cause of the data
- 从句谓语动词 could have produced
- 从句宾语 the data

后验概率描述每个所猜想的（被观测到的）这些数据的产生原因可能产生（被观测到的）这些数据的方式的相对数量。

每个所猜想的（被观测到的）这些数据的产生原因可能产生（被观测到的）这些数据 = each conjectured cause of the data could have produced the data
方式 = ways

用设问，可以说

In how many ways could each conjectured cause of the data have produced the data?
The numbers of ways are stated by posterior probabilities.

@ysc3839 #7 这是不行的，因为通知区域图标关联的窗口可能是高权限进程（或者另一个非管理员用户的进程），窗口消息仍然可以送达（ Explorer 有 UIAccess ），但 Explorer 无权访问该进程。此外关联窗口可以变更，要恰当实现等待进程结束还是挺复杂的（需要用 WaitForMultipleObjects 技巧）。

首先，那个东西叫“通知区域”，不叫 tray 。即使你认为 tray 来自于早期代码里的命名，tray 也是指整个任务栏。

这个问题的成因是通知区域图标是程序通知任务栏创建的，崩溃时程序没有通知删除，所以不会立刻消失。

鼠标放上去会消失是因为 Explorer 会给图标对应的窗口发消息，如果窗口句柄已经无效，则会删除图标——注意窗口句柄是 USER 句柄，因此既没有计数也会复用，在极限情况下可能新程序被分配到已经崩溃程序使用过的句柄，导致新程序莫名其妙收到消息。

Explorer 崩溃重启后程序需要重新添加图标，获取这一信息的方法是注册“任务栏创建好了”消息。

为什么不能轮询——因为不存在一个“心跳”消息，也不应该随便给窗口发送消息（虽然理论上可以注册一个新名字，这样任意窗口都不会对该消息有特殊反应才对），也不应该轮询（性能问题）。

这个问题显然是可以解决的，比如任务栏上列举窗口的按钮可以对崩溃立刻作出反应，这个变化是 USER 监控，并发送 WM_SHELL_* 消息给任务栏的。然而通知区域图标并不是 USER 概念而是 shell 概念（只存在于 explorer.exe 进程中），虽然可以提升到 USER 概念实现之，估计是不值得吧（ USER 是 per-session 级别的，可以容纳的句柄数量也相当有限）。

更好的解决方法是——不要崩溃。

类似的问题也存在于 Application Desktop Toolbar 。还有更多设计 bug 导致 shell 的一些部分需要两次操作才能刷新（ COM categories 、shellnew 等）。

@Youngsun #16 iOS 和 Android 都可以是平板电脑操作系统。

虽然不是期望的解决方法，但是为什么这么多人认为要远程桌面客户端必须是 PC ？可以是 iOS 或者 Android 啊。

正经的解决方法是虚拟机，为了提升效率可以采用启动到虚拟磁盘。即使不用虚拟启动，也可以为朋友建立主机上的另一个账户，然后另一个账户自己用虚拟机。

注意双系统是不能实质上解决问题的，这是因为对文件系统的权限保护是操作系统进行的，因此在 A 系统里具有管理员权限的用户自然可以任意修改 B 系统的内容。表面上解决问题是没问题的，只要 A 系统不要给 B 系统的分区分配盘符也不要挂载到目录上（ B 对 A 亦然）即可阻碍大多数程序（刻意或无意）修改另一个系统。

在干净的 Windows 上建立受限账户，可以保证受限账户不能影响其他账户。然而如果受限账户以管理员身份运行另一个程序，那相当于用了管理员账户，自然可以修改操作系统进而影响所有用户。