## 从重复拍摄到全新发现：一个星空摄影目标规划器
一位星空摄影师对反复拍摄像仙女座这样熟悉的星体感到沮丧，于是他创建了一个工具来重拾探索夜空的乐趣。使用Stellarium等软件手动规划目标耗时费力，需要不断核对可见性、焦距兼容性和难度——往往又回到“安全”的选择。
解决方案？一个星空摄影目标规划器应用程序。该应用程序根据位置、天空质量（例如Bortle 5后院）、焦距和期望难度来筛选潜在目标，简化了选择过程。一个关键功能是“发现模式”，它优先考虑鲜为人知的星云和天体，发掘NGC 7822和问号星云等隐藏的瑰宝。
该应用程序为每个目标提供关键细节，包括最佳成像时间、坐标、构图估算和诚实的难度评估。这种工作流程大大缩短了规划时间——从寻找熟悉目标所需的13分钟，到寻找全新目标所需的85秒，使摄影师能够在一年内拍摄超过40个深空天体。该应用程序目前处于测试版阶段，可免费使用。
每日HackerNews RSS
一个新的网络工具“星云摄影目标规划器”(astroimagery.com) 帮助星云摄影师发现不太为人知的星云进行拍摄。该工具在Hacker News上分享后，因其易用性获得了积极的初步反馈，但有用户指出需要选择“发现模式”才能找到更多非热门目标。
用户们赞赏这个资源，其中一人提到他们最近也构建了一个类似的应用程序，Conjunction1.com。 还有人对该项目的源代码在Github上开放感兴趣。 总的来说，该工具似乎对计划星云摄影拍摄很有用，满足了摄影师寻找新目标的需求。 一些建议的改进包括在设备部分添加望远镜直径/类型和相机灵敏度细节。
## Yapi：强大的API测试工具
Yapi 是一款新的开源命令行工具，专为需要直接从终端测试 API 的高级用户设计。它支持 HTTP、gRPC、TCP 和 GraphQL（未来计划支持更多协议），允许进行全面的测试，包括跨不同协议的请求链。
主要功能包括：内置集成测试，带有期望和断言；语言服务器协议 (LSP) 用于 IDE 集成（目前支持 Neovim，计划支持 VSCode）；以及 GitHub Actions 支持用于 CI/CD。Yapi 还通过配置文件简化了多个环境（开发、预发布、生产）的管理。
目前处于早期 Alpha 阶段，Yapi 正在积极开发中，并欢迎用户通过 GitHub Issues 提供反馈。它被设计为高度可配置和可管道化，将 JSON 输出到 stdout，其他信息输出到 stderr。
您可以从其 GitHub 仓库安装 Yapi，并创建请求文件来定义和执行您的 API 测试，开始使用。欢迎贡献！
## Yapi：一款新型FOSS终端API客户端
Jamiepond分享了**Yapi**，一个免费且开源的基于终端的API客户端（yapi.run），旨在作为Postman等工具的替代品。Yapi专为`nvim`/`tmux`用户设计，目标是通过简化的工作流程提高生产力。
早期的反馈显示其潜力，用户们赞赏它作为一个可定制、自托管解决方案，而不是不断地重新构建自己的工具。一位用户建议能够合并多个“环境”以实现灵活的测试场景。
讨论还涉及了该领域的日益活跃，另一位开发者分享了**Voiden**，一个类似的项目，利用可执行markdown进行文档编写和测试。Yapi的创建者表示有兴趣建立一个用于API定义的标准文件格式，以改善IDE集成并减少碎片化。
一些用户报告在链接的博客文章中遇到404错误，这归因于自定义博客托管设置中的缓存问题。该项目正在GitHub上积极寻求反馈。
## 超越维生素与止痛药：寻找产品与市场的契合点 这篇文章挑战了常见的“维生素 vs. 止痛药”的创业比喻，认为它并无帮助，并专注于可操作的测试，以识别真正有价值的产品创意，特别是对于B2B创始人。核心思想：**关注确定性，而不仅仅是识别问题。** 关键测试包括：**预算削减排名** – 你的产品在成本削减措施中是否会是最后被削减的？寻找它在基础设施、沟通或记录系统中的位置。其次，寻找**非自愿销售** – 用户*恳求*付费，表明迫切的需求。避免需要市场教育或解决人们没有主动意识到的问题的想法。 此外，努力做到在*特定领域*为*特定人群* **好10倍** – 而不仅仅是普遍改进。这创造了一个“无法衡量”的价值主张，绕过冗长的采购流程。 最终，作者提倡寻找那些*已经知道*自己有问题的用户，并且*现在*就在积极寻找解决方案。这些测试旨在消除噪音，并建立对产品与市场契合的信心，提醒创始人“创造人们想要的东西”。
这个Hacker News讨论围绕着“止痛药 vs. 维生素”的比喻，这经常被用于创业建议中。这个观点在2006年被广泛传播，认为创业公司应该努力成为“止痛药”——解决人们*需要*立即解决的迫切问题，而不是“维生素”——可有可无，容易被削减预算的附加品。
然而，这个比喻引发了争论。一些人认为真正的维生素是维持生命所必需的，不像补充剂，因此成为“维生素”应该是目标。另一些人澄清，这个比喻指的是容易被丢弃的*补充剂*维生素。
核心观点仍然是：成功的创业公司通常解决紧迫、关键的问题（止痛药），客户即使在经济困难时期也会优先为此付费，从而可能带来持续的收入。虽然承认个人健康需求和补充剂的好处，但讨论最终强调了创业公司的产品要解决一个“真正的问题”的重要性。
停止劣质软件
Stop Slopware
2 天前
## 停止“劣质软件”：呼吁开源软件质量 StopSlopware.net 关注日益严重的“劣质软件”问题——指那些低质量、杂乱无章、难以维护的软件，往往因不当使用人工智能而加剧。该网站并非旨在批评，而是建设性地敦促开发者提高作品质量。 其核心信息尤其针对初学者：优先*学习*而非仅仅*产出*代码，并避免过度依赖人工智能，因为它会阻碍真正的理解。对于所有开发者，建议放慢速度，简化设计，并确保项目的每个部分都得到充分理解和清晰记录——编写你自己的README！ StopSlopware 提供了一个快速链接，可以分享给存在这些问题的项目，从而节省审查者的时间，并为作者提供反思和改进的机会。它源于对重复反馈的沮丧，以及对培养高质量、可维护的自由和开源软件的奉献。
龙芯架构的支持已经进入了开源Linux基础设施的大部分领域。尽管龙芯中科尚未发布龙芯架构手册的剩余部分，但由于公开的QEMU和Linux变更等大量公开信息，以及指令编码和行为等“未公开”信息实际上已经公开。手册的缺失不再能阻碍人民的优化工作。我们预计龙芯架构的新生态系统将在2023-2024年期间迅速发展，有了您的参与将会更快。本网站由社区维护。欢迎加入！
## 取消平台化策略的反噬 试图通过“取消平台化”来压制争议人物的尝试已被证明是无效的，甚至可能适得其反。最初的反应，例如马修·伊格莱西亚斯声称“取消平台化特朗普就奏效了”，很快就被挑战，因为特朗普和塔克·卡尔森等人物在更大的平台上卷土重来。这呼应了弗洛伊德的压抑理论——压制思想并不能消除它们，而是迫使它们以更具破坏性的形式浮出水面。 2021年的“大取消平台化”——包括对Parler的行动以及对亨特·拜登笔记本电脑故事的压制——旨在控制叙事，但反而助长了怨恨和极端声音的崛起。埃隆·马斯克收购推特暴露了政府此前审查言论的努力，导致了一种转向开放性讨论的转变。 这种开放性，以推特“社区笔记”功能为例，拥抱了“思想市场”的方法，允许用户集体评估信息。它也揭示了一种被称为“偏好伪装”的现象，即被压制的信念在人们感到可以安全表达时会爆发——就像是对虚假觉醒表演的悄然远离。 虽然言论自由允许有害意识形态持续存在，但教训很明确：审查制度行不通。相反，直接面对具有挑战性的思想，促进真正的辩论，以及批判性地检查我们自己的偏见，对于健康的民主至关重要。现在的挑战是在这个不受监管的环境中以理性的方式航行，并抵制回音室和分裂性言论的吸引力。
## 取消平台化适得其反：一则黑客新闻讨论摘要
近期一篇文章在黑客新闻上引发争论，认为取消平台化个人和观点并不能消除它们，反而可能通过将它们驱赶到互联网上不那么显眼的地方，从而加强和两极分化它们。用户讨论了例如撤回《60分钟》节目片段、金融制裁以及平台内容审核等案例，质疑压制观点是否比公开挑战它们更具危害性。
许多评论者同意，仅仅移除声音并不能解决潜在的信念，并以特朗普即使被推特封禁后仍有支持者，以及尽管平台移除了相关内容，反疫苗情绪仍然存在为例证。一些人提到了“斯特赖桑德效应”以及审查制度可能适得其反的观点。
一个关键的争论点是，直接与有害观点互动是否比压制它们更有效，一些人认为，充分的公开辩论至关重要。另一些人则反驳说，这种互动往往是无效的，尤其是在面对根深蒂固的信念时，而且即使是严格的审核也能促进更健康的讨论，正如黑客新闻平台本身所展示的那样。讨论还涉及了一些审查行为的表演性质以及将一种文化背景（例如中国）的策略应用于另一种文化背景的复杂性。
经典台球可以计算（二维台球系统是图灵完备的）
Classical billiards can compute (2d billiard systems are Turing complete)
2 天前
arXivLabs是一个框架，允许合作者直接在我们的网站上开发和分享新的arXiv功能。个人和与arXivLabs合作的组织都认同并接受我们开放、社群、卓越和用户数据隐私的价值观。arXiv致力于这些价值观，并且只与秉持这些价值观的合作伙伴合作。您是否有为arXiv社群增加价值的项目想法？了解更多关于arXivLabs的信息。
## ExecuTorch：使用 PyTorch 进行设备端 AI
ExecuTorch 是 PyTorch 针对 AI 模型直接部署到设备（从智能手机到微控制器）的解决方案，优先考虑隐私、性能和可移植性。它在 Meta (Instagram, WhatsApp, Quest, Ray-Ban 智能眼镜) 内部得到广泛使用，允许使用熟悉的 PyTorch API 无缝部署 LLM、视觉、语音和多模态模型。
主要特性包括直接从 PyTorch 导出 *无需* 中间格式转换，拥有 50KB 的微小运行时，并通过一次导出支持 12+ 硬件后端（Apple、Qualcomm、ARM 等）。它利用提前编译来优化模型以进行边缘部署，采用标准化的算子集和 CPU 回退。
部署涉及导出、编译（具有量化选项）和执行生成的 `.pte` 文件。ExecuTorch 提供 C++、Swift (iOS) 和 Kotlin (Android) 的 SDK，以及用于 LLM 和多模态模型支持的工具（Llama 3, Llava, Voxtral）。高级功能包括量化、内存规划以及用于调试和优化的开发者工具。
ExecuTorch 采用 BSD 许可，并欢迎社区贡献。
## Executorch：PyTorch 的设备端 AI - 摘要
Meta 的 Executorch 旨在将 PyTorch 模型带到移动、嵌入式和边缘设备。讨论强调了用户对 Torchscript 弃用及其替代方案 `torch.export` 的限制感到沮丧。用户在迁移时，在控制流实现和后端支持（如 TensorRT）方面遇到困难。
虽然 Tensorflow Lite 在微控制器领域仍然占据主导地位（尽管 PyTorch 具有树莓派 Pico 2 示例），但 Executorch 提供了简化移动开发的潜力——避免了对 C++ 或 MLC 的需求。一个关联项目 ai-edge-torch 促进了从 PyTorch 到 TFLite 的转换。
对话还揭示了三星 Exynos NPU SDK 存在的问题，该 SDK 因文档匮乏和访问限制而受到批评，与高通和联发科更开放的方法形成对比。
Executorch 团队承认路线图计划包括改进微控制器（Arduino、STMicro）和 Web（WASM）支持，并积极通过 Discord 和 GitHub 寻求社区反馈。他们还指出 Vulkan 后端集成，并且正在收集反馈以改进三星支持，然后再宣布该后端准备就绪。
## AI 与软件验证的未来：一种平衡的观点
人工智能正在迅速改变形式化验证的格局——这是一个数学证明软件正确性的过程。在数十亿美元的投资和 Lean 等证明助手日益普及的推动下，人工智能正在取得显著成果，甚至能够解决国际数学奥林匹克竞赛中的复杂问题。专家们对人工智能革新软件工程的潜力持乐观态度。
然而，仍然存在重大挑战。一个主要障碍是大多数现有软件缺乏形式化规范；人工智能辅助编程提供了一条解决途径，即通过激励规范驱动的开发。即使*有*了规范，证明工程仍然困难，工具也不够完善。
人工智能在自动形式化（将意图转化为形式逻辑）和证明编写方面表现出色，但自动形式化步骤引入了一个关键漏洞——“可信计算基”，因为机械地验证翻译的准确性是不可能的。此外，证明助手速度慢，并且创建用于验证的全面模型（尤其是针对运行时性能）极其复杂。
作者提倡一种协同方法：**验证引导开发 (VGD)**。 这将形式化验证的简化实现与更快的生产版本相结合，并使用测试来确保它们行为一致。 尽管测试存在局限性，但它仍然对于证伪不正确的定理和探索形式化模型范围之外的领域至关重要。 最终，强大的测试*和*由人工智能驱动的日益复杂的形式化验证相结合，为实现更可靠的软件提供了最有希望的途径。
## AI 与软件验证的未来 (Hacker News 总结)
这次 Hacker News 的讨论围绕一篇博客文章，该文章认为人工智能正在将软件开发的瓶颈从 *实现* 转移到 *验证*。 长期以来，形式化验证一直是一个目标，但历史上它过于复杂且耗时。 然而，人工智能的最新进展，特别是大型语言模型，正在改变这一现状。
核心思想是人工智能可以协助生成形式化规范，并且至关重要的是，*尝试证伪* 这些规范，从而有效地自动化大部分验证过程。 这并不意味着完全自动化的证明即将到来，但它使得处理非平凡代码库的验证变得更加可行。
对话强调了对不同验证方法价值的争论——从基本的单元测试到形式化证明——以及静态类型和动态类型的作用。 许多评论者认为人工智能将重燃人们对测试驱动开发和极限编程等技术的兴趣。 然而，对于广泛形式化验证的实用性仍然存在怀疑，人们担心计算成本以及人工智能可能通过修改测试而不是修复代码来“作弊”。 最终，讨论指出，人工智能将能够实现更高程度的软件正确性，但道路仍然充满挑战。
## 3D HBM：可行的未来，但存在重大障碍 Imec 的最新研究表明，将高带宽内存 (HBM) 直接堆叠到 GPU 上（“3D HBM-on-Logic”）在技术上变得可行，为 demanding 的 AI 工作负载提供潜在的性能提升。然而，出现了显著的热挑战——初步模拟显示温度远超安全限制。 Imec 提出了一种多方面的解决方案，包括移除 HBM 基底，合并 HBM 堆栈，减薄内存，以及至关重要的是，**将 GPU 的时钟频率减半**。增强冷却，可能包括背面冷却，也至关重要。 虽然这些缓解措施将温度降低到与当前 2.5D 设计相当的水平，但权衡是巨大的。最大的问题是 GPU 频率降低 50%，影响整体计算吞吐量。尽管如此，Imec 认为增加的内存带宽可以弥补一些性能损失，可能为受内存限制的 AI 任务提供 22-46% 的性能提升。 然而，商业可行性仍然存疑。实施这些更改需要在整个供应链中进行重大重新设计，可能影响成本和良率。其他方法，如先进的 2.5D 互连或光存储解决方案，也在探索中。最终，Imec 的工作强调了创新散热的迫切需求，因为 AI 需求不断将硬件推向极限。
一篇最近发表在morethanmoore.substack.com上的文章讨论了高带宽内存（HBM）直接集成在逻辑芯片之上（“HBM-on-Logic”）的挑战和潜力。
Hacker News的评论员们争论了该文章对降低时钟速度以显著提升LLM推理性能的否定——许多人会接受这种权衡，考虑到运行这些工作负载的巨大成本。一个关键点是*为什么* HBM要直接放置在芯片上而不是在PCB上。 回复强调，通过PCB过孔路由信号的效率低于芯片到芯片的桥接，并且将HBM放置在逻辑芯片下方可以改善散热。
讨论的结论是，HBM集成仍在发展中，超大规模数据中心正在权衡功耗、密度和性能之间的复杂权衡。预计未来十年将继续采用异构计算方法，利用这种密集但脆弱的计算架构以及其他架构。