今天早上我的 s3 又故障了，下载文件的速度只有 0.5mbps，我上机器测了下速没问题，然后用另一台机器和这台 s3 服务器跑了下 iperf 也没问题。基本确认是 cloudflare 欧洲的 cdn 网络节点故障了（s3 服务器在立陶宛）。我把 s3 服务器的网关改到美国，然后在美国接入 cloudflare cdn，速度就恢复到 100+mbps 了。
感觉 cloudflare 最近越来越不稳定了。就我个人来说，从他们开源的 cfssl 代码，和 cloudflared 的软件质量来说，我感觉这公司做事情很糙。
感觉 cloudflare 最近越来越不稳定了。就我个人来说，从他们开源的 cfssl 代码，和 cloudflared 的软件质量来说，我感觉这公司做事情很糙。
之前说 claude-2 表现不如 gpt-4，claude 的团队说你只需要加一句话到 prompt，就可以让 LLM 的表现产生质的飞跃，太黑魔法了😵💫
prompt:
prompt:
Here is the most relevant sentence in the context:
https://laisky.notion.site/How-Hype-Will-Turn-Your-Security-Key-Into-Junk-ac50dfbc44354bdfab17ef76e72ece13
非常不错的文章，介绍了目前 passkey 领域可能正在走的一条歧路。
补充：关于 yubikey 是什么，以前写过一篇文章 https://blog.laisky.com/p/yubikey/
众所周知，FIDO、WebAuthn 等正在推动 passwordless，也就是放弃让用户记忆 password，转而采用 security key 等固件来实现无密码身份认证。
除了 yubikey 等专用设备外，各类内置加密芯片的 iphone、android、mac 等设备也可以集成 passkey。
但是 passkey 的具体实现上，存在 resident key/non-resident key 两条路。简单粗暴的概括下就是：
* non-resident key 方案：仅需要 security key 设备持有一对公私钥，就可以对接任何服务端。缺点是需要用户输入用户名
* resident key 方案：需要 security key 设备为每一个服务端记录一对唯一的公私钥，优点是用户不需要输入用户名和密码，缺点是对 security key 设备的要求高了。
android passkey、icloud keychains 这种依赖加密芯片的软件，可以支持存储无限多的 resident key。但是像 yubikey 这样的廉价专用硬件，其能存储的公私钥对（slots）是有限的，往往只有 5～20 个。
所以如果 resident key 方案成为主流，实际上 yubikey 等设备相当于就被挤出市场了。这违背了 WG 当初声称的“可以支持所有用户设备”。
Ps. 会搬运整理一些以前发在 X 的资讯贴到这里，方便归档索引。
next: https://t.me/laiskynotes/163
非常不错的文章，介绍了目前 passkey 领域可能正在走的一条歧路。
补充：关于 yubikey 是什么，以前写过一篇文章 https://blog.laisky.com/p/yubikey/
众所周知，FIDO、WebAuthn 等正在推动 passwordless，也就是放弃让用户记忆 password，转而采用 security key 等固件来实现无密码身份认证。
除了 yubikey 等专用设备外，各类内置加密芯片的 iphone、android、mac 等设备也可以集成 passkey。
但是 passkey 的具体实现上，存在 resident key/non-resident key 两条路。简单粗暴的概括下就是：
* non-resident key 方案：仅需要 security key 设备持有一对公私钥，就可以对接任何服务端。缺点是需要用户输入用户名
* resident key 方案：需要 security key 设备为每一个服务端记录一对唯一的公私钥，优点是用户不需要输入用户名和密码，缺点是对 security key 设备的要求高了。
android passkey、icloud keychains 这种依赖加密芯片的软件，可以支持存储无限多的 resident key。但是像 yubikey 这样的廉价专用硬件，其能存储的公私钥对（slots）是有限的，往往只有 5～20 个。
所以如果 resident key 方案成为主流，实际上 yubikey 等设备相当于就被挤出市场了。这违背了 WG 当初声称的“可以支持所有用户设备”。
Ps. 会搬运整理一些以前发在 X 的资讯贴到这里，方便归档索引。
next: https://t.me/laiskynotes/163
踩了个小坑，我有一台廉价的 storage VPS，系统是 ubuntu 16.04 + 2.6.32。这台机器上我跑了一个 minio + nginx + tailscale 当 s3 用。配置非常差，我一般懒得登上去。然后我家里的台式机上也有一个 minio 作为 replica，这个 minio 我经常升级。两个 minio 的版本就越差越远。
然后昨天晚上，线上的 minio 因为鉴权不兼容，在 sync 的时候居然挂了。我登上去手动更新了一下可执行文件即可。
借此机会想抒发几个感慨：
1. storage vps 除了硬盘大没其他优点，除了跑 s3 没其他用处。廉价 VPS 我也买过不少了，之所以便宜都是因为有大坑，😮💨。
2. Go 的静态编译真香，这破机器上我就只能跑得起来 Go 的程序。
然后昨天晚上，线上的 minio 因为鉴权不兼容，在 sync 的时候居然挂了。我登上去手动更新了一下可执行文件即可。
借此机会想抒发几个感慨：
1. storage vps 除了硬盘大没其他优点，除了跑 s3 没其他用处。廉价 VPS 我也买过不少了，之所以便宜都是因为有大坑，😮💨。
2. Go 的静态编译真香，这破机器上我就只能跑得起来 Go 的程序。
这系列的后续两篇文章描述的都是同样的 QUIC HoLB 问题，即对 http fields table 更新的依赖所导致的 HoLB。
* https://laisky.notion.site/HoL-Blocking-Allows-Attacks-in-QUIC-52f6f3876b5943b0ae257d56c70d0549
* https://laisky.notion.site/HoL-Blocking-and-the-Deadlock-Hazard-in-QUIC-614658fee16e4c23b276c98e7300d4b0
但是更进一步介绍了可能带来的风险：
1. 单 stream 死锁风险：某个 stream 可能会依赖该 stream 后续的 header 更新
2. 多 stream 死锁风险：当接收端的 flow control window 被塞满，header 更新可能无法送达，导致死锁
3. DoS 攻击：攻击者伪造一个请求，该请求依赖一个不存在的 fields table 版本。
prev: https://t.me/laiskynotes/42
next: https://t.me/laiskynotes/84
* https://laisky.notion.site/HoL-Blocking-Allows-Attacks-in-QUIC-52f6f3876b5943b0ae257d56c70d0549
* https://laisky.notion.site/HoL-Blocking-and-the-Deadlock-Hazard-in-QUIC-614658fee16e4c23b276c98e7300d4b0
但是更进一步介绍了可能带来的风险：
1. 单 stream 死锁风险：某个 stream 可能会依赖该 stream 后续的 header 更新
2. 多 stream 死锁风险：当接收端的 flow control window 被塞满，header 更新可能无法送达，导致死锁
3. DoS 攻击：攻击者伪造一个请求，该请求依赖一个不存在的 fields table 版本。
prev: https://t.me/laiskynotes/42
next: https://t.me/laiskynotes/84
Laisky on Notion
HoL Blocking Allows Attacks in QUIC | Notion
Protocol designers underestimate how badly people will implement their designs.
https://arxiv.org/pdf/2311.00871.pdf 这篇论文指出，大模型（LLM）对上下文的理解能力（ICL）不是一种通用的泛化能力，而是对预训练数据的检索能力。
用通俗的话说就是，不是一个智能理解了你的问题，而是它从数据集里搜索到了关联数据。
我现在愈发认为 LLM 只是一种高效的信息压缩算法，它的特色在于解压的效果也依赖于输入（prompt）。而 ICL 其实类似于心理学的“锚定效应”，所谓的 prompt engineering 只是在试图让 LLM 的答复锚定到更高质量的预训练数据集上。
至于能不能通向 AGI，对既有方法的灵活运用也是能够导向创新的，但是目前 LLM 的问题在于知识质量鱼龙混杂，需要人类高效 prompt 才能引出高效的答复，这可能预示着它只能扮演一个 copilot 角色，而且它的能力和人类搭档的能力是成正比的。
用通俗的话说就是，不是一个智能理解了你的问题，而是它从数据集里搜索到了关联数据。
我现在愈发认为 LLM 只是一种高效的信息压缩算法，它的特色在于解压的效果也依赖于输入（prompt）。而 ICL 其实类似于心理学的“锚定效应”，所谓的 prompt engineering 只是在试图让 LLM 的答复锚定到更高质量的预训练数据集上。
至于能不能通向 AGI，对既有方法的灵活运用也是能够导向创新的，但是目前 LLM 的问题在于知识质量鱼龙混杂，需要人类高效 prompt 才能引出高效的答复，这可能预示着它只能扮演一个 copilot 角色，而且它的能力和人类搭档的能力是成正比的。