2024-08-09 Hacker News Top Stories #

1. lenacapavir 是一种新型抗病毒药物，2022 年获得批准，成为市场上首个用于 HIV 治疗和预防的胶囊抑制剂，在临床试验中显示出 100% 的预防率。
2. 谷歌和 Meta 达成秘密协议，通过 YouTube 推广 Instagram 广告给青少年，规避了谷歌针对未成年人的在线规则。
3. 苹果未能兑现其在 macOS 系统中关于开发者 ID 证书撤销检查相关的隐私承诺，并在 macOS 14 Sonoma 发布当天悄悄删除了有关这一承诺的内容。
4. Firefox Nightly 131 版本推出了新的侧边栏和垂直标签功能，旨在提升用户的浏览体验和工作效率。
5. RP2350 微控制器的推出解决了先前 RP2040 存在的一些问题，如核心升级、内存增加等，提高了性能和灵活性。
6. NASA 因 Boeing Starliner 遇到的技术问题，考虑让宇航员 Suni Williams 和 Butch Wilmore 使用 SpaceX 的 Crew Dragon 宇宙飞船返回地球。
7. Andrej Karpathy 认为“人类反馈强化学习”（RLHF）仅勉强算是强化学习，并不是真正的 RL。
8. C# 正式提案引入类型联合的概念，旨在解决单一变量需存储不同类型值的问题。
9. Raspberry Pi 推出了新款微控制器板 Raspberry Pi Pico 2，基于 RP2350 微控制器，具备两个 150MHz 的 Arm Cortex-M33 核心和增强的安全特性。
10. System76 的 COSMIC 是一个全新的桌面环境，旨在提供强大的自定义操作系统体验，支持自动平铺、独立显示器操作等功能。

Prevention of HIV #

https://www.science.org/content/blog-post/prevention-hiv

这篇文章讨论了 HIV 预防领域的一个重要进展——药物 lenacapavir 的成功。lenacapavir 是一种抗病毒药物，用于 HIV 的治疗和预防，2022 年获得批准，成为市场上首个胶囊抑制剂。该药物通过直接干扰病毒蛋白外壳的组装来发挥作用，这在以往的研究中从未成功过。

在临床试验中，lenacapavir 显示出前所未有的效果。在南非和乌干达的高风险女性志愿者中，接受每六个月一次的注射，结果显示 HIV 感染的预防率达到了 100%。这一结果在最近的科学会议上引起了热烈的反响，甚至在报告结束时获得了长时间的掌声，这在科学会议上并不常见。

与之对比的是，传统的 HIV 药物组合在预防方面仍然存在小幅感染率，这可能与患者对药物方案的依从性有关。相比之下，lenacapavir 的半年度注射方案更易于患者遵循。

文章还提到，这一成果对未来 HIV 疫苗的研发提出了高标准的要求，并可能影响相关临床试验的设计。如果比较的标准是零感染，那么其他药物或疫苗的试验将面临伦理和科学上的挑战。

总的来说，lenacapavir 的成功标志着 HIV 预防领域的一次重大突破，尽管全球每年仍有超过一百万的新感染，但这一进展为控制和预防 HIV 提供了新的希望。

https://news.ycombinator.com/item?id=41184365

• 新药物的出现可能会显著降低新感染的数量，尤其是与现有药物相比。
• 药物的耐药性问题使得冗余药物的研发显得尤为重要。
• 该药物的作用机制与传统疫苗不同，直接作用于病毒的外壳。
• 药物的半衰期较长，可能与其分子结构中的氟元素有关。
• PFAS 类化合物的安全性存在争议，但并不意味着所有 PFAS 都是有毒的。
• 该药物在防止 HIV 感染方面的有效性得到了实证支持。
• 价格问题是药物普及的关键，尤其是在发展中国家。
• 药物研发的高成本与失败率使得制药公司在定价时需要考虑多种因素。
• 大部分药物研发资金来自政府资助，制药公司在此过程中获益。
• 药物的市场定价往往与其研发成本不成正比，存在价格垄断现象。

https://www.ft.com/content/b3bb80f4-4e01-4ce6-8358-f4f8638790f8

谷歌和 Meta（前身为 Facebook）之间达成了一项秘密协议，旨在通过 YouTube 向青少年推广 Instagram 广告，规避了谷歌针对未成年人的在线规则。据《金融时报》及知情人士的透露，谷歌为 Meta 开展了一项营销项目，专门针对 13 至 17 岁的 YouTube 用户，推广其竞争对手的照片和视频应用 Instagram。

这一广告活动故意将目标用户标记为 “未知” 类别，谷歌知道这一类别中包含大量未成年人。相关文件显示，为了掩盖该活动的真实意图，项目采取了措施以避免触及谷歌禁止针对未成年人进行个性化广告的政策。谷歌对此表示，他们的技术保护措施有效，并称没有直接针对已知的未成年 YouTube 用户。

然而，谷歌并没有否认使用 “未知” 这一漏洞。Meta 则表示，选择 “未知” 人群并不构成个性化或规避规则，且他们在广告中遵循了自身及同行的政策。

两家公司在这个营销项目上合作，Spark Foundry（法国广告巨头 Publicis 的美国子公司）负责启动这项试点计划，最初在加拿大进行，并于 2023 年 2 月至 4 月间进行测试。由于取得了初步成功，项目于 5 月在美国进行试验，后续计划扩大到国际市场，推广 Meta 的其他应用如 Facebook。

这一合作关系的建立源于 Meta 在青少年用户流失方面的压力，尤其是面对 TikTok 等竞争对手的挑战。谷歌则在试图增强广告收入，并在此过程中希望与 Meta 建立更为紧密的 “全漏斗” 关系，以进行更为高调和昂贵的品牌广告。

与此同时，随着对社交媒体平台保护儿童的责任法案（Kids Online Safety Act）在美国参议院的通过，社会各界对大科技公司的信任度持续下降，许多人对谷歌和 Meta 在此合作中针对未成年人的行为表示关切。

此外，Meta 还面临着来自 33 个州的诉讼，指控其对年轻用户实施 “操控性” 策略，联邦贸易委员会也在寻求限制 Meta 从青少年用户中获利。尽管 Meta 否认这些指控，但其面临的压力显示出社交媒体巨头在青少年保护方面的种种挑战。

总体来看，这一事件引发了人们对大科技公司在青少年保护方面可信度的质疑，并加剧了对其监管的呼声。

https://news.ycombinator.com/item?id=41188295

• 谷歌和 Meta 的秘密广告交易针对青少年，反映出对隐私和数据收集的担忧。
• 一些评论认为这与历史上烟草公司针对未成年人吸烟的策略相似。
• 有人指出，广告行业利用情感操控消费者，尤其是青少年，来提高销售。
• 讨论中提到，资本主义的短期利润驱动导致公司做出不道德的决策。
• 许多评论者认为，应该对广告进行更严格的监管，甚至禁止针对儿童的广告。
• 还有人提到，广告的存在使得人们在不知情的情况下被操控，影响了个人选择和隐私。
• 对于广告的看法存在分歧，有人认为广告可以帮助人们发现有用的产品，而另一些人则认为广告是对人类心理的剥削。
• 讨论中提到，可能需要通过法律手段来限制广告的影响力，保护青少年免受不良信息的侵害。

Apple memory holed its broken promise for an OCSP opt-out #

https://lapcatsoftware.com/articles/2024/8/3.html

这篇文章的标题为《苹果抹去了其关于 OCSP 选择退出的破坏性承诺》，作者是 Jeff Johnson，发布日期为 2024 年 8 月 7 日。

文章主要讨论了苹果公司在其 macOS 系统中与开发者 ID 证书撤销检查相关的隐私承诺未能兑现的情况。2020 年 11 月，苹果的 OCSP（在线证书状态协议）服务发生大规模故障，导致全球 Mac 用户无法启动应用程序。为了解决这一问题，苹果在一份支持文档中做出了一系列承诺，包括停止记录与开发者 ID 证书检查相关的 IP 地址、引入新的加密协议、加强服务器故障保护，以及为用户提供选择退出这些安全保护的选项。

然而，作者指出，至今为止，苹果并未在 macOS 中实现用户选择退出的选项。更令人失望的是，在 2023 年 9 月 26 日 macOS 14 Sonoma 发布当天，苹果悄悄删除了关于这一承诺的内容，原支持文档的链接也被重定向到一个略有不同的文档，但内容大致相同。

文章批评苹果的这一行为，认为公司希望用户忘记其曾做出的承诺。尽管苹果声称“隐私是基本人权”，但作者认为，苹果在保护用户隐私方面的行动并未兑现，用户无法验证其 IP 地址是否被记录。为了保护隐私，作者建议用户使用防火墙软件（如 Little Snitch）来阻止与苹果服务器的连接。

总体而言，文章强调了苹果在隐私保护方面的失信行为，并呼吁用户采取措施保护自己的隐私。

https://news.ycombinator.com/item?id=41184153

• 有人对 OCSP 的隐私问题表示担忧，认为其会将用户访问的网站信息发送给证书颁发机构（CA），可能导致用户被分析和画像。
• 有评论指出，OCSP 的优势在于能够实时了解证书状态，而不需要下载过时的证书撤销列表（CRL）。
• 一些用户表示对苹果的隐私承诺感到失望，认为其并未真正实现用户隐私保护。
• 有人提到，苹果的系统和软件设计围绕着“信任苹果”的隐私理念，质疑这种信任的合理性。
• 讨论中提到，苹果的隐私技术与其他公司相比，虽然有进步，但仍然存在许多问题和不足。
• 有人认为，苹果的隐私承诺更多是市场营销，而非真正的用户隐私保护。
• 还有评论指出，苹果的某些行为让人怀疑其对用户数据的处理方式，认为其可能会在未来改变隐私政策。
• 一些用户对使用 Linux 系统表示满意，认为其在隐私和安全性方面表现更好。

Firefox Sidebar and Vertical tabs: try them out in Nightly Firefox Labs 131

在 2024 年 8 月 7 日的 Mozilla 博客中，Firefox Nightly 131 版本推出了新的侧边栏和垂直标签功能。这一更新是社区高度期待的，旨在提升用户的浏览体验和工作效率。

主要内容摘要： #

1. 新功能介绍：

   • 垂直标签：使用户更容易浏览信息和在任务之间切换。
   • 侧边栏：允许用户快速交叉参考他们的工具，如手机标签、常用扩展和书签，帮助用户更好地管理任务。

2. 如何启用：

   • 用户需更新到最新的 Nightly 版本。
   • 进入设置 > Firefox Labs，激活侧边栏和垂直标签实验。
   • 通过右键点击工具栏，选择“自定义工具栏”，将侧边栏图标拖到工具栏上，点击该图标即可展开垂直标签。

3. 用户反馈的重要性：

   • Mozilla 呼吁用户测试这些新功能，并在 Mozilla Connect 上分享反馈，以帮助改进这些功能。
   • 对于使用侧边栏 API 或与标签相关的 Web 扩展开发者，鼓励他们测试新功能，以便提前发现潜在问题。

4. 未来计划：

   • Mozilla 将持续优化这些功能，并在未来几个月内进行改进。
   • 他们还计划在 Mozilla Connect 上分享改进的待办事项，以便用户了解这些功能的最终目标。

这一更新旨在通过更流畅的上下文切换和多任务处理，提升用户的浏览效率。Mozilla 期待用户的积极参与和反馈，以便进一步完善这些新功能。

https://news.ycombinator.com/item?id=41192118

• 有用户表示他们曾是树状标签的重度用户，但最终回归到常规标签，因为水平标签的空间限制帮助他们更好地管理打开的标签。
• 一些用户认为标签和书签应该合并，标签可以作为项目或主题的书签使用，保持树状结构以便于管理。
• 许多人提到不同用户有不同的需求，标签和书签的区分是有用的，尤其是对于需要频繁打开和关闭的标签。
• 有用户使用多个浏览器窗口来管理标签，认为这样可以更好地组织工作。
• 一些用户对 Firefox 的内存管理表示担忧，建议使用扩展来优化标签管理。
• 讨论中提到 Firefox 的用户界面需要创新，但也有用户认为稳定性和可靠性更为重要。
• 有用户提到使用 Sidebery 扩展来管理标签，认为其功能强大且易于使用。
• 许多用户对垂直标签的实现表示期待，认为这将改善标签的可视化和管理。
• 有用户提到在不同的浏览器中使用标签的体验差异，尤其是 Chrome 和 Firefox 之间的比较。
• 一些用户希望浏览器能够提供更好的分屏视图功能，以便同时查看多个网页。

I got almost all of my wishes granted with RP2350 #

https://dmitry.gr/?r=06.%20Thoughts&proj=11.%20RP2350

该网页介绍了 RP2350 微控制器的特点和优势，作者 Dmitry 分享了自己对 RP2040 的使用经验以及对 RP2350 的期待和实际体验。

主要内容摘要： #

1. RP2040 的不足：

   • 虽然 RP2040 在多个项目中表现出色，但也存在一些不足之处，特别是在某些应用场景下，作者不得不转向 STM32H7 系列芯片，尽管对其质量表示不满。

2. RP2350 的改进：

   • 核心升级：RP2350 配备了两个 Cortex-M33F 核心，支持浮点运算，并且引入了加速双精度数学运算的自定义指令集。
   • 内存和 PIO 改进：内存容量翻倍，PIO（可编程输入输出）单元数量增加到三个，支持更复杂的操作和跨 PIO 同步。
   • DMA（直接内存访问）增强：DMA 现在支持无限传输，且可以灵活调整内存地址，极大提升了性能。
   • QSPI PSRAM 支持：RP2350 支持 QSPI PSRAM，能够高效读写，并且有缓存机制，解决了以往芯片在使用 QSPI RAM 时的种种问题。

3. 项目示例：

   • 作者展示了自己使用 RP2350 开发的 DEFCON 32 徽章项目，成功实现了 Game Boy 模拟器，并且能够运行 PalmOS，展示了 RP2350 的强大功能。

4. 未来展望：

   • RP2350 的推出使得许多原本依赖 STM32H7 的项目可以转向 RP2350，节省成本和时间，并且新版本 RP2354A 和 RP2354B 还增加了内置闪存和更多 GPIO 引脚的选项。

5. 免责声明：

   • 作者声明没有受到任何形式的补偿或要求来撰写此文章，所有观点均为个人意见。

总结： #

RP2350 的推出标志着微控制器技术的一个重要进步，解决了 RP2040 的一些短板，提供了更强大的性能和灵活性，适合各种项目需求。

https://news.ycombinator.com/item?id=41191069

• RP2350 的发布引起了广泛的兴奋，许多开发者期待其在电机驱动和传感器控制方面的应用。
• 有评论提到，RP2350 解决了 RP2040 的一些缺陷，特别是在硬件支持和性能方面。
• 一些开发者对 RP2350 的多核设计表示赞赏，认为这为不同应用提供了灵活性。
• 对于 RP2350 的安全性和加密功能，评论者表示这是一个重要的进步，尤其是在高容量产品中。
• 有人提到，RP2350 的 USB 接口仍然是 micro-USB，而不是更现代的 USB-C，这引发了一些不满。
• 讨论中提到，RP2350 的价格和性能使其在市场上具有竞争力，尤其是在与其他微控制器的比较中。
• 一些开发者对使用 Bazel 作为构建系统表示不满，认为这增加了复杂性。
• 对于 RP2350 的 RISC-V 核心的引入，评论者认为这是一个大胆的尝试，可能会改变未来的开发趋势。
• 有人指出，RP2350 在功耗管理和集成度方面的改进是其一大亮点。
• 讨论中还提到，RP2350 的开发团队在听取用户反馈后进行了许多改进，值得赞扬。

NASA says Boeing Starliner astronauts may fly home on SpaceX in 2025 #

https://www.nytimes.com/2024/08/07/science/boeing-starliner-nasa-spacex.html

2024 年 8 月 7 日，NASA 承认波音公司的 Starliner 宇宙飞船在其首次载人测试飞行中出现的问题比之前预想的更加严重，因此宇航员苏尼・威廉姆斯（Suni Williams）和巴奇・威尔莫（Butch Wilmore）可能无法乘坐 Starliner 返回地球。NASA 目前正在考虑让他们搭乘竞争对手 SpaceX 的 Crew Dragon 飞船回家。

这次飞行原定在国际空间站（ISS）停留约八天，但现在可能会延长到明年。NASA 的空间操作任务局副局长肯・鲍沃索克（Ken Bowersox）在新闻发布会上表示：“我们可以选择两条路径，理性的人可能会选择任何一条。” 这给波音公司带来了更多的麻烦和尴尬，因为该公司在航天领域与联邦政府有数十亿美元的合同。

波音在 8 月 1 日宣布，因 Starliner 项目的意外支出将再写下 1.25 亿美元的损失，之前已累计写下 15 亿美元的损失。威廉姆斯和威尔莫已经在国际空间站停留了两个月，工程师们正在分析 Starliner 在靠近对接时多个推进器的故障表现以及若干氦气泄漏的相关数据。

如果决定采用备选方案，下一艘 SpaceX 的 Crew Dragon 飞船将只携带两名宇航员前往国际空间站，威廉姆斯和威尔莫将作为国际空间站的全职成员停留半年，预计在明年 2 月乘坐 Crew Dragon 返回地球。NASA 官员表示，Crew Dragon 的发射已推迟至最早 9 月 24 日，以便对 Starliner 进行进一步评估。

在新闻发布会上，波音公司表示仍然相信 Starliner 的能力和飞行合理性。如果 NASA 决定更改任务，波音将采取必要措施使 Starliner 配置为无人返回。NASA 早在七月初就开始与 SpaceX 进行备选方案的初步规划。由于测试中发现推进器出现明显退化，NASA 对于 Starliner 的信心下降，加快了与 SpaceX 的合作进度。

如果最终选择使用 Crew Dragon，Starliner 仍将在九月初返回地球，但将是无人驾驶。届时，SpaceX 的 Crew Dragon 将搭载四名宇航员完成他们的任务，接替在国际空间站的 Crew Dragon 的宇航员。同时，计划中的 “极光黎明”（Polaris Dawn）任务可能会在 8 月 26 日进行，目标是将宇航员送往距地面 870 英里的轨道，进行商业太空行走等活动。

总之，波音的 Starliner 项目面临的技术挑战和决策延误，促使 NASA 考虑依赖 SpaceX 的 Crew Dragon 作为备用方案，可能影响到宇航员的回程安排及后续任务的计划。

https://news.ycombinator.com/item?id=41184359

• NASA 工程师与波音工程师对 Starliner 的风险评估存在显著分歧，前者认为风险较高，后者则认为风险较低。
• 波音在多个资格测试中表现不佳，历史上几乎每次测试都出现问题，导致 NASA 对其信任度下降。
• 有评论指出，波音的管理层与工程师之间存在脱节，可能导致安全隐患。
• 许多评论认为，NASA 不应为了维持波音的市场地位而降低安全标准。
• 波音的设计和管理文化被批评为过于关注短期财务利益，而忽视了基本的工程和制造实践。
• 有观点认为，NASA 应考虑将更多资源投入到其他竞争对手，如蓝色起源等，以促进市场竞争。
• 讨论中提到，SpaceX 与波音在测试和开发哲学上存在根本差异，SpaceX 更倾向于通过频繁测试来学习和改进。
• 一些评论认为，波音的工程师在面对管理层压力时，可能会感到无法表达对安全的担忧。
• 有人提到，NASA 在历史上曾因管理层的决策而导致灾难，强调工程师的声音应得到重视。
• 最后，许多评论者对波音的未来表示担忧，认为其在当前市场环境中可能难以维持竞争力。

RLHF is just barely RL #

https://twitter.com/karpathy/status/1821277264996352246

Andrej Karpathy 在推特上讨论了“人类反馈强化学习”（RLHF），并指出它与传统的强化学习（RL）相比，仅仅是“勉强算是强化学习”。他将 RLHF 视为训练大型语言模型（LLM）的第三个也是最后一个主要阶段，前两个阶段是预训练和监督微调（SFT）。

Karpathy 以 AlphaGo 为例，强调了真正的强化学习的强大。他指出，AlphaGo 是通过实际的 RL 训练的，计算机通过玩围棋并最大化胜利的奖励函数来训练，而不是通过 RLHF。如果 AlphaGo 使用 RLHF，它的训练效果将大打折扣，因为 RLHF 依赖于人类评估的“奖励模型”，而这种模型可能会误导。

他进一步解释了使用 RLHF 训练 AlphaGo 的过程：首先需要人类评估者比较两个围棋局面，然后收集大量的比较数据来训练一个“奖励模型”。然而，这种方法存在两个根本问题：一是人类的“感觉”可能并不准确，二是 RL 优化可能会偏离轨道，找到对奖励模型有利但实际上不好的局面。

Karpathy 表示，虽然 RLHF 在 LLM 的构建中是有帮助的，但它并不是真正的 RL。他指出，RLHF 可以利用人类评估者在选择候选答案时的优势，尤其是在一些复杂的任务中。此外，RLHF 还可以帮助减少模型的幻觉现象，因为强大的奖励模型可以惩罚不准确的生成内容。

最后，他强调，迄今为止，在开放领域中，尚未成功实现真正的 RL，因为在开放式问题解决任务中获得实际奖励是非常困难的。他认为，谁能解决这个问题，谁就能在 LLM 中实现真正的 RL，进而在开放领域的任务中超越人类。

https://news.ycombinator.com/item?id=41188647

• AI 编程助手将在未来几年迅速发展，因为编程有明确的奖励函数，而聊天 AI 在处理开放性问题时缺乏清晰的反馈机制。
• 编程的奖励函数并不总是明确，尤其是在需求模糊或变化频繁的情况下，编写规范的过程可能会导致问题。
• 许多优秀的软件是由开发者为自己编写的，而糟糕的软件往往是为他人或不熟悉的需求而开发的。
• 规范的严格定义在用户界面软件中可能是有害的，因为客户的需求常常会变化。
• 生成代码的 AI 需要明确的规范，但人类在编写规范时也会面临不确定性和模糊性。
• LLM（大语言模型）在处理数学定理证明方面可能会表现出色，因为它们能够利用形式验证提供准确反馈。
• 未来的编程可能会变得更加声明式或基于约束，但仍需明确指定所需的属性。
• 目前的 AI 编程助手在复杂性和性能安全性方面仍存在局限性，无法完全取代人类程序员。
• 编程的复杂性和不确定性使得 AI 生成的代码在实际应用中可能需要人类的监督和干预。
• 未来的编程可能会转向测试驱动开发，开发者定义需求和期望，AI 根据这些生成实现代码。

Official proposal for Type Unions in C# #

https://github.com/dotnet/csharplang/blob/18a527bcc1f0bdaf542d8b9a189c50068615b439/proposals/TypeUnions.md

该提案旨在为 C#引入类型联合（Type Unions），也称为区分联合（Discriminated Unions）。以下是该提案的详细中文摘要：

1. 背景与动机 #

在软件开发中，常常需要在一个变量中存储不同类型的值。传统上，开发者可能会使用继承或接口来处理这些情况，但这在某些情况下并不理想，尤其是当类型之间没有明显的继承关系时。使用 object 类型虽然可行，但会导致代码可读性差和类型安全性低。因此，引入类型联合可以更好地处理这些需求。

2. 解决方案 #

提案中提出了四种类型联合的实现方式，以满足不同的使用场景：

• 标准联合类（Standard Union Classes）：适用于那些成员类型可以一起定义的情况，通常用于协议、序列化和 UI 数据模型等。
• 专用联合结构（Specialized Union Structs）：适用于需要避免内存分配的场景，例如在内存块中映射或频繁改变的状态机状态。
• 临时联合（Ad Hoc Unions）：用于从现有的、可能不相关的类型中形成联合，允许灵活的类型组合。
• 自定义联合（Custom Unions）：用于无法通过其他方式定义的联合类型，允许开发者根据特定需求自定义实现。

3. 联合类与联合结构的实现 #

• 联合类：通过类似于枚举的语法定义，允许成员类型持有状态变量。构造和解构通过类型测试和模式匹配实现，且被认为是穷尽的（exhaustive），即在 switch 表达式中不需要默认情况。
• 联合结构：与联合类类似，但所有成员都是结构体，避免了堆分配。联合结构也支持穷尽性和类型测试。

4. 临时联合的实现 #

临时联合是匿名的，使用 (A or B or C) 的语法来定义。它们的构造和解构与联合类和结构相似，且支持穷尽性。

5. 常见联合类型 #

提案中还提出了两个常见的联合类型：

• Option：表示可能存在或不存在的值。
• Result：用于表示函数的成功结果或错误。

6. 相关提案 #

提案还提到了一些相关的功能，如封闭层次结构（Closed Hierarchies）和单例值（Singleton Values），这些功能将与类型联合一起工作，以增强 C#的类型系统。

7. 结论 #

该提案旨在通过引入类型联合来增强 C#的类型系统，使得开发者能够更方便地处理多种类型的值，同时保持代码的可读性和类型安全性。这一特性在其他编程语言中已经得到了广泛应用，因此在 C#中引入这一特性是合乎时宜的。

以上是对 C#类型联合提案的详细摘要。希望这能帮助你更好地理解该提案的内容和目的。

https://news.ycombinator.com/item?id=41183240

• 有人认为 C#引入类型联合是一个积极的进展，能够使语言更接近 F#的功能。
• F#的代数数据类型（ADTs）在类型安全和表达能力上有明显优势，许多开发者希望 C#能借鉴这些特性。
• 一些开发者对 C#逐渐向 F#靠拢表示欢迎，认为这使得 C#开发者更容易接受新特性。
• 也有观点认为 C#的语法应保持独特性，不应过于模仿 F#，以免导致 F#的边缘化。
• 对于新特性的引入，开发者普遍希望能够简化代码，减少复杂性。
• 有人提到 Java 在某些方面已经实现了类似的功能，认为 C#的进步是必要的。
• 讨论中提到，F#的语法优雅且易于使用，许多开发者对此表示怀念。
• 一些评论者认为，C#的类型联合提案需要更多的细节和实际应用示例来支持其必要性。
• 还有人指出，C#的现有特性已经能够通过接口和记录类型实现类似的功能。
• 对于如何学习 F#，有建议认为应同时学习.NET 平台的知识，以便更好地理解 F#的特性。

Raspberry Pi Pico 2, our new $5 microcontroller board, on sale now #

https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new-5-microcontroller-board-on-sale-now/

Raspberry Pi 最近推出了新的微控制器板 Raspberry Pi Pico 2，售价为 5 美元。Pico 2 基于新开发的 RP2350 微控制器，具有更高的核心时钟速度、双倍的内存、更强大的 Arm 核心、新的安全特性和升级的接口能力，显著提升了性能和功能，同时与早期 Pico 系列保持硬件和软件兼容。

主要特点： #

1. 核心与性能：

   • 配备两个 150MHz 的 Arm Cortex-M33 核心，支持浮点运算和数字信号处理（DSP）。
   • 520KB 的片上 SRAM，支持十个并发访问的内存银行。

2. 安全性：

   • 采用 Arm TrustZone 架构，支持签名启动、8KB 的一次性可编程（OTP）内存、SHA-256 加速和硬件真随机数生成器（TRNG）。
   • 设计了全面的安全架构，旨在抵御现代攻击。

3. 接口与扩展性：

   • 提供 12 个升级的 PIO 状态机和一个新的 HSTX 外设，支持高速数据传输。
   • 支持外部 QSPI PSRAM。

4. 封装选项：

   • 提供多种封装选择，包括 7×7mm 和 10×10mm 的 QFN 封装，GPIO 数量从 30 到 48 不等。

生产与可用性： #

Pico 2 目前已在生产中，预计将在未来几周内向经销商发货。预计在年底前推出无线版本 Pico 2 W。

软件与开发支持： #

Raspberry Pi 还发布了更新的 Pico SDK，并提供了新的 MicroPython 和 CircuitPython 镜像。同时，RP2350 也将作为 Trusted Firmware-M 的参考硬件平台，旨在为开发者提供安全设备的开发支持。

安全性挑战： #

为了确保 RP2350 的安全性，Raspberry Pi 正在进行安全架构审计，并提供 10,000 美元的奖金，鼓励发现其签名启动过程中的漏洞。

合作伙伴与生态系统： #

Raspberry Pi 与多家合作伙伴共同开发基于 RP2350 的产品，包括高性能显示器、Arduino 兼容的开发板等，进一步丰富了其生态系统。

总的来说，Raspberry Pi Pico 2 的推出标志着其在微控制器领域的进一步发展，提供了更强大的性能和安全性，适合各种开发和应用场景。

https://news.ycombinator.com/item?id=41192341

• 有人对 Raspberry Pi Pico 2 使用 Micro USB 表示失望，希望能改用 USB-C。
• 认为 Micro USB 的使用可能是因为 Raspberry Pi 基金会希望利用现有的库存。
• 有评论提到，虽然 Micro USB 在某些情况下更可靠，但 USB-C 的普及性和便利性更高。
• 对于新型号的 RISC-V 核心的引入，有人表示期待，同时也有人质疑其是否会影响 ARM 核心的使用。
• 有人提到 RP2350 的 Pico 2 在性能上有所提升，特别是在外部内存支持方面。
• 讨论中提到，RP2350 的 PIO（可编程输入输出）功能相比 ESP32 更具灵活性。
• 有人对数字废物和环境影响表示担忧，认为应更好地利用已有的设备。
• 讨论中提到，未来可能会推出带有无线功能的 Pico 2 W 版本。
• 有人认为，虽然 RP2350 没有内置 WiFi，但仍有许多不需要无线功能的应用场景。
• 对于新产品的定价，有人认为其成本仍然相对较低，适合大规模生产。

Cosmic: A New Desktop Environment #

https://system76.com/cosmic

System76 的 COSMIC 是一个全新的桌面环境，旨在为用户、开发者和设备制造者提供强大的自定义操作系统体验。以下是该页面的详细摘要：

COSMIC 概述 #

• 目标：COSMIC 旨在解放计算机，提供一个强大的桌面环境，允许用户创建独特的操作系统体验。
• 版本：目前为 Alpha 1 版本，尚不完整，欢迎用户反馈 bug 和功能请求。

特性 #

1. 用户体验：

   • COSMIC 是一个模块化的图形用户界面，设计灵活，便于创建个性化的用户体验。
   • 支持 Linux 发行版根据品牌颜色和配置进行定制。

2. 工作流增强：

   • 用户可以自由设置面板位置，使用垂直或水平工作区。
   • 支持多个显示器的独立操作或跨显示器的单一工作区。

3. 窗口管理：

   • 提供自动平铺功能，新打开的窗口会自动排列。
   • 支持“粘性窗口”，重要窗口可以保持在前。

4. 主题自定义：

5. 应用程序：

   • 包括 COSMIC 终端、文件管理器、文本编辑器和应用商店等核心应用。
   • Applets 系统使重要设置易于访问，独立运行，互不影响。

当前进展与未来计划 #

• Alpha 版本已包含大部分日常使用所需的功能，后续将完善设置页面、修复 bug 并进行性能改进。
• 计划中的功能包括无障碍功能、日历集成、窗口动画改进等。

社区与支持 #

• 提供代码访问、开发者聊天、设计系统等资源，鼓励社区参与和贡献。

COSMIC 的目标是通过提供一个灵活且功能强大的桌面环境，提升用户的计算体验，特别是针对 Linux 用户。

https://news.ycombinator.com/item?id=41192303

• 有评论认为 COSMIC 的集成平铺功能是其杀手级特性，尤其适合不想花时间配置的用户。
• 一些用户对 COSMIC 的设计表示担忧，认为其界面缺乏可用性，过于注重美观而忽视用户体验。
• 有人指出，COSMIC 的开发可能会为 Linux 桌面环境带来新的竞争和创新，尤其是在多任务处理方面。
• 评论中提到，COSMIC 的开发基于 Rust 语言，可能会为未来的桌面环境提供更好的基础。
• 一些用户对 COSMIC 的外观表示失望，认为其与现有的桌面环境没有显著区别，缺乏独特性。
• 有评论提到，Linux 桌面环境的设计往往由开发者主导，而缺乏专业设计师的参与，导致界面设计不够理想。
• 一些用户期待 COSMIC 能够提供更好的窗口管理功能，尤其是在多窗口和多任务处理方面。
• 有人认为 COSMIC 的开发是为了填补 GNOME 在用户界面上的不足，提供更灵活的选择。