该项目致力于数字化玛伊蕾德·尼·格拉达(Máiréad Ní Ghráda)的《曼南南的数字化》(1940),这是一部罕见的爱尔兰语青少年科幻小说,可能包含机甲的首次描绘以及对引力助力的文学提及。由于该书目前没有再版或翻译版本,此举旨在提高其可读性。
该工作涉及从扫描的PDF文件中提取文本并仔细校正,因为该书使用了较旧的爱尔兰语正字法。目前正逐章推进,已完成并手工校正了第9-18页的OCR输出结果。一项关键策略是尽早识别并修复常见的OCR错误,因为这些模式会在整个文本中重复出现,从而简化未来的校正工作。
该项目欢迎贡献,特别是来自爱尔兰语母语者的帮助,以识别和纠正提取文本中任何剩余的错误。全书共188页,包含目录,列出了章节标题和页码范围。
## 6502 笔记本项目总结
该项目详细介绍了基于 65C02 处理器、运行于 8MHz 的一个完全功能、便携式笔记本电脑的创建过程。目标是超越“PCB 堆叠”,构建一个自包含的系统。
该笔记本电脑具有 46K RAM、ROM 中的 BASIC、65C22 VIA 以及 9 英寸显示屏。存储由 Compact Flash 卡提供,由 10000mAh 电池供电,并通过 USB-C 充电。输入由内置键盘处理,同时也可通过串口控制台进行操作。内部扩展槽允许未来升级。
开发始于 2025 年底,并在 2026 年初获得可用的 PCB。关键里程碑包括使核心组件正常工作、集成键盘以及实现带有 `LOAD`、`SAVE` 和 `DIR` 命令的 Compact Flash 支持。图形功能已添加,包括用于绘制圆、线和散点的命令。该项目基本完成,功能性外壳已组装完毕,但仍有待改进之处,例如更大的显示屏(计划 10.1 英寸)和键盘代码优化。
在商业山核桃产业出现之前,山核桃是美洲原住民的重要资源,用于食物、贸易、仪式(如阿尔冈昆人的“powcohiccora”饮料)和医药——甚至作为抗菌剂。这个坚果的名字本身就源于阿尔冈昆语,指的是它坚硬的外壳。
虽然像华盛顿和杰斐逊这样的南方人喜欢山核桃,但早期的商业种植尝试由于种子生长的树木产量不稳定而失败。这种情况在19世纪由奴隶园丁安托万改变,他开创了一种成功的嫁接方法,创造了“百年”品种。这项创新使得大规模生产成为可能,到1920年产量达到每年一千万磅,并建立了一个价值数百万美元的产业。
尽管取得了成功,但当种植园转为种植甘蔗时,安托万的工作最终被遗忘。这个故事凸显了奴隶个人对植物学和农业贡献被更广泛地抹去的现象,他们的关键专业知识和劳动常常被欧洲探险家掩盖。山核桃至今仍具有文化意义,尤其是在黑人南方美食和传统疗法中。
## RynnBrain:一个具身基础模型
RynnBrain是一个新的具身基础模型,旨在理解和与物理世界互动。它已发布代码和模型检查点(2B、8B和30B-A3B版本),擅长需要详细视频理解、空间推理和精确规划的任务。
主要特点包括强大的第一人称理解(如具身问答和物体计数)、准确的时空定位,以及一种独特的交错推理方法,将语言与物理现实相结合。还提供专门的后训练模型,用于机器人任务规划(RynnBrain-Plan)、视觉语言导航(RynnBrain-Nav)和链式指向推理(RynnBrain-CoP)。
RynnBrain基于Qwen3-VL构建,采用统一的编码器-解码器架构,并经过大量时空和物理数据的训练。它使用新的RynnBrain-Bench基准进行评估,重点关注物体与空间认知、 grounding 和指向。 演示、cookbook 以及预训练/评估细节(通过RynnScale)均可获得。
## 星际飞行:复古游戏深度解析
《星际飞行》于1980年代发行,是一款开创性的沙盒太空探索游戏,玩家可以完全自由地驾驶星舰——采矿、战斗和外交都是可行的途径。 整体故事随着玩家发现一个来自古代种族的威胁而展开,该威胁导致恒星耀斑并摧毁生命。 过去和现在都广受赞誉,《星际飞行》深刻影响了后来的开放世界游戏。
最近,一位狂热爱好者开始逆向工程《星际飞行》,并发现这个过程极具挑战性。 与通常使用大量汇编代码的游戏不同,《星际飞行》是用Forth编写的,这是一种极简主义编程语言。 这导致可执行文件结构与原始源代码非常接近,并且仍然存在令人惊讶的调试信息。
该游戏的代码严重依赖于间接线程——一种节省空间但速度较慢的方法——并利用了大量的代码覆盖,从而使分析变得复杂。 该项目成功地解除了游戏的汇编,揭示了其错综复杂的内部结构,并提供了对开发者原始思维过程的迷人一瞥。 最终解编译的代码和数据是公开可用的,为探索经典游戏的核心提供了一个独特的机会。
## Perlin Terminal:你的命令行中的精美噪声
Perlin Terminal 使用 24 位真彩色和半块字符,将令人惊叹、流畅的 Perlin 噪声动画直接带到你的终端,从而提高视觉保真度。享受流畅的 60 FPS 的流动渐变和有机运动。
该程序提供多种颜色主题——海洋、火焰、极光和矩阵——每种主题都能创造出独特而迷人的效果。它易于自定义,可调整噪声比例、动画速度,甚至 Perlin 噪声种子。
安装很简单,可以使用 `cargo install --git https://github.com/denisepattenson/perlin-terminal` 或从源代码构建。使用 `--theme` 和 `--scale` 等标志控制动画,并使用 Ctrl+C、Q 或 Esc 干净地退出。需要支持 24 位真色彩的终端和 Rust 1.70+。
## DjVu:被忽视的文档格式
DjVu 是一种在处理扫描文档(尤其是书籍和学术论文)方面明显优于 PDF 的文件格式。虽然现代 PDF 已经采用了一些 DjVu 的创新技术,但在高效处理扫描内容方面仍有所不足。PDF 通常将扫描件视为简单的图像(如 JPEG),导致文件体积庞大且文本表现力差。然而,DjVu 能够智能地将文档分析为文本和图像的混合体,丢弃冗余数据,从而实现显著更好的压缩。
DjVu 由后来创立深度学习的先驱们(包括 Yann LeCun 和 Léon Bottou)创建,它利用小波和算术编码(IW44 和 JB2)等先进的压缩技术来实现令人印象深刻的文件大小。它甚至包含可能容易受到攻击的元素,突出了像 PDF 这样复杂格式中固有的安全风险。
尽管 DjVu 具有技术优势,并有可能创建一个庞大的在线图书馆,但由于操作系统和浏览器缺乏原生支持,它未能获得主流应用。如今,访问 DjVu 文件通常需要专门的软件,例如在已 root 的电子阅读器上使用 Koreader,这对于一种理想的便携式扫描内容格式来说,是一个令人沮丧的障碍。作者认为,DjVu 保存的知识甚至可能超过许多现代、数字原生信息的价值。
## Windows 原生构建的困境与解决方案
在 Windows 上维护原生项目,往往演变成支持复杂的 Visual Studio 安装程序,而不是自己的代码。仅仅将“Visual Studio”列为依赖项,就会给贡献者带来令人沮丧的体验,需要特定的工作负载(如 C++ 构建工具和精确的 SDK 版本),并且经常导致花费数小时排查难以理解的构建错误。这与 Linux 不同,在 Linux 上,工具链可以通过包管理器轻松管理。
核心问题在于 Visual Studio 的整体性——将编辑器、编译器和 SDK 混为一体——以及其组件缺乏版本控制。这导致安装时间过长、安装过程不透明以及环境不一致(“在我机器上可以运行!”)。
为了解决这个问题,开发者 marler8997 创建了 **msvcup**,一个将 MSVC 工具链视为现代、版本化的依赖项的 CLI 工具。它解析 Microsoft 的组件清单,直接从 Microsoft 的 CDN 下载必要的包,并将它们安装到隔离的、版本化的目录中。
**msvcup** 提供快速、可重现的构建、交叉编译支持,并消除了对 Visual Studio GUI 的需求。它已被证明可以成功地从头开始构建 raylib 等项目,而无需完全安装 Visual Studio,从而为更精简的 Windows 原生开发体验提供了一条途径。
Go的包完整性非常强大,这得益于Go校验和数据库,它确保所有用户访问的是每个模块版本的相同、经过验证的源代码,即使在去中心化模块获取的情况下也是如此。该数据库在首次使用时对模块版本进行加密哈希处理,并验证后续获取,防止恶意篡改,例如强制推送的标签或打字劫持攻击。
然而,依赖GitHub等代码托管平台会引入漏洞——它们的网页界面不会将源代码与校验和数据库进行验证。像`go mod download`以及即将推出的`go mod verify -tag`命令可以在本地提供帮助,但pkg.go.dev等服务仍然链接到潜在的未经验证的代码。
新的替代方案,如pkg.geomys.dev,通过直接从Google模块代理访问模块压缩文件,提供经过验证的源代码查看。虽然目前信任该代理,但未来的更新旨在整合透明日志证明检查,以增强安全性。这项工作由Geomys支持,并获得Ava Labs和Teleport等公司的资助,确保可持续的开源维护。
## 快速模式对决:Anthropic vs. OpenAI
Anthropic 和 OpenAI 最近都推出了其编码模型的“快速模式”,大幅提升了交互速度。然而,两种方法以及结果却大相径庭。OpenAI 的快速模式声称超过每秒 1000 个 token(比标准速率快 15 倍),但依赖于一个更小、能力较弱的模型 GPT-5.3-Codex-Spark,该模型运行在配备巨大内部内存的 Cerebras 专用芯片上。
Anthropic 的方案通过减少“批处理”来实现高达 2.5 倍的速度提升——本质上是优先考虑即时响应,而不是最大化整体吞吐量,成本增加 6 倍。
虽然 OpenAI 的速度令人印象深刻,但 Spark 能力的降低导致更多错误,尤其是在工具调用等复杂任务中。Anthropic 优先考虑模型保真度,即使速度提升较慢。这种差异源于 OpenAI 利用新硬件(Cerebras 芯片)和精馏模型,而 Anthropic 优化现有基础设施。
最终,作者质疑“快速、能力较弱的推理”是否真的是人工智能的下一个重大飞跃,认为准确性对于有用的 AI 代理仍然至关重要。