## 儿童、屏幕与有缺陷的法案：KOSMA解读 华盛顿正在讨论如何应对科技对青少年心理健康的影响，重点关注一项名为《儿童远离社交媒体法案》（KOSMA）的法案。尽管该法案旨在“保护儿童并赋能家长”，但讽刺的是，它反而将控制权移交给大科技公司——正是这些公司一直受到议员们的批评。 尽管存在广泛担忧，各大平台已经禁止13岁以下用户使用，这主要是由于现有的隐私法律。然而，研究表明，大多数13岁以下用户的社交媒体使用并非秘密；大约90%是在父母知情甚至协助下进行的。KOSMA将*要求*平台监管家庭，如果发现未成年人使用“合理推断”，即使得到父母同意，也必须终止账户。 这意味着共享家庭账户——例如孩子与父母一起观看教育YouTube视频——可能会被锁定或需要进行侵入性的年龄验证（例如身份证扫描）。KOSMA不是尊重父母的指导，而是迫使平台根据算法推断来推翻家庭的决定。 批评者认为，KOSMA无法解决问题，反而会将权力集中在科技公司手中，阻碍正常的、受监督的在线体验。他们建议，更有效的方法是加强对*所有*用户的隐私保护，而不是授权科技公司来决定谁可以访问互联网。
每日HackerNews RSS
## 国会与科技巨头：隐私与控制的辩论
最近一篇在Hacker News上讨论的EFF文章引发了关于拟议立法可能将家长控制权交给科技公司的争论。核心问题在于，这些举措可能成为要求在线访问进行年龄验证的垫脚石，最终将在线活动与政府身份证件联系起来——引发了重大的隐私担忧。
许多评论员担心这并非关于保护儿童，而是关于政府获得对公民更大的控制权并侵蚀在线匿名性。一些人认为这只是游说在起作用，而另一些人则指出过去类似的监管尝试都失败了。
提出的解决方案范围从更严格的家长责任和为儿童提供的功能有限的“基本”手机，到行业自我监管和标准化的年龄验证机制。然而，对于每种方法的可行性和潜在缺点都存在怀疑，包括创造新的诈骗途径和进一步限制在线自由的风险。
一个反复出现的主题是围绕新技术的历史性道德恐慌模式，以及在没有造成意外后果的情况下制定有效立法的困难。最终，这场讨论凸显了保护儿童在线和维护隐私和匿名的基本权利之间的紧张关系。
适用于嵌入式设备的微内核操作系统。Xous是一个为中等规模嵌入式系统设计的微内核操作系统，具有清晰的进程分离。几乎所有内容都在用户空间实现，消息传递是基本的通信方式。您可以在Xous Book中了解更多信息。该项目由NGI0 PET基金资助，该基金由NLnet建立，并得到欧盟委员会下一代互联网计划的财政支持，受DG Communications Networks, Content and Technology的管辖，协议编号为825310。
## Xous 操作系统：概要
Xous 是一种用纯 Rust 编写的新型操作系统，旨在实现安全性和透明性，尤其适用于带有 MMU 的嵌入式系统。在 NLNet（部分欧盟资助）的支持下，并有 “bunnie” Huang 等人的参与，Xous 专注于微内核架构，并尽可能利用 Rust 的安全特性。
主要特性包括使用内存重映射的独特 IPC 机制、通过虚拟内存管理关注硬件层面的安全性，以及适应较小内存占用（数百 KB）的设计。该项目还强调可验证的构建，并伴随定制硬件开发，例如 Baochip RISC-V 处理器。
讨论重点是平衡 Rust 的安全保证与内核级编程的现实（需要 `unsafe` 块进行硬件交互），以及与 seL4、Redox 和 QNX 等现有系统的比较。核心目标是提供可信赖的处理链，从硬件检查到软件工具链，为嵌入式应用程序提供安全环境。该项目正在积极开发中，并有最近的演讲详细介绍了其架构和目标。
四个月前，我辞掉了工作，与佩德里克共同创立Skald，最初的动力更多是追求独立，而非什么颠覆性的想法。我们获得了天使投资（包括前老板）和Broom Ventures的资金，优先考虑对创始人友好的条款，而非快速扩张。我最初的计划是不断尝试想法，直到找到一个有潜力的，但佩德里克的财务状况要求我们尽快融资。 融资后，我意外地承受了巨大的压力。尽管外部看起来很成功，但我感觉自己无法达到期望——这些期望既真实又源于过去对我的“创业潜力”的赞扬。这导致了无效的自我怀疑，以及将注意力放在增长指标上，而不是健全的战略。 我意识到我优先考虑向投资者展示成功，而不是建立可持续的业务，并且根据感知到的潜力而非真正解决问题来进行调整。最终，我认识到信任我们的流程、专注于创造价值以及记住投资者相信的是*我们*，而不是某个具体的想法的重要性。我现在重新集中精力，充满动力，并分享这段经历，希望它能引起其他创始人的共鸣。
## DevOps 的演变与人工智能的影响
DevOps 的核心目标——将开发者直接连接到生产反馈——由于技术不足在很大程度上未能实现。现有的工具往往*增加*了工作量，而不是简化代码部署与实际影响之间的循环。虽然在理论上拥有无限资源的情况下可行，但实际的可观察性对于大多数团队来说仍然是一个挑战。
然而，人工智能改变了游戏规则。首次，现成的技术能够为普通的工程组织提供快速有效的反馈循环。但这同时也带来了一个新的挑战：现有系统无法应对人工智能辅助开发将产生的“代码冗余”。
关键在于从被动式运维循环（响应故障）转向主动式、价值创造循环：部署、观察、学习。人工智能现在允许将遥测数据*带给*开发者，并将其置于他们现有的环境中，从而消除了他们成为可观察性专家的需求。
这意味着开发者将花费更少的时间编写代码，而将更多的时间用于验证、实验和理解生产行为。瓶颈从代码*编写*转移到代码*理解*，将工程师转变为更像科学实验者。虽然 DevOps 本身并未消亡，但其最初的目标终于在人工智能的帮助下得以实现，这要求采用新的仪器化和分析方法。
## DevOps 现状：批判性审视
最近在 Hacker News 上出现讨论，质疑 DevOps 在二十年后是否真正兑现了其承诺。核心论点在于开发和运维仍然是截然不同的技能，很少有人同时具备。许多评论员同意，当组织试图强行统一角色，而不是在专业团队之间培养协作和相互尊重时，DevOps 往往会失败。
几个要点浮出水面：DevOps 经常变成将运维责任转嫁给开发人员的一种方式，或者用更廉价的替代方案取代专门的运维团队。这通常会导致开发人员缺乏运维理解，并且依赖于复杂的工具（如 Kubernetes），而没有进行适当的配置或定制。
对话还强调了一个文化问题：成功的 DevOps 需要一种思维方式的转变，优先考虑团队合作和共同责任，而不仅仅是采用工具或重组团队。一些人认为，人工智能工具的兴起可能减轻一些负担，但要警惕过度依赖未经证实的结果。最终，讨论表明 DevOps 本身并没有缺陷，但常常由于组织问题、领导力失败以及缺乏对真正整合团队的投资而失败。
## Kip：一种受语言学启发的编程语言 Kip 是一种实验性编程语言，它独特地将土耳其语语法整合到其类型系统中。它利用土耳其语名词格——例如主格、宾格和与格——来定义函数参数之间的关系，从而实现灵活的参数顺序。该项目探索了语言学和类型论的交叉点，用作研究和教育工具，而非生产就绪的语言。 Kip 支持代数数据类型、用于泛型的类型变量、使用土耳其语条件后缀进行模式匹配以及命名常量。它包含用于整数和字符串的内置类型，以及基本的算术、比较和 I/O 操作。 该语言利用 TRmorph 工具包进行土耳其语形态分析，通过在编译过程中携带多个解析来处理歧义。Kip 使用 Haskell 实现，并提供 REPL、文件执行和基于浏览器的游乐场。它缓存类型检查的文件以加快执行速度，并在编译器更新时使缓存失效。 尽管仍在开发中，Kip 展示了一种新颖的编程语言设计方法，展示了自然语言结构如何影响代码结构和可读性。
## Kip：一种受土耳其语启发的编程语言
一种名为Kip的新编程语言发布，它基于土耳其语的格系统，并提供基于浏览器的游乐场 ([https://alpaylan.github.io/kip/](https://alpaylan.github.io/kip/))。Kip由Joomy开发，Alpaylan提供WASM绑定，旨在利用土耳其语的粘着性特征，带来独特的编码体验。
该语言使用土耳其语的格作为命名参数，允许以任何顺序提供参数，系统通过形态分析推断其含义。这通过TRmorph实现分析和类型检查，以解决歧义。它从Lingua::Romana::Perligata和Tampio等项目汲取灵感。
讨论强调了通过混淆实现安全性的潜力、翻译土耳其语语法概念（如“语气”）的挑战，以及与记录类型的比较。该项目仍在开发中，最近开始JavaScript转译，开发者欢迎错误报告和反馈。创建者指出，该项目灵感来源于使用一种LLM难以处理的语言的想法。
抱歉，此网站需要 JavaScript。
## 阿姆斯特丹地铁挖掘揭示数百年历史
一篇 Hacker News 讨论强调了阿姆斯特丹北/南地铁线建设中令人着迷的考古发现，相关记录在 [belowthesurface.amsterdam](https://belowthesurface.amsterdam) 上。该项目在阿姆斯特丹中央车站附近独特的“沉箱”水下进行，揭示了各种各样的文物——从罗马时代的餐具到 1990 年代的诺基亚手机——本质上是几个世纪运河生活中被丢弃物品的历史记录。
评论员称赞了网站的展示方式，特别是罗金站的展示，并指出它提供了对历史悠久日常生活的洞察。讨论涉及保护过去与为未来建设之间的价值，一些人认为应该优先保护历史，而另一些人则强调进步的必然性以及拯救*一切*的实际可行性有限。 几位参与者分享了与挖掘出的技术相关的个人记忆，例如爱立信和诺基亚手机。最终，该项目被视为阿姆斯特丹市一项具有文化意义的努力。
启用 JavaScript 和 Cookie 以继续。
## 人工智能时代编程的乐趣
最近的Hacker News讨论集中在AI工具（如Claude）是否降低或提升了编程的乐趣。许多评论者认同原发帖者的观点，即*编写*代码本身可以带来深刻的满足感，即使AI可以自动化这项任务。
核心争论围绕着基础知识：理解代码*如何*运作对于调试、保证质量和解决复杂问题仍然至关重要。简单地接受AI生成的代码而不理解被视为不良的工程实践。有些人将其比作工匠与工业——手工制作、优雅的解决方案与快速生产的“足够好”的替代品。
然而，其他人认为AI工具具有赋能作用，使他们能够专注于更高层次的问题解决和创造性任务。这场讨论凸显了程序员角色可能发生的变化，转向提示工程、系统设计以及对AI辅助代码进行严格测试。最终，许多人同意编程的乐趣仍然可以找到，无论是在精心设计解决方案还是利用AI将想法变为现实。价值正在转向创新和想法的传播，而不仅仅是生产。
## OpenAI 将在 ChatGPT 中引入广告
OpenAI 计划在 ChatGPT 中测试广告，首先面向免费用户，然后扩展到每月支付 8 美元的 ChatGPT Go 用户。此举源于运行 AI 的巨大成本，引发了用户之间的争论。
许多评论员表达了对“劣质化铁律”的担忧——服务为了追求利润而降低用户体验的趋势。人们怀疑广告是否会明确标记，并担心它们会变得与自然内容难以区分，模仿 X 等平台上的策略。
讨论还集中在 OpenAI 潜在的数据收集做法，以增强广告定位。一些人认为广告是免费访问的合理交换，而另一些人则哀叹之前无广告体验的不可避免的衰落。一些用户指出 ChatGPT 的性能似乎有所下降，这表明了一种先发制人的策略，随后逐渐退化，以激励升级——或接受广告。
最终，这场对话凸显了一种常见的矛盾：在快速发展的 AI 领域，如何在可访问性和可持续性与用户体验之间取得平衡。
## minikv：基于Rust的分布式键值和对象存储
minikv是一个健壮的、多租户的键值和对象存储，使用Rust构建，专为学习和生产使用而设计。它通过Raft共识和2PC提供强一致性，并通过预写式日志（WAL）确保数据持久性。
最近的更新（v0.7.0）引入了基于值的搜索的二级索引、多键事务、流式导入/导出以及持久化的S3支持的对象存储。之前的版本添加了企业级安全功能，如加密、配额和审计日志。
主要特性包括用于可扩展性的虚拟分片、可插拔的存储选项（内存、RocksDB、Sled）以及通过Prometheus指标和内置管理仪表板提供的全面可观察性。它提供HTTP REST和S3兼容的API，以及用于内部通信的gRPC。
minikv非常适合探索分布式系统的工程师、试验Rust基础设施的团队以及对构建可靠、可扩展系统中的权衡感兴趣的任何人。它在GitHub上可用，并高度重视测试、文档和持续集成。
## Minikv：一个基于Rust的分布式存储引擎
Whispem发布了Minikv，一个开源的分布式键值和对象存储，使用Rust构建，旨在用于学习、实验和自托管。它结合了一个强一致性的键值数据库（使用Raft共识）与S3兼容的对象存储以及基本的多租户功能。
主要亮点包括自动故障转移、可插拔的存储后端（内存、RocksDB、Sled）、指标（Prometheus）、TLS以及通过单个二进制文件轻松部署，该文件与Docker/Kubernetes兼容。该项目最初始于对分布式系统的学习实践，并发展成为一个潜在的生产就绪工具。
该发布引发了关于AI工具在开发中应用程度的讨论，作者始终坚持所有代码都是手动编写的，但承认AI在文档方面提供了一些帮助。该项目在GitHub上可用 ([https://github.com/whispem/minikv](https://github.com/whispem/minikv))，并且作为一个crate可用 ([https://crates.io/crates/minikv](https://crates.io/crates/minikv))。
大型软件公司经常因过度会议、强势高管和繁重官僚主义等问题而受到批评。然而，这种批评往往缺乏对这些特征*存在原因*的理解。作者曾在从初创公司到谷歌等公司工作过，认为这些不一定是失败，而是规模和责任的*结果*。
在大型组织中，协调成为首要挑战，这使得会议对于跨团队合作至关重要——并非功能失调，而是必要的。高管充当重要的客户代表，弥合开发者和用户之间的差距，鉴于层层隔阂，他们的意见是必要的。最后，严格的流程并非束缚，而是当软件支撑数百万用户依赖的关键系统时，至关重要的风险管理工具。
核心信息是，在批评大型组织之前，了解其中固有的复杂性和风险至关重要。被视为负面的行为，往往是对规模、可靠性和广泛影响需求的合理应对。
## Hacker News 讨论摘要：对大型软件公司的常见误解
最近 Hacker News 的讨论围绕一篇挑战对大型软件公司常见批评的博文展开。核心论点是，许多被认为的问题——过多的会议、官僚主义、缓慢的决策——并非内在缺陷，而是对规模和风险管理的*应对*。
评论者争论作者是否充分考虑了组织内部的既得利益，认为效率低下常常源于个人保护职业生涯或掩盖无能。一个关键点是，软件行业领导者缺乏深刻技术理解的情况非常普遍，这与桥梁建设或法律等领域形成对比。
然而，其他人反驳说，将问题完全归因于组织结构忽视了基本的协调挑战。讨论还涉及理解流程*存在的原因*的重要性，即使这些流程看起来很繁琐，以及在软件影响数百万用户时，平衡速度与可靠性的难度。最终，对话强调了在批评大型组织之前，需要进行细致的理解，承认许多行为是内在复杂性的结果，而不是病态的表现。