cf 提供两个服务，这两个服务作用是不一样的，1. DNS 解析服务； 2. cdn 服务。

你可以只使用 dns 解析服务，而关闭 cdn 服务（关闭解析记录后面的小云朵就行），这个时候只是通过 cf 的 nameserver 解析你的域名到你设置的 ip ，相当于域名解析托管在 cf 。

开启 cdn 服务的时候，解析到 cf 的 ip （一般都是 anycast ip ），也就是访问域名实际上先访问 cf 的边缘服务器，然后 cf 服务器回源请求你的服务器，获取资源，这个过程中某些静态资源可能会被 cf 缓存以加速访问，你也可以自己设置缓存的内容和 TTL 。这个过程有一个问题，就是实际访问你的源服务器的是 cf 的 ip 地址，真实 ip 会放在请求头里面，所以如果你想获取真实用户 ip 需要处理一下。

cf 的 origin certificate 只能用在 cf 的服务器回源用，也就是用于源服务器和 cf 之间的通信，如果你想申请一个“真正”通用的证书，要不然买，要不然用 LE 之类的免费证书。

LE 证书申请现在用很多自动化工具，certbot 、acme.sh 等等，操作都比较简单，仔细看一遍文档。要注意的是 LE 的申请请求有频率限制，短时间内请求太多（包括申请失败）会被封禁，需隔一段时间再申请。

首先不考虑你能不能做到跳起来这些事情，单单考虑其中的简单原理，坠落造成的伤害源自身体外部和内脏受到了瞬间的很大的冲击力，而对于任何物体，冲击力来源于动量的瞬间变化$F=\frac{\Delta p}{\Delta t}$，也就是速度的瞬时变化，因此任何能够避免坠落伤害的方法归根结底都是减少速度的瞬时变化。

那么跳起来的结果是什么呢？答：短时间内的获得反向速度。因此，不管你能不能跳起来，这样做的后果还不如直接摔死。这里同时可以澄清一下某些超英片里的经典场面，在被车（物体）撞到的瞬间，抱走某人，如果是当前真实宇宙，结果只能是被救的人没被车撞死，而是被超人撞死，当然超级英雄生活在平行宇宙，你可以说他们使用神力保护了被救者不受物理伤害。😄

你也可以思考一下，为什么救生气垫可能救跳楼的人一命，而地面不行。你需要的不是跳起来，而是动量消除的神力。

作为游科首个 3A 规格游戏，定价试试水，做做口碑其实是不错的选择，品质好的话可以走长卖路线。

同样也要考虑到虽然近几年游戏价格通胀厉害，都奔着 100 刀去了，但支持游科的那些粉丝里面相当一部分事实上对定价是十分敏感的，也算是照顾一些非游戏硬核玩家的群体的预期。

真诚是最好的本钱，捧得越高摔得越惨，前有 CDPR 覆舟之鉴。

可能是坏了，也可能是系统 bug ，touch bar 发热是正常的，如果没有负载也很烫可能硬件出问题了。我经历过至少 2 个系统版本触摸板力反馈都是坏的，查了很多资料，折腾了很长时间，最后让自己不再纠结，后来自己又好了。

主密码记得写下来，保存起来。说到这个，我想起来曾经用 enpass 遇到的一个事情，浏览器插件自动检测到修改密码框，自动生成了新密码，点击保存，修改成功，结果数据库里面根本没存新密码。

如果 Bitwarden 支持其他管理器那种密钥文件+密码口令的方式更安全一点，口令丢了问题也不严重。

obsidian 里的 `<>` 可能受到了 `<https://example.com>` 语法的干扰，像楼上说的，加反斜杠

个人的生长周期略有区别，如果不是比平均值低很多的话不用过于担心，女生快速长身体的阶段主要是小学，现在的小朋友营养都很好，发育都是比较好的。

另外，激素类的治疗的话，还是建议咨询正规医院的医生，使用激素可能会破坏正常的内分泌，有一定的副作用。

拒绝任何 `bash -c $(curl example.com)` 或者类似的管道安装和运行的方式，尤其是直接使用 root 用户的情况下。

跑来源不明的脚本属于心比较大的情况，除非是非常值得信赖的情况。

Après moi, le déluge 。即便将来有完善的数字遗产继承流程，也不见得有人愿意继承，在现有环境下如果想要某个服务持续运行只有成立一个组织，以商业方式存续。

唯一需要担心的是隐私泄露和身份冒用，典型的就是电话号码，现在手机号码已经成为重要的数字资产，没办法随意注销，放以前手机号都是随便用随便丢的。

十有八九是 siri 的识别问题，有一个 app 2Do 曾经也有识别问题，会被识别为 todo ，这个可能需要开发者优化。

个人建议是不要直接使用 brew 安装的 Python ，除非是你主动安装的，因为作为依赖安装的 Python 会随着升级而升级版本，带来非常多的问题。

brew 本身是非常激进的，会保留最新版本，也就是说，pip3 、Python3 这些命令作为软链接指向的永远是最新的，即便你不喜欢虚拟环境，但是直接使用 brew 来管理 Python 依然是非常糟糕的想法。

之所以会出现不同版本的 Python ，因为系统软件也好，brew 安装的第三方软件也好，会不同程度的依赖不同的版本，只要有一个软件直接或者间接的依赖某个 Python 版本，brew 就会安装它，但随着后续升级，brew 也会同步更新，如果你因为 brew 安装了 Python 就直接用，大抵上会发现之前安装的 package 失踪了。

一句话总结就是，Python 生态就是这样的，只有你适应它。

不是“大部分”决策都是错误的，而是一开始的模型就是错误的，你接受了别人灌输给你的“模型”，然后发现实践出来的结果和预期不符就认为是自己的决策错了。

然而事实上，大部分时候大部分人都只是从“市场”、“媒体”中选择性接受了自己认可的预期，给自己的决策找了一个“自圆其说”的借口。

活下来的水手都是谨慎加上运气好。

@huzhikuizainali 不考虑，“5 在 7 之前”考虑的事件剔除了所有既没有出现 5 也没有出现 7 的试验，总体的试验空间只包含要么出现一次 5 ，要么出现一次 7 的情况。

这个可以尝试使用条件概率的思维理解，“5 出现在 7 之前”这个事件的概率可以理解为，在一个连续的试验中的某一次在确定出现了 5 或 7 中的一个的条件下（不出现需要重抛），出现 5 的概率。

因为出现 5 和出现 7 是互斥事件，所以对任一次实验的结果，事件“出现 5 或者 7”的概率为 P(5)+P(7)，因此事件“在出现 5 或者 7 的情况下，出现的是 5”的概率即为 P(5)/(P(5)+P(7))，放在一个连续试验中，就是一直抛，直到出现 5 或者 7 中的一个为止，而结果出现 5 的概率。

保险可以一定程度上分散风险造成的损失，但不能规避风险，同样的，也不能阻止风险的扩散，风险本质是不可预知的。

保险公司依然知道需要精巧的设计所需分担的风险的种类，近可能将其限制在一个狭窄的范围，即便如此保险公司依然不可能给自己买保险，遇到意料之外的情况，也只能破产。

而软件工程是风险最具有扩散性的地方，大量的项目互相交错依赖，层层叠叠，你甚至不知道你所依赖的某个项目究竟是谁在提交代码。这里是信任不应该发生的地方，而你能做得也只有信任，你只能相信开发者是有道德感的，同时还有大量的人在做 review ，同样富有道德感，并且有足够的能力和精力发现问题。

没有任何出于理性的方案能够防范这种原初风险，正如没有任何理性的兜底方案能够创造出美好无痛的生活。

MacOS 大部分偶发的神秘问题都需要靠重启解决，现在的 MacOS 就是这样的魔法。重启不行就需要重装了。

问题不仅在于如何处理盗版用户，而在于如何识别盗版用户，盗版并不是把自己写在脑门上，那么在用户的计算机系统上，使用一些“技术手段”，收集一些“必要信息”，是否是允许的呢？

用户需不需要在家里安装一颗摄像头来证明自己无罪呢。不要只关心结果。

推荐一个工具 [Mise]( https://github.com/jdx/mise) ，可以部分实现你要的功能。

mv 命令的第二个参数如果是已经存在的目录，则执行的是移动。

移动的情况比较简单，前面的参数（目录、文件……）移动到最后一个参数（已经存在的目录）下面。mv 不会帮你自动创建不存在目录。

mv webapps.dict webapps 是把 webapss.dict 整个文件夹移动到 webapps 下面，而 mv webapps.dict/* webapps 是把 webapps.dict 文件下面的内容移动到 webapps 下面。