HeHeDa: https://jandan.net/t/5860953
OO: 358 XX: 4
所斯旧: @蛋友16fd762e1e6be 是的。数学上有一整个分支是关于“平面铺砌”的，这是个蛮重要的领域。
OO: 77, XX: 1
kev_oio: 喵喵砖
OO: 36, XX: 1
蛋友16fd762e1e6be: 这种是怎么设计的，肯定有什么诀窍吧
OO: 6, XX: 1
https://www.youtube.com/watch?v=Ju0ndy2kwlw
M2 组 exo cluster 跑 LLM，瓶颈还是通信
https://www.youtube.com/watch?v=AOaXXJUdXds
「Your head is huge...」
EA 开源命令与征服系列游戏
#开源
EA 在一位 MOD 开发者 Luke "CCHyper" Feenan 帮助下在 GPLv3 许可证下公开了多款《命令与征服》系列游戏的源代码，其中包括：原版《命令与征服》（aka《泰伯利亚黎明》）、《命令与征服：红色警戒》、《命令与征服：叛逆者》、《命令与征服：将军》 及其扩展《零点行动》。EA 还为 Steam 上的《命令与征服》系列加入 Steam Workshop 支持，允许社区的地图创作者创作自定义地图并发布在 Steam 上。EA 还发布了 C&C Modding Support 包，提供了原游戏开发商 Westwood 使用的 SAGE 引擎的 Xml、Schema、Script、Shader 和 Map 文件。
Github.com/electronicarts
盐酥鸡老板在生日会的时候被盗了400万美金的资产。
https://x.com/suji_yan/status/1895103068808642811
https://fxtwitter.com/mrblackstudio/status/1895079859476468197
Читать полностью…
一个价值 2.61 美金的 Bug
Claude 前几天发布了 Claude Code，号称能够根据需求自动完成开发任务。我看了 Fireship 发布的影片介绍 Claude 3.7 及其相关生态产品的开发能力，虽然觉得有趣，但也注意到整个测评过程过于「可控」，并没有体现最新模型和 Claude Code 解决真实世界问题的能力。因此我提交表单申请了 Claude Code Beta 的测试资格，打算亲自试试。
第二天就收到了邮件，并激活了测试身份。在开始开发前，你需要先向账户里面充值。考虑到 Claude 本身是一个很大的吞金兽，我便先充了 10 美金进去（加一块的税，总共 11 美金）。Bybit 发的 Australia 卡是可以直接在 Anthropic Console 里面充钱的，记得国家选 Australia 不然付款请求会被拒绝。接下来就是 npm 安装 Claude CLI、配置环境，整体上都没有什么问题。
在进入 Claude CLI 后，程序会先邀请你输入 /init 命令，随后它会简要地用 LLM 分析一下整个工程的结构，这一步读了不少文件，花了 $0.5，并在项目中生成了一个 Claude.md。按照我的理解，后面所有的开发请求都会带上这个文件以确保模型能正确理解整个项目的特点。最后生成的项目摘要其实有点错误，比如我的 Rust 异常处理主要都用 anyhow 来做，我的项目没有用 just 调用 linter，也基本没有一行单元测试（对不起 OTZ）。不过这都是小问题，可以在它生成之后手动调整一下。
接下来就是「主菜」，让 Claude Code 在 Rune 这个核心代码量超过六万行的中大型仓库里面修 Bug。
我首先选择处理的 Bug 是 Rune 的远程控制协议不能正确传输媒体封面图的问题。我之前在赛博轮椅这篇文章讲过，想让 LLM 处理好问题，你必须得自己非常清楚问题是什么，把问题的边界收束好，让 LLM 负责整理和转化。因此我先花了点时间把问题的前因后果讲清楚，并且把所有需要参考的代码全都列了出来。很令人惊喜的是，尽管我提出来了一个大概的开发方向，但 Claude 并没有完全遵照我的想法执行，而是提出了一个更好的解决思路，并且产出了 Linter 没有大吼大叫的代码。虽然他的实现是有错误的，像是把 Server 和 Client 的关系搞反了、host 的传递实现不正确。但是基于它的良好设计，我没有费太多力气就完成了收尾工作。
接下来我请 Rune 处理 Flutter 和 Rust 侧的整合问题，因为 Rune 的遥控协议是基于自签证书实现的，Flutter 那边做自签证书校验很麻烦，所以网络请求栈全在 Rust 侧。我请它把之前实现的、有问题的 Flutter 侧网络请求转移到 Rust 侧，同样手工整理了很多有用的上下文信息。Claude Code 一步一步地在工程里面寻找参考实现，并且自己写出了 Protobuf 定义、Rust 侧的响应函数和 Flutter 侧的 API Binding。因为中间需要在命令行里面跑一遍代码生成，而 Claude Code 并没有做这件事（我不知道是它不能做还是因为我没提醒它做，它就没做），因此生成出来的代码并没有通过 Linter 检验。特别是 Flutter 侧的 API Binding，调用了完全不存在的 API。不过，这都是很好修的小问题，令我印象深刻的是，它扎实地完成了每一处的异常处理、并且有调理地完成了数据的流动和管理。和修上一个 bug 一样，我怀着非常愉快的心情把它没解决的几个小问题处理了一下，整个程序就跑通了。
老实讲，Cover Art 在客户端和服务器端的流动是一个不好做的事情，如果给我做的话可能要花个两三天才能摸清楚整个业务流程要怎么跑才是最优的，但是 Claude 3.7 给我的开发过程提供了很强的支撑，把原本的技术需求转化成了超出我预期的代码实现。哪怕产出的结果是有 Bug 的，也不能削弱模型产出代码以及背后洞见的价值。
Claude Code 的出现又激起了很多工程师的担忧：它会替代工程师吗？经过一下午的实验，我给出的答案是否定的。比起「终结者」，它更像是优秀工程师的劳保用品，能够减少大量低价值脑力活动造成的心力耗竭。这 2.61 美元然我一下午过得神清气爽，消灭掉了可以说是最难缠的一块 Bug，我觉得很值当。
Ref:
[1] 完整命令行输出
[2] Rune
昨天又推了一版 alpha.2，把 linux-arm64 和 macos 版本修了一下。趁着这次发版讲讲 1.1.0 发版之后的一些幕后故事。
在 1.1.0 发版之后我做了很多探索性的工作，像是音乐的自动 tagging 功能、音频相似性分析算法的测试。音频识别的 Rust 实现已经全都做完了，基于 AcoustID 和 Shazam 两套服务，但是前者限定了不能商业使用（Rune 是一款开源且具有商业性质的软件）、后者是基于野路子直接调 Shazam Android 私有 API 完成识别，我肯定不能随便在 Rune 里面嵌入这些逻辑，所以那一段时间折腾的封装最后就变成了搁置案件放在了 Rune 的软件仓库里没有做后续集成。
不过基于音频识别衍生出来的音频指纹算法可以用于判断媒体之间的相似性，因此媒体去重这个功能现在已经具备技术基础，还差细节性的 UX 设计，这是一个比较复杂的事情，我后面会花时间慢慢做。
接下来就是耗费了我一个多月才完成的遥控协议：在一台电脑上控制另外一个设备上的 Rune 播放什么曲目。
在初期构思这个功能时，我想到了两个实现路径，一个是提供一个简单的播放控制功能：你可以控制播放暂停、切换曲目，就像大多数开源的音频遥控实现一样。另外一个实现路径是：提供完整的 Rune 使用体验，从媒体库浏览、到管理功能全部保留，就像在操控一台正常的 Rune 客户端一样，只是发声的设备不在本地而已。
拿着两个提案去社区里问了一圈，大家更喜欢后面的提案，于是我就开始着手实现了。
因为 rinf 这套方案本身就是通过 protobuf 在 Flutter 和 Rust 之间通信的，所以原理上，我只需要在 Rust 侧把收到的信号走 Websocket 服务器透到目标设备上，再把远端执行的结果传回来，遥控功能就算做完了。
不过，实操上并不是「这不是很简单，你做做不就有了」的事情。因为 rinf 本身并非基于 RPC 思路设计，因此我得用 macro 手工把二者串起来的才能让整件事情工作。此外，Rust 侧也得处理没有唤起方的「事件广播」，像是播放进度、媒体可视化。所以我做的第一件事请就是，把原来实现的 macro 全都打掉，写一套可以自由组合后端的新 macro，并基于此实现一个 Websocket 服务器。
接下来是设备之间的发现问题，很多「开源拖拉机」的做法是「直接打目标设备的 IP」，这不失为一种可行的解决方法，但过于 Nerdy，对用户来说心智负担真的很大。所以我们参照 localsend 的协议在 Rust 上实现了一个基于 UDP 多播的内网发现流程。调试的时候因为忘了 lo 上不能多播所以浪费了很多时间，不过这一块还是比较顺利地实现出来了。
接下来就是鉴权系统的实现和通信加密。我们一定不能直接做明文通信，但内网通信设备之间怎么互信是一个比较麻烦的事情。这边我选择的方案是自签一个证书，公钥的签名当成 Client 模式的密钥、而这个密钥本身也能做 HTTPS 服务的证书，这样能保证基本的通信安全性，而且是通过一组密钥同时解决了鉴权和加密两件事，用户体验上的负担是比较小的。客户端在 Pin 证书的时候，Rune 会挖掉密钥上的两个字符，要用户做一道选择题，在客户端发起请求的时候，担任服务器的 Rune 客户端会自动弹出鉴权请求窗口，上面同时显示了确认是否授权、以及本机密钥两部分功能。客户端需要比照图案作出选择，服务端需要确认给予控制权限。
另外，这套加密通信系统也支持标准证书，这样你可以通过 Nginx 安全第把播放器控制服务暴露给公网，来实现更多用例。
这个设计看起来都挺美好的，但现实比较残忍。我得承认作为一名前端，搞自签证书、配证书信任之类的事情并不是我擅长的，因此熟悉这一块的基础知识和工具链就花了好长时间。算上画界面写后端之类哩哩啦啦的各种杂活，还有我兼开的旧坑卡牌游戏北平IO，这段时间每天都在把自己往 Burnout 的边缘推，所以效率并不高，眼睛一闭一睁好几周就飞出去了。
你或许以为上面这些就是实现遥控功能的全部，但事实上还有很多细节的功能要处理。比如，并不是所有请求都可以被发送到远程，像是连接管理、断开连接、切换媒体库之类的功能还是需要在本地处理，这不仅意味着你需要在封装层面区分两种不同的的消息类型，本地也得提供大量的伪实现来确保能有一个「工作一半、完成基本系统管理」的播放器核心（主要是为了过编译）。
除此以外，虽然播放是在远程，但是展示媒体封面这件事情是在本地发生的，所以还得单独处理 Coverart 提取和下载的问题。但我个人觉得，因为后面还要做手机客户端直接从另外一个 Rune Instance 同步音乐的功能，所以传输二进制文件肯定绕不开，该做还是要做。因为 Flutter 信任自签证书没那么好搞，所以这些功能全都放在 Rust 侧来做了。当然，这些也都是不走远程协议的 RPC 请求。
反正，一个「看起来蛮简单」的功能，实际做起来其实挺复杂的。这次做遥控协议还带来了一个有趣的副产物：Smart Speaker Service，一个纯 CLI 程序，你可以把它挂在 systemd 上，用任意一台设备来控制它的音乐播放。这有点像 Sonos，但不带云服务。
但考虑到 Rune 本身推崇的就是「把音乐放在你自己的电脑上」，这个 Half Sonos 并不鸡肋。
Spotify's Beta Used 'Pirate' MP3 Files, Some from Pirate Bay (❄️ Score: 151+ in 3 days)
Link: https://readhacker.news/s/6pPMf
Comments: https://readhacker.news/c/6pPMf
维苏威火山突然喷发致大脑组织玻璃化
#科学
公元 79 年 8 月，维苏威火山的突然喷发摧毁了意大利庞贝和赫库兰尼姆两座古城。考古学家于 2020 年在赫库兰尼姆一名遇难者头骨中发现了深蓝色玻璃状物质，这是人类大脑在极端条件下瞬间转化为玻璃的结果。这种现象极为罕见。因为要形成玻璃，物质必须被迅速加热到至少510摄氏度，然后急速冷却，以防止晶体结构的形成。对于含有水分的有机物来说，这种情况几乎不可能自然发生。这名死者当时躺在奥古斯都学院的床上，被突如其来的火山灰云瞬间吞噬。普通的火山碎屑流温度不会超过 465 摄氏度，并且冷却速度较慢，不足以导致如此剧烈的变化。科学家推测，是维苏威火山喷发时释放出的超高温火山灰云造成了这一切。这些火山灰云不仅温度极高，而且来去匆匆，它们迅速提升了人体温度，随后又快速消散，导致环境温度骤降。在这种极端条件下，遇难者脑组织瞬间经历了从液态到固态的直接转换，形成了独特的有机物玻璃，而他的头骨为这份珍贵的大脑标本撑起了保护伞，长久地留存了下来。
Scientific Reports:Unique formation of organic glass from a human brain in the Vesuvius eruption of 79 CE
科技日报:揭秘古代悬案：大脑组织为何变成了玻璃
https://github.com/Losses/rune/releases/tag/v2.0.0-alpha.1
发版了，arm 版 Linux 和安卓的 CI 炸了，刚修完，下一版再带上这俩 CI 的修复
Claude Code 这类大语言模型最大的价值在于，把问题的提出这个过程显化出来，让开发者专注于思考「问题是什么」，而不是在实现细节里迷失方向（aka 在屎山里面捞趣多多）。
Читать полностью…
https://fixupx.com/aidenybai/status/1894805880396521862
“法克力扣”
