首页 文章 精选 留言 我的

精选列表

搜索[策略引擎]，共10000篇文章
优秀的个人博客,低调大师

hadoop主节点（NameNode）备份策略以及恢复方法

link:http://jiajun.iteye.com/blog/809125 一、dits和fsimage 首先要提到两个文件edits和fsimage，下面来说说他们是做什么的。 集群中的名称节点（NameNode）会把文件系统的变化以追加保存到日志文件edits中。 当名称节点（NameNode）启动时，会从镜像文件 fsimage 中读取HDFS的状态，并且把edits文件中记录的操作应用到fsimage，也就是合并到fsimage中去。合并后更新fsimage的HDFS状态，创建一个新的edits文件来记录文件系统的变化 那么问题来了，只有在名称节点（NameNode）启动的时候才会合并fsimage和edits，那么久而久之edits文件会越来越大，特别是大型繁忙的HDFS集群。这种情况下，由于某种原因你要重启名称节点（NameNode），那么会花费很长的时间去合并fsimge和edits，然后HDFS才能运行。 二、Secondary NameNode 目前使用的版本hadoop-0.20.2可以使用Secondary NameNode来解决上面的问题。Secondary NameNode定期合并fsimage和edits日志，把edits日志文件大小控制在一个限度下。因为内存需求和NameNode差不多(On the same order)，所以Sencondary NameNode通常要运行在另外个机器上。 secondary NameNode配置在conf/masters文件，启动命令:bin/start-dfs.sh（如果你使用不建议的start-all.sh也是会启动的）。 三、什么时候checkpiont secondary NameNode 什么时候执行checkpoint来合并fsimage和eidts。呢？有两个配置参数控制： fs.checkpoint.period 指定两次checkpoint的最大时间间隔，默认3600秒。 fs.checkpoint.size 规定edits文件的最大值，一旦超过这个值则强制checkpoint，不管是否到达最大时间间隔。默认大小是64M。 secondary NameNode 保存最后一次checkpoint的结果，存储结构和主节点（NameNode）的一样，所以主节点（NameNode）可以随时来读取。 如果你没有启动secondary NameNode 那么可以试试 bin/hadoop secondarynamenode -checkpoint 甚至 bin/hadoop secondarynamenode -checkpoint force. 看看生成的文件。 checkpoint可以解决重启NameNode时间过长的弊端。另外还有偏方： 四、Import Checkpoint（恢复数据） 如果主节点挂掉了，硬盘数据需要时间恢复或者不能恢复了，现在又想立刻恢复HDFS，这个时候就可以import checkpoint。步骤如下： 拿一台和原来机器一样的机器，包括配置和文件，一般来说最快的是拿你节点机器中的一台，立马能用（部分配置要改成NameNode的配置） 创建一个空的文件夹，该文件夹就是配置文件中dfs.name.dir所指向的文件夹。 拷贝你的secondary NameNode checkpoint出来的文件，到某个文件夹，该文件夹为fs.checkpoint.dir指向的文件夹 执行命令bin/hadoop namenode -importCheckpoint 这样NameNode会读取checkpoint文件，保存到dfs.name.dir。但是如果你的dfs.name.dir包含合法的fsimage，是会执行失败的。因为NameNode会检查fs.checkpoint.dir目录下镜像的一致性，但是不会去改动它。值得推荐的是，你要注意备份你的dfs.name.dir和 ${fs.checkpoint.dir}/dfs/namesecondary。 五、Checkpoint Node 和 Backup Node 在后续版本中hadoop-0.21.0，还提供了另外的方法来做checkpoint：Checkpoint Node 和 Backup Node。则两种方式要比secondary NameNode好很多。所以 The Secondary NameNode has been deprecated. Instead, consider using the Checkpoint Node or Backup Node. Checkpoint Node像是secondary NameNode的改进替代版，Backup Node提供更大的便利，这里就不再介绍了。 切换namenode之后发现 进入的安全模式如下 $ hadoop dfsadmin -report Safe mode is ON 解决方案有两种 1）执行命令：bin/hadoop dfsadmin -safemode leave dfsadmin -safemode value 参数value的说明如下： enter - 进入安全模式 leave - 强制NameNode离开安全模式 get - 返回安全模式是否开启的信息 wait - 等待安全模式结束。 2）bin/hadoop fsck / 第一种方法，需要每次都执行一遍，很纠结~ 第二种方法，如果数据多，那执行起来会很慢，没办法，慢慢等吧。 [hadoop@vm×× name]$ hadoop fsck / FSCK started by hadoop (auth:SIMPLE) from /×.×.×.× for path / at Thu Apr 16 15:31:10 CST 2015 ..Status: HEALTHY Total size:109836279 B Total dirs:10 Total files:2 Total blocks (validated):2 (avg. block size 54918139 B) Minimally replicated blocks:2 (100.0 %) Over-replicated blocks:0 (0.0 %) Under-replicated blocks:0 (0.0 %) Mis-replicated blocks:0 (0.0 %) Default replication factor:1 Average block replication:1.0 Corrupt blocks:0 Missing replicas:0 (0.0 %) Number of data-nodes:4 Number of racks:1 FSCK ended at Thu Apr 16 15:31:10 CST 2015 in 4 milliseconds The filesystem under path '/' is HEALTHY 本文转自茄子_2008博客园博客，原文链接：http://www.cnblogs.com/xd502djj/p/4425990.html，如需转载请自行联系原作者。
2017-08-03
优秀的个人博客,低调大师

无线可穿戴产品致胜设计六大策略

当美国漫画家Chester Gould在Dick Tracy的手腕上画出手表图案时，他一点也没有意识到，科幻小说能在70年后变为现实。作为一名连环画画家，Gould想象出未来设备，却没有考虑太多细节。如今，这些非常真实的腕上设备和其他无线可穿戴设备(WWD)为工程师带来一系列他们必须克服的设计细节挑战。工程师必须在经济实惠、引人注目、超紧凑的设计中无缝集成复杂的传感、处理、显示和无线技术，且可在单一、小巧和具有成本效益的电池供电下工作数个月，甚至数年。下面让我们一起来讨论对于可穿戴设备、技术和组件选择的具体需求，以及如何在超小的外形尺寸中实现复杂功能、长电池使用寿命和无缝无线连接。 在可穿戴产品设计中，工程师必须考虑三个关键因素：各种操作模式下的功耗(节能)、从匹配电路到天线之间的适当RF设计、以及设计中器件的集成度。我们将更详细的讨论集成所面临的挑战，因为很难在不考虑功耗和RF设计的情况下独立讨论这个因素。 大多数无线可穿戴设备涵盖共同的组件，包括电池、天线、微控制器(MCU)、无线电和传感器。从这个名单上看，显而易见，电池将在很大程度上影响可能实现的功能和WWD的工作寿命。考虑到电池电量将会快速耗尽，大多数WWD并非一直保持连续的数据传输，因此通常我们假设通信是突发的和偶发的。此外，集成了无线电的MCU，通常被称为无线MCU(WMCU)，它使用方便、节省电路板面积并且降低了功耗，因此我们也假设在可穿戴设计中采用WMCU。 为应用选择合适的WMCU是一项复杂的决策过程，因为对于功能丰富的设备的高功能性将受到电池操作寿命的限制。如果我们仅仅关注WMCU的峰值功耗，那么从电池寿命这一单一因素来看，评估结果是相当令人失望的。然而，WWD通常工作在多种不同的能耗模式(EM)，并且仅在极少情况下进入高功耗状态。因此，通过考虑在各种能耗模式中所花费的时间，我们可以评估电池的实际使用寿命。 Silicon Labs为其基于ARM架构的EFM32 MCU定义了5种能耗模式：EM0(活动/运行)、EM1(休眠)、EM2(深度休眠)、EM3(停止)和EM4(关闭)。这5种模式使得设计人员能够灵活的决策和优化系统的整体功耗。然而，能够识别这些模式以及数据手册中的规格数据并不能确保“在各种模式下都获得低功耗”，或者简单的说，不能确保“节能”。确保节能并发展良好的终端客户体验是构建WMCU可运行于这些不同模式的方法。事实上，依赖于突发传输之间的时间间隔，活动模式EM0可能仅占整体功耗中极小比例。而深度休眠模式EM2所占用的时间可以代表电池使用寿命的最大比例。 当为应用选择最佳WMCU时，工程师应当关注以下特性，包括可提供高集成度、具有良好架构的低功耗WMCU。超低功耗WMCU的一些特性无需多说，但也应被完整的列出： ●最低运行功耗(EM0) ●最低待机电流(EM1和EM2) ●微处理器内核的选择，包括8位和32位ARM Cortex(从M0+到M4) ●无线电配置选择，包括单收、单发、收发一体和性能等级 其他MCU特性，包括相关架构和集成度，同样重要而且需要进一步说明： ●极短的唤醒时间 ●自主的外设操作 ●自主的外设间操作(外设反射系统) ●低能耗传感器接口(LESENSE) ●丰富的高能效外设和接口 ●RF集成 最低待机电流和极短唤醒时间 当打算设计一个尽可能节能的无线可穿戴设备时，人们必须要想到所有可能的功耗优化办法。当设备唤醒时，它必须要尽可能快，如：尽可能快的收集和处理数据，然后尽可能快的返回到休眠模式。确保在休眠模式和活动模式之间快速转换是一项必须要考虑到的关键要素。一个处理器在活动模式所花费的时间即使仅比另一个处理器多出10%，那么对电池寿命的影响也是巨大的。例如，假设处理器1花费99.9%的时间在休眠模式(1μA)，0.1%的时间在活动模式(10mA)，同时处理器2花费99.89%的时间在休眠模式，0.11%的时间在活动模式，那么第二个处理器的整体电流消耗将增加9.1%。有趣的是，如果处理器1和2在每6小时中分别处于活动模式100ms和110ms，那么其结果就会突显出极低的深度休眠电流的重要性。在这种情况下，第二个处理器只比第一个多消耗0.44%的电量。然而，如果处于活动模式的时间相同，并且把深度休眠电流从1μA增加到1.1μA，那么电流消耗将上升9.6%! 自主的外设操作 取决于可穿戴设备的功能特性，可能需要对片上外设进行频繁、甚至持续的交互或监视。在这种情况下，CPU在这些时间内要保持活动的需求将导致电池电量的消耗非常明显。确保片上拥有无需CPU参与的自主操作能够使系统运行在低能耗模式的同时，仍然能够执行非常高级的任务。这些外设可包括串行接口(例如，低能耗UART、免晶体USB)、I/O端口(例如，外部中断、GPIO)、定时器和触发器(例如，低能耗定时器、低能耗传感器接口)、模拟模块(例如，ADC、LCD控制器)和安全(例如AES加速器)。 自主外设之间的操作(外设反射系统) 也有一些情况，外设之间可能需要进行通信。在这些情况下，一个外设需要能够产生一个或者多个能够立刻被另一个片上外设所感应到的事件。例如，一个定时器能够被设定创建一个事件，然后触发一个ADC开始采样。在外设之间使能自主的操作，无需唤醒CPU，能够确保获得最低的系统功耗。这种能力是Silicon Labs EFM32 MCU架构的一个关键特性，被称为外设反射系统(Peripheral Reflex System)。 低能耗传感器接口(LESENSE) 最终当CPU需要被唤醒以执行特定任务时，大多数MCU被设置为在一系列特定时刻上唤醒，并监视它的接口，如果没有动作需要，它将返回到休眠模式。这些定期唤醒循环产生了不必要的电池能量消耗。EFM32 MCU采用的LESENSE架构允许对模拟传感器(电阻式、电容式和电感式)进行自主监测，仅仅在相关事件或者条件满足时才唤醒CPU，就跟其他事件处理一样。例如，LESENSE能够被设置去自主的监测一个温度传感器，仅仅超过可编程的99华氏度门限时才通过外设反射系统唤醒CPU采取动作。因此，使用LESENSE能够最小化CPU使能的时间，当不得不消耗最大功耗时，尽可能的缩短最大功耗时的运行时间。 丰富的高能效外设 开发一个在各种操作模式下都尽可能减少能耗的可穿戴设备需要仔细审查MCU的各个运行方面。虽然我们已经讨论了外设的自主操作，但我们还需要进一步讨论外设本身的低功耗需求。如果外设本身功耗极大或者如果时钟在非必要情况下使能，那么自主操作起到的作用也会非常小。 就外设本身而言，时钟管理单元对于MCU或者WMCU整体功耗起着重要作用。时钟管理单元可以对多种时钟和振荡器进行单独控制，并且基于操作所采用的功耗模式和使能的外设进行最优化时钟选择。使用低能耗振荡器结合灵活的时钟控制方案，能够尽可能的最小化应用中的功耗。高能效的时钟管理单元包括低电流振荡器、低启动时间、动态系统时钟分频、时钟门控、以及用于32kHz外设模块和时钟预分频器。 低能耗自治UART的有效性对于获得超低系统功耗也是同等重要的，尤其是在深度睡眠(EM2)模式，这时大多数其他外设与CPU都处于关闭状态。UART应该包括必要的硬件支持来最小化异步串行通信中的软件干预。通过使用32.768 kHz时钟源，低能耗的UART可支持高达9600 baud/s，并且当完成UART帧接收后，可以快速唤醒CPU。 当设备的大部分部件处于断电状态时，低能耗定时器能够被用于定时和输出，因此允许在执行简单任务的同时保持系统功耗绝对最小值。如果适当配置，这种定时器能够提供高达16kHz频率(32kHz振荡器频率的一半)的无差错波形。 对于MCU或者WMCU中的模拟资源，例如ADC、DAC、LCD控制器、模拟比较器和其他外设，应当仔细分析它们的功耗和灵活性。例如，12位1Msps ADC在全速时可消耗350μA，但是并非所有应用都需要运行在这种速率下。在仅需要6位、1ksps的应用中，这时ADC仅消耗0.5uA，功耗显著减少了。LCD控制器应当能够在没有任何CPU干预下运行定制动画，并且仅仅是更新数据时才唤醒CPU。 加密占用非常大的片上资源，且显著消耗电池电量。最低成本的8位MCU通常需要把安全逻辑作为运行时代码来执行，而32位MCU最可能包括一个AES加速器。当硬件AES加速器可用时，它应当有能力在无需CPU参与下自主运行，并且应当包括支持自治密码模式的DMA以最小化电池消耗。 RF集成 以上的讨论内容主要集中在MCU架构之内。然而，其他与无线收发器相关的特性也应当关注。基于应用需求，无线可穿戴设备可能从不需要接收信息，但是多数设备需要在一些时候发射数据。电池供电设备的低功效放大器会显著增加系统功耗，并且使应用增加电池尺寸和成本以满足系统运行寿命的需要。例如，长距离通信设备可能需要RF有+13dBm、16dBm或甚至+20dBm等级别输出功率。虽然在WMCU中集成+10dBm RF功率放大器(PA)是普遍存在的，但是如果应用需要更大输出功率，那么就需要片外的三极管或者放大器。问题是对于创建低成本且切实可行的解决方案来说，这些片外助推器是无益的，因为解决方案既要满足高效又要低成本。因此，在要求长距离和/或者频繁通信的应用中，效率和电池寿命通常与获得具有竞争力的成本目标是矛盾的。克服这个问题的一种方法是确保WMCU中集成适当大小的PA，甚至最大可达+20dBm。通过在WMCU设备中集成PA，PA的电流消耗能够被最小化。归功于PA输出和助推放大器之间的适当匹配，以及发射链的安全设计对温度和电压变动的补偿，因此没有损耗。一个完全集成的PA使得PA操作得以完全控制，确保获得最低功耗。 许多应用运行于2.4GHz频段，这种情况下，IC供应商有机会可以通过集成匹配电路和提供单端RF输入输出来简化系统设计。Sub-GHz应用倾向于覆盖非常宽的频率范围，从数百MHz到1GHz。在这些情况下，集成匹配组件是不现实的。然而，在WMCU中集成通常片外使用的被动器件，并且由于对于分离实现方案有成本优势，因此在大多数流行的频段应用中是可行的。 最后，我们在无线可穿戴设备中还没有讨论的是天线发射和接收特性。由于尺寸和成本限制，大多数无线可穿戴设备的天线发射特性一般都较差，因为它们通常简单的把天线打印在PCB板面材料上(像FR4)。为了补偿天线损耗或低增益，最简单方法是增加RF输出功率来获得期望的输出功率。不幸的是，如前面所讨论的，这个发射器将比那些天线已经被优化过的发射器消耗更大的能量。更好的设计和更低的匹配电路损耗将是最优化操作的保证，但是天线设计具有极大的设计难度，特别是当考虑到可穿戴设备所处不断变化的RF环境时。由靠近终端用户身体(例如手覆盖到设备上时)而产生的不匹配波动能够引起许多问题。一些WMCU设备，例如Silicon Labs的Si4010“片上遥控器”发射器，有集成的天线调谐电路，能够在这些时候动态的补偿天线。这种电路起着非常重要的作用，不仅控制功耗，而且也确保无线电辐射保持在法规限定范围之内。 一种补偿较差天线接收性能的方法是把系统设计成天线分集接收，即采用多天线。虽然许多应用将从实施天线分集中获益，但也有一些因素需要考虑。首先，天线分集倾向于帮助那些在发射端和接收端之间的距离上有如此情况的：接收到的信号水平接近背景噪声水平(即接近链路覆盖范围的边沿)，或者由多径传输或物体遮挡而产生的衰落传输环境。 为了降低功耗和芯片成本，WMCU IC通常仅集成一条接收路径，因此天线分集必须通过一个片外天线开关进行切换，以便在两个天线之间交替选择。然而，由两个天线共享一条接收路径的方案可能比人们预期消耗更多的功耗。因为在这种情况下，发射的前导符长度必须被扩展，以便为两个天线按顺序进行评估提供足够的时间。为分析和选择最佳天线，也增加了计算成本和电流消耗。 最后，还有一个间距问题。在无线通信系统中天线之间的距离被推荐为波长(λ)的整数倍或分数倍，最小间距是1/4λ。在2.4GHz，波长为125mm，依据最小间距λ/4或31.25mm的分离天线设计在一些无线可穿戴设备内是可行的。然而，对于工作在Sub-GHz频段的WWD来说，克服这种挑战将变得极其困难。在868MHz频段，天线应当被保持最小86mm的间距，这导致在许多WWD应用中无法使用天线分集。 因此，工程师必须在改善传输距离和接收性能与增加复杂性和尺寸、计算成本和电流消耗之间进行权衡。假设天线分集不是问题，增加的计算成本和相应的功耗能被克服。那么，在变化的和非同步的环境中，定期的在天线间进行切换也是需要的，因为无线电在信息包到达前不知道哪个天线能够实现更好的接收效果。Silicon Labs的EZRadioPRO收发器拥有集成的前导符质量检测器以基于RSSI值来决定信号质量，并确认有效信息包到达两个天线。集成检测器的好处是它能够选择最佳的天线，卸载MCU负担，从而也在选择过程中减少整体功耗。 总结 如果今天Chester Gould依旧健在，那么他肯定印象深刻，他的想象力已被大大超越。众多公司已经推出了远远超过Dick Tracy具有无线电话功能的腕表设备，并且正在开发各类更先进的可穿戴设备。然而，当设计人员试图集成更多特性和功能到无线可穿戴设备时，底层的关注点几乎总是相同的——如何获得更低的功耗、如何在设计中适应小的外形尺寸、如何确保设备具有可靠的无线通信。而且最终的关切点将是如何以尽可能低的价格获得这些产品设计目标，但是那是我们的另一个话题…“Six-two and even，over and out”。 作者：何妍 来源：51CTO
2017-07-31
优秀的个人博客,低调大师

开源游戏引擎 Godot 4.6.3 发布

Godot 4.6.3 现已发布，这是一个维护版本。共有 41 位贡献者提交了 86 项修复，一些更新内容如下： 2D：在检查器中修改TileMap时更新图层选择器（GH-117256）。 3D：修复 Marker3D 编辑器小工具在负轴线上比预期更暗的问题（GH-116995）。 3D：修复GridMap在编辑器中粘贴单元格时旋转错误的问题（GH-116683）。 Animation：修复 SplineIK 崩溃情况（GH-117959）。 Buildsystem：2026 年 Android 版本年度更新（GH-113761）。 C#：防止 SourceGenerators 成为传递依赖项 (GH-114868)。 Core：Android：修复模板构建中的--main-pack使用（GH-119495）。 Core：Debugger：与其无限循环处理数据读取错误，不如断开连接（GH-113905）。 Core：修复RefCounted::unreference()中的竞争问题 (GH-118678) 。 Core：提高Object信号的线程安全性（GH-117511）。 Editor：避免资源收集中的重复（GH-118926）。 Editor：当缓存未初始化时，不要打印 UID 错误（GH-118527）。 Editor：修复并改进编辑器布局对话框（GH-117846）。 Editor：修复游戏重新启动时游戏速度 UI 未重置的问题（从编辑器）（GH-116568）。 Export：iOS：修复 Xcode 26 的一键部署问题（GH-118559）。 GUI：修复鼠标悬停时 TextEdit IME错误（GH-111859）。 GUI：RTL：修复表格后的字符点击偏移量（GH-117011）。 Import：替换导入实例时复制场景唯一 ID (GH-118522)。 Input：Android：修复目标 API level 36 时对返回导航的处理（GH-117653）。 Input：修复了Input.get_joy_info()中对 joypad UTF-8raw_name读取错误的问题（GH-115218）。 Physics：修复使用 Jolt 时过度移除区域重叠的问题（GH-118285）。 Rendering：添加项目设置以禁用新的 Volumetric fog blending行为（GH-119414）。 Rendering：修复 GLES3 批处理跳过渲染特定缓冲区大小的所有项目的问题（GH-117725）。 Rendering：修复 LightmapGI 探针更新速度设置未在 Compatibility 中应用的问题（GH-117771）。 Rendering：在 GLES3 和移动渲染器上为每个网格选择相关的 3D 灯光（GH-107234）。 更多详情可查看：https://godotengine.org/article/maintenance-release-godot-4-6-3/
2026-05-22
优秀的个人博客,低调大师

开源游戏引擎 Godot 4.6.2 发布

Godot 4.6.2 现已发布，这是一个维护版本。共有 61 位贡献者为本次版本提交了122 项修复，一些更新内容如下： 3D：修复子控制块的 3D focus 选择（GH-116972）。 3D：修复 DirectionalLight3D 属性列表（GH-117189）。 Animation：发射animation_finished信号后检查playback_queue是否存在（GH-116676）。 Animation：切换动画时取消选择 bezier keyframes（GH-116953）。 Animation：修复标记选择期间时间线光标跟随鼠标的问题（GH-117634）。 Animation：修复选择期间动画编辑器关键帧的视觉偏移（GH-117290）。 Core：修复空字符串导致的String::split_崩溃（GH-117353）。 Core：修复复制实例化节点时可编辑子节点的状态（GH-117041）。 Core：RingBuffer：修复T read()方法读取空缓冲区的问题（GH-117388）。 Editor：修复构建配置文件生成器生成无效配置文件的问题（GH-115410）。 Editor：修复暂停和停止后静音按钮的问题（GH-116537）。 Editor：修复 Window 子类的主题项检查器工具提示（GH-115245）。 Editor：在编辑时设置 Tree 内联单元格编辑器的辅助功能名称（GH-117135）。 Editor：默认情况下停止自动补全功能吞噬单词（GH-117464）。 Export：Android Editor：导出期间将密钥库复制到临时文件（GH-116161）。 GDExtension：在MovieWriter中添加缺失的GDVIRTUAL_BIND(_get_supported_extensions)（GH-117479）。 GUI：修复双击后 RichTextLabel 拖动选择不起作用的问题（GH-117201）。 Import：Blender 尝试次数应递增，以避免无限循环（GH-116589）。 Physics：Jolt Physics：在以非常小的角度旋转物体时，提高 MoveKinematic 的精度（GH-115327）。 Physics：Jolt Physics：重新设计重力如何应用于动态物体，以防止弹性碰撞时能量增加（GH-115305）。 Platforms：Android：修复在 Gradle 构建的应用程序中使用 treeUri 时 FileAccess 崩溃的问题（GH-117131）。 Platforms：修复 macOS Steam 打开项目时丢失时间跟踪的问题（GH-117335）。 Platforms：iOS：添加 UIScene 生命周期事件（GH-116395）。 Platforms：iOS：将 VC UI 首选项传播到 SwiftUIhosting controller（GH-116633）。 Platforms：macOS：如果Magnet正在运行，则启用事件唤醒（GH-116524）。 Platforms：Windows：当 ANGLE 初始化失败时设置当前驱动程序（GH-117253）。 Rendering：正确应用固定尺寸进行单声道/立体渲染（GH-115147）。 Rendering：修复画布渲染器中意外的写合并内存读取（GH-115757）。 Rendering：修复计算顶点蒙皮时切线解码检测的问题（GH-117401）。 Rendering：macOS：在虚拟机中运行时强制使用 ANGLE（GL over Metal）（GH-117371）。 此版本基于commit001aa128b构建。 更多详情可查看：https://godotengine.org/article/maintenance-release-godot-4-6-2/
2026-04-07

资源下载

更多资源
腾讯云软件源

腾讯云软件源

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

时间: 2026-08-21 大小: 1MB 下载: 10次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

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

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册