2作者: RgrTheShrubbr21 天前
内部功能: - 由 Firebase 提供支持的实时消息传递 - 好友列表、群组和在线状态 - 带自动回复的离开消息(以及经典的 %n、%d、%t 变量) - 好友图标和可编辑的个人资料 - 群聊房间 - 真实的 AIM 音效 - 完整的 Windows 98 桌面 UI — 任务栏、桌面图标、开始菜单等。 如果您有任何建议或反馈,我将非常感激。还有很多工作要做,但这一直是一项充满爱意的劳动。 目前,每个登录用户都会自动添加到您的好友列表中。我认为这是让人们开始互相聊天的绝佳方式。 前几天,我和一个家伙聊起了 90 年代的滑板运动,以及《托尼·霍克职业滑板》游戏,他通过即时消息给我发了一张他收到的 CCS 杂志的照片。
6作者: octalide21 天前
各位 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 个月内死亡吗? 我已经在后台研究这个项目两年多了。这是一个长期项目,我计划在可预见的未来持续维护它,无论是否有用户基础。 如果你喜欢这门语言,我强烈鼓励你参与到它的开发中来,因为它将以某种形式永远存在下去。 我知道这有点“语无伦次”,但我想说的是,能够参与这个项目是一件非常快乐的事情,我非常欢迎任何和所有的意见和贡献,特别是如果你讨厌这门语言或者发现了需要修复的问题。 请告诉我你们的想法!
3作者: x1colegal21 天前
各位 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/) 欢迎提出问题、批评和建议。
1作者: Chukz21 天前
为一家人工智能证明基础设施初创公司寻找技术联合创始人。设想为人工智能生成内容提供类似 SSL/TLS 的安全保障。我们已拥有机构级的蓝图,并有 3 家设计伙伴正在洽谈中,英国实体正在组建。现阶段仅提供股权。正在寻找一位希望创造有意义事物的后端/加密工程师。有意者请私信。
6作者: jasonephraim21 天前
这种情况我经历过两次了,我想知道这是否是我能摆脱的困境,还是这就是创业公司的本质——或者别的什么。在我担任技术主管的初创公司里,似乎总会出现一种情况,导致投资枯竭。两次都是,事情看起来进展顺利,但两年后,由于我/产品无法控制的因素,就会出现一轮轮的裁员,结果都一样。我最终成了最后一个技术通才。我需要尽可能多地编写代码,管理(如果还有的话)我部门的工程师,基本上独自承担支持工作,负责大部分产品路线图,与客户就支持和实施进行沟通,与集成合作伙伴合作,以及随着新事物落到精简的团队头上,责任清单还在不断扩大。我能很快掌握新的领域(金融、保险、合规),并且能很好地切换上下文。我一直都是那个“搞定一切”的人——一个能承担责任并将其完成的人。但是,我没有得到奖励,反而只是保住了工作,同时承担了那些不幸同事的工作。 在这些收缩时期,工作量从未减少。客户、集成、支持量都一样(目前是这样)。我注意到的另一件事是,审查力度反而增加了,而不是减少了。我认为一个很大的因素是创始人或高管会更积极地参与进来,或者试图填补空缺。这会引起各种各样的问题。 在上一轮裁员后,公司给我提供了一个修改后的职位和职位描述,重点是管理现在基本上只剩下我一个人的部门,而一年前这个部门还有六个人。其中充满了“领导团队达成目标”之类的职责。我确实有点想接受,因为这正是我当初被聘用的那种角色,而且以后找工作也会有帮助。但无论如何,我无法接受,因为我基本上就是这个团队。这感觉像个陷阱(或者至少是愿望成真,但一次又一次地被证明是徒劳的,因为我无法控制的因素)。 我也可以直接离开,但就业市场和经济看起来非常糟糕。上次我花了八个月才找到一份工作。这主要是因为我的经验和背景。我曾涉足工程、产品、支持、销售、客户成功、集成和用户沟通。我看起来像一个什么都能做/做过的人,但这反而会让人觉得我什么都没真正拥有。事实上,随着事情的发展,我拥有了太多太多的东西。 有三件事我想仔细思考,并希望得到一些帮助: 1. 这仅仅是公司的问题和我的运气不好吗?我选择的初创公司所在的行业或提供的产品是否容易受到风险投资趋势和炒作的影响?这两家公司看起来都是很好的机会,我完全理解总有风险——但目前/过去的结果,就我所扮演的角色和裁员后的处境而言,令人惊讶地一致。 2. 我应该坚持立场吗?我有一个习惯,就是试图解决问题并想办法。在上一次收缩期间,我曾向公司总裁提出,希望坐下来审视我们团队的职责和正在使用/销售的项目,看看哪些是必不可少的,哪些可以被覆盖等等。但这一切都没有发生——我是否应该更坚定地要求,而不是默默地承担? 3. 抛开公司不谈,我是否应该拥抱这个角色并尝试发展它?我是否应该接受自己是一个了不起的通才,“万金油,但样样不精通”,并使其成为一个更明确的角色/职业?我知道需要这样的人,但没有公司能真正为他们制定职位描述。我看到人工智能正在帮助弥补我无法投入时间去发展的越来越多的空白。我也有足够的经验和知识知道人工智能是一个工具,需要密切指导并在专注/合适的领域应用。(举个例子——我花了过去两个小时阻止它在我们 Go 的黄金测试框架中失控,因为它想忽略我们的测试模式)。 我很想知道其他人是否在初创公司遇到过类似的问题。另外,是否有其他像我这样的“红法师”技术人员,因为被要求负责的领域太广泛而难以在就业市场上找到工作?
10作者: Darmani21 天前
大家好!我们是 Jimmy 和 Ray。Jimmy 是 Thiel Fellow,拥有麻省理工学院博士学位,在编程工具领域拥有 15 年经验;Ray 在 19 岁时成为一家市值 20 亿美元公司的销售副总裁,并创建了副业代码。 去年,我们着手解决一个问题:“如果人工智能能以 100 倍的速度编写代码,为什么你的交付速度没有提高 100 倍?” 我们的发现令我们震惊——即使是相当不擅长技术的人和独立创始人也告诉我们,他们花费了超过一半的开发时间来阅读 AI 编写的代码。而其余的大部分时间则花在清理这些代码,或者希望自己当初没有这么做。 巧合的是,我们之前的两个产品分别是帮助用户快速熟悉大型代码库的工具([https://x.com/0xjimmyk/status/1873357324229984677](https://x.com/0xjimmyk/status/1873357324229984677))以及面向 CEO、YC 创始人以及顶级公司工程师的深度代码质量概念培训(mirdin.com),因此我们非常有能力解决这些问题。 Command Center 是一个专注于质量的智能编码环境。只需几次按键,您就可以同时开始构建 3 个功能,并很快准备好 3 个差异(diff),每个差异包含跨越 50 个文件、修改 2000 行代码。 这通常是您会想“糟了,接下来怎么办?”的时候。 在 Command Center 中,您只需点击“重构”,然后看着那些杂乱的代码变成可读的、健壮的代码。接着点击“生成演练”,然后突然之间,要阅读一个 2000 行的代码差异,您不必上下滚动来理解它,只需按右箭头键 200 次。看到不喜欢的地方?点击第 37 行,输入“在后台执行此操作以及所有其他网络获取 Cmd+Enter”,然后您将有更多的智能体来将您的代码塑造成最终形态。点击或输入“提交”、“推送”、“创建 PR”——您刚刚交付了一个高质量、无冗余的功能。 我们致力于在管道的每个环节做到最好,但您也可以在当前工作流程最薄弱的环节尝试 Command Center 的部分功能。我们的用户有人在 Zed 或 Codex 应用中完成所有编码,然后在代码运行完成后跳转到 Command Center 进行演练。甚至还有一个技能可以从您选择的环境中打开 Command Center 的演练。或者,您可以让 Command Center 在您进行其他工作时保持运行,如果您的 AI 删除了任何内容,Command Center 的快照将是您的救星。 我们去年悄悄上线,并一直在进行改进。质量和可用性不断提高,现在 Command Center 已经准备好获得更多关注。 自我们悄悄上线以来,至少出现了十几个其他的智能编码环境……它们几乎都拥有相同的功能集,专注于那些已经很容易的部分(生成代码的初始版本),而对于困难的部分(之后的一切),最多也只是一个粗糙的解决方案。Command Center 的重点是让困难的部分变得容易。 以下是我们的用户评价: “[重构] 让您的 LLM 拥有品味。我从未见过 LLM 编写出如此好的代码。” — Doug Slater,首席工程师,Climavision “通过 Command Center 的演练,我可以在不到一半的时间内完成 400 行的代码差异。” — Prateek Kumar,平台工程师,Sumo Logic 这个产品并非适合所有人。如果您是那种宣扬“提示是源头,代码是编译器输出”的人,那么您可能不会喜欢 Command Center。 但如果您想在每天交付 20 个 PR 的同时,仍然坚持传统的工程纪律,那么这里就是您的理想环境。