24小时热榜

我们开发 Greenlight 是因为 App Store 的拒绝很糟糕。 它会扫描您的源代码、Manifest 文件以及 IPA/APK/AAB 文件，以检测是否违反 Apple 和 Google Play 的政策。 它在本地运行，无需账户或上传：brew install revylai/tap/greenlight && greenlight preflight . MIT 许可

LabCraft 是一个由人工智能指导的学习平台，它不是一个聊天机器人！它包含课程内容和一个可供学习者安全练习所学知识的实验环境。人工智能导师会观察用户在实验环境中的操作，并在用户遇到困难时引导他们达成目标。这个过程会随着时间的推移不断迭代，以改进课程、实验环境和导师，所有这些都是为了提供更好的学习体验。 目前，我专注于 Nix/NixOS。这是一项非常有用的技术，但学习曲线陡峭，我的目标是让 LabCraft 帮助用户克服这一挑战。实验环境包含带有仪器化 Shell 的 Linux 虚拟机，使人工智能导师能够观察用户运行命令并根据需要进行指导。Nix/NixOS 课程的约 48 个部分中的第 1 部分今天已对所有用户开放。 我正在寻求用户的反馈，以了解如何以及在何处可以改进学习体验。

我创建它的主要目的是为了测试和探索，但主要原因是因为之前的工作使得它成为可能。

加州有一项古老的第8号提案规定，如果房主房屋的实际价值低于县评估价值，他们可以申请降低房产税。 申请流程是阅读一份名为“出版物30”的100页文件，以精确选择您附近的同类房产，填写表格，签名，然后通过传真/邮寄方式发送给县评估员。 我创建了saveproptax，利用一个基于“出版物30”规则、Redfin数据以及一些基础的传真/邮件发送工具训练的LLM来自动化这一过程。它每年已为湾区房主平均节省了2800美元的房产税。

目前，在

各位 HN 用户： 我们是 OpenLake 的开发者，OpenLake 是一个开源存储引擎，用于将 KV 缓存卸载到远程磁盘和内存。 在将 KV 缓存卸载到本地磁盘后，我们发现瓶颈在于 PCIe 或 NIC 的带宽。我们想知道 GPU 无损压缩是否适用于快速读取和降低 TTFT（Time To First Token）。 BF16 通常很难压缩（符号/尾数熵很高）。令我们惊讶的是，真实世界的 KV 块差异很大。指数字节的熵非常低，几乎没有填充。我们没有压缩整个张量，而是仅在 GPU 上压缩指数流。 我们在 H100（生产 KV 快照）上取得了以下成果： - 1.51 倍无损压缩 - 622 GB/s 的中位数 GPU 解码速度 解压缩速度比 400 Gb/s 的 NIC 带宽快约 10 倍，并且可以无损地传输数据，而不会改变质量。 我们将开源此项目，命名为 ExANS，它将通过我们的 vLLM 和 SGLang 连接器在 OpenLake v0.8 版本中提供。推理引擎无需进行任何更改。 我很想了解大家目前是如何处理 KV 传输的。你们是否在使用 KV 压缩，或者带宽目前还不是瓶颈？ 谢谢！ GitHub：https://github.com/openlake-project/openlake 技术博客：https://theopenlake.com/blog/exans-lossless-gpu-compression-for-bf16-kv-cache

我非常喜欢使用 Conductor 及其带来的体验，但我更喜欢使用终端。所以我构建了 t。<p>它的功能：<p>- `t new "fix vault sync"` 会创建一个 git worktree 和一个分支，并进入该目录。<p>- `t claude`、`t codex`、`t grok`、`t gemini` 会在此处启动一个代理，并将该会话记录到 worktree 和分支中。<p>- 一个任务可以包含多个对话，来自不同的代理，同时在不同的窗格中运行。所有对话都引用同一个 worktree/分支。<p>- `t sessions` 会列出附加到该任务的所有对话，并恢复你选择的对话。`t find` 会在所有对话中进行搜索。

旨在提高编码速度并减少 token 使用量。理论上，大型语言模型（LLM）可以比直接编写代码更快、更省 token 地为确定性本地编码器提供计划，到目前为止，这一理论已经得到了验证。虽然短期内进行修改和教授编码器新的本地技能可能需要时间和 token，但 Sif 会记住新技能，无需重复学习。 名称：Sif 1.0 许可证：Apache 2.0 在 Windows 上开发和测试。 我的大部分测试涉及将 Python 转换为 C++，尽管我也尝试过通用的编码任务。 到目前为止，Python 到 C++ 的转换效果良好。对于前沿模型，大约需要 250-300 个 token 来生成计划，对于闪存开源模型，则需要 400-500 个 token。如果 Sif 之前已经处理过所有要求，则可以一次性完成转换，无需修复。如果您感兴趣，可以在存储库中找到几份测试/基准报告，其中重点介绍了过程中的成功和失败。对于感兴趣的人，我将非常感谢您提供的任何反馈。

大家好，我最近发布了一个名为“Hive for Buzz”的 Buzz iOS 原生客户端的 TestFlight 版本。 我主要想测试一下 Buzz 是否能够完全使用原生方式构建客户端，而无需我修改代码并审查 Buzz 的一切。结果发现，我比官方客户端更喜欢它，哈哈，仅仅是因为原生体验更好，而且它是开源的。这是代码仓库：https://github.com/jtvargas/buzz-ios-client 我的路线图是继续与官方最新版本保持同步，并实现良好的 Siri 意图/设备上的 Apple Intelligence。基本上是想让 Siri 更好地了解我的工作空间，这样在新版本的 iOS 中，Siri 就可以从我与我的代理（agents）进行的工作中获取上下文/参考，也许还可以添加一些通过 Siri 触发工作的意图——我还不确定，需要进一步研究，但目前该应用已经稳定可用，我正在征求反馈意见，谢谢！——我的愿景更像是构建“Apollo for Reddit”，而这个将是“Apollo for Buzz”，哈哈——希望你们喜欢。