啊，原来除了设置界面会 crash，后台跑的 service worker 也会在操作的时候触发崩溃啊，devtools 直接断开连接（

android 多任务最大的问题是隐藏在背后的逻辑问题，这个永远不是交互设计所能解决的。。。
什么逻辑呢，就是 android 自带了一个返回堆栈，不同的 activity 正常切换时，应该可以维护这个栈，返回键能返回到上一个界面，回到启动器点开新 app，或者点击通知，应该会启动一个新的栈（暂且不提那些设计不良的，滥用 clear top,single top 的）
但是呢，一旦你使用任务切换功能，以上功能就会被完全破坏了，返回键很有可能是直接回到启动器，再也找不回原来的栈了。。。
更别说应用内部的导航也可以轻易破坏这个栈，使得返回键存在的意义被无限缩小，用户需要小心谨慎的使用手机，才可以在按下返回键的时候有充足的自信预测下一帧看到的画面是桌面还是前一个应用。。。（关键也没个提示告诉你返回键是回到桌面还是上个应用）
一个理想的多任务切换，应该把这个结构拓展成有向无环图，A 界面导航到 B 界面，然后返回 A 界面导航到 C 界面，再切换到 B 界面按下返回键时应该能回到 A 界面，再次切换 C 界面时，也应该能够回到 A 界面。

@BeautifulSoap wayland 的输入法架构比 x11 靠谱多了，直接用 text input 协议就能做远程输入的基础支持，合成器可以直接发送文本给应用，而不需要再开一个输入法程序，因此要做输入法穿透，应该是理论上可行的

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/unstable/text-input/text-input-unstable-v3.xml

@BeautifulSoap 官方的 Wayland 已经秘密上线，我之前发过
Bug 很多，比如 dpi 不是 100 就是一堆锯齿
窗口对话框会被窗口本身盖住使得操作无响应
GL 加速的程序帧率只有 40

Insider 里之前就这样了（
然后还是有卡死 explorer 的 bug
WSL2 初始化的过程中 explorer 可能先死了，然后任务栏也没咯

创建规则后 tab 崩溃，触发错误 STATUS_ACCESS_VIOLATION

建议用 git bundle 功能打包成单文件然后上传云存储

@kidlj 是 aws lambda

@noe132 不是很懂，<T extends string>(input: T[]): Record<T, number>能解决的事情为啥要玩类型体操

declare function fn<T extends string>(input: T[]): Record<T, number>;

const ret = fn(['a', 'b']);
ret.a = 1;
ret.b = 2;
ret.c = 3; // error: Property 'c' does not exist on type 'Record<"a" | "b", number>'.

前端搞骗自己的加密也是没有用的，顶多增加别人攻击成本（如果 https 不起作用，比如企业根证书），攻击者可以直接更改你的 js 拿密码

什么都不懂你打算怎么看，这不是 canvas 糊的吗

(CGI：你在说我？

@AceCandy 如果让持有锁的线程一直不释放不就其他的就没法继续了，不能在有限的步骤内完成，不要问为啥让它不释放，这就是无锁算法定义的一部分，CAS/FAA 不可拆分更是前提条件，这玩意就是证明题，前置条件满足了之后，证明不可能存在这个特殊情况，就证明了算法是无锁的，反之就是阻塞的。

@bugmakerxs CAS 由 cpu 实现者保证至少有一个线程能在任意冲突场景的情况下写入成功（当然，总得符合条件，你不能全部参与比较的都不与原值相等），至于 cpu 怎么实现的，并不重要，因为这属于定义的一部分，不符合这个定义的，就不是这个上下文里的 CAS 操作。
（话说回来，CAS 通常是作为无锁算法实现的基础组件，很少会有恰好只需要 CAS 就可以完成的需求，另外 CAS 也可以用于实现阻塞算法）

无锁的定义和锁倒是没有直接联系，只要求当任意线程在任意时刻卡死时（但是不能死光）起码剩下的线程中至少还有一个能继续跑（无等待就是剩下没死的线程都能继续跑）
卡死可以理解为依据设定跑一个死循环，或者调度器不再调度到那个线程，而不要管为啥（这里必须假设 CAS/FAA 一类的操作不能被任意方式打断，要么没有执行到，要么已经执行过了，原则上关闭中断也算，但是这里就复杂化了）。
继续跑的定义就比较麻烦了，通常可以理解为在有限步骤内能成功完成（失败的不算，比如你拿不到锁直接返回错误的那种）。
普通的无锁允许出现某个线程永远无法继续，（因为只要求至少一个，只要保证系统中永远存在两个或以上的线程在运行，其中一个就可以一直卡下去，即所谓的饿死）无等待要求所有线程都要能在有限步骤完成（除了依据设定卡死的）
所以判定一个算法是不是无锁的就很简单了，只要找不到任何一种能让所有剩余线程卡死的中断点的组合（也就是每个选中线程都按设定在特定位置停下，并且此时其他线程也按设定跑到特定的位置，可以理解为极端条件），就是无锁算法，而如果甚至无法让剩余线程中的任意一个卡死，那就是无等待算法。

Windows 提供了隔离进程（给 docker 用，应该有足够的隔离能力）
但是目前只在 win server 上启用
而且没有图形功能
我用类似方法试图复刻 docker for windows 的操作（然后补全图形功能），但是失败了，附上源码，看看有没有高手能够在这个基础上做一个能用的 https://github.com/codehz/winsilo
目前最大的问题是：只能以 nt system 账户运行，虽然可以丢掉特权，但是看起来就很不安全（
其次就是尚未实现文件系统隔离，虽然有个理论上的方法（用自带的几个容器相关的文件系统过滤器驱动），但是一直没操作成功过（