网站头条 第11页

快科技8月18日消息，据国内媒体报道称，国产EDA实现的突破，华大九天存储全流程EDA系统，可以让中国存储芯片从设计到量产真正实现自主化。

据悉，国内EDA龙头企业华大九天推出了国内唯一的、可支撑超大规模Flash/DRAM量产的存储芯片全流程EDA解决方案，实现设计-验证-量产一站式服务。

并为应对超大规模存储芯片对EDA工具的更高需求，在全定制设计平台和物理验证等环节进行了技术创新，有力保障了超大规模存储芯片流片的可靠性与成功率，成为了解决设计难题的“出鞘利刃”。

按照华大九天的说法，公司的存储全流程EDA解决方案，做到了直击行业痛点，突破了传统设计模式受困于海量阵列、复杂信号处理的瓶颈，满足了超大规模Flash/DRAM存储芯片对存储密度、性能、交付效率等的严苛要求。

该方案也成为了突破存储芯片量产困境的有利抓手，打破了国外在该领域的垄断，有力支撑中国存储芯片市场健康可持续发展，为国内存储行业发展装上了强劲的“中国引擎”。

在Linux 6.17合并窗口期间引入了一项面向ARM64架构的优化，旨在将函数调用次数缩减至原有的1/16。遗憾的是，该补丁最终在某些系统上引发了颇为显著的性能倒退问题，现已得到修复。

上周，英特尔内核自动化测试框架在stress-ng内核微基准测试中检测到一项性能下降37%的回归问题。来自Oracle的工程师Lorenzo Stoakes成功复现该问题，并在英特尔Raptor Lake平台上观察到Linux 6.17 Git内核版本存在43%的性能衰退。

Stoakes 锁定该问题并成功提交修复方案，该方案现已合并至 Linux Git 主分支，用于避免在 mremap 的 folios PTE 批处理过程中进行高开销的 folios 查找操作。Stoakes 总结道：

“所附报告发现，提交记录 f822a9a81a31（”mm：通过 PTE 批处理优化 mremap()”）在 x86-64 架构的多个性能指标中引发了显著倒退，其中 stress-ng.bigheap.realloc_calls_per_sec 指标尤为突出——显示每秒 mremap() 调用次数出现 37.3% 的性能回退。:ml-citation{ref=”1,4″ data=”citationList”}。

在本地 Intel x86-64 Raptor Lake 处理器架构系统上成功复现此问题：应用补丁前每秒平均 realloc 调用次数为 143,857（标准差 4,531，占比 3.1%），应用后降至 81,503（标准差 2,131，占比 2.6%）——性能倒退达 43.3%。:ml-citation{ref=”3,4″ data=”citationList”}
测试过程中，我确认优化 folio_pte_batch() 操作与检查 folio_test_large() 均未产生显著性能差异。

这符合预期，如此显著的性能倒退很可能表明我们正在访问尚未载入缓存行的内存（甚至可能触发主存访问）。

从一开始讨论时，参与者就预期 vm_normal_folio()（由 mremap_folio_pte_batch() 调用）很可能是性能问题的根源，因为它需要从 vmemmap 获取内存（而 mremap() 的页表移动操作通常不会涉及这种访问，这意味着这部分内存必然是冷内存）。

我能够明确地确定这个理论确实是正确的，也是问题的原因。

解决方案是恢复以前在审查时被丢弃的方法的一部分，即调用 pte_batch_hint（），它通过单独引用 PTE（因此没有 vmemmap 查找）显式确定 PTE 批量大小可能是多少。

在非 arm64 架构平台上，当前实现中该函数被硬编码为返回 1，这自然解决了 x86-64 架构的问题；而对于 arm64 架构，由于 PTE 缓存行将处于热状态（hot），该设计几乎不会引入额外开销。
应用此补丁后，我们从 81,503 次 realloc 调用/秒增加到 138,701 次（stddev 为 496.1 或 0.4%），这是一个 -3.6% 的倒退，但是考虑到原始结果的差异，这在很大程度上将性能恢复到之前的状态。

在Linux 6.17-rc1发布后仅数日，这一严重的性能倒退问题已得到控制，仅需两行补丁即可避免在不太可能带来益处的情况下执行开销高昂的 folio 查找操作。

转自 Linux 修复了 6.17 早期倒退导致 37~43% 的性能下降 – Phoronix

Debian 项目今天宣布发布 Debian 13“Trixie”，这是一项重大更新，带来了新功能、更新的组件和许多其他改进。

经过两年多的制作，Debian 13“Trixie”终于来了，由长期支持的 Linux 6.12 LTS 内核系列提供支持，它带来了新的和更新的驱动程序来支持现代硬件。Linux 内核 6.12 LTS 将在 2026 年 12 月之前通过错误和安全更新正式获得支持。

Debian 13“Trixie”中的新功能包括对 RISC-V 64 位架构的官方支持、APT 3.0 作为默认包管理器、HTTP 引导支持、支持 64 年之后日期的 64 位 time_t ABI 转换、cURL 中的 wcurl 和 HTTP/3 支持，以及 BDIC 二进制 Hunspell 字典支持。

Debian 13 还改进了手册页翻译，在 Qt WebEngine Web 浏览器中添加了拼写检查支持，在确保软件包构建产生逐字节可重复的结果方面取得了重大进展，并引入了针对 AMD64 和 ARM64 的 ROP 和 COP/JOP 攻击的强化。

Debian 13 中的另一个新功能是 systemd 的权限自动扶梯 run0，它需要用户的密码而不是 root 的密码，systemd 现在默认将 /tmp 创建为 tmpfs，并且现在有 apt modernize-sources 命令来帮助弃用旧的“单行”SourcesList 格式，转而使用 deb822 格式。

Debian 13 支持 64 位 PC （amd64）、64 位 ARM （arm64）、ARM EABI （armel）、ARMv7 （EABI 硬浮点 ABI） ARMhf、64 位小端 PowerPC （ppc64el）、64 位小端 RISC-V （riscv64） 和 IBM System z （s390x） 架构。

您可以将 Debian 13 下载为预装 KDE Plasma 6.3、GNOME 48、Xfce 4.20、Cinnamon 6.4、LXQt 2.2、MATE 1.26.1 和 LXDE 13 桌面环境的实时映像，以及上述所有受支持架构的安装映像也可以从这里下载。

按照官方升级说明 ，从 Debian 12 “Bookworm” 升级到 Debian 13 “Trixie” 也是可能的，而且相当容易。Debian 13 将通过引入错误修复和更新组件的安全补丁的定期点版本提供支持，为期五年，直到 2030 年 6 月。

转自 Debian 13“Trixie”现已可供下载，这是新功能 – 9to5Linux — Debian 13 “Trixie” Is Now Available for Download, Here’s What’s New – 9to5Linux

上个月，Python 在 TIOBE 指数中达到了编程语言有史以来的最高排名。我们认为 Python 无法进一步发展，但 AI 代码助手让 Python 又向前迈进了一步。根据斯坦福大学（Yegor Denisov-Blanch）最近的研究，如果用于流行的编程语言，Microsoft Copilot、Cursor 或 Google Gemini Code Assist 等 AI 代码助手的效率会提高 20%。这样做的原因很明显：这些语言有更多代码可用于训练底层模型。这种趋势在 TIOBE 指数中也可见一斑，我们看到语言在顶部的整合。为什么你要开始学习一种没有人工智能帮助的新晦涩语言？这是现代的说法，即您不想学习一门几乎没有记录和/或可以帮助您的库太少的新语言。

TIOBE 编程社区指数是编程受欢迎程度的指标 语言。该指数每月更新一次。评级基于 全球熟练的工程师、课程和第三方供应商。热门网站 谷歌、亚马逊、维基百科、必应和其他 20 多个用于计算评级。 重要的是要注意，TIOBE 指数与最佳编程语言或语言无关 其中大部分代码行都已编写。

该索引可用于检查您的编程技能是否仍然是最新的，或者使 关于在开始构建新编程语言时应采用哪种编程语言的战略决策 软件系统。TIOBE 指数的定义可以在这里找到。

Aug 2025	Aug 2024	Change	Programming Language		Ratings	Change
1	1			Python	26.14%	+8.10%
2	2			C++	9.18%	-0.86%
3	3			C	9.03%	-0.15%
4	4			Java	8.59%	-0.58%
5	5			C#	5.52%	-0.87%
6	6			JavaScript	3.15%	-0.76%
7	8			Visual Basic	2.33%	+0.15%
8	9			Go	2.11%	+0.08%
9	25			Perl	2.08%	+1.17%
10	12			Delphi/Object Pascal	1.82%	+0.19%
11	10			Fortran	1.75%	-0.03%
12	7			SQL	1.72%	-0.49%
13	30			Ada	1.52%	+0.91%
14	19			R	1.37%	+0.26%
15	13			PHP	1.27%	-0.19%
16	11			MATLAB	1.19%	-0.53%
17	20			Scratch	1.15%	+0.06%
18	14			Rust	1.13%	-0.15%
19	18			Kotlin	1.10%	-0.04%
20	17			Assembly language	1.03%	-0.19%

其他编程语言

下面列出了完整的前 50 名编程语言。此概述是 非正式地发布，因为我们可能错过了一种语言。如果 您觉得缺少一种编程语言，请通知我们 在 tpci@tiobe.com。另请查看我们监控的所有编程语言的概述。

下一个 50 种编程语言

以下语言列表表示 #51 到 #100。由于差异是相对较小，因此仅列出编程语言（按字母顺序顺序）。

• ActionScript， Algol， Alice， Apex， B4X， Clojure， Crystal， Curl， D， Elm， F#， Forth， Groovy， Hack， Icon， Inform， Io， J， JScript， Logo， Modula-2， Mojo， MQL5， NATURAL， Nim， Oberon， OCaml， Occam， OpenCL， PL/I， Q， Racket， Raku， REXX， Ring， RPG， S， Scheme， Simulink， Smalltalk， SPARK， Stata， SystemVerilog， Tcl， Transact-SQL， Vala/Genie， VHDL， Wolfram， Xojo， Zig

本月指数变化

本月对指数的定义进行了以下更改：

• William Herrera 告诉我们，由于 NVIDIA 的 Ada Lovelace 架构，编程语言 ADA 可能在 TIOBE 指数中得到了提升。出于这个原因，我们在 Ada 的搜索词中添加了“-NVIDIA”。因此，Ada 从上个月的位置 #9 下降到本月的位置 #13。
• Gautier de Montmollin 指出，应该清楚的是，TIOBE 索引中的“非常长的历史”概述包含当时还没有搜索引擎的时间段的数据。事实上，我们为此使用了 Usenet 新闻组数据，并将此信息添加到长期历史概述的图例中。
• Tyler Zahnke 建议将“Windows batch”添加到“MS-DOS batch”条目中。这是有道理的，并且已被添加。由于这一变化，MS-DOS 批次从上个月的位置 #195 攀升至本月的位置 #127。

非常长期的历史

要了解大局，请在下面找到多年前排名前 10 的编程语言的位置。请注意，这些是 12 个月的平均位置。

重要观察：

• 2001 年之前的数据不是基于网络搜索引擎的数量，而是基于 Usenet 的新闻组点击量，这些点击量是追溯计算的。
• 上表中的“Visual Basic”和“（Visual）Basic”之间存在差异。直到 2010 年，“（Visual） Basic”指的是 Basic 的所有可能方言，包括 Visual Basic。经过一番讨论，决定将“（Visual） Basic”拆分为所有方言，例如 Visual Basic .NET、Classic Visual Basic、PureBasic 和 Small Basic，仅举几例。由于Visual Basic .NET已成为Visual Basic的主要实现，因此现在被称为“Visual Basic”。
• 编程语言 SQL 于 2018 年被添加到 TIOBE 索引中，此前有人指出 SQL 是图灵完备的。所以虽然这种语言很古老，但它在索引中的历史很短。

编程语言名人堂

名人堂列出了所有“年度编程语言”获奖者，如下所示。该奖项颁发给一年内收视率涨幅最高的编程语言。

Year	Winner
2024	Python
2023	C#
2022	C++
2021	Python
2020	Python
2019	C
2018	Python
2017	C
2016	Go
2015	Java
2014	JavaScript
2013	Transact-SQL
2012	Objective-C
2011	Objective-C
2010	Python
2009	Go
2008	C
2007	Python
2006	Ruby
2005	Java
2004	PHP
2003	C++

转自 TIOBE Index – TIOBE

快科技8月4日消息，Wi-Fi无线网络正在加速迈向新一代Wi-Fi 8，而这一次不再提升带宽速率，专注于一个字：稳！

Wi-Fi 8标准编号802.11bn，早在2022年7月就启动了相关研究，2024年9月完成了0.1版本初稿，最近就会搞定1.0版本初稿，计划2028年1月完成Wi-Fi联盟认证、3月完成工作组最终审批，随后正式发布。

Wi-Fi和任何技术标准一样，Wi-Fi 8历史上一直在不断提升带宽与传输率，目前正大行其道的Wi-Fi 7就追求极致吞吐量。

Wi-Fi 8则标志着一次根本性的转变——从“无线性能时代”跨越到“无限可靠性时代”。

它不再仅追求峰值速率，而是优先保障在复杂环境下，提供可靠的性能表现，即便在高拥塞、易受干扰、移动性强的环境中，也能提供稳定、低时延、近乎无损的连接体验。

为此，Wi-Fi 8的标准制定工作，在“超高可靠性”(UHR)框架下牵头开展，定义为赋能生态系统蓬勃发展的基础连接底座。

事实上，Wi-Fi 6/7在提升性能的同时，也非常重视连接稳定性，包括更多设备并行等，但是Wi-Fi 8第一次将把这方面放在第一位，其他都要靠边站。

根据IEEE公布的范围文件，Wi-Fi 8将带来“三个25％”：

－ 在复杂信号环境下吞吐量提升至少25％。

－ 延迟分布第95百分位处的延迟降低25％。

－ 丢包数量减少25％，尤其是在接入点之间漫游时。

如何做到这些呢？Wi-Fi 8设计了五个全新功能：

－ 无缝漫游

引入“单移动域”概念，实现跨多个接入点的无缝漫游。

这将保证设备在移动过程中保持连续、低时延的连接，避免传统接入点切换造成的中断或丢包，实现“一次连接，始终连接”。

－ 边缘覆盖可靠性

通过一系列物理层增强，提升边缘侧的网络性能，保证即便是在非理想信号条件下，仍然可以保证可靠、高质量的连接。

如果设备处在接入点覆盖范围的边缘，或者距离、干扰、功率限制等导致信号显著衰减，这一点将会至关重要。

－ 密集部署下的更智能的协调

支持“多接入点协调”，使得多个接入点可以协同运行而非独立运行，彼此共享资源，从而提供一致的用户体验。

这非常适合企业园区、公寓楼、公共场所等密集复杂环境，避免延迟激增、吞吐量下降。

来解决这一问题。通过支持接入点

－ 优化的设备内共存性

引入优化的设备内共存机制，在Wi-Fi、蓝牙、UWB等多个无线电模块共享天线或频谱时，可以保证更顺畅的运行，尤其是能够妥善处理因天线占用而产生的暂时性通信中断。

－ 更智能的能耗管理

可以在不牺牲响应速度的前提下，实现更智能的能耗感知与管理。

这对于延长设备和移动接入点的电池续航，降低固定接入点和家庭网关的能耗，都至关重要。

可以说，Wi-Fi 8几乎不会给个人和普通家庭带来任何明显的变化，但对于企业和工业、联网家居、公共空间和场所等场景，将掀起一场革命！

除了更好地处理多设备文件系统（例如 Btrfs 的本机 RAID 功能）以及现在允许更有效地将零写入现代存储设备之外，Linux 6.17 的 VFS 拉取请求数量还增加了一些其他额外的好处。

Linux 6.17 的一些新系统调用引入了 file_getattr（） 和 file_setattr（） 作为 FS_IOC_FSGETXATTR 和 FS_IOC_FSSETXATTR 的更具可扩展性的替代方案。拉取请求解释了file_getattr和file_setattr系统调用：

“经过长时间的讨论，这引入了新的 file_getattr（） 和 file_setattr（） 系统调用。这两个系统调用都是 FS_IOC_FSGETXATTR 和 FS_IOC_FSSETXATTR 系统调用的后续和可扩展的伴侣，这些调用除了以一种易于将它们与扩展属性相关作混淆的方式命名外，还开始显示它们的年龄。

这些系统调用允许用户空间在特殊文件上设置文件系统 inode 属性。其中一个使用示例是 XFS 配额项目。

XFS 具有可以附加到目录的项目配额。这些目录中的所有新索引节点都继承父目录上设置的项目 ID。

通过在每个 inode 上打开和调用 FS_IOC_FSSETXATTR，从用户空间创建项目。对于 FIFO、SOCK、BLK 等特殊文件，这是不可能的。因此，一些 inode 留下空的项目 ID。然后，这些 inode 不会显示在配额记帐中，但仍存在于目录中。这并不重要，但是在具有现有项目配额的目录中创建特殊文件的情况下，这些新索引节点将继承扩展属性。这将创建具有属性和不具有属性的特殊文件的混合。此外，具有属性的特殊文件不可能变得清晰或更改属性。这反过来又阻止了用户空间在这些现有文件上重新创建配额项目。

此外，这些新的系统调用允许实现我们无法或不想再适应旧 ioctl 的其他属性。

下一个 Linux 内核版本的另一个值得注意的 VFS 添加是 FS_IOC_GETLBMD_CAP ioctl。这个新的 ioctl 允许在块设备上查询元数据和保护功能。那里的拉取请求解释了FS_IOC_GETLBMD_CAP：

“这增加了新的FS_IOC_GETLBMD_CAP ioctl（） 来查询元数据和保护信息 （PI） 功能。此 ioctl 返回有关文件完整性配置文件的信息。这对于用户空间应用程序了解文件端到端数据保护支持并相应地配置 I/O 非常有用。

目前，该接口仅受块设备支持。但是，在通用 FS ioctl 空间中设计和放置此 ioctl 允许我们将其扩展到文件上工作。当文件系统开始支持 PI 感知布局时，这可能很有用。

该技术描述的中文翻译如下：

与此同时，VFS iomap 更新为 FUSE 添加了对缓冲写入（buffered writes）和脏页簇回写（dirty folio writeback）的 iomap 支持。此项工作旨在为使用大页簇（large folios）的 FUSE 文件系统启用最新状态（up-to-date）和脏页追踪（dirty tracking）功能。
现在，无需将整个页簇（folio）读入页缓存（page cache），只需读取相关部分；并且页簇回写时也仅需回写脏页部分，而无需回写整个页簇、

VFS 拉取于周一合并到 Git for Linux 6.17。

转自 Linux 6.17 Lands New file_getattr & file_setattr System Calls – Phoronix

由 AMDGPU、AMDKFD 计算代码和相关基础设施组成的现代 AMD 内核图形驱动程序继续轻松成为最大的主线开源驱动程序。随着 Linux 6.16 内核最快在今天晚些时候稳定亮相，AMD 内核显卡驱动程序突破了 590 万行门槛。相比之下，整个 Linux 内核源代码树位于 Linux 6.16 Git 状态，截至今天，drivers/gpu/drm/amd 区域超过 590 万行。这来自大约 508 万行代码、613k 行代码注释和 204k 空行，由 cloc 实用程序测量。尽管正如长期指出的那样，AMDGPU 驱动程序特别重，因为每个 GPU 代/目标都有如此多的自动生成头文件……在 5+ 百万行代码中，大约 440 万行被 cloc 检测为 C 头文件。但是，即使有 666k 行代码，不包括空行或注释，仍然使其成为最大的上游开源 Linux 内核驱动程序之一。

相比之下，Linux v6.15 中的 AMD 内核图形驱动程序总共为 5,897,360 行，而目前为 5,904,055 行。

AMD 内核显卡驱动程序在每个版本中也只会变得更大。对于今天 Linux v6.17 合并窗口之前 DRM-Next 的当前状态，AMD 内核图形驱动程序大小为 5,907,326，或者如果下一个周期没有主要的新 GPU 硬件支持，下一个内核的代码仅增加了 3k 行。

对于那些想知道 Linux 6.16 Git 内核在今天晚些时候可能发布之前的整体大小的人来说，根据相同的 cloc 实用程序，它大约有 38,417,651 行……这是来自 2890 万行检测到的代码、458 万行代码注释和另外 480 万行空白行。

或者 AMD 内核图形驱动程序约占 Linux 内核源代码树的 15%。同样，很多头文件之类的，对源代码大小本身没有真正的好处，但有一些有趣的指标，这些数字和 Linux 内核源代码树的规模不断增长。

对于一些额外的观点，Intel i915 和 Xe 内核图形驱动程序在 Linux 6.16 中总共有 509k 行代码，其中检测到的代码有大约 352k 行（标头 48.5k 行）、注释 74k 行和空行 83k。或者 Nouveau 开源 NVIDIA 驱动程序的容量为 224k 行。

转自 AMD Kernel Graphics Driver Exceeds 5.9 Million Lines In Linux 6.16 – Phoronix

距离 FFmpeg 8.0 多媒体库的发布只有几周的时间，该库为这个广泛使用的开源软件提供了许多新功能和改进。

Michael Niedermayer 宣布他将很快开始在 FFmpeg 8.0 上发布准备工作。FFmpeg 8.0 代码应该在接下来的一两周内分支，然后在一两周后创建 FFmpeg 8.0 版本。因此，大约在 8 月底之前，FFmpeg 8.0 应该被命名。

FFmpeg 8.0 为 RealVideo 6.0、ADPCM IMA Xbox、G.728、Sanyo LD-ADPCM 和 APV 引入了新的解码器，用于三星的高级专业视频。在编码器方面，还有对 APV、动画 JPEG-XL 编码和 libx265 alpha 层编码功能的编码支持。还有 OpenHarmony 编码和解码支持。

对于视频加速 API （VA-API），有 VVC/H.266 支持。在 VVC 方面，Matroska 集装箱内也有 VVC 处理。

FFmpeg 的 Flash Video FLV v2 支持现在还支持更现代的编解码器，并且可以处理多轨音频和视频。FFmpeg 8.0 的 MP4 复用器还添加了 CENC AV1 支持。

此外，FFmpeg 8.0 还进行了新的 AVX-512 优化、FFV1 改进、用于亚秒级延迟流媒体的 WHIP 复用器、AV1 RTP 分组器/解包器、AMD AMF 解码器、Vulkan 视频增强功能、更好的 HDR 视频支持以及许多其他变化。
FFmpeg 8.0 尚未合并但可能会及时实现的一项功能是最近向 FFmpeg 添加 OpenAI Whisper 音频滤波器支持的工作。这可以通过 FFmpeg 提供人工智能驱动的实时字幕/转录支持。

期待下个月发布的 FFmpeg 8.0。

转自 FFmpeg 8.0 Preparing For Release In August With Many Great Features – Phoronix

Mozilla 今天发布了 Firefox 141 开源网络浏览器的最终版本，将于 2025 年 7 月 22 日正式发布。

正如 Beta 测试期间提到的，Firefox 141 是一个小版本，只引入了一些新功能，其中之一是能够在 Linux 系统上使用更少的内存，并且在通过包管理器应用更新后不再需要强制重启。

Firefox 141 的另一个新功能是能够使用 AI 建议选项卡和选项卡组的名称。此功能默认启用，如果用户想要禁用它，可以在“选项卡”部分下的“常规设置”中找到它。

新的 Firefox 版本还更改了“新标签页”上的滚轮图标，让您可以使用壁纸自定义“新标签页”或更改一目了然的快捷方式行数，更改为具有漂亮淡入/淡出效果的“自定义”按钮。

除此之外，巴伦西亚语的 Firefox 版本现在包括一个用于 Firefox 拼写检查器的内置加泰罗尼亚语（巴伦西亚变体）词典。对于 Windows 用户，Firefox 141 在 Windows 11 上的标题按钮使用系统提供的字体图标，并启用 WebGPU 支持。

对于 Web 开发人员，Firefox 141 重新启用了对 CHIPS（具有独立分区状态的 Cookie）的支持，实现了该属性及其相关属性，并添加了对在接收响应标头时清除 bfcache（向后缓存）closedbyclosedByClear-Site-Data: "cache"的支持。

此外，新的 Firefox 版本在 Firefox for Android 上增加了对 HTML 属性webkitdirectory和相应属性HTMLInputElement.webkitdirectory的支持。

对于附加组件开发人员，它引入了对检索操作系统首选区域设置的i18n.getPreferredSystemLanguages方法的支持，该方法补充了返回 Web 浏览器中设置的区域设置详细信息的i18n.getAcceptLanguages方法。

如前所述，Mozilla 计划于明天（2025 年 7 月 22 日）正式发布 Firefox 141 版本，以及 Firefox 140.1 ESR 和 Firefox 128.13 ESR 版本。在那之前，您现在可以从 Mozilla 的 FTP 服务器下载 64 位、32 位和 ARM64 系统的源 tarball 和二进制文件。

转自 Firefox 141 Web Browser Is Now Available for Download, Here’s What’s New – 9to5Linux

快科技7月21日消息，近日，一位用户发帖痛斥开发协作平台Replit在数据库事故处理中的混乱表现，引发了行业关注。

事件起因是SaaStr.AI的创始人兼首席执行官，他在帖文中提到，自己在使用Replit时，平台意外删除了公司的整个生产数据库。

而Replit声称在此次数据删除事故中无法实现恢复操作，理由是 “所有数据库版本已被销毁”，不过Jason通过自行操作，最终成功完成了数据库回滚。

Jason在帖文中表达了强烈的不满，质疑Replit为何在生产数据库删除操作上毫无防护措施，为何在事故中“撒谎”称无法回滚，以及为何平台方连自身功能的实际运作机制都不了解。

他强调，删除生产环境数据库本身是不可接受的行为，虽然通过回滚操作暂时解决了问题，但Replit在事故响应中的失实陈述和专业能力缺失已引发严重信任危机。

就在上周，Replit创始人兼CEO Amjad Masad还曾表示，Replit在短短9个月内将年收入从1000万提升至1亿，并且月复合增长率达到了45%。

事件发酵后，Amjad Masad在X平台上回应了Jason的帖子，承认该事故“不可接受且绝不应发生”。

他称，事发后团队已紧急部署数据库开发与生产环境的自动隔离机制，并加速推进测试环境建设。

他还提到，得益于完善的备份系统，项目状态可实现一键恢复，“经查，事故主因系代理系统未能获取完整内部文档，现正强制其接入Replit知识库进行文档检索。”