一周热榜

嗨，HN！我一直在开发一个物联网平台，旨在通过将预配置的LTE硬件与云平台结合起来，简化远程传感器网络的部署，以便进行远程编程和基于人工智能的分析。 我正在尝试解决的主要挑战包括： 1. 消除物联网部署中的基础设施设置烦恼 2. 使远程编程和调试对那些可能难以物理接触的设备变得可行 3. 使用自然语言分析传感器数据，并可能根据分析结果采取行动 我非常希望能得到以下方面的反馈： 1. 这种物联网开发的方法对你们来说有趣吗？ 2. 你们希望通过这种平台探索哪些应用场景？ 3. 对于采用这样的技术，你们有什么顾虑？ 4. 有没有人推荐一些工作流程或工具，以提高人工智能代理的可靠性？目前我正在使用大型语言模型生成孤立的SQL查询来提取数据，但确保响应的一致性一直很具挑战性。 感谢大家的想法，欢迎随时询问有关硬件或平台如何工作的任何问题。我很乐意深入探讨细节！

我在适应世界的新节奏和发展方面遇到了困难。<p>虽然人工智能有些有趣，但我担心长期来看，这会对人类造成生存风险，尤其是在失去自主性、推理能力、人性和创造力方面——这与社交媒体对我们注意力和心理健康的影响类似。<p>我通常比较保守，支持技术和初创企业，但在这种情况下，我担心自己在技术上已经达到了“事件视界”，而我才刚刚走上职业生涯的半途。<p>我能看到人工智能的影响力，但我就是无法在技术上跟上潮流——这对我没有吸引力。感觉这只是糟粕堆积在一起。<p>向Claude或Cursor请求编写代码确实很酷，但我对编程这门技艺的情感投入却减少了。<p>然而，我们似乎正处于一个“沉没或游泳”的时刻，这与Shopify的Tobi在他的博客中提到的情况类似。<p>对此有什么建议吗？

我知道最近这个项目一直在衰退……大多数引用的资料都很旧，比如这个： https://github.com/richardjrossiii/CBasediOSApp<p>所以我想问：这可能吗？

嘿，HN， 我们是 Chonkie 的开发者，一个强大且易于使用的分块库。去年十一月，我们在 HN 上介绍了 Chonkie OSS（<a href="https://news.ycombinator.com/item?id=42100819">https://news.ycombinator.com/item?id=42100819</a>），并收到了非常棒的反馈。今天，我们很高兴地分享 Chonkie Cloud，这是一个完全托管的分块服务，并推出了新工具，使构建和调试 RAG 系统比以往任何时候都更容易。 --- 为了提供一些背景信息： 我们在去年底将 Chonkie 作为一个开源项目推出。几周前，我们决定全职投入这个项目。不幸的是，这一转变并没有我们预期的那么顺利。由于一些法律问题，我们不得不在一个新的代码库中从头开始重建整个项目。 重新开始的过程很糟糕，但这给了我们机会来整理和构建更快、更干净、更好的东西。你可以在这里查看新的代码库：<a href="https://github.com/chonkie-inc/chonkie">https://github.com/chonkie-inc/chonkie</a> --- 我们今天推出的内容： - **Chonkie Cloud** – 一个完全托管的分块服务。只需发送你的文本，就能获得分块结果。它支持我们所有的分块器，并配有一个可视化 RAG 的游乐场。试试看：<a href="https://chonkie.cloud" rel="nofollow">https://chonkie.cloud</a>（无需信用卡） - **Chonkie Recipes** – 预定义的分块配置，帮助你快速入门。如果你不确定使用哪些设置，只需在我们的配方中找到最接近的匹配。这些配置适用于递归和延迟分块器。可在这里获取：<a href="https://huggingface.co/datasets/chonkie-ai/recipes" rel="nofollow">https://huggingface.co/datasets/chonkie-ai/recipes</a> - **Chonkie Vizard** – 一个在开发过程中可视化分块输出的工具。如果你曾经用充满破折号和星号的打印语句进行调试，这个工具就是为你准备的。 安装方法：`pip install "chonkie[viz]"` 示例用法 (1)：`viz.print(chunks)` # 在终端打印 示例用法 (2)：`viz.save("out.html", chunks)` # 保存以备后用 --- 接下来要做的事情： - 一个代码分块器 - 用于清理和准备数据的文件“厨师” - 与向量数据库和数据提取工具的集成 - 支持更多语言（TypeScript 是我们列表上的第一位） --- 我们非常希望能收到关于我们正在构建的内容的反馈。如果你有功能请求或想法，请在代码库上提出问题（<a href="https://github.com/chonkie-inc/chonkie">https://github.com/chonkie-inc/chonkie</a>）或在这里评论。 谢谢！

我一直在想，是否有人知道为什么没有适合大规模直播内容的P2P协议，且质量还不错？具体来说，是什么技术限制，还是说大多数人不想被媒体公司的律师搞得一团糟？我搜索了一段时间，找不到能够处理数千人同时直播的解决方案。最接近的可能是WebRTC，但它似乎只能处理大约500个节点。 我在想，现在大多数人至少有30Mbps的上传速度，而1080p的直播只需要大约10Mbps，720p则需要大约5Mbps。我认为直播不一定是实时的，人们肯定不会介意有一定的延迟。我认为在网络中数据包传播的复杂度应该是对数级别的（Log(N)），因为如果一个主节点在分享内容，并且连接了10个从节点，那么这些从节点又连接了其他10个从节点，以此类推。 我能想到的另一个限制是优先处理哪些人先接收数据包，因为有很多人拥有1Gbps或超过10Mbps的连接。同时，还需要降低对“吸血鬼”用户的优先级，以防止他们影响直播质量。 不过，是否有人知道为什么这仍然不是一个现实呢？在网站上找到直播流非常简单，但它们都是360p的，或者几乎无法加载。我看到BitTorrent的原始创造者在十多年前就开始创建类似的东西，但似乎这个项目已经死掉了。而且这还忽略了编写这样一个程序所需的巨大时间投入。我想知道，是否在技术上有可能实现例如10万人同时直播，为什么可以或不可以。 只是一些想法，提前感谢！

我最近在现代系统上复活了Infocom原版UNIX z-machine的源代码。修改后的源代码、使用说明、z-machine的构建以及嵌入式游戏可执行文件的示例都已提供。 此外，还有一篇详细的文章，介绍了原始源代码的状态、移植过程，以及Justine Tunney的Cosmpolitan项目在将《祖尔克三部曲》（以及更多内容）移植到Windows/Mac/Linux/BSD的arm/x86机器上所发挥的不可或缺的作用，这一切都是在一个慵懒的星期天完成的。