Orien Daily
- 🌃 Orien Daily 晚刊【5.14】
1️⃣ Win API进Linux内核 — 游戏性能提升
2️⃣ Needle：26M模型学会调用 — Gemini蒸馏超小模型
3️⃣ Anthropic复盘Claude Code
4️⃣ K8s v1.36发布 — 安全默认+AI负载
5️⃣ AI聊天机器人泄露手机号
6️⃣ Notion变身Agent中枢
7️⃣ 中美首脑北京会谈 — 就台湾问题交锋
8️⃣ 太阳能无人机破纪录后坠毁
频道：@OrienDaily - HTTP/2 协议层面的「极速拒绝服务」——Rapid Reset 攻击
2023 年底，Cloudflare、Amazon、Google 联合披露了一个影响几乎所有 HTTP/2 实现的漏洞：CVE-2023-44487。攻击原理出奇地简单——HTTP/2 支持多路复用，客户端可以在一个 TCP 连接上同时发起大量请求流（stream），每个流有独立的 ID。协议同时允许客户端随时发送 RST_STREAM 帧取消一个流。把这两个特性组合起来：攻击者瞬间发起成千上万个请求流，然后立即对每个流发送 RST_STREAM。服务端收到 RST 后释放资源，但请求处理的开销已经发生——连接速率限制根本拦不住，因为从连接维度看一切"正常"。结果就是极低带宽成本打瘫后端，而攻击者手中可能只握着几十条 TCP 连接。各 CDN 的缓解集中在两个方向：一是对单连接内 RST_STREAM 的频率设限，二是对并发流的创建速率做更激进的约束。有意思的是 HTTP/3（基于 QUIC）天然不受影响，因为 QUIC 的流管理机制截然不同——这大概是少有的"新协议更安全"的真实案例。 - 📸 加藤小夏 (X)
・
New Balance 204Lのビジュアルモデルに👟
204Lかわいかったな〜
全国のABC-MARTで是非☑
#newbalance #204L #abcmart #abcマート #pr
@ABCMART_INFO
https://gs.abc-mart.net/feature/31249/
・
原文 #加藤小夏 - 🌅 Orien Daily 朝刊【5.13】
1️⃣ 独立开发者全栈迁欧 — 逃离美云的路径
2️⃣ Needle 蒸馏工具调用到 26M — 小模型也能 fn call
3️⃣ Notion 变身 AI 代理中枢 — 工作空间直调 agent
4️⃣ xAI 50台燃气涡轮无监管 — 排放争议升级
5️⃣ 太阳能无人机破续航 — 翼展堪比747
6️⃣ FCC 助 AT&T 抢频谱 — 小运营商怒了
7️⃣ 和食爱好者益生菌多 — 米饭习惯也是肠活
8️⃣ 磐越道巴士车体送检 — 从损毁反推碰撞速度
频道：@OrienDaily - 🌃 Orien Daily 晚刊【5.13】
1️⃣ Googlebook引热议 — HN 799分
2️⃣ 资深开发者为何不善表达 — 经验≠沟通力
3️⃣ 用代码渲染天空与日落 — 光学模拟技术文
4️⃣ Medicare新支付为AI而建 — 科技圈几乎没注意
5️⃣ FDA局长因电子烟强批辞职 — 政治干预科学
6️⃣ 太空制药走向商业化 — Varda签约药企
7️⃣ AWS让AI操控桌面 — 无API也能协作
8️⃣ 日本机器狼驱熊需求暴涨 — 电动吓人神器
频道：@OrienDaily - 🌅 Orien Daily 朝刊【5.13】
1️⃣ 拓竹被指滥用开源契约 — 封闭生态引争议
2️⃣ 双胞胎被炒后删96个政府数据库 — 安全漏洞暴露
3️⃣ Musk想把OpenAI给孩子 — Altman作证揭露
4️⃣ 特朗普启程访中会晤习近平 — 经贸台海成焦点
5️⃣ 少年依ChatGPT建议服药身亡 — 家属提起诉讼
6️⃣ 软件架构的系统学习法 — matklad长文干货
7️⃣ Redis与野心的代价 — 开源基础设施十字路口
8️⃣ GitHub MCP密钥扫描GA — AI开发安全升级
频道：@OrienDaily - 🌃 Orien Daily 晚刊【5.12】
1️⃣ TanStack NPM供应链攻击复盘 — 攻击手法与影响披露
2️⃣ GitLab裁员弃用CREDIT价值观 — 公司转型引发热议
3️⃣ Amazon全美上线30分钟配送 — 日用品极速送达
4️⃣ Linux两周连爆两个严重漏洞 — 内核安全再响警报
5️⃣ 警视厅警示"影子AI"风险 — 非授权AI使用存隐患
6️⃣ 卡乐比改黑白包装 — 中东局势致墨水断供
7️⃣ Thinking Machines造边说边听AI — 打破模型交互局限
8️⃣ 乐天移动au漫游9月终止 — KDDI称漫游已尽其用
频道：@OrienDaily - 📚 「に基づき」vs「を基に」vs「に準拠して」— 論文里说"基于"到底用哪个？
写研究計画書的时候，"基于某某理论"这个意思大概会出现十次以上。但日文里表达"基于"最少有三个常用说法——「に基（もと）づき」「を基（もと）に」「に準拠（じゅんきょ）して」——它们语气不同、搭配对象不同，混着用会让审阅者觉得你日语还不够细腻。
先说最常用的「に基づき」。这个词前面的对象通常是某种理论、数据、法规这类有权威性的依据。比如「従来の研究に基づき、新たなアルゴリズムを提案する」，意思是"以已有研究为根基，提出新算法"。注意它用的是「に」而不是「を」，因为依据的对象是你在上面构建东西的基础，而不是你亲手改造的素材。另一个细节：论文正文里用「に基づき」比「に基づいて」更正式，「に基づき」是中止形，后面可以接续下一句，不会显得口语。
再说「を基に」。这个词更像是"拿……当素材来加工"，前面的东西是你改造的原材料。比如「先行研究の結果を基に、実験設計を見直した」，意思是"把先行研究的结果当素材，重新设计了实验"。跟「に基づき」的关键区别：「に基づき」强调依据的权威性，而「を基に」强调你在原始材料上做了调整。所以「この理論に基づき」是在说"这个理论是我的理论基石"，而「このデータを基に」是在说"这些数据是我加工的原料"。
最后是「に準拠して」，这个词几乎只用在"符合规范/标准/协议"的场景。比如「RFC 9000 に準拠して実装を行った」，意思是"按照 RFC 9000 的规范来实现"。它跟「に基づき」的区别在于：「に準拠して」暗示你在严格遵循某个外部标准，没有自由发挥的空间；而「に基づき」只是说你的工作有理论支撑，具体怎么做你还是可以有自己的创新。
💡 記憶ポイント：権威ある理論→「に基づき」、加工する素材→「を基に」、従うべき規格→「に準拠して」。三者在论文里各就各位，别串场。 - 🔐 DNS Rebinding：让浏览器自己撕开内网防火墙
你架了一台内部服务，只绑了内网 IP，防火墙规则严丝合缝——外部根本连不上。你觉得安全了对吧？但如果我能让你的浏览器替我访问这台内网机器呢？
2016 年有一篇论文重新把一个 1996 年就被人提过的老手法翻了出来，叫 DNS Rebinding。原理极其简单：DNS 解析是有 TTL 的，而浏览器同源策略只看域名不看 IP。所以攻击者注册一个域名，比如evil.com，第一次解析指向攻击者的外网服务器，页面正常加载，浏览器认为资源来自evil.com。然后 TTL 到期，攻击者把 DNS 记录改成目标内网地址——比如192.168.1.100。页面里的 JS 再次发请求到evil.com时，浏览器缓存中的同源策略仍然认为"这是同一个域"，但底层 IP 流量已经发往内网了。
整个攻击链没有任何端口转发、没有任何隧道，浏览器自己就完成了从外网到内网的跳转。
这个手法的杀伤力在于它绕过的不只是防火墙。很多内网服务（路由器管理面板、Redis、Elasticsearch、调试用 API）裸跑在 HTTP 上，没有认证也没有 HTTPS。浏览器带着用户的 Session Cookie 发请求，等于用户本人操作。你可以读取响应——因为同源嘛——于是内网数据就这么被 JS 一行行搬走了。
防御思路有几个层面。。现实中最有效的组合是：内网服务上认证 + 反向代理校验 Host + 浏览器端启用 DNS rebinding 保护策略。
有意思的是，这道题的核心矛盾其实是 Web 安全模型的基因缺陷——同源策略设计时假设"同域名 = 同主体"，但 DNS 把这个假设撕开了一条缝。十七年前有人指出，十七年后依然有人靠它打进内网。不是漏洞太多，是模型本身的边界还在被重新划定。 - 你有没有过这样的体验：超市购物时，如果你要买十样东西，每样东西分散在不同货架的各自区域——面包在烘焙区、牛奶在冷藏区、零食在零食区——你得满场跑。但如果这十样东西恰好都在同一个货架上呢？一趟拿完，省时省力。
CPU 遍历数据也是一样的故事。
假设你有一组粒子，每个粒子有 x 坐标、y 坐标、速度和质量。非常直觉的写法是 Array of Structs：
struct Particle { float x, y, v, m; }
Particle particles[1024];
内存布局长这样：x₀ y₀ v₀ m₀ | x₁ y₁ v₁ m₁ | x₂ y₂ v₂ m₂ | ...
很自然对吧？每个粒子是一块完整的对象，读一个粒子就能拿到它的所有属性。
但如果你要遍历所有粒子的 x 坐标求质心呢？CPU 从内存读数据不是逐字节的，而是一整块一整块地搬——这个块叫 cache line，通常 64 字节。一个 Particle 是 16 字节，凑巧一个 cache line 能塞下 4 个。听起来不错？
问题在于：当你只要 x，cache line 却把 x、y、v、m 全搬了进来。你只用了 1/4 的数据，剩下 3/4 都是白搬的。你的带宽就这么浪费了 75%。
换成 Struct of Arrays 呢：
struct Particles { float x[1024], y[1024], v[1024], m[1024]; }
内存布局：x₀ x₁ x₂ x₃ | x₄ x₅ x₆ x₇ | ... | y₀ y₁ y₂ y₃ | ...
现在遍历 x 数组，一个 cache line 拿到的是 16 个连续的 x 值。没有 y、v、m 抢位子——每一字节都在为你干活。带宽利用率从 25% 直接拉到接近 100%。
实测下来，同样是遍历 100 万个粒子求 x 的总和，SoA 可以比 AoS 快 3-4 倍。这不是算法变刁了，纯粹是数据排得更对脾气，让缓存替你干活。
当然，SoA 不是万能药。如果你经常需要同时读写单个粒子的所有属性（比如物理碰撞检测），AoS 的局部性反而更好，因为一个粒子的数据都在一个 cache line 里。选哪种布局，取决于你的"主要访问模式"是什么——逐字段扫描，还是逐对象操作。
下次写热循环之前，先问自己：我的数据是按字段走的，还是按对象走的？把字段的呼吸对齐到 cache line 的节奏上，剩下的交给硬件就好。
![📸 黄礼志 (X) ×3[260511] 1:00AM KST原文 #黄礼志](/static/https://cdn5.telesco.pe/file/V8EjcQ1GhakloQaYU6AWCMZBksk1BOnmA0-SyWqpmsweEEgO7jwwDf98mZoORaQahgngeNrX5Hgmf_5fV-XRi0AZPOo4yMWuHrw7r7cDNkInxjmXNVW-KUP4m7zCurlyhh5ZDByWCqoTb2860tu6HHUFDPVBdPqfauss8Afj3A_iotvXzefqqxcvOv1vIrBkBbzlZsvwt7TigpTvnG0zX6J6jEFxMZ2DjNVjQx0VGX3p2q5qwgeRiGmLlrILAadyvnMI2Gt6hIyHpIFsa6-x3l3AHxaHRpExdWZsGFAZGtr03vk0P8Vrvhn48Qiyaqu1oMGcmc_Qdgm84z4eyB9fGw.jpg)
![📸 黄礼志 (X) ×3[260511] 1:00AM KST原文 #黄礼志](/static/https://cdn5.telesco.pe/file/q6Fw8Aj0C1aoR2L8FGibBf-KbFb-rToNR2cj18qPmdpAguSl7BmmWZ9Zh31XkFjOBi7_tnyaWKzDD1xBUyRDO4Eb1sE5no8jus-kYqjDGiNukRNlGMaoYA7NW4wgL_-709M68br4569_501UdKwq3RNnPE5_lG5VJWN7AoYPiWjm-qNycxICRLT3_pUS80EJPI4bwal1yNEchk4tayOtApFPH_MQOPuv0HSELFK-tpYaMzoR7QVjc-CTDrv_sXxr2_vXAAcI7Rw06mycZGF70jXoGj7ZSV5e9eO-EFGCIm9wWvZg39afQKaj2GGsrpXO1Liyy0n9fe4iYq6-Lm_S1g.jpg)
![📸 黄礼志 (X) ×3[260511] 1:00AM KST原文 #黄礼志](/static/https://cdn5.telesco.pe/file/RbSLl9JFA_LkVeEFLAQto-btHssNphUQa1woHbA3b2--yVADntFPRE7HHigbCxYfuJWvMrIEZQaBHEWmhZnZPf6oEpQpvbnnT4yR8TK446uXAhDRBk7aYTmuOmNwbIJfe1zkT18J_-_g-p12YpcXSKfmmsqoXCukcyvci-5dxsvlA-VUoCF5L1Tk8Yc4Vil4TvECT9kKkOTzlTySJgQ42wVUUXYXGaR-7mCNyN5GDEikX9nuOZ1Eba1eNrGuy0W_rOr5tMnZ41Doi9fP6cM73uZ6aBdb1vXTsQSBYEIb1jy-e6q2hmS1mMegk7O7HMD1e6xceT0udVPOIjiaY5UvtA.jpg)
![📸 黄礼志 (X)[230511] 1:00PM KST原文 #黄礼志](/static/https://cdn5.telesco.pe/file/ht3E4BJvkxlRVec5FQsHGawtSIWtKDIB5NuuVrYeyP2H4k2-G-cD38eHDpLD9sbXZb1Tljeb4LIpUS388_hrKPzVfbN1Id3GBQt1EwoCABqWzeAXuxKfxlqhaPTZTJIXUlreT_AfHzpQfJEfvc5-PMOFYjpmwgOp4AKGHXpfciXKi0XJVtfzpOuscc9kKcdq0vJlp-6QCMlIyIS-zems9aNrZusyquEX--qS-BAL9nS211zcdMljNZMbAoxpR6dOCsmC8Jx4l7GKBhSCW00KCon0eLX6s-hSFb19XYmpiOTZ2MyQxFSUgrKet4uP-6cGNVaECz8xyrBPPNVU8xoTWw.jpg)
![📸 黄礼志 (X)[260513] 9:26PM KST原文 #黄礼志](/static/https://cdn5.telesco.pe/file/ZEWsa8l0FB1AsJ74e-EB3yFLeVpZFIlgbH4uftj2JjvTXjyOaAASC68HDtO6Qw-qzLC1vnT7HUh4-M8sKggoIbhxh4BAH2Ll0vHYEVylDJ08UG23Z1VYOQ8-MFkC9JZTgcDaDYFPUXPx7c1AeyrCDub1AMykgZd02EUFD8eVfP_XEBAYDvoTRAOXbkoE6r5UVFTld8AF5CWBhvYO1NcAewFbDys2rvuzcMZCp3vqcdtEb3TUPRaUrSZi608rSi_hL6x7yg4hu6-4B1MVITCcfcCF2814R7pRj1DyNgZ-0YEMJT2OE35FkwbNPBrvIAM_31J8owXMdrnFU37vPhF1rA.jpg)
