什么都不懂你打算怎么看，这不是 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 账户运行，虽然可以丢掉特权，但是看起来就很不安全（
其次就是尚未实现文件系统隔离，虽然有个理论上的方法（用自带的几个容器相关的文件系统过滤器驱动），但是一直没操作成功过（

列目录的前提是真的存在有目录（
url 不必真的映射到文件系统上，完全可以只是作为路由参数而已，即使真的映射到文件系统，那也得服务端提供列目录的功能。。。

@lance6716 保证不重复也可以是有界的保证，也可以是随机，比如在周期范围内（不然总数大于可能的状态数，数学上就必然会有碰撞，讨论这个没有意义）保证不重复的随机可以通过随机排序来做到。。。（然后那个随机排序用的是有效的随机源）

除此之外，还有一个思路是直接服务端渲染完搜集绘图指令发送到前端，然后在 canvas 里复现结果，这样就完全不用考虑布局差异了，可以做到 100%兼容，除开一部分文本输入的做一些特殊处理，其他的应该都可以做到 canvas 里。
GTK3 的一个显示后端就是直接接入浏览器的。

@3dwelcome Erlang 早就用这一套思路做服务端实时渲染了。。。不过前端用 wasm 的也就近几年才流行，知名的有 C# 的 OOUI

这个架势下去迟早整个 gnu/linux 要变成 systemd/linux，所有用户侧的东西都要被替换完了（

UWP 程序就别用 sandboxie 了。。。

开发分支和发布分支独立（每个大版本都弄一个独立分支，同时也要打 tag ）然后修复通用问题的时候就是去开发分支上 cherry pick，然后再打 tag

官方推的是 Kotlin （

是不是可以直接撤销证书。。。每次认证颁发新证书，退出时就直接撤销