一个可能的方式是宽松化你的 schema。

{
"@comment": "这是一段注释",
"username": "example",
"email": "[email protected]"
}

理论上，指数稀释了个股风险，你投资的是一个“方向”。

看了一下 docsify，似乎需要页面运行 JS。docsify 本身已经是这样一个轮子了。

看起来这种模式你不需要 CI，因为不存在 build 的过程，直接 push 就完事儿了。

如果你有 CI，你可以把 blog source 和 publishing repo 分离，然后每次 push source 后自动构建 publishing repo。我目前是这么做的（但并不是 CI 而是有一个本地脚本自动完成这个工作）。

最简单的是换 Windows。

提示：你提供的信息太笼统，问你们 IT 去比较好。

是因为有程序泄露 USER 句柄。

每个会话理论上最多有 65536 个 USER 对象，每个 USER 对象在其会话中具有惟一的 USER 句柄（一个 uint16 ）。默认情况下 Windows 允许一个进程建立最多 10000 个 USER 对象。几个 USER 对象的例子：菜单、窗口、光标、钩子、热键列表。

如果你打开 7 个程序，每个尝试创建 9360 个菜单对象并不删除它们，然后挂着不结束（显然，进程结束的时候它创建的 USER 对象会被系统回收），则当前桌面的 window manager 里将最多还能建立 16 个 USER 对象（实际上你一般无法全都成功，因为 Explorer.exe 里面也有很多 USER 对象）。Explorer 显示菜单的时候需要菜单对象，但是无法创建，就会有这种情况。

要解决该问题，最简单的方法是注销再登录，这样你会获得一个全新的会话。如果你知道哪个程序在泄露 USER 句柄，你可以关闭或重启这个程序（类似于补救内存泄露的方法）。

可以用 Sysinternals 的 Process Explorer 查看一个进程的 USER 对象数。

————————

读者习题：每个经典的 Win32 控件（按钮、复选框、单选按钮、进度条、文本框、标签、滚动条……）都是一个窗口，为什么 IE/Edge/Chrome 浏览复杂网页的时候不会耗尽 USER 对象？

答案：因为它们会自己绘制这些控件而不使用系统提供的窗口版本。但 IE 中的下拉列表仍然是窗口版本，因此如果一个网页具有一大堆下拉列表，可能会快速消耗 IE 的 USER 对象配额。

这个不符合 Fitts's law

“ if you are working on everything above, here are the must-haves ”

和 the basics 关系是啥呢？

（对这个薪资有兴趣，然而我不会前端

搜索 javascript left shift

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Bitwise_Operators

Bitwise operators treat their operands as a sequence of 32 bits (zeroes and ones).

...

Bitwise operators perform their operations on such binary representations, but they return standard JavaScript numerical values.

...

Signed 32-bit integers

The operands of all bitwise operators are converted to signed 32-bit integers in two's complement format.

我在想这个“匆”是怎么打出来的……五笔 /笔画输入嘛？

最近半年一直是星客多快剪，挺好的；然后最近才去了一次双面理发馆，超赞。

两个都没有办卡推销，效率也很高。

@AifeiI

默认设置应该是只能建文件夹的，至少 1709 已经是这样了。不存在“更新之后更加严格地执行”，如果之前不严格，那就是一个安全漏洞。

或许你之前见过的情况是：

a) Windows 对 C 的默认安全设置不是那样
b) 有人改过 C 的安全设置

因为 ACL 是这样的：

Owner = TrustedInstaller

Administrators = Full control
SYSTEM = Full control
Users = Read + execute
Authenticated Users = Modify (subfolders and files only)
Authenticated Users = Create folders (this folder only)

所以对于 UAC 启动的情况，或者对于一个普通用户，本来就应该是只能建立文件夹。

整个帖子没看懂目的是啥。

如果你想研究授权的运作机制，只要看软件的代码即可，从表面观察是没什么意义的。

如果你想知道为什么离线验证可以是安全的（假设你不尝试绕过软件的逻辑），这是因为存在着公钥密码学方案。一个简单的授权机制可以是这样：
软件作者生成一对密钥用于签名，公钥随着软件分发（比如写死到代码里），私钥用于产生授权数据。
软件根据运行环境（例如硬件配置等）生成一段文本（不考虑客户隐私的话比如系统状态的总结，考虑隐私的话用一个 hash 函数）。
用户把文本、想要得到的时长、费用交给作者，作者对 (文本, 时长) 签名（用私钥），交还给用户。
用户把签名输入软件，软件用公钥验证后发挥其功能。

Microsoft Support 不是一个论坛，宣布周期的页面最后更新时间是 2018 年 2 月

然而 CPython 的实现里永远只有一个线程在运行 Python 代码，除非写 Excel 的库已经实现了在 Python 外的代码（如该库用 C++ 实现）分别释放和拿取下 GIL，否则不会有效果。

如果该库用的是 Excel COM，那么多线程也不会有效果，因为 Excel object 是 single-thread apartment，这表示 Excel object 必须在同一个线程上运行。因为 Excel 是 out-of-process server，实际上所有调用都涉及 marshaling，修改业务在 Excel 进程里进行，你最多可以节省的是 marshaling 需要的时间。

@Judoon NTFS 不能，因为 Linux 不使用 Windows SID，然而对应的概念（执行权限）是存在的。

权限的丢失发生在共享协议上，共享协议层可以进行 owner/group/mode 映射，然而看起来它只进行了文件的字节传输。最简单的映射方法是计算 NTFS 上改对象 owner 的权限并设置为新文件的 owner/group 权限，计算 Everyone 的权限并设置为新文件的 other 权限，令新文件的 owner/group 为粘贴者的 owner/group。

此外，在不同的 Unix/Linux 机器之间传输，权限也是需要映射的，两者不非要有相同的用户和组，单纯迁移八位掩码会因为 owner 和 group 的改变出现意想不到的结果。通常做法是照抄掩码并改变 owner/group 为粘贴者。我不知道用了目录服务的机器会怎么样（是否会有相同的 UID - 用户名 对应关系之类的）。