具有更强的语义和可访问性优势。
期望未来 HTML 能引入类似
现有方案中，通过 CSS 的 :before/:after 注入内容会导致 DOM 内容与实际显示不一致，影响复制粘贴和可访问性，应避免此类做法。
Liquid Glass Is Cracked, and Usability Suffers in iOS 26
#
https://www.nngroup.com/articles/liquid-glass/
iOS 26 主推的“Liquid Glass”视觉语言把界面做成会流动、会折射、会呼吸的玻璃泡，第一眼惊艳，用三天就抓狂。具体毛病有六点：
- 透明 + 动画=看不见 信息浮层、搜索条、标签栏全部半透，叠在照片或动态壁纸上，文字压文字、图标压图片，对比度低到需要放大镜；按钮没事就抖、闪、冒泡，用户注意力被反复勾走。
- 触控面积缩水 苹果过去要求图标至少 1 cm×1 cm、间距 0.4 cm，现在为了塞下常驻搜索，底部导航挤成一团，Photos、App Store 的标签图标比上一代窄了约 20%，误触率飙升。
- 位置天天变 搜索原先在顶部下拉呼出，现在固定到底部浮丸；Safari 的前进键时有时无；Health 的标签栏一点搜索就整条缩成一个小图标。界面元素忽大忽小，肌肉记忆全废。
- 老规矩被拆 返回键旁原本有“上一页”文字提示，现在只剩秃箭头，部分 App 还把当前页标题放在那里，让人分不清点回去会到哪；Safari 把多标签按钮藏进“⋯”菜单，每次换页多两步。
- 发现门槛变高 浮动按钮与页面内容颜色相近，常被当成背景忽略；Mail 的搜索条与邮件预览重叠，用户测试里 30% 的人找不到搜索；Maps 餐厅页的底部图标直接融进食物照片。
- 整体方向走偏 整套设计语言更像给宣传片做的，而不是给手指和眼睛做的。苹果被指借“炫玻璃”转移视线，掩盖 AI 功能跳票。结果用户每天要花额外时间“擦玻璃”、找按钮、重新学基础操作，效率下降，错误增加，审美疲劳比电池先用完。
https://news.ycombinator.com/item?id=45544044
- 新版 iOS 的“液态玻璃”设计风格让界面显得杂乱，透明效果影响可读性，屏幕空间利用效率降低，整体体验不如以往。
- 系统存在大量视觉和交互层面的 bug，如深色模式下输入框突然变亮、按钮对齐异常、应用启动时模式切换延迟等。
- “液态玻璃”设计被质疑为未完成的 alpha 版本，设计概念不成熟，存在明显缺陷，可能是为掩盖“Apple Intelligence”失败而仓促推出的补救措施。
- Apple Intelligence 功能未能达到预期，缺乏实用价值，与 ChatGPT 类应用相比差距明显，未能有效整合用户上下文信息。
- 尽管苹果拥有用户上下文优势，但若不尽快改进 AI 功能，可能在与 OpenAI 等对手的竞争中失去先机。
- OpenAI 虽可尝试通过第三方应用接入设备功能，但受制于苹果和谷歌的权限控制，难以深度集成核心服务。
- 苹果地图长期表现不佳，导航逻辑不合理，常推荐不现实的掉头路线，语音提示也不如谷歌地图清晰，每次更新都令人失望。
- 有人认为苹果地图初期失败是管理层内部斗争的结果，但该说法缺乏依据，更合理的解释是数据不足导致的客观问题。
- 老款设备用户可能无法获得新系统更新，成为此次更新的牺牲者，无法享受新功能或修复。
https://fulghum.io/album-cards
作者 Jordan Fulghum 在 2025 年 10 月分享了一项为 10 岁儿子重新构建音乐发现乐趣的创意项目——“专辑卡片”（Album Cards）。他回忆自己童年时通过翻看 CD 封面、阅读歌词和 liner notes 来建立音乐品味，而如今的孩子却习惯于被智能音箱和流媒体自动播放的背景音乐包围，缺乏主动探索和拥有感。
为弥补这一缺失，他设计了一套结合实体卡片与现代技术的解决方案：使用 Trading Card 尺寸的卡片，印上高分辨率的专辑封面，并嵌入 NFC 芯片。这些卡片可通过手机轻触直接在家中音响系统中播放对应专辑，无需打开屏幕或应用。
项目核心挑战在于专辑艺术通常是正方形，而 Trading Card 是 2.5:3.5 的矩形比例。为解决这一问题，作者使用 AI 扩散模型将原画作扩展至合适比例，保留风格与构图，虽有瑕疵但效果令人惊喜。部分专辑如《Nevermind》则用色块补全。
音乐来源为作者自建的 Plex 服务器中的 MP3 文件，通过 PlexAmp 应用将 NFC 标签编程为直接播放特定专辑的链接，操作简单高效。卡片使用标签纸打印后粘贴在空白扑克牌上，并将 NFC 芯片夹在中间。3D 打印的展示架用于收纳和展示。
当儿子第一次拿到卡片，像玩宝可梦卡牌一样翻阅，最终选择 Daft Punk 的《Discovery》，轻触后《One More Time》在全屋响起，瞬间点燃了他对音乐的兴趣。
这个项目不仅让音乐从“无形背景”变为可触摸、可选择、可收藏的实体体验，更激发了孩子主动聆听和建立个人品味的意愿。作者认为，这无意中帮助孩子从被动消费转向主动发现，重新找回了音乐带来的深层喜悦。
https://news.ycombinator.com/item?id=45543475
- 作者通过制作带有 NFC 标签的实体专辑卡片来引导孩子探索音乐，体现了对物理媒介和音乐深度体验的重视。
- 有人回忆童年在家中翻阅书籍、唱片、磁带等媒介的经历，认为这种探索式学习是宝贵的，而如今孩子可能只会被动接收流媒体音乐。
- 有人担忧孩子未来只能通过数字平台接触音乐，缺乏实体媒介带来的仪式感和深度体验。
- 有人认为，尽管数字音乐便捷，但实体唱片和书籍仍具有情感价值，即使不常使用也值得收藏。
- 有人质疑 NFC 卡片项目的意义，认为如果拥有唱片机，让孩子直接接触实体唱片会更有价值。
- 有人反驳称，现代音乐平台如 Spotify 让音乐发现更加主动和高效，用户可以通过相关艺术家和电台功能深入探索音乐。
- 有人认为，过去音乐专辑承载意义，人们会反复聆听并分享，而如今音乐选择过多导致音乐变得轻浮、缺乏重量。
- 有人指出，现代音乐平台存在大量匿名制作的“脸无艺术家”和 AI 生成音乐，导致音乐失去个性和真实性。
- 有人认为，音乐“自动播放”并非新现象，广播电台早已如此，现代音乐平台只是延续了这一模式。
- 有人强调，真实音乐爱好者依然会主动选择和深入聆听音乐，平台只是工具，不能代表整体。
- 有人指出，音乐品味的差异与年龄增长有关，个人经历丰富后对音乐的感受会变化，不能简单归因于媒介变迁。
- 有人认为，当代青少年同样能深入欣赏音乐，甚至通过数据库发现冷门好歌，与过去在唱片店探索并无本质不同。
- 有人分享与 12 岁侄女共同欣赏经典音乐的经历，说明跨代音乐共鸣依然存在，且数字平台有助于发现被忽视的佳作。
- 有人用德国高中生在街头大声合唱《99 个气球》的场景，说明年轻人依然能被经典音乐打动，音乐的感染力并未消失。
Daniel Kahneman opted for assisted suicide in Switzerland
#
https://www.bluewin.ch/en/entertainment/nobel-prize-winner-opts-for-suicide-in-switzerland-2619460.html
瑞士著名心理学家、2002 年诺贝尔经济学奖得主丹尼尔·卡尼曼于 2024 年 3 月 27 日在瑞士选择安乐死，享年 90 岁。他生前长期居住在巴黎，晚年仍保持清晰思维，享受生活，参观博物馆、观看芭蕾舞剧，并与家人共度时光。
卡尼曼在去世前向亲密朋友发送了一封告别邮件，公开表达了自己选择安乐死的决定。他坦言，这一决定并非出于疾病痛苦，而是为了避免未来可能出现的身心衰退，尤其是目睹母亲、妻子及挚友因衰老而经历的痛苦。他强调，自己希望在尚有自主意识时主动结束生命，以维护尊严与独立。
尽管他并未患有严重疾病，但已察觉到记忆力下降和肾功能减弱。他明确表示，若等到生命“显然不值得继续”时才做决定，已为时过晚。他的选择虽被部分人视为“过早”，但他认为这正是其意义所在。
卡尼曼的伴侣芭芭拉·特沃斯基于 2018 年因血管性痴呆去世，这一经历对他影响深远。他希望在生命最后阶段仍保持好奇与求知欲，甚至在临终前仍表示“我想学点新东西”。
他不希望自己的离世引发公众讨论，也未将此作为社会议题发声。他仅在信中感谢亲友一路陪伴，并写道：“谢谢你们让我度过了一段美好的人生。”
该文章发布于 2025 年 3 月 24 日，由瑞士媒体 blue News 报道，配图来自瑞士通讯社（sda）。文中附有瑞士心理危机援助热线及亲友哀伤支持机构信息，呼吁关注心理健康与生命尊严。
https://news.ycombinator.com/item?id=45547492
- 阿尔茨海默病会彻底改变一个人，导致其失去自我，使原本友善的人变得令人反感，这种变化令人恐惧。
- 人们不应因担心被他人负面评价而选择安乐死，因为这种担忧反映了对他人看法的过度在意，而非对自身价值的真正尊重。
- 阿尔茨海默病患者的行为并非其本意，社会应更关注如何妥善照顾这类病人，而非简单地评价其行为。
- 一旦患上阿尔茨海默病，个体的人格和记忆会逐渐消失，留下的是一个与原本人格完全不同的“躯壳”，这种丧失是不可逆的。
- 有人希望在失去自我前选择安乐死，以保持对自身尊严的掌控，而不是让疾病决定自己最后的形象。
- 社会对阿尔茨海默病患者的处理方式往往缺乏同情与支持，导致患者和家属承受巨大痛苦，这反映出医疗与社会系统的缺陷。
- 人们在健康时往往关心自己如何被他人记住，但当疾病剥夺了自我意识后，这种“被记住”的愿望已无意义。
- 真正的“好”不等于被所有人喜欢，历史上许多有道德勇气的人反而被误解或憎恨，因此不应以他人评价作为行为标准。
- 人类对他人看法的在意，本质上是一种“人性尊重”的虚荣，而非对道德或真实价值的追求。
- 一些人选择安乐死，是因为他们无法忍受自己在疾病中变成“别人眼中的麻烦”，这种心理源于对失去社会认同的恐惧。
GNU Health
#
https://www.gnuhealth.org/about-us.html
GNU Health 是一个由 GNU Solidario 主导的自由/开源社区驱动项目，致力于通过技术手段改善全球健康状况，涵盖从社会医学到精准医疗的广泛领域。该项目是 GNU 官方项目之一，曾荣获自由软件基金会的社会效益奖，已被多个国家的医院、政府及国际组织采纳。
GNU Health 生态系统包含多个核心组件：
- 医院管理（HMIS）：提供电子病历、医院管理与卫生信息系统功能，支持从私人诊所到国家级公共卫生系统的灵活部署。系统模块化设计，涵盖初级保健、妇产科、儿科、外科、实验室管理、遗传学、影像诊断等多个领域，同时整合财务、药品、库存等内部管理功能。
- GNU LIMS（Occhiolino）：专为医疗与生物医学领域设计的实验室信息管理系统，支持检验申请、执行与结果评估，并可与患者档案及财务系统联动。
- MyGNUHealth：基于桌面与移动设备的个人健康记录（PHR）应用，采用 Kivy Python 技术开发，强调隐私保护，使患者能够自主管理自身健康信息，提升医患沟通效率。
- GNU Health 联邦网络：支持构建跨区域、跨国界的去中心化健康网络，实现大规模异构节点间的协作，为公共卫生决策、研究与政策制定提供精准数据支持。
- 嵌入式 GNU Health：将 GNU Health 部署于单板计算机（SBC），用于实时监测生命体征、连接实验室设备或作为个人健康追踪工具，适用于医院、科研机构及基层医疗。
GNU Health 不仅是技术系统，更是一种社会运动，倡导“以人为本”的社会医学理念。项目关注贫困、营养不良、污染水源、战争、艾滋病、结核病等可预防的社会疾病，强调健康受社会经济条件决定，主张通过改善生活环境实现全民健康。其核心理念是“人先于病人”，致力于推动全球医疗公平。
https://news.ycombinator.com/item?id=45550049
- 有用户分享了一位牙医使用完全开源软件和自研电子病历系统创办牙科诊所的经历，相关项目仍在持续维护。
- 该牙医是 Clear.dental 的创始人 Tej Shah，其项目代码托管在 GitLab 和 KDE 的 Invent 平台。
- 有人在 Reddit 上发起 AMA 活动，但关于开源的问题未被广泛讨论，引发对社区关注点的反思。
- 由于英国的网络审查政策，用户无法访问某些 Reddit 内容，需通过替代前端或存档服务查看。
- 使用如 rl.bloat.cat 等替代 Reddit 前端可绕过部分限制，但存在速率限制和稳定性问题。
- 英国对网络自由的限制可能演变为更广泛的互联网专制，令人担忧未来可能封锁 Tor 等去中心化网络。
- 一些去中心化服务如 Redlib 采用 Monero 支付和高安全性运维，以应对审查，但其运营仍面临法律风险。
- 有观点指出，Reddit 的隐私设置允许用户隐藏帖子和评论历史，这既保护隐私也削弱了对不当行为的监督。
- 隐私保护与防止网络骚扰之间存在权衡，部分人认为公开历史有助于识别谎言和滥用行为。
https://blog.tangled.org/intro
Tangled 是一个基于 AT 协议的去中心化代码协作平台，旨在让开发者重新享受社交化、趣味化的编程体验。它强调用户对代码数据的完全所有权，支持开源社区自主治理。
平台采用“结点”（knots）机制，这些是轻量级、无头的服务器，可单租户或多租户运行，适合个人在树莓派上自托管，也支持社区级部署。Tangled 默认提供免费托管的管理型结点，用户可轻松创建和管理 Git 仓库。
App 界面（tangled.sh）作为全网统一视图，无缝整合来自不同结点的仓库，支持浏览、克隆和贡献代码，实现跨结点协作的流畅体验。
Tangled 的设计遵循三大原则：数据所有权、低使用门槛、不牺牲用户体验。其架构支持常见的 Git 工作流，保持去中心化的同时确保操作自然顺畅。
目前 Tangled 已从邀请制开放为公众访问，用户可直接通过 tangled.sh/login 登录使用。项目仍在早期开发阶段，团队正通过自用方式持续完善核心功能。欢迎加入 #tangled 频道（libera.chat）获取帮助与参与共建。
https://news.ycombinator.com/item?id=45543899
- 代码托管平台应拆分为独立服务，如代码仓库、协作工具、CI/CD、任务管理等，以打破现有垄断。
- 尽管 Git 本身是去中心化的，但实际使用中仍倾向于集中化，因为多数开发者更习惯于访问“唯一权威代码库”。
- 多个独立服务虽然灵活，但会带来信任问题和集成复杂性，而单体平台在用户体验和运维效率上更具优势。
- 企业用户更倾向于使用一体化平台，以避免管理多个供应商、调试集成问题和分散的开发体验。
- 去中心化服务的基础设施虽然可以轻量化运行（如在树莓派上），但对普通开发者仍存在较高的入门门槛。
- 虽然 PDS（个人数据服务器）和中继节点等组件技术上简单，但整体系统仍需一定运维能力，且资源成本需由服务提供方承担。
- 服务的可持续性依赖于资金支持，完全免费的去中心化平台难以长期维持，仍需商业模式支撑。
- 当前去中心化生态中，PDS 的托管服务正在多样化，基础设施成为热门发展领域。
- 一些去中心化工具如 pgit 和 pr.pico.sh 已能实现静态代码浏览和补丁审查，但功能仍有限。
- 代码托管平台的集中化本质源于商业逻辑，即通过锁定用户来实现盈利，而非技术必然。
- 去中心化平台的用户体验需“开箱即用”，否则难以吸引主流开发者。
- Tangled 项目近期因 OAuth 库更新导致新用户无法创建仓库，已修复并建议用户重新登录。
AMD and Sony’s PS6 chipset aims to rethink the current graphics pipeline
#
https://arstechnica.com/gaming/2025/10/amd-and-sony-tease-new-chip-architecture-ahead-of-playstation-6/
索尼与 AMD 正在合作开发下一代游戏主机芯片“Project Amethyst”，旨在重新构想当前图形处理流水线。该项目目前仍处于早期模拟阶段，但已展现出令人期待的潜力。
新架构聚焦于提升机器学习（ML）效率，采用“神经阵列”技术，使部分计算单元能够共享数据，形成类似“集中式 AI 引擎”的处理模式。这将显著提升着色器引擎的可扩展性，使更大范围的屏幕内容可由 AI 技术进行处理与增强，从而更高效地实现如 FSR 和 PSSR 等超分辨率技术。
在光线追踪方面，Project Amethyst 引入专用的“辐射核心”（radiance cores），专门负责光线遍历计算，即判断光线与场景中多边形的碰撞关系。这一设计将光线追踪的计算压力从 CPU 和 GPU 中分离，使其能更专注于纹理与材质的着色任务，提升整体效率。
此外，该芯片还重点解决 GPU 内存带宽瓶颈问题。通过采用更先进的压缩技术（如 Delta Color Compression），减少传输数据量，从而缓解高分辨率渲染下的带宽压力。
整体来看，Project Amethyst 不仅追求性能跃升，更强调能效与架构创新，为未来几年的主机游戏体验提供技术支撑。
https://news.ycombinator.com/item?id=45546593
- PS6 可能标志着游戏主机在计算和图形性能上表达性提升的终点，未来进步将依赖 AI 技术，但其成本和算力需求可能超出经济可行性。
- 游戏体验的核心在于玩法和叙事质量，而非单纯的图形进步，当前硬件已能满足多数玩家的需求。
- 实时生成模型有望彻底改变渲染方式，消除“诡异谷”效应，带来接近真实的视觉体验。
- 未来游戏可能完全由 AI 实时生成，通过预测下一帧内容实现，但当前技术在计算效率上仍存在瓶颈。
- 当前 AI 生成技术在处理世界模拟时计算开销巨大，远超传统三角形渲染的并行化效率。
- 未来游戏可能通过高效程序化生成资产，按需生成并缓存内容，减少重复渲染负担。
- 游戏行业面临同质化问题，大量重复内容导致玩家审美疲劳，新硬件难以带来根本性变革。
- 旧世代游戏在玩法和叙事上已足够优秀，许多 25 年前的游戏仍能提供极佳体验，无需依赖新硬件。
- 游戏创新的重心已从技术进步转向叙事和玩法，类似电影行业从技术特效转向故事表达。
- 尽管存在疲劳感，但当前游戏产业创新作品远超以往，问题在于发现新游戏的难度而非缺乏创新。
Superpowers: How I’m using coding agents in October 2025
#
https://blog.fsck.com/2025/10/09/superpowers/
本文介绍了作者在 2025 年 10 月如何利用 AI 编码代理（coding agents）提升开发效率，核心是其新构建的“Superpowers”系统。该系统基于 Anthropic 推出的 Claude Code 插件机制，通过“技能”（Skills）赋予 AI 代理超能力。
系统启动后，Claude 会自动加载一套引导流程，强调“拥有技能即拥有超能力”，并要求用户通过脚本搜索技能，使用时需遵循技能说明。整个开发流程遵循“头脑风暴 → 规划 → 实施”的模式，且默认在开始编码前与用户讨论计划。
在项目执行中，系统能自动创建 Git 工作树，支持并行任务互不干扰。用户可选择两种工作模式：一是传统的人工管理方式（双会话协作），二是更先进的“子代理分发模式”——任务被逐一分配给子代理执行，并在每一步进行代码审查，全程遵循 RED/GREEN TDD 原则。
实现完成后，系统可自动创建 GitHub Pull Request、合并工作树或直接停止。
文章的重点在于“技能”机制。技能是赋予 AI 代理能力的核心，作者通过让 Claude 阅读书籍、文档或代码库，自动生成可复用的技能文档（SKILL.md），实现自我进化。例如，作者曾让 Claude 阅读一本编程书，提取隐含的可复用技能。
为确保技能的有效性，作者设计了“技能测试”流程：用模拟真实场景的子代理压力测试来验证技能的可理解性、完整性和执行力。测试场景包括高时间压力下的故障排查、已有工作与技能建议冲突时的选择等，推动技能文档不断优化。
作者还发现，将罗伯特·西奥迪尼的“影响力”原则应用于 AI 代理，能有效提升其行为合规性。这一理念甚至被实证研究证实对 LLM 有效，令 AI 自身也受到震撼。
整体来看，该系统标志着 AI 开发代理正从“执行指令”迈向“自主学习与自我完善”的新阶段。
https://news.ycombinator.com/item?id=45547344
- Jesse 使用编码代理的方式比大多数人的实践更具雄心，其项目代码库值得深入研究。
- Research->Plan->Implement 流程与技能系统是互补的，但部分流程更适合用代码实现以提高可靠性。
- 当前的 AI 工具仍处于探索阶段，实际开发中仍需结合传统方法，AI 并未完全替代人工。
- 项目中使用 LLM 生成技能文档的方式效率不高，实际效果与直接提供上下文无异。
- 项目中将数据存储在用户主目录下不符合 XDG 规范，存在污染主目录的问题。
- 使用大写强调（如 IMPORTANT）对当前模型已无显著影响，应更注重清晰指令。
- 项目中引用的“说服性提示”论文与实际用途不符，存在误导。
- 模型常给出基于自身推理时间的错误任务耗时预估，需手动干预。
- 模型在调试时会表现出不合理的“游戏化”行为，需引导其进入真实场景。
- 项目中的技能文档格式混乱，缺乏统一标准，更像是 LLM 生成的粗糙说明。
- AI 代理的实际价值提升仍需具体案例支撑，目前缺乏客观对比证据。
- 有效的开发实践包括使用语音输入、合理管理 token、设定明确的完成标准。
- 为不同任务设置专用 AI 会话能显著提升输出质量，符合模型特性。
(Re)Introducing the Pebble Appstore
#
https://ericmigi.com/blog/re-introducing-the-pebble-appstore/
Pebble 重新推出 Appstore，旨在复兴其经典生态。新版本的 Appstore 网站 apps.rePebble.com 保留了 2016 年的视觉风格，同时进行了多项优化：支持社交分享预览、新增“相似应用推荐”功能，帮助用户发现隐藏佳作。未来计划加入应用试玩模拟器、API 问题预警、更完善的分类与推荐机制，以及对冷门新应用的更多曝光。
Pebble 与 Rebble 联合合作，由 Rebble 提供后端支持，所有新提交的应用可通过 dev-portal.rebble.io 提交并同步至 Pebble Appstore。用户无需订阅 Rebble 即可免费使用 Appstore，Core Devices 正直接资助 Rebble 这一非营利组织以维持服务。
硬件方面，Pebble 2 Duo 已完成首批 2,960 台白色款的生产，黑色款因假期延迟，预计年底恢复。Pebble Time 2 进入 DVT（设计验证测试）阶段，计划于 12 月 26 日左右启动量产，首批预购发货最早将在 2025 年 1 月进行。受春节工厂停工影响，2 月前难以完成全部交付。
软件层面，Pebble Time 2 新增自动适配高分辨率屏幕功能，旧应用可选择性扩展至 200x228 像素全屏显示，提升视觉体验。已有开发者如 Lignite 已推出原生支持新屏幕的精美表盘（如 Mosaic），社区创作活力持续。
开发工具方面，Pebble SDK 已升级至 Python 3，支持在浏览器中通过 Cloud IDE 快速构建应用，甚至可通过 AI 辅助生成项目（pebble new-project –ai）。支持在模拟器中测试新应用，兼容 Pebble Time 2 的高分辨率屏幕。未来计划引入 Pebble 包管理、Timeline 支持、新传感器 API（气压计、触摸屏），并推出基于 Moddable 的全新 JS SDK（替代 Rocky.js）。
Pebble 社区感谢 Rebble 近十年来的持续支持，其在 2017 年便存档并重建了 Appstore，是当前生态得以延续的关键力量。开发者可积极参与，共同打造新一代 Pebble 生态。
https://news.ycombinator.com/item?id=45544228
- 原 Pebble Appstore 的代码设计为客户端逻辑，便于社区自行存档和托管，确保即使官方服务关闭也能继续使用。
- Rebble 社区在 2017 年就已备份并托管 Pebble Appstore，使旧应用得以恢复并持续更新。
- 旧款 Pebble 手表仍具实用价值，得益于 Rebble 社区的持续维护与支持。
- 由于旧 Pebble 电池老化，充电时间短但续航表现不稳定，需长时间充电才能获得较佳使用时间。
- 无法更换电池的早期 Pebble 型号（无四颗螺丝）难以维修，建议选择带螺丝后盖的型号或 Pebble Time/Steel 等更易维护的版本。
- 一些用户因环保理念和怀旧情感，不愿更换旧设备，即使新 Pebble 已推出。
- 有人建议购买新 Pebble 后赠予无手表的朋友，以实现设备循环利用。
- 有用户认为 Pebble 的设计风格已过时，希望未来能有更符合现代审美的设计更新。
- Nothing 的智能手表设计风格可能满足对极简、高颜值设备的偏好。
- Pebble Time 2 曾进行过重新设计，可能更符合部分用户审美。
- Teenage Engineering 的设计被评价为“伪怀旧”，存在结构质量上的缺陷。
- 一些用户认为 Garmin 系列手表在续航、应用支持和屏幕方面已具备类似 Pebble 的优势，但软件体验较差。
- Garmin 手表硬件优秀但软件体验不佳，存在卡顿、操作繁琐、开发困难等问题。
- 有观点指出 Pebble 使用的是透射式记忆液晶屏（LCD），并非电子墨水屏（e-ink），但其技术在功耗和显示效果上表现优异。
- 电子墨水技术与 LCD 技术不同，e-ink 并非 LCD，但“电子纸”这一术语常被误用。
Does our “need for speed” make our wi-fi suck?
#
https://orb.net/blog/does-speed-make-wifi-suck
文章探讨了当前消费者对 Wi-Fi“速度”的过度追求如何导致家庭网络体验恶化，尤其是在 5 GHz 频段使用过宽的信道宽度（如 80 MHz 或更宽）的问题。
尽管专业网络规划中推荐使用 20 MHz 或 40 MHz 信道以减少干扰、提升网络密度和稳定性，但主流消费级路由器和 Mesh 系统默认采用宽信道，以迎合用户对“峰值速度”的偏好。这种做法在高密度住宅区尤其有害，容易引发同频和邻频干扰，降低整体网络质量。
文章指出，频繁进行的互联网速度测试本身也会严重破坏 Wi-Fi 体验。测试设备（尤其是通过 Wi-Fi 连接）会占用大量空中时间，造成空气时间争用，导致延迟上升、抖动增加、丢包率升高，使其他设备（如 iPhone）的响应能力显著下降。实验表明，当测试设备通过有线连接进行测速时，对网络的影响几乎为零，证明问题根源正是 Wi-Fi 上的高负载测试流量。
此外，许多 ISP 和设备厂商因担心在速度基准测试中表现不佳，不愿默认配置更合理的窄信道，进一步加剧了问题。而消费者对“速度”的执念，也使得厂商缺乏动力改进网络的响应性和可靠性。
文章强调，真正的用户体验关键在于响应速度、稳定性和低延迟，而非峰值吞吐量。IEEE 802.11bn（Wi-Fi 8）标准已开始转向这一理念，但要到 2028 年才可能完成。6 GHz 频段虽能缓解部分压力，但当前 Wi-Fi 6E 和 Wi-Fi 7 的普及率仍低，难以快速解决根本问题。
最后，文章呼吁：无需等待新技术，现有设备通过合理配置即可显著改善体验。关键在于改变行业和用户对“速度”的单一关注，转而使用持续监测工具，提供直观的响应性、可靠性等真实体验指标，推动厂商和运营商真正以用户体验为核心进行优化。
https://news.ycombinator.com/item?id=45542444
- 为每个设备分配独立的 Wi-Fi 信道能显著提升网络性能，即使信号质量一般但无干扰的信道也优于高干扰的优质信道。
- 最有效的提升 Wi-Fi 速度的方法是减少 Wi-Fi 使用，尽可能通过以太网连接设备。
- 除了手机和笔记本电脑外，其他设备如电视等应优先使用有线连接，以避免无线网络拥堵。
- 有线网络连接能极大改善视频通话等高带宽需求应用的使用体验。
- 即使房屋已预装以太网接口，但位置不合理导致无法使用，实际利用率低。
- 可通过使用细小、颜色匹配的以太网线并巧妙隐藏（如沿踢脚线或门下布线）来实现美观布线。
- 建议在房屋建设阶段就预留空管，方便后期布线，成本增加不多但长期收益显著。
- 未来可考虑在每个电源插座旁增加兼具网线和快充功能的 USB 接口，提升设备连接便利性。
- Android 设备在插入有线网络适配器时，理论上可自动切换至有线连接，实现无缝网络切换。
- 有线网络连接比 Wi-Fi 更稳定可靠，尤其在高带宽场景下优势明显。
- 使用超薄（3mm）的 Unifi 网线可实现美观且稳定的千兆网络连接，适合家庭布线。
- 家庭布线应优先考虑使用实芯线而非软线，以提升信号稳定性和耐用性。
- 在房屋装修阶段预埋 PVC 管道，能极大简化后期布线工作，提升未来改造灵活性。
Hacker News 精彩评论及翻译
#
Daniel Kahneman opted for assisted suicide in Swit…
#
https://news.ycombinator.com/item?id=45548022
I had an old teacher who died almost a year ago.
Great guy, very sociable, knew everyone in the little town he lived in. Kept in touch with a lot of students. Good neighbour, friendly guy who’d talk to everyone.
He got Alzheimers. He started forgetting stuff, and it frustrated him. He got caught driving dangerously, and cursed the doctor who took away his license.
He argued with me about the state of some chicken he wanted to cook. I told him “this is pink all over, you have to cook it more”. He got angry. I understood he’d become like this to everyone.
He pissed off everyone on his street, and all police, medical and social workers sent to help him. The disease made him blow up every relationship he had with anyone that he didn’t know well, like me and a couple of colleagues.
He got found in his house, having left the gas on, endangering the whole street. He ended up in a care home, not knowing who he was, or who I was.
If he’d been run over by a car, or died of a heart attack at the age of 80, people he knew would remember him as that nice old guy who had a dog and made a lot of art, and was friendly to everyone. Instead he was that 83 year old guy who pissed off everyone, nearly blew up the neighbourhood, and drove like a maniac.
You really don’t want to end up with dementia and related illnesses, it totally sours everyone’s view of you.
lordnacho
我有一位老教师，他去世快一年了。
他人很好，非常善于交际，住的那个小镇里他认识所有人。和很多学生都保持联系。他是个好邻居，对谁都友善，喜欢和每个人聊天。
他得了阿尔茨海默症。他开始忘记事情，这让他很沮丧。他因为危险驾驶被抓住，还咒骂了吊销他驾照的医生。他想煮鸡，却因为鸡肉的状态问题和我争吵。我跟他说：“这鸡还是粉色的，得再煮一会儿。”他生气了。我明白，他对所有人大概都变成这样了。
他惹怒了街坊邻居，以及所有派来帮助他的警察、医生和社会工作者。这场疾病让他和所有不太熟的人都闹翻了，比如我和几位同事。人们在他在家里时发现他忘了关煤气，危及了整条街的安全。最后他被送进了养老院，不再认识自己，也不认识我了。
如果他在80岁时被车撞了，或是死于心脏病发作，认识他的人们会记住他，那位有只狗、爱画画、对每个人都友善的好老头。取而代之的是，他成了那个83岁的老头，惹怒了所有人，差点炸了整条街，还像个疯子一样开车。
你真的不想患上痴呆症及相关疾病，因为那会彻底改变大家对你的看法。
Liquid Glass Is Cracked, and Usability Suffers in …
#
https://news.ycombinator.com/item?id=45544236
This update is one of the rare cases where I really dislike the new version. I’m usually happy with Apple updates, even ones the commentators dislike. This time I’m sorta agreeing with them: I don’t like the new iOS. Same with the Mac and iPad: other than being glitchy, I just don’t like the changes. It feels like my screen real estate isn’t as efficiently used, UI elements feel jumbled and the transparency makes things harder to read. I’m sure I’ll get used to it over time but I’m not enjoying it so far, even after going into the settings to try to adjust things I don’t care for. Not my favorite update cycle from Apple, and I’m usually one of the overly positive folks on whatever Apple ships.
porcoda
这次更新是我少数几个真心不喜欢新版本的情况之一。我通常对苹果的更新很满意，即使是那些评论家不喜欢的。但这次我倒是有点同意他们的看法：我不喜欢新的iOS系统。Mac和iPad也是一样：除了存在故障，我就是不喜欢这些改动。感觉屏幕空间没有高效利用，界面元素显得杂乱，半透明效果也让内容更难阅读。我相信我以后会习惯的，但到目前为止，即使我进入设置尝试调整那些我不喜欢的选项，我依然不喜欢。这不是我最喜欢的苹果更新周期，而我通常是那个对苹果发布的任何产品都持过度积极态度的人。
Daniel Kahneman opted for assisted suicide in Swit…
#
https://news.ycombinator.com/item?id=45548598
You really don’t want to end up with dementia and related illnesses, it totally sours everyone’s view of you.
This seems like such an absurd conclusion to this, as though the opinions of other people of you are what matter when you functionally lose your personhood and then die.
Maybe a better focus would be that there often isn’t a good way for a community to manage a person who suddenly becomes irrational because of an illness.
AQuantized
你真的不想患上痴呆症及相关疾病，因为这会彻底毁掉所有人对你的看法。
这个结论似乎太荒谬了，就好像当你实际上已经丧失人格并最终离世时，别人的看法才是最重要的。
或许更好的关注点在于，当一个人因病突然变得无法理性思考时，社区通常没有很好的方法来应对。
Ryanair flight landed at Manchester airport with s…
#
https://news.ycombinator.com/item?id=45547079
In safety-critical systems, we distinguish between accidents (actual loss, e.g. lives, equipment, etc.) and hazardous states. The equation is
hazardous state + environmental conditions = accident
Since we can only control the system, and not its environment, we focus on preventing hazardous states, rather than accidents. If we can keep the system out of all hazardous states, we also avoid accidents. (Trying to prevent accidents while not paying attention to hazardous states amounts to relying on the environment always being on our side, and is bound to fail eventually.)
One such hazardous state we have defined in aviation is “less than N minutes of fuel remaining when landing”. If an aircraft lands with less than N minutes of fuel on board, it would only have taken bad environmental conditions to make it crash, rather than land. Thus we design commercial aviation so that planes always have N minutes of fuel remaining when landing. If they don’t, that’s a big deal: they’ve entered a hazardous state, and we never want to see that. (I don’t remember if N is 30 or 45 or 60 but somewhere in that region.)
For another example, one of my children loves playing around cliffs and rocks. Initially he was very keen on promising me that he wouldn’t fall down. I explained the difference between accidents and hazardous states to him in childrens' terms, and he realised slowly that he cannot control whether or not he has an accident, so it’s a bad idea to promise me that he won’t have an accident. What he can control is whether or not bad environmental conditions lead to an accident, and he does that by keeping out of hazardous states. In this case, the hazardous state would be standing less than a child-height within a ledge when there is nobody below ready to catch. He can promise me to avoid that, and that satisfies me a lot more than a promise to not fall.
kqr
在关键安全系统中，我们区分事故（即实际损失，如生命、设备等）和危险状态。其关系方程式为：
危险状态 + 环境条件 = 事故
因为我们只能控制系统，而无法控制其环境，所以我们关注的是预防危险状态，而非事故本身。如果我们能让系统始终避开所有危险状态，我们也就避免了事故的发生。（试图在不关注危险状态的情况下预防事故，等同于依赖环境永远对我们有利，而这最终注定会失败。）
在航空业中，我们定义了这样一种危险状态：“着陆时剩余燃油少于N分钟”。如果一架飞机着陆时油量少于N分钟，那么只要环境条件稍有不利，它就可能坠毁，而不是成功着陆。因此，我们在设计商业航空时，会确保飞机在着陆时总有至少N分钟的剩余燃油。如果没有，那就是严重的问题：系统已经进入了危险状态，这是我们绝不愿看到的。（我不记得N的具体数值是30、45还是60，但应该是这个区间里的某个数。）
再举一个例子，我有一个孩子喜欢在悬崖和岩石附近玩耍。起初，他热衷于向我承诺自己绝不会掉下去。我用他能理解的方式向他解释了事故与危险状态的区别，他慢慢意识到，自己无法控制事故是否发生，因此向我承诺“不会出事”是个糟糕的主意。他能控制的是，不让恶劣的环境条件导致事故，而要做到这一点，他就要避开危险状态。在这种情况下，危险状态就是：站在离悬崖边缘不足一个身高的地方，而下面又没有人准备接住他。他可以向我承诺他会避开那种情况，这远比他承诺“不会掉下去”更能让我安心。
Does our “need for speed” make our wi-fi suck?
#
https://news.ycombinator.com/item?id=45542577
I did some experimentation with UniFi hubs and came to the conclusion that if you can give each device its own WiFi channel that would be ideal – contention is that bad and often an uncontended channel with otherwise poor characteristics will beat a contended channel that otherwise looks good.
The other bit of advice that is buried in there that no-one wants to hear for residences is the best way to speed up your Wi-Fi is to not use it. You might think it’s convenient to have your TV connect to Netflix via WiFi and it is, but it is going to make everything else that really needs the Wi-Fi slower. It’s a much better answer to hook up everything on Ethernet that you possibly can than it is to follow the more traveled route of more channels and more congestion with mesh Wi-Fi.
PaulHoule
我对UniFi Hub进行了一些实验，得出的结论是：如果能让每台设备都拥有自己的WiFi信道，那将是理想的情况。——竞争的状况是如此糟糕，以至于一个特性不佳但无竞争的信道，其表现往往会优于一个特性良好但存在竞争的信道。
其中还有一条建议，是没人想在家庭环境中听到的：提升你Wi-Fi速度最好的方法，就是不要使用它。你可能会觉得让电视通过WiFi连接Netflix很方便，这一点没错，但这会拖慢其他真正需要Wi-Fi的设备。相比于选择更常见的增加信道和拥塞的mesh Wi-Fi路线，尽可能地将一切设备都通过以太网连接，才是更好的解决方案。
Daniel Kahneman opted for assisted suicide in Swit…
#
https://news.ycombinator.com/item?id=45548635
The parent described someone who went above and beyond the norm of other members in his community in his constant positive interaction with his neighbors, collegues, and former students. It is highly likely this kind of person would give a considerable shit if he knew he would become a nightmare for the same community.
There may be others reading in the thread who also can relate to the personality of the teacher and may care about their affect on others when they are “not themselves”.
sillyfluke
这位家长描述了一个在邻里、同事和前学生的日常互动中，其行为举止远超社区常人水准的人。如果这样的人知道自己会成为整个社区的噩梦，他很可能会感到非常在意。
或许在帖子中还有其他人也能体会到这位老师的性格，并且在意当他们“不像自己”时会对他人产生何种影响。
Tennessee man arrested, accused of threatening a s…
#
https://news.ycombinator.com/item?id=45551642
I think this is an example of using slow trials as a nonjudicial weapon. The defendant did not break the law and isn’t likely to be convicted (at least not on appeal), but they can hold him in jail for months because they got mad at his Facebook post.
whatshisface
我认为，这就是一种利用拖延审判作为非司法武器的例子。被告人并没有违法，且很可能不会被定罪（至少在上诉时不会），但他们只因为看不惯他的脸书帖子，就可以将他关押数月。
Daniel Kahneman opted for assisted suicide in Swit…
#
https://news.ycombinator.com/item?id=45548178
I’m part of the Jain community in Bangalore, and the version of this in society exists, called Sallekhna [1], a tradition that’s developed over millennia, and this is venerated and celebrated.
The philosophical underpinning is giving up of materialness. The practicality of the 5 instances that I witnessed over the past year - typical terminal individuals choose this. They pass away surrounded by loved ones (they typically medicate for any pain, and the body starts shutting down when food and water stops). This is observed with somberness, but celebrated as very positive act.
When someone starts this process, it’s a unique experience speaking with them, as there’s usually nothing that comes up, and the moment does not really lend itself to small talk :)
[1]
https://en.wikipedia.org/wiki/Sallekhana
anilgulecha
我是班加罗尔耆那教社群的一员，在我们的社会中，存在一种被称为“萨莱克纳”[1]的传统做法，它历经数千年发展而来，并且备受尊崇和庆祝。
其哲学基础是放弃物质性。在我过去一年见证的5个实例中，通常是临终病人会选择这种方式。他们会在亲人的陪伴下离世（他们通常会用药来缓解疼痛，并且当停止进食和饮水后，身体机能会开始衰竭）。虽然整个过程庄严肃穆，但它被视作一种非常积极的行为并加以庆祝。
当有人开始这个进程时，与他们交谈是一种独特的体验，因为通常没什么可谈的，而那个时刻也不适合闲聊。
Microsoft only lets you opt out of AI photo scanni…
#
https://news.ycombinator.com/item?id=45552226
“You can only turn off this setting 3 times a year.”
Astonishing. They clearly feel their users have no choice but to accept this onerous and ridiculous requirement. As if users wouldn’t understand that they’d have to go way out of their way to write the code which enforces this outcome. All for a feature which provides me dubious benefit. I know who the people in my photographs are. Why is Microsoft so eager to also be able to know this?
Privacy legislation is clearly lacking. This type of action should bring the hammer down swiftly and soundly upon these gross and inappropriate corporate decision makers. Microsoft has needed that hammer blow for quite some time now. This should make that obvious. I guess I’ll hold my breath while I see how Congress responds.
themafia
你每年只能关闭这个设置3次。
真是惊人。他们显然认为用户别无选择，只能接受这种苛刻且荒唐的要求。就好像用户不明白，他们必须大费周章地编写代码来强制执行这个结果。这一切都是为了一个给我带来 questionable 好处的功能。我认识我照片里的人。为什么微软如此热衷于也知道这一点？
隐私立法显然存在不足。这种行为理应让这些粗鲁且不恰当的企业决策者受到迅速而严厉的惩罚。微软早就该吃点教训了。这件事本该让这一点显而易见。我就姑且看看国会有何反应吧。
Ryanair flight landed at Manchester airport with s…
#
https://news.ycombinator.com/item?id=45540402
Naively as an outsider, this situation seems like everything worked as intended?
On a nominally 2h45m flight, they spent an extra 2 hours in the air, presumably doing doing fuel intensive altitude changing maneuvers, and were eventually able to land safely with their reserves almost exhausted.
I’m a little confused by what there is to investigate at all.
How much fuel should they have landed with?
abtinf
作为一个门外汉，我天真地觉得这种情况似乎一切按计划进行？在一次名义上为2小时45分的航班中，飞机在空中多飞了2个小时，想必是为了进行大量消耗燃料的变高机动，最终在燃油储备几乎耗尽的情况下安全着陆。我搞不懂，这究竟有什么可调查的？他们着陆时应该剩下多少燃料？
Examples are the best documentation
#
https://news.ycombinator.com/item?id=45538265
Please don’t follow this advice! The best thing about old school Python was that I could reliably pull up the documentation for a library and it would clearly list the arguments and return values for each function.
Now when I look at the documentation for many JavaScript, and even Python, libraries it’s just examples. That’s great if I’m trying to just throw something together as quickly as possible, but not if I need to fix a problem or actually learn the library.
Also having examples is fine, but they should be considered a bonus; not documentation.
harimau777
千万别听这个建议！老派 Python 最好的一点是，我可以随时查阅库的文档，文档会清晰地列出每个函数的参数和返回值。现在当我查看许多 JavaScript，甚至是 Python 库的文档时，里面只有例子。如果我只想尽快拼凑出一些东西，这很好，但如果我需要解决问题或真正学习这个库，就不行了。另外，有例子当然很好，但它们应该算作一个加分项，而不是文档本身。
Examples are the best documentation
#
https://news.ycombinator.com/item?id=45536084
Similarly, unix man pages desperately need examples. They are almost without fail written as an exhaustive reference for someone who already knows how to use the tool, which is a totally valid use case. But that means they’re generally useless for someone trying to use a tool for the first time. Good documentation needs to have both.
bigstrat2003
同样，Unix 的手册页急需示例。它们几乎毫无例外地被写成一种详尽的参考资料，对象是那些已经知道如何使用该工具的用户，这本身完全是一种有效的使用场景。但这意味着对于初次尝试使用该工具的人来说，这些手册页通常毫无用处。好的文档需要兼顾两者。
“Vibe code hell” has replaced “tutorial hell” in c…
#
https://news.ycombinator.com/item?id=45541071
Minor part of the article, but the thing about “tutorial Hell” is very true:
Students would watch (or fall asleep to) 6-hour videos, code along in their own editors, feel like they got it, and then freeze up the moment they had to write anything from scratch. Classic tutorial hell.
This is why, across history, the tried and true method of learning a craft is an apprenticeship. You, the junior, tag along a senior. You work under a shop that is led by a senior-senior that is called a master. Apprentices become craftsmen, craftsmen become masters. AFAIK, the master does not ‘offload’ project guidance into non-craftsmen, it is an expected part of the craftsmen role to be project/product managers/owners.
I’ve said this a million times to close friends and at this point I’m only half joking. We, and I’m including myself in the ‘developer’ crowd although I may not deserve it, have really dropped the ball in not being a ‘guild’ since way back when. At least since the late 1980’s; and certainly since before the Original Boom of software dev as a profession (I’m assuming it was late 90’s? I know not)
(Although I suspect that if that were the case we’d have fewer developers throughout the 00s and 10s, which may have impacted the development of the field itself in unexpected, but likely negative, ways)
gota
虽然是文章的一小部分，但“教程地狱”这一点说得太对了：
学生们会看（或者看着看着就睡着了）长达6小时的视频，在自己的编辑器里跟着敲代码，感觉自己已经掌握了，但一旦需要自己从头开始写点什么，大脑就一片空白。这就是典型的“教程地狱”。
这就是为什么，纵观历史，学习一门手艺最行之有效、经久不衰的方法就是学徒制。作为学徒，你跟着一位资深师傅学习。你在一个由一位被称为“大师”的资深师傅领导的工作坊里工作。学徒成为工匠，工匠成为大师。据我所知，大师不会将项目指导“外包”给非工匠，担任项目/产品经理/负责人是工匠角色的应有之义。
我已经跟我的好朋友们说过无数次了，到现在说这话，我一半是在开玩笑。我们，包括我自己——虽然可能我还不配被称为“开发者”——在很久以前就没有形成一个“行会”，我们在这件事上真的搞砸了。至少从20世纪80年代末开始；肯定是在软件开发作为一门职业的第一次繁荣期之前（我猜是90年代末？我也不确定）。
（虽然我怀疑，如果情况真的是这样，那么在整个00年代和10年代，我们的开发者数量会更少，这或许会对该领域的发展产生意想不到的、但很可能是负面的影响）
Superpowers: How I’m using coding agents in Octobe…
#
https://news.ycombinator.com/item?id=45549036
I often feel these types of blogposts would be more helpful if they demonstrated someone using the tools to build something non-trivial.
Is Claude really “learning new skills” when you feed it a book, or does it present it like that because you’re prompting encourages that sort of response-behavior. I feel like it has to demo Claude with the new skills and Claude without.
Maybe I’m a curmudgeon but most of these types of blogs feel like marketing pieces with the important bit is that so much is left unsaid and not shown, that it comes off like a kid trying to hype up their own work without the benefit of nuance or depth.
Avicebron
我常常觉得，这类博客文章如果能展示有人用这些工具来构建一些非同小可的东西，会更有帮助。当你给Claude喂一本书时，它真的在“学习新技能”吗，还是仅仅因为你的提示词鼓励它做出那样的回应，所以它才表现出那样？我觉得，他们必须演示一下掌握了新技能的Claude和没有掌握新技能的Claude作为对比。也许我是个老古董，但我总觉得，这类博客文章大多像营销软文，关键信息语焉不详，没有展示出来，给人的感觉就像一个孩子在吹嘘自己的作品，既缺乏深度，又不够严谨。
I switched from Htmx to Datastar
#
https://news.ycombinator.com/item?id=45536535
I recently read this:
https://drshapeless.com/blog/posts/htmx,-datastar,-greedy-developer.html
Which states some of the basic (great) functionality of Datastar has been moved to the Datastar Pro product (?!).
I’m eager to support an open source product financially and think the framework author is great, but the precedent this establishes isn’t great.
rubenvanwyk
我最近读到了这篇文章：https://drshapeless.com/blog/posts/htmx,-datastar,-greedy-developer.html
文章指出，Datastar的一些基础（优秀）功能被移到了Datastar Pro产品中（？！）。
我很乐意通过付费来支持一个开源产品，并且觉得这个框架的作者很棒，但这开创的先例不太好。
Does our “need for speed” make our wi-fi suck?
#
https://news.ycombinator.com/item?id=45543041
The other bit of advice that is buried in there that no-one wants to hear for residences is the best way to speed up your Wi-Fi is to not use it. You might think it’s convenient to have your TV connect to Netflix via WiFi and it is, but it is going to make everything else that really needs the Wi-Fi slower. It’s a much better answer to hook up everything on Ethernet that you possibly can than it is to follow the more traveled route of more channels and more congestion with mesh Wi-Fi.
Absolutely. Everything other than cell phones and laptops-not-at-a-desk should be on Ethernet.
I had wires run in 2020 when I started doing even more video calls. Huge improvement in usability.
JoshTriplett
另一条针对家庭用户的、且很少有人愿意听的建议是：加速Wi-Fi的最佳方式就是干脆别用它.你可能会觉得让电视通过Wi-Fi连接Netflix很方便，事实也确实如此，但这会让其他真正需要Wi-Fi的设备速度变慢.更好的做法是，尽可能将所有设备用网线连接起来，而不是选择mesh Wi-Fi那条路——增加信道、却让网络更加拥堵.
没错.除了手机和不固定放在桌面的笔记本电脑之外，所有其他设备都应该使用网线连接.
2020年我开始进行更多视频通话时，就拉了网线，使用体验有了巨大的提升。
Boring Company cited for almost 800 environmental …
#
https://news.ycombinator.com/item?id=45540677
All this so a handful of passengers a week can wait for the extremely small pool of vehicles in a dusty hole
leakycap
就为了每周那可怜的几位乘客，在一个尘土飞扬的破地方眼巴巴地等着区区几辆车。
Liquid Glass Is Cracked, and Usability Suffers in …
#
https://news.ycombinator.com/item?id=45544149
Literally every change made in iOS 26 feels like a downgrade to me. This is the first time I have ever considered downgrading iOS.
mfro
说真的，iOS 26 的所有改动在我看来都是降级。这还是我头一次考虑降级 iOS。
I switched from Htmx to Datastar
#
https://news.ycombinator.com/item?id=45536797
Thanks to Chris to continue challenging his comfort zone (and mine!) and sharing his impressions and learnings with us!
I may be a little biased because I’ve been writing webapps with htmx for 4 years now, but here are my first thoughts:
-
The examples given in this blogpost show what seems to be the main architectural difference between htmx and Datastar: htmx is HTML-driven, Datastar is server-driven. So yes, the API on client-side is simpler, but that’s because the other side has to be more complex: on the first example, if the HTML element doesn’t hold the information about where to inject the HTML fragment returned by the server, the server has to know it, so you have to write it somewhere on that side. I guess it’s a matter of personal preference then, but from an architecture point-of-view both approaches stand still
-
The argument of “less attributes” seems unfair when the htmx examples use optional attributes with their default value (yes you can remove the hx-trigger=“click” on the first example, that’s 20% less attributes, and the argument is now 20% less strong)
-
Minor but still: the blogpost would gain credibility and its arguments would be stronger if HTML was used more properly: who wants to click on <span> elements? <button> exists just for that, please use it, it’s accessible ;-)
-
In the end I feel that the main Datastar selling point is its integration of client-side features, as if Alpine or Stimulus features were natively included in htmx. And that’s a great point!
David-Guillot
感谢 Chris 不断挑战自己的舒适区（以及我的！），并与我们分享他的印象和所学。
因为我已经用 htmx 写了4年的 Web 应用，所以我可能有点偏见，但这是我的初步想法：
-
这篇博客文章中给出的例子似乎展示了 htmx 和 Datastar 之间主要的架构差异：htmx 是 HTML 驱动的，而 Datastar 是服务器驱动的。所以，是的，客户端的 API 更简单，但这是因为另一端（服务器端）必须更复杂：在第一个例子中，如果 HTML 元素没有持有关于在哪里注入服务器返回的 HTML 片段的信息，那么服务器就必须知道它，所以你必须把它写在服务器端的某个地方。我想这只是一个个人偏好的问题，但从架构的角度来看，这两种方法都是站得住脚的。
-
当 htmx 的例子使用带有默认值的可选属性时，“更少的属性”的论点似乎不公平（是的，你可以删除第一个例子中的 hx-trigger=“click”，这样属性就减少了20%，这个论点现在也弱了20%）。
-
虽然是小问题，但仍然值得一提：如果 HTML 的使用更加规范，这篇博客文章会更具可信度，其论点也会更有力：谁想点击 <span> 元素呢？<button> 的存在就是为了这个目的，请使用它，它更具可访问性 ;-)
-
最后，我觉得 Datastar 的主要卖点是其集成了客户端特性，就好像 Alpine 或 Stimulus 的特性是原生内置在 htmx 中一样。这是一个很棒的优点！
Vibing a non-trivial Ghostty feature
#
https://news.ycombinator.com/item?id=45550683
Tip: I very often use AI for inspiration. In this case, I ended up keeping a lot (not all) of the UI code it made, but I will very often prompt an agent, throw away everything it did, and redo it myself (manually!). I find the “zero to one” stage of creation very difficult and time consuming and AI is excellent at being my muse.
This right here is the single biggest win for coding agents. I see and directionally agree with all the concerns people have about maintainability and sprawl in AI-mediated projects. I don’t care, though, because the moment I can get a project up on its legs, to where I can interact with some substantial part of its functionality and refine it, I’m off to the races. It’s getting to that golden moment that constitutes 80% of what’s costly about programming for me.
This is the part where I simply don’t understand the objections people have to coding agents. It seems so self-evidently valuable — even if you do nothing else with an agent, even if you literally throw all the code away.
PS
Put a weight on that bacon!
tptacek
小贴士：我经常用AI获取灵感。这次我最终保留了AI生成的很多（不是全部）UI代码，但我经常提示AI代理，然后扔掉它做的所有事，自己手动重做！我发现创作的“从零到一”阶段非常耗时困难，而AI非常擅长做我的灵感缪斯。
这恰恰是编程代理最大的优势。我看到了人们对于AI介入项目中可维护性和过度扩展的所有担忧，并且大体上同意。但我并不在意，因为一旦我能让项目站稳脚跟，能够与其功能的实质性部分进行交互并完善它，我就开始顺利推进了。对我来说，编程中80%的成本就在于达到那个黄金时刻。
我就是不明白人们对编程代理的反对之处。它看起来如此不言而喻地有价值——哪怕你除了用代理之外什么都不做，哪怕你字面意义上扔掉所有生成的代码。
附言
给培根压上重量！
https://news.ycombinator.com/item?id=45542459
Ignoring political implications here and just on a personal level I wish political ads were banned. Quite possibly my least favorite type of ad to see and I’ve never felt meaningfully informed by them (generally quite the opposite).
tdb7893
抛开政治层面的影响，仅从个人角度来看，我希望能禁止政治广告。这大概是我最不喜欢的广告类型了，而且我从未觉得它们能提供任何有意义的信息（通常恰恰相反）。
Ask HN: What’s the best hackable smart TV?
#
https://news.ycombinator.com/item?id=45541121
Do recommend the LG C series (C5 or C4 are new or the C1 series if you want a deal on classifieds - same hardware as the higher end models but needs a firmware bit flip). The OS is very rootable and it makes a great TV that doubles as a monitor. Supports free sync / g-sync. OLED is nice at this scale.
Text is very readable, refresh rate is good. It uses the same panels as the fancier G series in the larger sizes. One can root the firmware to make it go brighter. (Though this is screen works well in medium or dimly lit rooms. It does not shine in very bright rooms).
Plenty of YouTube videos singing the C series praises as a TV / Monitor.[1] LG webOS is also trivial/friendly to root in developer mode and network control of the tv is a nice to have.
Would avoid Samsung. I love the matte on the Frame and the design of the Serif but the OS is frustrating / impractical to root.
[1]
https://youtu.be/Qtve0u3GJ9Y
paulgerhardt
我推荐LG C系列电视（新款有C5或C4，或者如果你想在二手平台淘个划算的，可以选择C1系列——它的硬件配置和高端型号一样，但需要对固件进行一位翻转）。它的系统非常容易获取root权限，所以它是一台既能当电视又能当显示器的绝佳选择。支持FreeSync/G-Sync，在这个尺寸下，OLED屏幕的体验非常棒。文字显示清晰，刷新率也很不错。它使用的是和更高端的G系列相同的大尺寸面板。用户可以通过破解固件来让屏幕变得更亮。（不过这款电视在中等或光线较暗的房间里表现很好，但在非常明亮的房间里就没什么优势了）。有很多YouTube视频都在称赞C系列电视/显示器的优秀表现。[1] LG webOS在开发者模式下也极易/友好地进行root，并且对电视的网络控制也是一个加分项。
不建议选择三星。我很喜欢The Frame的哑光屏和The Serif的设计，但它的系统很难/不切实际地进行root。
[1]
https://youtu.be/Qtve0u3GJ9Y