=编译环境里写的支持本地给的判题脚本写的-std=c++11：我用了一些c++17的特性，在本地改了编译选项过了，但是线上又编译通不过了，线上不能看报错也不能确定到底咋回事。请问到底能不能用c++17的特性

如果初始状态就已经是分离的，还需要移动到刚好临界的状态吗

为啥这个CodeArts不支持MatePad EDGE？

如题. 希望能知道是正确性瓶颈还是耗时瓶颈. 以便更好地针对优化.

好像pdf里没有找到

是否保证所有测试数据中最短平移向量具有唯一性？

如题所示。 比如两个重叠的正方形应该往四个方向移动都是最小平移向量。 但是评分规则说的是和标准输出误差小于eps。 那这种情况下应该输出哪一种向量

这个年份不对看着有点害怕

testtesttesttestest

【话题交流】人工智能可以帮助人们完成哪些工作？

1.静态动态 IP 之争：稳定性 VS 便捷性文章链接： https://bbs.huaweicloud.com/blogs/472794文章描述： IP 地址作为网络设备的 “数字身份证”，静态与动态 IP 是两种主流分配方式，适配场景与使用体验差异显著。静态 IP 固定不变，稳定性强，适配服务器、监控等对网络连续性要求高的场景，却需手动配置且可能额外付费。动态 IP 由服务器自动分配、动态切换，便捷性足、隐私防护更优，适合家用及移动设备，却受限于不稳定性。二者各有优劣，核心适配不同需求，选对 IP 分配方式是保障网络使用体验的关键。...2.【Datawhale学习笔记】预训练模型实战文章链接：https://bbs.huaweicloud.com/blogs/472793文章描述：Bert Bert的工作范式预训练 (Pre-training)在一个庞大的、通用的文本语料库（如维基百科、书籍）上，通过特定的无监督任务来训练一个深度神经网络模型。这个阶段的目标不是为了完成某个具体的 NLP 任务，而是让模型学习语言本身的规律，比如语法结构、词语间的语义关系、上下文依赖等。训练完成后，就得到了一个包含了丰富语言知识的、参数已经训练好的预训练模型。微调 (Fine-tun...3.MySQL Docker 容器化部署全指南文章链接：https://bbs.huaweicloud.com/blogs/472792文章描述：本文详细介绍MySQL容器化部署全流程，含4种镜像拉取方式、3种部署方案（快速部署适测试、挂载目录适生产、docker-compose适企业级）、3种结果验证手段及5类常见问题解决方案，还针对不同用户给出操作建议（如初学者先试快速部署，生产用挂载或compose）...4.RAID10 单盘失效降级处理实操文章链接：https://bbs.huaweicloud.com/blogs/472770文章描述：RAID10 降级在日常运维工作中，我曾处理过一起4盘RAID10阵列单盘失效引发的降级告警事件，成功化解了数据丢失风险，现将本次处理经验总结如下，为后续同类故障提供参考。事件过程收到「XXXX」节点存储告警，查看后发现RAID 异常。通过执行storcli64 /call show all和storcli64 /call show all | less命令，拉取阵列全景信息；同时配合服务器...5.DeepSeek 深夜发布 Engram：比 MoE 更节能的突破，V4 架构初露端倪文章链接：https://bbs.huaweicloud.com/blogs/472760文章描述：当AI模型规模不断扩张，一个根本性问题愈发凸显：宝贵的算力是否被浪费在了本应“记住”而非“推算”的任务上？DeepSeek最新披露的Engram技术，正是对这一痛点的结构性回应。它试图将事实性记忆从昂贵的连续神经网络计算中剥离，转向确定性的高效查找，为大模型架构开辟了一条全新的“稀疏性”优化路径。这或许意味着，下一代模型的竞争焦点，正从参数规模转向计算质量的重新分配...6.实战指南：将Allure报告集成到Playwright测试中文章链接：https://bbs.huaweicloud.com/blogs/472752文章描述：面对自动化测试产生的大量结果，如何快速定位问题并高效分析？仅仅依赖控制台日志早已捉襟见肘。本文将分享如何将Playwright与专业的Allure报告系统深度集成，将散乱的测试输出转化为结构清晰、信息丰富的可视化报告。通过实战配置与代码示例，带你打造团队协作与问题排查的效率利器...7.Playwright CI/CD集成指南：配置GitHub Actions与Jenkins文章链接：https://bbs.huaweicloud.com/blogs/472750文章描述：将Playwright自动化测试集成到CI/CD流程，是保障前端质量与交付速度的关键一步。无论是选择开箱即用的GitHub Actions，还是灵活可控的自托管Jenkins，实现自动化执行与反馈都能将测试价值最大化。本文将结合实战经验，详解两种主流方案的配置要点与优化技巧，助你构建高效的自动化质量防线...8.C++线程编程模型演进：从Pthread到jthread的技术革命文章链接：https://bbs.huaweicloud.com/blogs/472743文章描述：本文系统性地分析了POSIX线程（Pthread）、C++11标准线程（std::thread）和C++20协作线程（std::jthread）的技术演进历程。通过对比三者的设计哲学、接口差异、资源管理机制和安全特性，揭示了线程编程从平台相关向语言原生、从手动管理向自动安全的转变路径。文章基于ISO C++标准和POSIX规范的技术事实，为开发者选择适当的线程模型提供理论依据和实践指导...以上就是部分1月博客热门文章的汇总。

1.1 数据倾斜1.1.1 问题描述某局点SQL执行慢，涉及大表的SQL执行不出来结果。1.1.2 分析过程数据倾斜在很多方面都会有体现：1.       gs_ssh –c “df -h”查看各个数据磁盘的利用率，会有不均衡的现象。正常情况下，利用率最高和利用率最高的磁盘空间相差不大，如果磁盘利用率相差超过了5%就要引起重视。2.       通过等待视图查看作业的运行情况，发现作业总是等待部分DN，或者个别DN。

【话题交流】谈谈人工智能产品可能会给我们的生活带来什么改变？

1.原子化服务与卡片开发：你做的卡片，真的“服务”了吗？文章链接：https://bbs.huaweicloud.com/blogs/471604文章描述：  本文收录于「滚雪球学SpringBoot」专栏(全网一个名)，手把手带你零基础入门Spring Boot，从入门到就业，助你早日登顶实现财富自由；同时，欢迎大家关注&&收藏&&订阅！持续更新中，up！up！up！！环境说明：Windows 10 + IntelliJ IDEA 2021.3.2 + Jdk 1.8 🧩 摘要说到原子化服务与卡片（Service Widget），我真会...2.C++多线程中join与detach机制深度解析文章链接：https://bbs.huaweicloud.com/blogs/471602文章描述：在多线程编程领域，C++11标准引入的std::thread库为开发者提供了跨平台的线程管理能力。其中，join()和detach()作为线程对象的两个核心成员函数，决定了线程生命周期的管理策略。本文将从基础概念出发，深入探讨两者的区别、应用场景以及底层实现机制，为读者提供全面的理解框架。 线程生命周期管理的基本概念 线程状态模型在C++多线程模型中，每个std::thread对象都关联着一...3.RFID技术：重塑大型企业工具管理与人员识别的智能引擎文章链接：https://bbs.huaweicloud.com/blogs/471601文章描述：RFID技术正成为大型企业提升工具管理和人员识别效率的智能解决方案。传统管理存在工具寻找困难、人工记录繁琐等痛点，而RFID通过非接触识别、批量读取等特性实现智能化管理。在工具资产管理方面，RFID实现智能仓储、无人盘点和全生命周期追踪；在人员识别领域，支持无感通行、精准考勤和应急定位。双轨应用更能产生协同效应，优化整体运营流程。典型案例显示，RFID技术能显著提升管理准确率和运营效率。4.人工智能的“理解”是否可能：从中文房间到生成式表征的语义鸿沟文章链接：https://bbs.huaweicloud.com/blogs/471581文章描述：人工智能的“理解”是否可能：从中文房间到生成式表征的语义鸿沟 引言：理解之谜与哲学困境1980年，哲学家约翰·塞尔提出了著名的“中文房间”思想实验：一个完全不懂中文的人被锁在房间中，通过一套复杂的规则手册处理中文符号。对于外界的中文提问，他能够给出正确的答案，但他本人并不“理解”中文。这个思想实验直指人工智能的核心问题：符号处理是否等同于理解？随着生成式AI的崛起，这个问题变得更加紧迫现...5.RFID技术：重塑大型企业工具管理与人员识别的智能引擎文章链接：https://bbs.huaweicloud.com/blogs/471571文章描述：随着企业数字化转型的深入，数据库作为核心基础设施之一，其性能、可用性和可维护性变得尤为重要。然而，随着数据规模的爆炸式增长和业务复杂度的提升，传统的人工运维方式已难以满足现代数据库的需求。为了解决这些问题，华为推出了基于其分布式数据库GaussDB的智能运维平台——DBMind，它通过引入人工智能（AI）和机器学习技术，实现了数据库的自动化运维、性能优化和故障预测。在本篇博客中，我们将深入探...6.Flink日志分析：快速定位生产环境问题文章链接：https://bbs.huaweicloud.com/blogs/471555文章描述：在大数据实时处理领域，Apache Flink 作为一款高性能的流处理框架，已被众多企业应用于核心业务系统。然而，当 Flink 作业部署到生产环境后，面对海量数据和复杂业务逻辑，问题排查往往成为运维人员的噩梦。本文将深入探讨如何通过有效的日志分析策略，快速定位并解决 Flink 生产环境中的各类问题。 日志：Flink 生产环境的"生命线"Flink 作业在生产环境中运行时，如同一个精密的...7.智能自行车状态监测与防盗系统文章链接：https://bbs.huaweicloud.com/blogs/471549文章描述：项目开发背景随着城市化进程的加速和环保意识的提升，自行车作为一种绿色、便捷的出行工具，在全球范围内受到广泛欢迎。然而，自行车盗窃问题日益严重，给用户带来财产损失和不便，传统机械锁具的防护能力有限，难以应对复杂的盗窃手段。此外，用户对骑行数据记录和实时状态监控的需求也在增长，这促使了智能自行车系统的开发。在现有市场中，自行车防盗和状态监测方案多依赖于简单的物理锁具或独立的电子设备，缺乏集成化...8.基于单片机的无线红外遥控密码锁文章链接：https://bbs.huaweicloud.com/blogs/471547文章描述：项目开发背景随着社会对安全需求的日益增长，传统机械锁具在防护能力和使用便利性方面逐渐显现出局限性，例如钥匙易丢失、复制风险高以及缺乏灵活的访问控制机制。电子密码锁作为一种现代化解决方案，能够有效提升安全级别，并通过数字化管理减少物理钥匙的依赖。本项目基于单片机开发无线红外遥控密码锁，旨在融合本地与远程控制功能，满足用户对高效、智能安防系统的需求。在嵌入式系统领域，单片机以其低成本、高可靠性...以上就是部分12月博客热门文章的汇总。

从异构到融合：openFuyao 多样化算力资源池化与调度总体方案——KAE-Operator 实践与拓展一、前言：多样化算力时代的调度挑战随着数据中心算力结构从传统 CPU 时代走向 “异构算力并存” 的全新阶段，GPU、NPU、DPU、KAE（Kunpeng Acceleration Engine）等专用算力设备持续增加。硬件能力越强，对软件层统一管理、自动化调度与性能释放的要求就越高。在这样的背景下，openFuyao 作为面向国产算力生态的开放容器平台，承担了 “将多样化算力能力池化、调度化、服务化” 的关键使命。然而，传统开发者仍依赖手工安装驱动、手工部署加速服务、手工调试节点能力 —— 流程繁琐、运维成本高、开发链路不统一。为解决这些问题，openFuyao 构建了以 KAE-Operator、NPU-Operator、NFD（Node Feature Discovery） 为核心的算力自动化能力体系，实现加速能力的 “自动部署、一键接入、统一调度”。本文将聚焦 KAE-Operator，并结合 openFuyao 的总体算力管理方案，展示其面向多样化算力生态的自动化与智能化演进。二、KAE 与 Operator 在 openFuyao 中的角色1. KAE 简介KAE（Kunpeng Acceleration Engine）是基于鲲鹏处理器体系打造的通用加速引擎，支持多类数据处理加速能力，包括：（1）加密加速（SM2/SM3/SM4、AES、SHA 等）（2）压缩与解压缩（3）数据传输和数据安全处理（4）通用数据面算法加速这些能力广泛应用于对象存储、数据库、日志服务、消息中间件和网络设备中，是云基础设施性能优化的关键组成部分。2. Operator 的角色：算力调度的自动化引擎在 openFuyao 中，Operator 框架承担以下核心任务：（1）自动部署驱动组件、用户态库与加速服务（2）自动注册节点算力能力，纳入调度体系（3）维护算力资源 CRD，支持算力池化（4）与 openFuyao 调度器协作，实现按需调度因此，Operator 是 “硬件能力 → 集群可调度资源” 的桥梁。三、KAE-Operator 系统架构与核心模块KAE-Operator 的架构遵循标准 Kubernetes Operator 设计，主要包含以下模块：1. 总体架构（1）Controller 控制器监听自定义资源（CRD）的变化，自动执行部署或更新动作。（2）CRD（Custom Resource Definition）定义 KAE 节点算力能力，例如加密模块、压缩模块、设备状态等。（3）DaemonSet / Deployment 机制DaemonSet：适用于节点级加速库 / 驱动的统一部署Deployment：负责控制加速服务组件和指标采集模块2. 关键模块说明模块功能资源注册模块自动发现节点 KAE 设备，写入 CRD，纳入 openFuyao 算力池状态同步模块实时上报健康状态、驱动版本、可用指令能力日志与监控模块输出运行日志、提供 Prometheus 指标，支持可视化观测该架构保证整个集群在大规模环境下也能保持低运维、低耦合与高自动化水平。四、安装与部署流程（基于官方文档）1. 前提条件（1）环境准备已安装 kubectl 和 Helm CLI（或集群支持应用商店 / 仓库配置）Kubernetes 集群中 KAE 工作节点需统一运行 openEuler 22.03 LTS 操作系统（非 KAE 工作节点无此限制）KAE 节点已激活 License（虚机场景需完成硬件切分和硬直通，参考官方文档）节点配置与系统版本一致的 yum 源（依赖 kernel-devel 等内核包）（2）离线环境 yum 源配置（可选）\# 1. 下载对应版本 openEuler 离线镜像并上传至 /mnt/iso 目录 \# 2. 创建挂载目录 mkdir -p /mnt/openEuler \# 3. 挂载镜像 mount /mnt/iso/openEuler-22.03-LTS-x86_64-dvd.iso /mnt/openEuler \# 4. 配置 yum 源 mv /etc/yum.repos.d/openEuler.repo /etc/yum.repos.d/openEuler.repo.bak cat </yum.repos.d/openEuler.repo \[openEuler\] name=openEuler baseurl=file:///mnt/openEuler enabled=1 gpgcheck=1 gpgkey=file:///mnt/openEuler/RPM-GPG-KEY-openEuler EOF \# 5. 更新缓存 yum clean all && yum makecache（3）NFD 依赖检查NFD（节点特性感知服务）为必选依赖，默认由 Operator 自动部署，若集群已运行 NFD 需手动禁用：\# 检查 NFD 是否已运行（输出 true 表示已运行） kubectl get nodes -o json | jq '.items\[\].metadata.labels | keys | any(startswith("feature.node.kubernetes.io"))' 2. 安装方式（1）openFuyao 平台可视化安装进入 openFuyao 平台，左侧导航栏选择「应用市场 > 应用列表」搜索 “kae operator”，进入应用详情页点击右上角「部署」，输入应用名称、版本信息、命名空间点击「确认」完成部署（2）通用场景 Helm 安装添加 Helm 仓库helm repo add openfuyao https://helm.openfuyao.cn && helm repo update基础安装（默认配置）helm install --wait --generate-name \\ \-n kae-operator --create-namespace \\ openfuyao/kae-operator3. 常见定制选项（核心配置）范围描述默认值nfd.enabled是否部署 NFD 服务（已运行 NFD 则设为 false）truenfd.nodefeaturerules是否安装 KAE 设备发现规则（NFD 已运行时设为 true）falseoperator.enabledHPRE是否启用 HPRE 设备管理（核心加密加速功能）truedriver.enabled是否由 Operator 管理 KAE 驱动（预装驱动时设为 false）truedriver.enabledCleanup卸载时是否删除宿主机驱动falsedevicePlugin.enabled是否部署 KAE 设备插件（预装插件时设为 false）truepsa.enabled集群启用 Pod Security Admission 时设为 truefalse4. 常见部署场景示例（1）指定命名空间安装helm install --wait --generate-name \\ \-n openfuyao --create-namespace \\ openfuyao/kae-operator（2）阻止特定节点安装驱动\# 标记节点禁止部署驱动（安装前执行） kubectl label nodes $NODE openfuyao.com/kae.deploy.driver=false \# 恢复部署权限 kubectl label nodes $NODE openfuyao.com/kae.deploy.driver=true（3）使用自定义镜像安装helm install --wait --generate-name \\ \-n kae-operator --create-namespace \\ openfuyao/kae-operator \\ \--set driver.repository=docker.io/your repository \\ \--set driver.version="0.1" 5. 验证部署结果\# 查看 Operator 相关 Pod 状态 kubectl get pods -n kae-operator \# 查看节点 KAE 资源标签（确认设备发现成功） kubectl describe nodes grep "openfuyao.com/kae.hpre" 五、功能亮点：让加速算力 “自动上线”自动化算力发现与注册无需人工配置，Operator 自动探测并上报加速能力，让算力自然池化。快速部署、低侵入性只需简单的 kubectl apply 或 Helm 命令即可完成加速引擎部署，极大降低运维门槛。支持多算力类型协同管理KAE-Operator 与 NPU-Operator、GPU-Operator 共享 openFuyao 的统一算力管理框架，实现跨设备协同调度。稳定可靠的容错机制监控失败自动重启、CRD 状态恢复、热更新能力确保算力服务持续在线。对 openFuyao 算力池化与统一调度的强化作用operator 是算力纳入统一调度体系的前提。 通过 CRD 注册和能力上报，调度器可以做到：（1）按需调度到支持某种加速能力的节点（2）针对不同算力设备进行差异化资源判断（3）实现跨节点、跨设备的算力池扩展六、拓展：NPU-Operator 与 NFD 的协同价值1. NPU-Operator：面向 AI 推理算力的自动调度NPU-Operator 与 KAE-Operator 架构一致，通过自动部署驱动、注册 NPU 设备能力，使 AI 推理算力可调度、可监控、可管理。典型能力包括：（1）NPU 设备拓扑查询（2）昇腾算子库自动加载（3）操作系统与驱动版本匹配检查（4）设备健康检测2. NFD（Node Feature Discovery）节点特征发现NFD 是实现 “精细化调度” 的关键组件，能够自动识别节点硬件特征并打上标签，包括：（1）CPU 型号、NUMA 拓扑（2）GPU/NPU/KAE 设备（3）巨页、PCIe 拓扑（4）节点性能能力（AVX、ARM 指令集等）openFuyao 的算力调度通过对 NFD 标签进行规则匹配，实现 “按需选节点” 的智能调度策略。七、总结与展望：构建真正的多样化算力融合调度体系KAE-Operator 与 NPU-Operator、NFD 的协同，是 openFuyao 在多样化算力时代的重要基石。它们实现了：（1）算力自动化上线（2）多设备统一资源模型（3）跨硬件能力的统一调度体验（4）开发者 “开箱即用” 的算力加速体验未来，openFuyao 将继续扩展到更多加速设备，包括 DPU、FPGA、专业 AI 芯片等，并基于 Operator 与 NFD 体系打造真正的：“多样化算力融合、池化、自治调度的云原生基础底座”对于硬件厂商与算力服务平台，openFuyao 提供了一个开放、可集成、可扩展的生态。 对于开发者，openFuyao 提供了 “一键部署、自动加速” 的全新体验。算力正在变得更快、更智能、更易获取，而 openFuyao 正在让异构算力变得 “像水电一样易用”。