最新

大家好！ 我很高兴与大家分享我作为学术研究一部分开发的这个项目：土耳其筛法引擎（TSE v1.0.0）。 这个引擎是 N/6 比特方法的实现，这是一种新颖的方法，旨在最大限度地减少内存占用，同时最大限度地提高素数生成的吞吐量。 无论您是数学爱好者、密码学研究人员，还是高性能计算（HPC）极客，我都希望得到您的反馈！ 大家好， 我一直在致力于优化素数筛选，特别是侧重于在不牺牲吞吐量的情况下减少内存占用。我开发了一种名为 N/6 比特的方法，并将其实现到一个名为土耳其筛法引擎（TSE）的工具中。 该项目现已开源，我正在寻求社区对实施和性能的反馈。 技术概述： 方法：N/6 比特结构（在链接的论文中解释）。 实现：使用 NVIDIA CUDA 和 OpenMP 的混合并行。 目标：在现代硬件上实现效率最大化。 我为那些有兴趣进行基准测试或代码审查的人提供了预编译的二进制文件。 GitHub：[https://github.com/bilgisofttr/turkishsieve](https://github.com/bilgisofttr/turkishsieve) Zenodo（学术论文）：[https://zenodo.org/records/18038661](https://zenodo.org/records/18038661) 我很乐意听取您对内存管理的看法，或者如果您有来自不同 GPU 架构的结果。

在YouTube视频中，我遇到了部分无法跳过的色情广告（包括露骨的音频和视频），推销壮阳药，这些广告甚至出现在教育类和儿童内容中。<p>我已立即向谷歌举报。<p>这已经过去一个多星期了。<p>没有收到任何回复，而且我在不同的浏览器/设备上多次看到了这个广告。<p>谷歌真的有真人审核这些广告吗，还是他们已经完全自动化了，只剩下机器人？<p>看起来他们现在会把广告卖给任何人，根本不审核，同时还像守财奴一样拼命敛财。<p>恶意广告由来已久，但这次的情况是我见过的最恶劣的。

Hi HN， 我是一名高中开发者，也是终端定制的忠实粉丝。在 Neofetch 停止维护后，我希望能构建一个“即时”响应，并充分利用 Rust 性能的工具。 这就是我创建 StarFetch 的原因。 为什么值得一试？ 零延迟：它的设计足够快，你可以把它放在你的 .zshrc 文件中，而不会感到任何卡顿。 Rust 驱动：这对我来说是一个学习系统编程的好方法，对用户来说，它也是一个内存安全的二进制文件。 简洁的输出：专注于核心信息，没有冗余内容。 我一直在自己的配置中使用它，配合 yabai 和 sketchybar 等工具，开发过程非常愉快。我最近甚至把它提交到了“This Week in Rust”。 我很乐意听取你对代码实现的想法，或者你认为现代 fetch 工具在 2026 年应该具备哪些功能。 GitHub: [https://github.com/Linus-Shyu/StarFetch_Core] 感谢您的关注！

- 比 Ghostty 文档更直观的视图 - 无需打开新的文本编辑器即可直接编辑配置 - 按名称或描述搜索

嗨，各位 HN 用户， 我构建了一个早期原型，探索在实践中是否可以使用自托管医疗记录，利用密码学证明，而无需将敏感的健康数据上链。 我正在测试的问题是印度尼西亚的医疗数据碎片化问题，患者记录分散在各家医院，在紧急情况下往往无法获取。 区块链仅被用作不可篡改的审计层；该系统即使链发生变化也能正常运行。 关键设计选择： * 医疗数据不上链（仅哈希值，用于验证和审计） * 所有记录均在链下加密 * 患者通过基于二维码的共享方式控制访问权限（医生不接触加密货币） * 区块链被视为验证层，而非存储层 目前获得的经验教训： * 医院不会运行区块链基础设施 * 医生不会管理私钥 * 用户体验比密码学更重要 * 密钥恢复比预想的更难 * 监管在早期就影响架构 这尚未达到生产就绪状态，也尚未解决监管、密钥恢复或医院互操作性问题。 我主要寻求关键反馈： * 这种方法在哪些方面存在根本性缺陷 * 我应该考虑哪些更简单的设计方案 * 医疗保健从业者的现实检验 代码库和技术细节在 README 中。 乐于回答问题。

大多数 ZK 证明系统都针对具有海量 RAM 的服务器级硬件进行了优化。当扩展到工业级规模的迹线（2^20+ 行）时，它们经常会遇到“内存墙”，其中分配和数据移动成为比实际计算更大的瓶颈。 我一直在开发 Hekate，这是一个用 Rust 编写的 ZK 引擎，它利用零拷贝流模型和混合分块评估器。为了测试其极限，我使用 Keccak-256 在 Apple M3 Max 笔记本电脑上与 Binius64 进行了正面交锋的基准测试。 结果突出了一个显著的架构差异： 在 2^15 行时：Binius64 速度更快（147 毫秒 vs 202 毫秒），但 Hekate 已经更节省内存 10 倍（44MB vs ~400MB）。 在 2^20 行时：Binius64 达到 72GB 的 RAM 使用量，在笔记本电脑上进入交换地狱。Hekate 在 4.74 秒内处理相同的工作负载，仅使用 1.4GB 的 RAM。 在 2^24 行（1670 万步）时：Hekate 在 88 秒内完成，峰值 RAM 为 21.5GB。由于在此硬件上出现 OOM/Swap，Binius64 无法完成任务。 核心区别在于“物化 vs 流式传输”。虽然许多引擎在 Sumcheck 和 PCS 操作期间在 RAM 中物化和复制大型多项式，但 Hekate 通过 CPU 缓存以分块方式流式传输它们。这使得 ZK 证明的单位经济效益从 2.00 美元/小时的高内存云实例转移到 0.10 美元/小时的商品硬件或本地边缘设备。 我正在寻求社区的反馈，特别是那些从事二进制域、GKR 和内存受限的 SNARK/STARK 实现的人。

你们中的许多人应该都熟悉 pg 的“创作者时间表，管理者时间表”：https://paulgraham.com/makersschedule.html 我发现，使用 Claude Code 后，我一天的工作方式发生的主要变化之一是，我的工作不再需要像创作者时间表那样，需要一整块时间来高度专注。 我可以给代理分配任务，然后去做别的事情，想回来的时候再回来，任务就完成了。测试一下，分配下一个任务，然后去吃个点心。重复这个过程。 会失去什么吗？当然，你无法像以前那样深度地投入到代码中。但并非所有代码都需要这样。有些事情是可以委托的。

我最常看到和听到的、最可靠的辨别方法是： “这不是 X，是 Y。” 或者 “这并非 X，而是 Y。” 此外，当人类拼写错误，例如将“IOUS”拼成“I O U S”，或者数字合成的“数字孪生”将“read”错误地拼写成“read”而不是“read”时。有时，单词的重音也会出错。 我希望这些“口令”能保留下来，因为它们至少能提醒我这是粗制滥造的 AI。

大家好，HN！我开发了ImageTextEditor——一个用于编辑图片中文字的小型网络工具。<p>目标是保持工作流程极简：上传 → 选择文本区域 → 输入替换文本 → 生成。我专注于通过移除旧文本并重建背景，使编辑效果看起来自然，而不是简单地覆盖新文本。<p>当前状态：[效果最好的功能]，已知局限：[棘手情况]。<p>我希望得到关于以下方面的反馈：<p>结果看起来“修补”的情况，<p>对于此类工具，哪种导出/定价模式是合理的，<p>您最希望它能良好处理哪些图像类型（截图 vs 照片 vs 横幅）。<p>感谢您的关注！