拍照看看 C to A 那条线的 A 头是怎样的？

@rrfeng 能删除原来的系统分区的话，在 PE 下删掉这个分区，然后转成 GPT，启动安装程序后选择刚刚删掉后未分配的空间安装。
如果只有一个系统分区的话，建议全盘清空。

没明白，你要实现什么功能？

我目前用的是 Google Firebase Hosting 。
也可以考虑一下 Cloudflare Workers Site https://blog.skk.moe/post/deploy-blog-to-cf-workers-site/

@autoxbc 抱歉，我确认了一下，确实不是选择器中的实现代码。
正确的代码应该是这段
https://github.com/jquery/jquery/blob/de5398a6ad088dc006b46c6a870a2a053f4cd663/src/selector.js#L858-L863

@autoxbc 但是那就是 jQuery 实现 :contains() 的代码。
还是说是我搞错了，实际上实现 :contains() 的代码不是这个？

@0attocs 顺便提一下，AMD CPU，用 VMware 装 macOS，开启了 Hyper-V 之后可能会无法启动虚拟机。
因为 macOS 内核会检测 CPUID 相关参数，发现不是 Intel CPU 就拒绝启动，于是有两种解决方案，一种是 patch 内核，另一种是修改 CPUID 返回的数据。前者比较麻烦，后者可以通过虚拟机实现，所以虚拟机装 macOS 一般是选择后者。
但是 Hyper-V 可能不支持修改 CPUID 还是有别的问题，改了之后就无法启动了。

我的方案是用 Content Farm Terminator https://github.com/danny0838/content-farm-terminator 添加一个标记，然后主动不去访问此类网站。

基本上没哪个语言的 socket 会支持代理功能的，建议使用系统级的代理。

hash 密码的话建议直接用 Argon2 。

@Remember macOS 和 iOS 的绝大部分 API 是基于 Obiective-C 的，理论上 objc 的消息传递机制比 WinRT/COM 的虚函数表更慢，但为什么没人说 macOS 慢呢？ Direct3D 也是基于 COM 的，似乎也没人说慢？

@ikas 我明白你的意思了，你是把 WinRT API 和 UWP 视作一体了，所以认为 UWP 仍未死亡。

按我的理解，WinRT 是 COM 的升级版，是一套描述 API/ABI 的规范，除了注册表注册以及 RPC 功能，其余部分和操作系统关系不大。
自 Win8 以来，微软在 Windows 中加入了许多基于 WinRT 的 API，这些 API 有的可以被 Win32 应用 (在 Win32 环境下) 使用，有的只有 Metro 应用 (在 Metro 环境下) 才可以使用。
后来微软把 Metro 这个开发平台 /运行环境推广到了别的设备上，取了个名字叫 UWP 。
现在 UWP 失败，微软把以前只能被 UWP 应用 (在 UWP 环境下) 调用的 API 一部分保留在系统中的同时开放给了 Win32 应用使用；一部分从系统中独立出来，做成了 Windows App SDK，给 Win32 应用使用，这个独立的 SDK 也在使用 WinRT 规范来描述它提供的 API 。
按我的理解，WinRT, 基于 WinRT 的 API 和 UWP 一直都是三个不同的东西。我认为 UWP 这个开发平台 /运行环境已经死了，但是 WinRT 本身，以及微软这么多年推出的、基于 WinRT 的、曾经是 UWP 专用的各种组件并没死。

@ikas 在我看来，UWP 最重要的特征是 Universal，即统一、跨平台。这也是多年前微软硬要把 UWP 和 Win32 割裂开的原因，因为 Win32 不跨平台，跟 UWP 的根本理念相抵触。而随着微软宣布放弃自研移动操作系统，UWP 基本上算死了。至于 Xbox，游戏软件并不是强依赖 UWP 的特性，所以可以忽略这一块。
至于 UWP 背后的各个技术，以微软的技术能力再过个 10 年可能都不会死。
为什么微软不像以前把 UWP 相关技术跟 Win32 割裂开了？因为跨平台已经失败，继续割裂既恶心开发者，对自己也没有好处，不如开放出来方便开发者，自己也能得个好的口碑。

@systemcall 那个隔离好像不是强制的，并不是真正意义上的沙盒。

@dingwen07 macOS 现在对于非商店应用也会限制访问桌面、下载等文件夹了，虽然限制不多，但起码还是开了个好头。
macOS 是使用沙盒机制的，因为你下载个第三方的终端应用，然后在 shell 里面访问相关文件夹也会被限制。
至于加载驱动，macOS 在授予管理员权限后也能加载驱动，这并不是问题。

@nieyujiang 我觉得微软是总想着提升对第三方软件的控制力，但是方法却没用对。
Vista 时期微软推出 WPF，但是 WPF 是跟 .NET 捆绑的，与 Windows 本身独立，大概是怕内置在系统中被别的开发框架使用，想让开发者去用微软自家的 .NET 平台开发。而同时期 macOS 的 Cocoa API 则是内置在系统中的。
后面 WinRT/UWP 虽然内置在了系统中，但是微软却想着把桌面和移动应用统一，让开发者开发桌面应用时“自动”帮 Windows Phone 扩充生态，于是砍掉了传统好用的 Win32 API 。然而微软为了兼容性又不敢把 Win32 应用直接砍掉，于是开发者们就用脚投票，直接不用 UWP 。苹果就明白桌面应用需要那些传统 API，以及触屏和键鼠操作差异较大，于是给桌面和移动平台使用两套不同的 API 。

@dingwen07 我也希望 Windows 能加入 macOS 那样的沙盒。不过可能是为了保证兼容性吧，微软就一直不加。
以及微软真的要推 UWP 的话，应该学学 macOS 保留传统 POSIX API 那样，保留传统 Win32 API 。

appx 没抛弃，还升级成了 msix，商店应用还是要用 appx 或 msix 。
winget 是对标 homebrew cask 这种“软件管家式”的包管理器，这类包管理器没有统一的包格式，主要是帮你自动安装各种软件。
至于 UWP 基本可以认为死了，因为微软的 Windows App SDK 项目已经在把曾经属于 UWP 的相关库拆分出来给 Win32 应用使用了。