首页 文章 精选 留言 我的

精选列表

搜索[静默安装],共10029篇文章
优秀的个人博客,低调大师

CherryPy 框架静默更新至 18.9.0 版:回顾其过去影响与特有优势

近日,Python的CherryPy框架悄然发布了新的18.9.0版本。虽然近年来,CherryPy在众多热门框架如Flask、FastAPI以及老牌劲旅Django的光芒下逐渐淡出了人们的视线,但它曾在国内乃至全球范围内广受欢迎,并受到了许多专业人士的推崇,其中包括著名的Python开发者Limodou。 尽管如此,它仍保留了一些独特的优点,使得它在特定场景下具有不可替代的价值。 首先,CherryPy作为一个纯Python编写的WSGI服务器,可以直接在生产环境中运行,无需额外配置其他的服务器软件。相比之下,Flask框架则提醒用户自带服务器只能用于开发和测试,需要用户自行选择合适的生产环境服务器。 其次,CherryPy支持在Windows操作系统上运行,这给那些在Windows环境下工作的开发者提供了便利。而一些新兴框架如FastAPI可能并不支持Windows平台。 最后,尽管CherryPy并非异步框架,但其性能在非异步框架中一直名列前茅。相较于重量级的Django,CherryPy更加轻巧,处理请求的速度更快。 总的来说,尽管CherryPy在近年来的关注度有所下降,但它依然拥有一些不容忽视的优点。对于那些寻找稳定、可在Windows环境下运行且性能良好的Web开发框架的开发者来说,CherryPy或许是一个值得考虑的选择。

优秀的个人博客,低调大师

OpenAI Codex CLI 被曝致命 Bug,静默写入日志直至耗尽 SSD 寿命

近日关于 OpenAI 的一条新闻在开发者社区中炸开了:OpenAI 自家的 Codex CLI 工具被发现了一个「烧硬盘」级别的 bug——它在后台以每秒约 5MB 的速度持续向本地 SSD 写入日志数据,按此速率计算,一年可写入约 640TB,足以在不到一年的时间内耗尽一块普通消费级固态硬盘的全部写入寿命。 这个 bug 最早可以追溯到今年 4 月。GitHub 用户 1996fanrui 在 6 月 14 日通过 issue #28224 详细记录了他的发现:他的机器在 Codex 运行的 21 天内,主硬盘被写入了约 37TB 的数据。经过排查,罪魁祸首锁定在 ~/.codex/logs_2.sqlite 这个 SQLite 数据库文件上。Codex 的日志系统被配置为以 TRACE 级别运行——这是日志等级中最详细的一档,它会记录几乎所有底层事件的诊断信息,从原始的 WebSocket 数据包到 passwd 和 ld.so.cache 等系统文件的打开事件,无一遗漏。 问题的隐蔽之处在于,这个 SQLite 文件并不会膨胀到一个令人警觉的大小。Codex 的日志系统采用的不是追加写入,而是一个持续「写入-删除-再写入」的循环模式,每分钟执行数万次插入和删除操作。这意味着仅从文件管理器里看这个文件的大小,你不会发现任何异常。但在这平静的表象之下,闪存芯片的实际写入量在飞速累积。 更糟糕的是,Codex 完全忽略了 RUST_LOG 这个标准环境变量——也就是用户自始至终没有任何简单的方法来调低日志级别,除非手动去修改源码。据分析,该日志系统的 SQLite sink 是在 PR #12969 中引入的,当时直接将全局日志级别设为了 TRACE,这个配置显然是为内部开发调试设计的,却在没有任何调整的情况下被推送给了所有终端用户。 从存储技术角度看,这个 bug 的破坏力不仅来自写入量大,还来自 SQLite 的 WAL(Write-Ahead Log)机制造成的写入放大效应。每次数据库事务不仅写入主数据库文件,还会写入 WAL 文件和回滚日志,实际的物理写入量远大于数据库文件本身的增量。再加上每分钟数万次的插入-删除循环,闪存转换层(FTL)的垃圾回收和磨损均衡算法也在承受额外的压力。用户即使通过 SMART 工具监测到了写入量异常,也很难第一时间将其归因于 Codex,因为操作系统并不直接显示单个进程对存储硬件的累积写入量。 衡量一下这个写入量的实际意义。一块典型的 1TB 消费级 NVMe SSD 的 TBW(总写入字节数)额定值大约在 600TB 左右。Codex 以 5MB/s 的基线速度写入,峰值可达 16MB/s,一年累计约 640TB。换句话说,如果你每天使用 Codex 进行较长时间的编码工作,你的 SSD 可能在不到一年时间内就被写入寿命耗尽。而 SSD 寿命耗尽的表现不是缓慢降速——它可能在某次写入操作中突然变为只读模式或彻底无法识别,导致数据丢失。 GitHub 上的开发者社区反应迅速而激烈。社区将此描述为「核攻击级别的磁盘写入」,并警告所有重度使用 Codex 的开发者检查自己的硬盘 SMART 数据。一位用户在 issue 评论中写道:「这是一个非常严重的 bug——在 Linux 机器上,如果系统在磁盘已满的状态下重启,不仅会导致登录失败,Codex 在 /goal 模式中还会主动删除磁盘上的文件和文件夹,试图腾出空间。」另一个评论直接表达了挫败感:「WTF,这太荒谬了,请对你们的用户多一点尊重。」 OpenAI 的响应速度在这个案例中倒不算慢。OpenAI 研究员 Vaibhav Srivastav 对外表示该问题已经在新版本中修复,敦促所有用户立即升级。6 月 22 日,两个修复相关的 PR(#29432 和 #29457)被合并到主分支,核心改动是将 SQLite 日志的默认级别从 TRACE 降至更合理的 INFO,据反馈可以减少约 85% 的日志写入量。剩余的写入是否仍在持续损害 SSD 寿命,社区仍在关注。 值得留意的是,类似的 SQLite 稳定性问题在此前的更新日志中曾被提及过多次,但写入速率的核心问题一直未被触及——issue #17320、#24275、#22444 等相关报告从 4 月起就陆续出现,直到 1996fanrui 的 issue #28224 用精确的数值(21 天 37TB)量化了问题的严重性,才引发了足够的公众关注。 在等待官方补丁推送的期间,社区摸索出了一个临时缓解方案:将 ~/.codex/logs_2.sqlite 软链接到 /tmp 目录下。由于 /tmp 在多数 Linux 和 macOS 系统中是挂载在内存上的 tmpfs,写入操作不会影响物理硬盘。这个文件不包含任何用户对话数据,因此在重启时丢失并不会造成任何实际损失。 这个事件也提醒了开发者社区一件更根本的事情:随着 AI 编码助手从辅助工具逐渐演变为日常开发环境的一部分,它们获得的系统权限和数据访问范围也在扩大。一个普通的代码编辑器通常不会以每秒 5MB 的速度向你的硬盘写入日志。但当 AI 编码助手需要读取你的项目文件、监听文件系统变化、建立代码索引、记录 WebSocket 通信时,它实际上已经变成了系统中最活跃的进程之一。尤其在 /goal 模式下,Codex 拥有文件系统的完整读写权限和自主决策能力——一个日志级别配置错误,就足以让一个强大的自动化工具变成硬件杀手。 参考来源: Reddit: OpenAI Codex has a bug that could kill your SSD in under a year Notebookcheck: OpenAI Codex has a bug that could kill your SSD in under a year GitHub Issue #28224: Codex SQLite feedback logs can write ~640 TB/year https://x.com/reach_vb/status/2069202270168772997

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册