这个时间当然可以伪造，但是：正常工作过程中改变时间是很少见的做法；如果你的仓库不允许 force push ，则无法事后伪造。证据需要多个互相印证，因此即使最终不能采信，这个证据也值得保留。

另外就是即使此证据无法直接采纳，它至少说明了理应存在这样的书证/电子数据的证据（意思：你的雇主应该有你的 Git 提交的真实记录，包括何时用什么 IP 的计算机用什么凭据 push 过代码），此时可以要求对方提供证据（即：证据对雇主不利，也可以被强制取出），拒绝提供会承担不利后果，伪造证据也有相应的惩罚。

网站的说明已经很明确了：比如你要算多少天、多少秒，考虑闰年、时区的话，并不是很容易计算。在需要嗟叹人生苦短的时候，有这个计算器还是挺方便的，不然都不知道该写多少天、多少秒。

Bug 也很明显：有些时区的 UTC 位移在一年内不是常数（夏令时），有些时区的 UTC 位移在多年间不是常数（历法修订），所以那个时区的功能很搞笑。

@aa22 #7 你有没有想过，最简单的解释是那个配置文件处于打开状态，所以不能删除呢？（默认配置，即用来初始化新用户的，也不能删除，原因自明。）

如果你发现某个用户已经注销，且没有任何进程是那个用户的身份运行，且你依然不能删除，说明有些服务没能及时卸载此用户的配置文件。重启之后再看一次。

但我想起来了 /t/633277 的情况，如果楼主的用户连接了微软账户，建议删除重建。

新建一个管理员用户，把你的旧 user profile 即 C:\Users\用户名 重命名为 C:\Users\用户名.old ，然后打开 sysdm.cpl ，在 Advanced | User Profiles | Settings 里删除旧用户的资料（因为重命名了，所以实际上资料不会删除，只会取消关联）。

重新登录旧账户，此时会建立新的 user profile ，然后按需从 C:\Users\用户名.old 里面把文件（我的文档等）移动回来即可——不要移动 OneDrive 的，让它重新同步。最后，删除建立的临时管理员账户。

如果你的程序 A 依赖的 MySQL 是商业协议的，那么你的程序本身不受 GPL 的约束，且没有你的同意的情况下，你的客户 C 无权把它和另一个款数据库 D （你提到的那款 GPL 3 协议的数据库）一起使用。

如果你同意 C 把 A 和 D 一起使用，令 A 连接 D 使用的整体为软件 A'，则 A' 受到 GPL 的约束，但是—— C 可以选择自己用 A' 而不分发给别人，因为 GPL 的约束仅在分发软件时存在，所以 C 没有必要开源 A'。

假设你只是允许了 C 把 A 和 D 一起使用，但没有以和 GPL 兼容的协议把 A 授权给 C ，那么：因为 A' 是 A 的衍生作品，所以受到 A 的协议约束，此时 C 无权按 GPL 分发 A'，因此 C 只能自己使用 A'，因为分发 A' 必然违反你的授权和 D 的 GPL 授权之一。

@pike0002 #2 因为那些资源是 Windows 的，所以我无法 relicense ，网上有很多下载的地方，也可以打开 Windows 8 ISO 提取。

ls -dir | ls -file | mv -dest ./

或者说

Get-ChildItem -Directory | Get-ChildItem -File | Move-Item -Destination ./

CSS 动画和 requestAnimationFrame 都是“浏览器认为的最佳动画时机”，除此之外 prefers-reduced-motion 表明用户不想看动画（比如晕动画的人），除此之外 setTimeout 的运行时机实际上也不会超过客户端的性能。

@pweng286 #1 大模型不需要理解加密后的输入，做的运算是大模型的同态作用。（同态加密的意义就是可以把任何运算都在密文里面进行，而不需要知道明文。）

如果大模型不经常更新的话，用 (F)HE 有点大炮打蚊子，可以用凝练的函数求值（ laconic function evaluation ）。但我对两者的实践都不是很了解，而且我的猜测是：现阶段它们的效率还不足以在可以容忍的时间内算完 LLM 一轮作用。

@qwingmix #13 直接阅读字体的授权是最快的解惑方式。如果授权明确了是不可撤销的，则按照授权使用就不会有事儿。

@processzzp #10 微软的文档观点相反 https://learn.microsoft.com/en-us/typography/fonts/font-faq 但是很神奇的是最后链接里列出的“自带”的简体中文字体只有等线、仿宋、楷体、黑体（ SimHei ）。另外链接页面是 Windows 10 的，没有授权信息页指向 Windows 11 的，而 Windows 11 的自带列表里有雅黑。

我的理解是：要么微软无权授权但错误授权（因此授权无效），要么方正无权追究 Windows 用户用商业软件在像素图里使用雅黑但错误追究（因此是无效诉讼）。当然，这并不改变方正会找人麻烦的事实。

信息不足。

如果你为员工建立了 Personal Account （定义见 https://docs.github.com/en/site-policy/github-terms/github-terms-of-service ），并且这些账户是免费的，并且你的员工自己有（别的、免费的） Personal Account ，并且两个 Personal Accounts 都是人类使用而非机器使用，则违反了“一个人最多一个免费 Personal Account （除了额外的一个机器账户）”的规定。

另外就是如果这些账户都是同一台电脑建立的，可能 GitHub 记得这件事，所以一个封了，其他的也就都一起被发现了。

如果是上面的情况，规避方法：不要帮别人创建 GitHub Personal Account ，除了上面的问题之外，还有一点比较重要的是你的员工可能没有被提示看 GitHub 使用条款，这会导致注册流程从合同角度不成立。让员工入职之后自己建立，或者使用自己本来就在用的账户，并且把公司邮件加入他的账户邮件里。

申诉找回：可以访问 support dot github dot com slash contact slash cannot_sign_in 申诉。如果是因为上面的原因，可以解释清楚状况并告知自己已经了解了规则，至少应该是可以取回数据的。

Windows 计划在 2027 年去掉 VBScript 的支持，届时可以用 PowerShell

(New-Object -ComObject InternetExplorer.Application).Visible = $true;

如果要命令行（创建快捷方式）的话

PowerShell -NoProfile -Command (New-Object -ComObject InternetExplorer.Application).Visible = $true;

@niubiman #21 不太确定你说的 Ctrl/Cmd+V 的 API 是什么，Windows 上发生的事情也是：用户按了 Ctrl+V ，程序意识到了这一点，然后调用 OpenClipboard, GetClipboardFormatNameW, GetClipboardData 读取剪贴板，操作系统不知道程序为什么调用它：可以是 Ctrl+V ，可以是上下文菜单的“粘贴”，可以是工具栏的“粘贴”，可以是这个 app 就是想查看剪贴板。

我没有仔细看过 WinRT 是如何限制剪贴板 API 只有前台才能访问的，有两种可能：WinRT 剪贴板 API 单纯选择在非前台时不访问剪贴板，实际无权限约束，直接用 Win32 API 就可以访问（当然，这样做的 app 无法通过审核就是了，但可以 sideload ）； AppContainer SID 拒绝非前台线程访问剪贴板，即实际上有权限约束。

iOS 上，我不确定用户点击菜单的时候，是真的有权限隔离，还是系统菜单和 app 主动访问都在同一个进程里，只是系统菜单访问剪贴板用的是私有 API （和 app 主动调用的 API 是两套路径），所以主动调用之以绕过弹框的 app 无法通过审核。

我的点在于：要区分用户是否主动，需要权限隔离（操作系统内核所施加的安全性）而非仅仅是审核（本质上是所有上架 app 被迫自律）；权限隔离需要的模型可以做，但不简单。

@niubiman #10 用户无法调用 API ，只能用手按一下屏幕，然后程序知道用户按了一下某个按钮的时候，调用 API 去访问剪贴板。

此问题根源在于无法准确建模访问剪贴板的时机，解法也只能是正确建模。一个可以考虑的思路是这样的：

1. 系统进程可以任意访问剪贴板
2. 所有 app 都默认不能访问剪贴板，但可以被用户同意访问（类似于地理位置的权限模型）
3. 提供一个新的按钮控件，此控件生活在系统进程里，点击此按钮时，系统进程读取剪贴板并传送到 app 进程的事件处理程序里

因为新按钮控件位于系统进程，在合适的权限模型下，app 进程无法访问系统进程，所以无法假装点击。

另外商店审核也可以加入规则，但在 API 和进程权限、隔离上建模是最重要的部分。

@Linho1219 #15 原生文本框的代码只要依然运行在 app 进程里，app 就完全可以选择把原生文本框里访问剪贴板的代码抽取出来。

当然，能这样做是因为 app 的代码并不是严格受控的，一般地，剪贴板 API （或者任何本机代码）并不知道自己的调用者是谁——对比 JavaScript ，后者可以做到“只有用户点击按钮的时候，才能用代码开启新标签页而不被默认阻拦”，是因为“谁、什么时候调用的”的信息来自 JS 引擎。