英国活动团体“讨厌埃隆”（Everyone Hates Elon，简称EHE）在Meta伦敦总部附近张贴了一则恶搞广告，以抗议该公司推出的新款智能眼镜。该海报采用了受科幻电影《极度空间》（They Live）启发的柱状透镜设计，画面会在凯莉·詹娜（Kylie Jenner）的宣传图与写有“我们时刻都在监视”的骷髅图案之间切换。
此次抗议活动突显了公众对Meta日益强大的监控技术愈发担忧。最新一代智能眼镜支持长达三分钟的连续隐蔽录制，批评者担心该功能会被滥用以进行骚扰——特别是一些“男性圈子”（Manosphere）的网红，他们利用这些摄像头在公共场合偷拍女性。
EHE认为，该技术对个人隐私构成了严重威胁，并指出目前人脸识别软件已能实时识别陌生人。通过质疑企业为何优先开发此类侵入性产品，该团体强调了技术飞速发展与道德监管之间日益扩大的鸿沟。EHE的观点十分直接：“亿万富翁本可以资助癌症治疗——那么他们为什么反而在资助为变态设计的眼镜呢？”
每日HackerNews RSS
伦敦公交车上的游击广告讽刺了凯莉·詹娜的 Meta 眼镜广告活动 Guerrilla London Bus Ads Mock Kylie Jenner's Meta Glasses Campaign
2 天前
抱歉。
Tokio/Rayon 陷阱：为什么 Async/Await 在处理并发时会失败 The Tokio/Rayon Trap and Why Async/Await Fails Concurrency
2 天前
尽管 `async/await` 因其类似同步代码的熟悉语法而广受欢迎，但作者认为它是一个“生产环境陷阱”，混淆了异步与并发的概念。通过在简单的接口背后隐藏复杂的状态机，`async/await` 强迫开发者成为手动调度员，不得不竭力分割 I/O 和计算密集型任务，以防止执行器停滞。 此外，这些运行时的默认配置往往会导致灾难性故障：无限制的任务会触发内存溢出（OOM）崩溃，而工作窃取调度器为了所谓的“公平性”牺牲了 CPU 缓存局部性，这通常会降低大规模下的吞吐量。当开发者被迫绕过运行时的“魔法”来确保稳定性时，这种抽象实际上已经失败了。 为了解决这个问题，作者推出了 **Project Tina**，这是一个“单核单线程”（thread-per-core）、无共享（shared-nothing）的并发框架。Tina 用结构化约束取代了隐藏的 `async/await` 复杂性：没有工作窃取，资源严格受限，且执行过程可预测、确定。通过显式暴露而非隐藏状态机，Tina 将架构确定性和系统可靠性置于语法“简易性”之上。作者总结道，对于大规模系统而言，可预测性远比 `async/await` 带来的简洁性更有价值。
Bluesky 已经收购了“ATPROTOCOL”商标，以保护生态系统免受此前威胁要对社区采取法律行动的恶意行为者的侵害。通过获得这些权利，Bluesky 确保了开发者可以继续在协议上进行构建，而无需担心外部干扰。 此举主要是一项防御性措施。Bluesky 旨在保持该协议的免费可用性，仅在商业品牌推广、听起来像官方的产品或商品方面要求许可。日常使用——例如命名开源工具、编写文档或描述兼容性——仍然是免费的，且不需要获得许可，前提是用户表述准确且不暗示官方背书。 Bluesky 强调，根据美国法律，商标保护是必要的，以防止他人劫持品牌。虽然 Bluesky PBC 目前出于实际原因持有该商标，但他们计划最终将所有权转让给一个独立的治理组织。归根结底，其目标是通过防止商标滥用来营造一个去中心化的开源环境，同时确保社区保有创新的自由。
抱歉。
**CatchCat** 是一款沉浸式的现实世界猫咪收集游戏，将你周遭的环境化作一场互动式的猫咪冒险。通过实时摄像头检测，玩家可以扫描并识别猫咪品种，将它们捕捉为独特的贴纸式纪念品。每只收集到的猫咪都拥有独特的特征、“零食”和“魅力”数值，以及五个稀有度等级之一——从常见的街头流浪猫到难以寻觅的黄金珍品。 该游戏强调安全性和真实性，利用设备端验证来防止作弊。玩家需管理“零食罐”补给来进行扫描，并可在全球社区地图上追踪猫咪的踪迹。除了收集之外，游戏还具有极强的社交属性；你可以结交好友、比对图鉴并分享你的精彩发现。 凭借完善的成长系统，玩家可以通过获得经验值来提升收集等级。展望未来，即将推出的“巷战（Alley Clash）”功能将把这些纪念品转化为战斗卡牌，让玩家能够利用猫咪的独特能力进行竞技对战。无论你是想寻找稀有品种，还是要在排行榜上更进一步，CatchCat 都能为你每天的散步增添一份充满成就感的策略乐趣。
抱歉。
G# 是一门兼具 Go、Kotlin 和 Swift 易用性的现代 .NET 语言。它将 Go、Kotlin 和 Swift 风格的特性（如包管理、func、数据类、if let 空值处理，以及基于作用域的结构化并发）引入了 .NET 运行时。源代码可直接编译为托管程序集。
编程往往会揭示出看似简单的系统（例如作业队列）背后隐藏着巨大的复杂性。在设计或使用这些系统时，必须运用**队列大小、显式限制和故障模型**等视角，以避免常见的陷阱。 作者通过描述一个仓库重打包系统来说明这一点，其中作业分为工作日的短任务（2 小时）和周末的长任务（7 小时）。一种天真的调度方法——设置紧凑的间隔以确保及时性——如果系统没有考虑到如何处理“重叠”（即新作业在前一个作业完成前触发）的情况，可能会导致灾难性的失败。 三种主要的重叠策略是： 1. **优先处理新作业 (Prefer New)**：取消旧作业。 2. **等待 (Wait)**：将新作业加入队列。 3. **优先处理旧作业 (Prefer Old)**：如果已有作业在运行，则取消传入的作业。 虽然“优先处理旧作业”看起来有些违反直觉，但作者证明，对于可预测的调度而言，它通常是最稳健的选择，而“等待”或“优先处理新作业”可能会导致资源耗尽或队列膨胀。在设计时考虑到这些约束，并记录系统的故障模型，可以实现更优雅的降级和更好的可靠性。
这场 Hacker News 的讨论探讨了任务队列的复杂性，从 UNIX 管道在概念上的简洁性，一直谈到了分布式系统中运维的棘手问题。
**主要观点包括：**
* **管道与队列的对比：** 支持者认为，UNIX 管道是一种被低估的本地解决方案，能够很好地处理背压（backpressure）以及生产者/消费者同步。批评者则反驳称，虽然管道对于本地、临时性任务很优雅，但缺乏现代分布式应用所需的持久性和网络透明度。
* **队列的隐性成本：** 资深工程师指出，任务队列往往会引入“级联故障”和不可预测的长尾延迟。简单的实现方式可能会导致下游服务过载，尤其是在系统恢复时，积压的任务会集中重试。
* **架构经验：**
* **背压是必须的：** 没有背压，队列可能会掩盖系统的脆弱性，直到发生灾难性故障。
* **延迟与利用率：** 排队论中的一个重要教训是：延迟呈非线性增长；在高利用率（如 95%）下运行，性能会比低利用率时出现指数级恶化。
* **以简洁胜复杂：** 许多人认为，对于某些问题，同步处理或适当的水平扩展，远比引入复杂消息队列的管理开销更可取。
Show HN: E-- – 一种介于英语和 Python 之间的编程语言 Show HN: E-- – A language you dial between English and Python
2 天前
E-- 是一种旨在将大语言模型（LLM）的创造性灵活性与确定性代码的可靠性相结合的编程语言。它采用两阶段流水线：首先是一个可选的、由大模型驱动的“标准化器”，将自由格式的英语转换为标准格式；随后是一个严格的确定性解析器，将该标准代码转译为标准的 Python 代码。 主要特性包括： * **确定性执行：** 一旦代码进入“标准 E--”格式，大模型便不再参与运行。生成的 Python 代码纯粹、可复现且易于调试。 * **大模型集成：** 用户可以插入 `{{ ... }}` 插槽，由大模型生成特定的值或代码片段。这些内容在转译时仅解析一次并进行缓存，确保后续构建在离线状态下也能保持确定性。 * **安全与透明：** E-- 使用明确的分隔符（如函数调用使用的 `[[ ]]`）来消除歧义。由于编译器是标准的非概率性编译器，生成的 Python 代码简洁且不受特定项目许可证的限制。 E-- 非常适合希望通过自然语言编写代码，同时又不愿牺牲传统确定性软件稳定性、可审计性和速度的开发者。它是开源的，可嵌入，并可通过 PyPI 获取。
抱歉。
SQLite 允许在字符串值中包含 NUL 字符（`0x00`），但这可能会导致误导性的行为。标准的函数（如 `length()` 和 `quote()`）以及命令行界面（CLI）会在遇到第一个 NUL 字符时截断输出。这会造成一种差异：数据库确实完整存储了字符串，但查询结果和 CLI 显示可能会错误地暗示字符串已提前结束。 若要验证包含 NUL 字符的字符串的真实长度和内容，应将该值转换为 `BLOB`。若要识别受到嵌入 NUL 字符影响的行，请使用 `instr(b, char(0))` 函数。如果需要清理数据，可以使用带有 `substr()` 的 `UPDATE` 语句来移除 NUL 字符及其后的内容。 由于 NUL 字符可能导致混淆和工具不兼容，因此不建议在 SQLite 文本字符串中使用 NUL 字符。
Hacker News 上的一场讨论揭示了 SQLite 中的一个奇特行为：字符串中的 NUL 字符可能会导致数据被截断。由于 SQLite 以 C 语言风格处理字符串，NUL 字符之后的内容对于 `length()`、`quote()` 等核心函数以及命令行工具来说通常是不可见的。
评论者们对这一设计的利弊展开了讨论：
* **数据隐藏：** 虽然这并非一项安全功能，但该行为允许用户在列中“隐藏”元数据，尽管这些数据并不可靠。
* **编码问题：** 这增加了存储 UTF-16 或 UTF-32 等非 ASCII 兼容格式的复杂性，因此专家建议对二进制或非标准编码数据使用 `BLOB` 存储。
* **设计批评：** 一些用户对此表示不满，认为 SQLite 在插入数据时应当进行截断或报错，而不是让已存储的数据变得无法通过标准查询访问。另一些人则指出，这是 C 语言字符串处理的必然结果，开发者在存储任意二进制数据时，应默认使用 `BLOB` 类型以避免此类陷阱。
请提供您需要翻译的内容。
抱歉。
在 1996 年的文章《反 Mac 界面》（The Anti-Mac Interface）中，唐·根特纳（Don Gentner）与雅各布·尼尔森（Jakob Nielsen）通过质疑麦金塔（Macintosh）人机界面指南的基本原则，挑战了 WIMP（窗口、图标、菜单、指针）模式的统治地位。作者在承认 Mac 使计算变得易于新手上手的同时，也指出这些设计限制——如僵化的隐喻、直接操纵和完全的用户控制——束缚了创新，并阻碍了资深用户的效率。
为了超越这种“停滞”的范式，作者提出了一个专为网络化、专家驱动的未来而设计的“反 Mac”界面。该模型倾向于使用语言交互（描述与命令）而非单纯的指向操作，偏好深层的面向对象表示而非静态图标，并主张在用户与智能代理之间共享控制权。通过摒弃对持续、显式用户输入及“感知稳定性”的必要性，他们构想了一个计算机会主动充当合作伙伴的界面。
归根结底，作者并非主张敌视或抛弃图形界面，而是将其作为一种激发全新设计范式的理论练习。他们认为，随着计算能力和用户专业知识的增长，界面必须从“模仿办公室”演变为能够利用语言、自动化以及丰富分布式数据环境的系统。
抱歉。