伦巴第大区正在实施新的法规，以规范数据中心的快速增长，旨在平衡人工智能竞赛的需求与环境的可持续性。议员马西莫·塞尔托里（Massimo Sertori）强调，虽然该地区不能停止工业发展，但将通过简化行政程序，优先考虑闲置工业区的再开发，从而抑制在绿地上的建设。 针对该地区巨大能源需求的担忧，该法律确立了统一的投资程序，并将意大利输电网公司（Terna）纳入指导委员会，以规划能源可用性，同时计划将授权上限限制在2吉瓦。 然而，反对派对此仍持批评态度。民主党议员马泰奥·皮洛尼（Matteo Piloni）在承认数据中心必要性的同时，认为该法律缺乏连贯的政治远见。他主张该法规未能提供强有力的土壤保护，并批评其缺乏严格的限制，认为真正有效的监管需要国家政府的干预。
每日HackerNews RSS
意大利的一项新区域政策提议，对建在绿地或农业用地上的数据中心征收200%的税收。该立法旨在保护土地，并为选择改造废弃工业用地的开发商提供行政简化程序。
这一政策在 Hacker News 上引发了激烈辩论。支持者认为，此举保护了重要的自然和农业资源，并指出与传统行业相比，数据中心提供的当地就业岗位相对较少。相反，批评者则将该税收视为“绿色政治”，认为这可能会阻碍技术进步。他们警告称，通过抑制人工智能和数字创新所需的基础设施建设，意大利和欧洲面临落后的风险，可能变得依赖外国科技巨头并丧失未来的经济价值。
讨论还触及了土地利用的必要性，一些人认为农业用地已经未被充分利用或用于非食品生产，而另一些人则强调粮食安全应被置于优先地位。归根结底，这场辩论反映了人工智能时代对基础设施的迫切需求与规范土地开发的社会环境努力之间更广泛的张力。
尽管大语言模型（LLM）擅长生成函数或文档等独立的增量任务，但它们目前尚不具备自主修改复杂软件系统的能力。作者认为，“模式匹配”（LLM 的强项）与“因果推理”（在大型实际代码库中处理依赖关系、不变量及连锁反应所必需的能力）之间存在本质区别。 由于 LLM 预测的是统计学上合理的词元，而非理解系统性的后果，因此在交付生产环境级软件时，它们仍不可靠。它们可以模仿工程工作，但无法维持安全变更现有系统所必需的内部因果表征。 因此，业界应将人工智能视为强大的辅助工具，而非人类工程师的替代品。对于企业级代码库而言，实现自主智能体的梦想尚未得到验证。团队不应追求完全自动化，而应利用 LLM 来提升人类工程能力，始终将人类的判断置于意图、架构和安全性的核心。在人工智能能够推理其变更带来的因果影响之前，人工监督依然是可靠软件开发的必要基础。
抱歉。
作者发现，NVIDIA A100 GPU 上的矩阵乘法（matmul）性能会随输入数据的不同而产生显著差异，其中预测性模式（如全零矩阵）的运行速度比随机数据更快。与矩阵乘法仅受计算能力或带宽限制的传统认知不同，作者指出**动态功耗限制（dynamic power throttling）**才是根本原因。
由于 GPU 设有严格的功耗上限，高频活动的操作（特别是涉及晶体管频繁开关的操作）会产生更多热量并消耗更多电力。当 GPU 达到功耗上限时，电压调节模块（VRM）会降低时钟频率以防止过热或电气故障。随机且复杂的数据会导致芯片内更多的“位翻转”，从而增加功耗并触发限频；而零值或重复模式消耗的功率较小，使 GPU 能够保持更高的时钟频率。
这揭示了 GPU 基准测试中的一个关键差异：基于最高时钟频率计算出的理论峰值浮点运算性能（FLOPS）往往无法实现，因为硬件更多是受限于功耗而非计算能力。这解释了为何 H100 等硬件的实际性能提升往往达不到理论营销指标，也凸显了功耗（而非晶体管数量）才是现代人工智能硬件的主要制约因素。
*thonking.ai* 最近的一篇文章指出，GPU 在处理“可预测”或特定数据模式时，矩阵乘法的执行速度更快。Hacker News 上的讨论澄清道，这一现象主要源于硬件的能耗动态：晶体管状态转换（位翻转）会消耗电能并产生热量。当数据可预测时，位翻转次数减少，从而降低了功耗和热应力，使得 GPU 能够在不触发降频的情况下保持更高的时钟频率。
评论者们探讨了为何硬件不对零值进行“跳过”或针对常量进行优化，硬件工程师对此解释称，实现此类逻辑所需的芯片面积和复杂度对大多数工作负载而言并不划算。其他人则指出，这种效应显著到可能被利用为侧信道攻击手段，因此研究人员建议采用随机旋转等技术来掩盖数据内容。最后，该讨论还涉及了电源管理的更广泛影响；虽然一些用户建议通过限制 GPU 功耗来提升热受限环境下的效率和性能，但另一些人认为，数据依赖型性能是硬件的基本特性，设计人员——以及越来越多的 AI 研究人员——必须将其纳入考量，以优化吞吐量。
本提案主张允许在 Go 中使用**泛型具体方法（generic concrete methods）**，从而解除历史上对方法声明自身类型参数的限制。 目前，Go 允许泛型函数，但限制方法只能使用接收者定义的类型参数。这一限制最初是为了避免支持泛型接口方法所带来的复杂性，因为此类方法在运行时难以高效实现。 作者认为，无论是否满足接口，具体方法对于代码组织和可读性而言都是一种有用的语言特性。根据本提案，泛型方法将不会实现泛型接口方法，它们仅作为与类型关联的函数存在。 **关键点：** * **语法：** 方法将采用与泛型函数相同的语法：`func (r Receiver) Name[T any](...)`。 * **兼容性：** 该变更完全向后兼容，且不会破坏现有接口。 * **用法：** 类型参数可以显式提供或进行推断，方法值/表达式与现有泛型保持一致。 * **实现：** 该提案仅需对语言规范、编译器和导入/导出格式进行少量调整，且利用了现有的泛型函数调用机制。
Go 最近提议增加对泛型方法的支持。尽管早期的常见问题解答（FAQ）曾暗示此功能可能永远不会实现，但它一直是开发者长期以来的诉求。
Hacker News 上的讨论凸显了开发者社区的分歧。支持者认为这是一次必要的演进，能够简化代码，减少对“蹩脚”替代方案的需求，并使 Go 更符合现代语言标准。许多开发者表示很高兴终于能够重构库，使其更具易用性和高性能。
然而，批评者仍持怀疑态度。一些人认为，Go 团队在功能特性上采取的渐进式、有时甚至是自相矛盾的方法——先以“违背 Go 哲学”为由否定，最终又采纳——让人感到像是“煤气灯效应”（gaslighting）或是最初的设计不佳。一个核心的技术争议在于高效实现泛型方法的难度，特别是由于它们目前无法在不产生复杂运行时开销的情况下满足接口需求。
该讨论帖也反映了关于“Go 哲学”的更广泛争论：一方珍视该语言最初的简洁性和稳定性，而另一方则认为该语言必须演进以保持竞争力，并避免强迫开发者使用大量重复样板代码的模式。尽管存在批评，但普遍的共识是，这一新增功能对现实世界的 Go 开发而言是一项实用的改进。
**XLIDE** 是一个 VS Code 扩展，无需安装 Microsoft Office 或使用 COM 自动化，即可直接编辑 Excel VBA 模块。它通过 `pyOpenVBA` 和 `openpyxl` 利用 Python 3.10+ 后端，为 Windows、macOS 和 Linux 提供了一个跨平台、高性能的开发环境。
主要功能包括：
* **现代编辑器体验：** 提供完整的语法高亮、符号导航（转到定义、查找所有引用、重命名）以及虚拟文件系统集成 (`xlide-vba://`)，支持通过 Ctrl+S 将更改直接保存到 `.xlsm` 文件中。
* **AI 集成：** 将所有 VBA 操作作为工具开放给 GitHub Copilot，实现智能代码生成和重构。
* **架构：** 在 VS Code 和长驻 Python 进程之间使用轻量级 JSON-RPC 2.0 桥接，确保快速响应，并将编辑器与 Office 二进制依赖解耦。
* **安全与配置：** 包含一个导出跟踪系统 (`trueUp`) 以保持文件一致性，并要求确认所有由 AI 代理执行的写入操作。
虽然它提供了强大的开发环境，但对 Live Share 的支持有限；受限于仅限主机的 RPC 限制，访客可以编辑活动缓冲区，但无法浏览项目结构。
私募股权（PE）公司正日益主导住房、地方新闻、公共安全等关键领域。这些公司利用杠杆收购，在让投资组合公司背负高额债务的同时，抽取管理费和股息，而这些往往发生在公司面临破产前很久。这种金融工程模式将短期回报置于运营健康之上，导致公众无法选择退出的公共服务出现系统性恶化。 尽管主流媒体常将这些问题视为孤立的失败——例如 RealPage 的算法租金操纵丑闻或地方新闻编辑室的空心化，但问题的本质是结构性的。当前的商业模式允许这些公司在榨取利润的同时，将破产风险转嫁给员工、债权人和公众。虽然诸如《制止华尔街掠夺法案》（Stop Wall Street Looting Act）之类的立法旨在提高企业的问责制，但根本矛盾依然存在：关键基础设施是否应被视为纯粹的盈利工具？除非解决将榨取置于服务之上的结构性激励问题，否则关键公共资产的退化将继续作为该模式的可预见后果，而非单一管理的失败。
本次讨论聚焦于私募股权（PE）在消防安全、医疗保健和暖通空调维修等基础服务行业的收购与整合中所扮演的角色。
批评者认为，私募股权公司采用的是一种掠夺性的“收购、整合与榨取”模式。通过杠杆收购为被收购企业增加债务负担，并专注于追求短期利润最大化，这些公司往往牺牲了长期的服务质量，增加了消费者成本，并将核心服务削减得“只剩骨架”。这种做法常被比作“贫民窟房东”式的行为——在榨取资产费用以获取收益的同时，导致服务质量崩塌。
辩论的核心在于原因所在：
* **养老金/捐赠基金的资金需求：** 有人认为，私募股权是现行系统为了维持养老金和捐赠基金的偿付能力，而被迫追求激进高收益回报的产物。
* **继任者缺失：** 另一些人指出，许多面临退休却苦于没有接班人的小企业主，将私募股权收购视为其唯一可行的退出策略。
* **系统性问题：** 主张监管的人士认为，偏向债务融资（利息扣除）的税法以及现代反垄断执法的缺位，使得这些垄断企业得以形成，实际上将社会必需品变成了“寻租”机器。
许多参与讨论的人士指出，市场之所以未能纠正这种现象，是因为私募股权公司瞄准的正是那些准入门槛高且需求缺乏弹性的行业。
![](https://www.ustc.ac.uk/news/\"https:\/\/ustc.ac.uk\/storage\/yH1JNvzTQgz0qJITjsLI6lL7t3pOL4Guc7o0jNFm.png\")
请提供您需要翻译的内容。
最近的一场 Hacker News 讨论探讨了拉丁语的历史和现代作用，起因是有观察指出波兰的历史文献经常用该语言记录。
参与者们提到，拉丁语曾作为欧洲的通用语长达数个世纪，是外交、科学和天主教会不可或缺的工具。在历史上的波兰，得益于完善的教区学校网络，以及拉丁语在推崇演说的共和政体中所发挥的作用，它得到了广泛普及。
讨论延伸至天主教会内部关于拉丁弥撒的持续争论。一些人因其审美和传统特质而倡导传统的脱利腾弥撒，而另一些人则强调了传统派与现代《新礼仪》之间的神学和政治张力。
最后，讨论还涉及了拉丁语在当代的实用性，指出它在医学和法律术语中依然存在。一些贡献者甚至提议将其作为欧盟的中性行政语言，理由是拉丁语作为一种“死”语言，在文化上保持中立且语言结构稳定，这与不断演变且可能带有政治偏见的现代通俗语言不同。
研究人员引入了 **Epicure**，这是一个新型的 Skip-gram 成分嵌入（ingredient embeddings）系列，通过对九种语言的 414 万份食谱进行多语言语料库训练而成。作者将原始成分字符串标准化为 1,790 个标准条目，并利用两种主要结构绘制了食品成分之间复杂的关联：成分-成分共现图和类型化成分-化合物图（FlavorDB）。 该项目采用了三种 Metapath2Vec 模型变体，每种模型都利用独特的随机游走方案来捕捉不同的烹饪维度： * **Cooc**：仅关注基于食谱的共现数据。 * **Chem**：优先考虑分子化合物和风味特征。 * **Core**：结合了食谱上下文和化学数据的混合方法。 通过将这些模型置于从烹饪背景到分子化学的谱系中，Epicure 为探索食品的几何结构提供了一个复杂的框架。这项研究为理解成分相互作用提供了一种多功能工具，支持了计算美食学和食品科学的进步。
Hacker News 的讨论对一篇题为《将全人类烹饪压缩至 2 兆字节》的论文提出了批评，普遍认为该标题具有误导性的诱导点击成分。尽管评论者认可其利用嵌入技术映射风味特征和食材搭配这一技术概念很有趣，但他们认为这并不能代表“全人类”的烹饪。
讨论要点如下：
* **方法论局限：** 该数据集仅依赖七种语言的 11 个来源，严重偏向中文和英语，而排除或未充分代表非洲、中东及各类地区性的主要烹饪传统。
* **技术与数据的区别：** 批评者认为“烹饪”涉及细腻的技巧、火候和感官体验，这些无法通过压缩食材列表来捕获。食谱被描述为算法性的“小抄”，而非真正的烹饪知识。
* **实用价值：** 许多用户分享了组织食谱的替代方法，如依赖关系图、“风味图谱”（《风味圣经》）以及模块化烹饪概念（如《比例》、《盐、脂、酸、热》），并指出这类模型的价值更多在于提供灵感和替代方案，而非生成独立且完美的食谱。
总体而言，社区认为该项目是一个巧妙的数据实验，而非全面的烹饪资源。
关于拉取请求、议题、Git 操作和 API 请求的事件 Incident with Pull Requests, Issues, Git Operations and API Requests
2 天前
您可以通过电子邮件或短信订阅“合并请求”、“议题”、“Git 操作”和“API 请求”的故障更新。 电子邮件通知会提供故障全生命周期的更新，而短信通知仅在故障创建或解决时发送。如需启用短信提醒，请输入您的手机号码（支持全球多个地区），并使用提供的验证码（OTP）进行验证。或者，您也可以点击“订阅”仅接收电子邮件通知。
Hacker News 社区对 GitHub 近期频繁宕机和性能不稳定的趋势表示强烈不满。用户反馈称，合并请求（Pull Requests）、CI/CD 流水线以及 API 可靠性等方面频繁出现问题，以至于这些故障已成为开发工作流中的常态。
讨论集中在几个潜在原因上：
* **负载大幅增加：** 许多人将不稳定性归咎于提交量同比激增 14 倍，这主要是由自动化 AI 代理和“氛围编程”（vibe coding）驱动的，给 GitHub 的基础设施带来了巨大压力。
* **技术与组织债务：** 批评者认为，微软的管理以及向 Azure 的基础设施迁移降低了平台的可靠性，一些观点指出工程质量和监管力度有所下滑。
* **“AI 垃圾内容”（AI Slop）问题：** 一种普遍的观点是，GitHub 正难以区分人类驱动的流量与 AI 机器人产生的高频“垃圾内容”。
尽管部分用户认为 GitHub 在前所未有的自动化时代面临扩展难题，但许多人正倡导去中心化，考虑使用 Forgejo 或 GitLab 等自托管替代方案，并重新评估对中心化平台的依赖。总体而言，舆论认为 GitHub 的感知质量和正常运行时间已有所下降，促使开发者寻求更具韧性的方案。
我发现了一些散布恶意软件的 GitHub 仓库。我问人工智能该怎么办，但它没给我任何有用的建议。于是我在 GitHub 上发起了一项讨论，有人回复了，内容竟然和我从 AI 那儿得到的如出一辙。我指出了这一点，结果评论被删除了。随后又有另一个人回复，内容又是同样的 AI 回答。 我曾在一个公司当开发人员，向老板请教一个业务任务，他给我发了一张 ChatGPT 的截图作为回复。我告诉他，这和我的问题毫无关系，而且内容全错。过了一分钟，他又发来一张 ChatGPT 的截图。他根本没看 AI 的回答，只是截了个图就转发给我了。 最近有人在 Reddit 上私信我，我们聊了几轮后，我意识到我是在跟一个 AI 代理对话。 我厌倦了和人工智能对话。我想和真人交流。但即使当我与真人交谈时，他们也只是把我的问题转手扔给 AI，然后把 AI 的回答转发给我。
Hacker News 上的讨论“我厌倦了与人工智能对话”反映出人们对人工智能生成内容的泛滥以及真实人类互动逐渐消亡的日益疲惫。
参与者重点提出了几点不满：
* **思维的“外包”：** 用户对同侪将专业及个人问题转交给人工智能处理的行为感到困扰，尤其是他们甚至不阅读生成结果，而非进行真正的对话或批判性思考。
* **在线人文主义的消亡：** 许多人感到互联网正在变成一片“敌对”的景观，机器人、算法生成的内容和“AI 垃圾”占据了社交平台，使得人们难以区分真实的人际连接与机器生成的模仿。
* **经济后果：** 一些人认为，人工智能正在放大现有的社会功能失调，例如“狗屁工作”和信息商品化，这可能导致人类专业知识价值的贬损。
尽管一些用户建议将人工智能作为提高效率的工具，但主流观点是渴望回归“人性”。许多人认为，由于数字世界正变得日益合成，解决之道在于回归线下的面对面互动，或回归人工智能时代前的媒介，以寻求真正的连接与智慧。