最新

大家好， 我一直在想，国防领域的创始人是如何获得意向书（LOI）的？我陷入了一个循环。没有资金，我无法完成一个完整的演示版本；但没有客户验证，我也无法获得资金；而没有演示版本，我又无法获得严肃的客户验证。 想听听大家的想法？

内部功能： - 由 Firebase 提供支持的实时消息传递 - 好友列表、群组和在线状态 - 带自动回复的离开消息（以及经典的 %n、%d、%t 变量） - 好友图标和可编辑的个人资料 - 群聊房间 - 真实的 AIM 音效 - 完整的 Windows 98 桌面 UI — 任务栏、桌面图标、开始菜单等。 如果您有任何建议或反馈，我将非常感激。还有很多工作要做，但这一直是一项充满爱意的劳动。 目前，每个登录用户都会自动添加到您的好友列表中。我认为这是让人们开始互相聊天的绝佳方式。 前几天，我和一个家伙聊起了 90 年代的滑板运动，以及《托尼·霍克职业滑板》游戏，他通过即时消息给我发了一张他收到的 CCS 杂志的照片。

各位 HN 的朋友们： 我是 Mach (<a href="https://github.com/octalide/mach" rel="nofollow">https://github.com/octalide/mach</a> 或 <a href="https://machlang.org" rel="nofollow">https://machlang.org</a>) 的创建者。两天前，我们终于实现了完全的自托管。我想在这里发帖展示一下这个语言，因为这对我们来说是一个重要的里程碑。 ## 语言简介（给好奇的朋友们）： * 整个开发流程中没有任何外部依赖，包括 LLVM、libc 绑定或任何类似的东西（除了历史上的引导编译器，它需要任何 C 编译器，但已被完全淘汰）。 * Mach 是一个非常“固执己见”且极度“反魔法”的语言。所见即所得（WYSIWYG）是该语言的核心原则。没有任何隐藏行为、隐式类型转换或“自动功能”。简洁性和消除歧义是该语言所坚持的核心原则。 * 目前，在编写本文时，其性能仅落后于 C 大约 4 倍，这几乎完全是由于缺乏深度编译器优化，例如尚未完全实现的自动向量化。最终，Mach 的性能将至少与 C 持平。 ## 我为什么要构建它？ 我热爱 C、Zig、Go 和（有时）Rust 等底层系统语言，但我想要一种能够积极地抑制“聪明才智”，以换取长期可维护性和整体清晰度的语言。Mach 非常“固执己见”，并明确要求冗长，这是其他语言所不敢的。计算机不是魔法，你编写的代码也不应该假装它们是。 这个项目最初是我个人的学习机会，但随着时间的推移，它发展成了一门功能齐全的语言。我还有很多东西需要学习，并且我很高兴能够在这个项目不断成长的过程中继续学习。 ## 我（读者）为什么要关心？ 如果你喜欢 C，你可能会喜欢 Mach。Mach 在“氛围”上深受 C 的启发，但在语法上有所改进，避免了一些常见的陷阱，揭示了许多内部机制，并且拥有一个远比 C 更好的依赖管理系统。 如果你想尝试一门完全能够取代 C 的语言，特别是如果你想为它的发展做出贡献，那么请务必过来看看！ ## 我应该去哪里查看？ GitHub 仓库中有一个指向我们 Discord 的链接，如果你想与我或其他几位常驻用户交流，可以在那里进行。 我的个人账户中有所有现有的工具以及一些示例仓库，如果你有兴趣尝试一下。 ## 这个项目会在 X 个月内死亡吗？ 我已经在后台研究这个项目两年多了。这是一个长期项目，我计划在可预见的未来持续维护它，无论是否有用户基础。 如果你喜欢这门语言，我强烈鼓励你参与到它的开发中来，因为它将以某种形式永远存在下去。 我知道这有点“语无伦次”，但我想说的是，能够参与这个项目是一件非常快乐的事情，我非常欢迎任何和所有的意见和贡献，特别是如果你讨厌这门语言或者发现了需要修复的问题。 请告诉我你们的想法！

各位 HN 用户： 在过去的几天里，我一直在开发 USTPS（UDP Speedy Transmission Protocol Secure），这是一个基于 UDP 的实验性加密传输协议。 USTPS 的主要目标是实现低延迟视频流传输。服务器可以获取视频源并通过 USTPS 端点暴露它，而 Linux 和 Android（Termux）客户端则接收流并将其本地暴露给 VLC、mpv 和 FFmpeg 等应用程序。 尽管流媒体是主要焦点，但 USTPS 并不仅限于媒体传输。它还可以用于其他可靠的加密 UDP 应用，这也是我在此基础上构建 USSH 的原因。 与基于 TCP 的传输相比，USTPS 的主要设计区别包括： * USTPS 是可靠的，但无序的。 * 如果数据包 N 丢失，后续数据包仍可被立即接收和处理。 * 丢失的数据包通过选择性重传进行恢复。 * 排序由应用层根据需要处理。 这意味着传输层本身不会引入“队头阻塞”（Head-of-Line Blocking）。其权衡之处在于，需要排序的应用必须自行实现重排序。我认为这是一个合理的权衡，因为它避免了强制所有应用程序都承担传输层排序的成本。 为了兼容媒体播放器，默认的 USTPS 客户端会在 `127.0.0.1:1238` 创建一个本地 TCP 端点。 客户端维护一个小的重排序缓冲区（默认 350 毫秒），以便重传的数据包有时间到达，然后再转发给本地 TCP 流。这使得 VLC、mpv 和 FFmpeg 等现有软件无需修改即可工作。 USTPS 目前提供： * 使用 ACK 和选择性重传实现可靠传输 * X25519 密钥交换 * AEAD 加密（AES-GCM 和 ChaCha20-Poly1305） * 可选的无序实时输出模式 * 流位置元数据 * 多客户端支持 * 本地 TCP 兼容输出 * 无拥塞控制（目前是故意的） 在开发 USTPS 的同时，我还构建了 USSH，这是一个完全运行在 USTPS 之上的类 SSH 远程 shell。 USSH 使用相同的底层无序传输，但客户端会在将终端数据呈现给用户之前对其进行重构和排序。这可以防止终端损坏，同时仍允许传输层本身保持无序。 USSH 包括： * 交互式终端会话 * PTY 支持 * 密码认证 * 主机密钥验证（TOFU） * 通过 USTPS 实现端到端加密通信 我目前正通过 Termux 从我的 Android 手机使用 USSH 来管理我的 VPS。 该项目尚处于非常早期（不到一周），主要出于实验和教育目的。我非常希望听到从事传输协议、流媒体系统、SSH 实现、QUIC、SCTP 和网络软件的各位的反馈。 USTP-Secure： [https://github.com/x1colegal/USTP-Secure](https://github.com/x1colegal/USTP-Secure) USSH： [https://github.com/x1colegal/USSH](https://github.com/x1colegal/USSH) Internet-Drafts： USTPS Draft： [https://datatracker.ietf.org/doc/draft-x1co-ustps/](https://datatracker.ietf.org/doc/draft-x1co-ustps/) USSH Draft： [https://datatracker.ietf.org/doc/draft-x1co-ussh/](https://datatracker.ietf.org/doc/draft-x1co-ussh/) 欢迎提出问题、批评和建议。

老实说，就像德拉奇布局一样