最新

我在Windows上开发Blazor Server应用程序，但将其部署到Linux服务器（主要是出于成本考虑）。<p>很多时候，应用程序在本地运行正常，但在Linux上却失败。在许多情况下，问题出在大小写敏感的路径或文件系统差异上。<p>我很好奇其他人是如何处理这种工作流程的。<p>你们也在Windows上开发并部署到Linux吗？遇到了哪些问题？

我正在开发一个专门为自主AI代理设计的内存平台。 目前，代理内存面临两个乏味的选择：RAG（关系拓扑丢失）和图数据库（需要大量指针追踪，并在重度递归推理时性能下降）。 我正在使用向量符号架构（超维计算）构建一种替代方案。通过将事实、序列和树以数学方式绑定成固定大小的高维向量（D=16,384），我们可以将复杂的图遍历压缩为O(1)常数时间的SIMD操作……并且以低成本实现一些类脑的功能，也就是说，不依赖于GPU和大型语言模型（LLM）。 设计正在顺利成熟，并严格分为两个部分，以尊重机械同情： • 数据平面（Zig）：纯粹的裸金属数学。通过io_uring实现2GB内存映射的NVMe块。事实被叠加到严格对齐到64字节缓存行的无锁8位累加器中。查询通过AVX-512 popcount指令执行，以线速计算汉明距离。没有垃圾回收。 • 控制平面（Gleam）：处理并发、路由以及用于外部通信的Linda风格元组空间。它管理代理的“清理”循环和自动分块，而不会阻塞数据平面。 • 桥接：一个严格的C-ABI/NIF边界，将指针从BEAM调度器直接传递到Zig的核心部分。 这里没有风险投资的浮夸言辞，我也没有对AGI做出夸大的声明。我已经完成了大部分规格、内存布局不变性和架构设计。现在开始编码，并取得了良好的进展。 我在寻找热爱低级系统（Zig/Rust/C）或高度并发运行时（Erlang）的人来帮助我构建这个平台。这是我第二个AI平台，第一个平台运转良好并在不断增长。 如果你对裸金属系统工程感兴趣，想解决LLM上下文瓶颈，我很乐意交流：请发邮件至acowed@pm.me。 祝好， Kendall

快速分享这个概述。为了获得一个操作系统神经系统，而不是典型的人工智能网络架构，我们做出了架构选择，将语音、接口和系统状态作为独立服务，通过共享的网络进行协调——这为我们提供了PearlOS的“骨架”。

Mozzie最初是我为自己的工作流程构建的一个工具。<p>我喜欢同时处理多个任务，但大多数开发工具将工作流程分散在不同的地方：工单存在于问题跟踪系统中，执行在终端中进行，而上下文在它们之间往往会丢失。我希望我的工作项目及其上下文能够紧挨着实际工作的地方。<p>Mozzie是一个本地桌面工作区，每个工作项目可以启动自己的终端或编码代理。这个想法是将任务作为主要界面——每个任务都持有其上下文，并可以独立运行命令或代理。<p>这样可以更轻松地并行处理多个任务，而无需不断在工具之间切换。<p>虽然还处于早期阶段，但我每天都在使用它，它符合我喜欢的工作方式。<p>我很好奇是否还有其他人喜欢这样工作或尝试过类似的工具。