• [问题求助] 【开源镜像站】【yum更新模块】一直出现Operation timed out
    https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: (28, 'Operation timed out after 30001 milliseconds with 0 out of 0 bytes received')Trying other mirror.https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: (28, 'Operation timed out after 30000 milliseconds with 0 out of 0 bytes received')Trying other mirror.https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: (28, 'Operation timed out after 30001 milliseconds with 0 out of 0 bytes received')Trying other mirror.https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: (28, 'Operation timed out after 30001 milliseconds with 0 out of 0 bytes received')Trying other mirror.https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: (28, 'Operation timed out after 30000 milliseconds with 0 out of 0 bytes received')Trying other mirror.https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: (28, 'Operation timed out after 30001 milliseconds with 0 out of 0 bytes received')Trying other mirror.https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.huaweicloud.com/centos-altarch/7/os/aarch64/repodata/repomd.xml: (28, 'Operation timed out after 30000 milliseconds with 0 out of 0 bytes received')Trying other mirror.
  • [技术干货] AI+科学计算-昇思MindSpore
    当前,人工智能基础性算法理论研究创新日益活跃,深度神经网络日趋成熟,各大厂商纷纷投入到深度神经网络算法的工程实现并发力建设算法模型工具,进一步将其封装为软件框架供开发者使用,这个过程中AI框架应运而生。随着人工智能的不断发展,新的趋势不断涌现,比如超大规模模型的出现(GPT-3等)。AI框架已经从最初的萌芽阶段发展到了如今的深化阶段。这一阶段,AI框架正向着全场景支持,超大规模AI,安全可信等特性深化探索,不断实现新的突破。与此同时,传统科学计算方式在处理气象,生物制药这类没有方程式可寻的领域问题显得力不从心。故传统科学计算领域亟需AI技术的加持,用大数据去驱动计算。目前AI在生物制药和气象领域都已经取得了一些颠覆性的突破,比如蛋白质结构预测,台风公里级风速预报都已经可以通过AI计算出来。昇思MindSpore框架是华为2020年开源的的一款全场景AI计算框架,它旨在提供友好设计、高效运行、简捷部署的开发体验,目前应用于医疗制药、气候、电子制造等多个领域。该框架提供面向端边云全场景的主流硬件支持,并针对昇腾硬件平台提供深度优化能力。该框架是目前国内唯一一个可以把AI和科学计算这种复杂的计算模式全部计算起来的框架。 MindSpore:“AI时代的基石”是如何炼成的?昇思MindSpore自2020年开源以来,不断的进行版本迭代开发。目前已经更新到了最新的1.6版本,框架的功能也不断被完善,各种关键特性不断出现。面对纷繁复杂的场景,各种不同的终端昇思MindSpore框架支持全场景协同的解决方案;面对传统科学计算领域不能求解的复杂问题昇思MindSpore框架推出了AI+科学计算的解决方案;全场景协同,端、边、云全场景无缝部署昇思 MindSpore在框架的设计上进行了分层设计,采用统一的端云统一内核(MindIR),将端云共用的数据结构和模块解耦出来,在满足端侧轻量化的同时,保持了端云架构的一致性,真正实现一次训练无缝部署、端云训练共模型。针对IOT设备,昇思MindSpore 设计了MindSpore for micro方案,MindSpore for micro通过CodeGen方式,将模型中的算子序列从运行时卸载到编译是,并且仅生成将模型执行的代码。它不仅避免了运行时解释的时间,而且还释放了内存使用量,以允许更大的模型运行。全流程极简,高效执行,安全可信自研的Compiler AI编译器基于端云统一的MindIR实现三大功能,包括硬件无关的优化(类型推导、高阶高维自动微分、表达式化简等);硬件相关优化(自动异构并行、内存优化、图算融合、流水线执行等);部署推理相关的优化(量化、剪枝等)。安全可信组件Armour则通过数据脱敏,差分隐私训练等方式保证了数据安全,通过丰富的人工智能鲁棒性检测工具保证了模型安全。AI框架的核心就是微分,自动微分已经比较完善了。昇思MindSpore框架与一般的AI框架相比可以实现高阶高维自动微分,从而在计算高阶微分时可以轻松解决复杂度及误差增加的问题。同时,昇思MindSpore还支持全自动异构并行,在进行分布式训练时自动实现数据并行,模型算子并行,优化器并行等等。昇思MindSpore团队为了解决传统科学计算领域的痛点,发挥其在大规模,多种设备训的练上的优势。该团队计划面向八大科学计算行业打造MindScience系列套件。这些行业套件包括了业界领先的数据集、基础模型、预置高精度模型和前后处理工具,加速了科学行业应用开发。具体如下表所示:与此同时,昇思MindSpore社区生态也在繁荣发展。截止到目前,昇思MindSpore在码云(Gitee)千万开源项目中活跃度排名第一,累计下载量超过130万;服务于5000家企业,涵盖政府、金融、制造、交通、能源、终端等端边云全场景行业;高校及科研机构基于昇思贡献顶会论文300+;100+高校参与社区模型众智活动,为昇思贡献代码,目前已支持300+主流模型,支撑全场景应用。AI框架之力初显:它山之石,可以攻玉传统科学计算方法通过数值迭代的方式解决问题,面临着维度灾难引起的计算量指数上升的问题,导致在复杂问题或者场景中“算不起”,甚至是“算不动”。而科学计算的诸多领域仍然存在着大量待求解的问题,因为机理不清楚,或者完全没有方程,又或者是计算过于复杂,以至于传统算法难以求解。而AI框架依赖于以神经网络为代表的具有“万能逼近”性质的数据工具从数据中挖掘规律,用数据驱动计算,可以大大提高科学计算的性能。而恰好,昇思MindSpore在大规模,多种设备的训练上又有独特的优势。比如:昇思MindSpore推出的分子制药研发套件MindSPONG 实现了分子动力学模拟,蛋白质折叠训推一体。蛋白质是生命的物质基础,是有机大分子,是构成细胞的基本有机物,是生命活动的主要承担者。没有蛋白质就没有生命。蛋白质由很多氨基酸长链组成,这些氨基酸通过折叠成精确的3D结构来完成无数的任务,这些结构控制着与其他分子互动的方式,决定了其功能以及它在疾病中的功能紊乱程度。所以,传统的药物研发一般是通过大批量筛选,寻找易与目标蛋白质分子紧密结合、易合成且没有毒副作用的化合物来完成。这种大批量筛选的方式存在着很大的盲目性,存在研发周期过长,研发成本过高的问题。研发人员如果可以提前预测蛋白质结构则可以大大减少寻找药物的盲目性,从而缩短药物研发的时间,降低研发成本。在过去,因蛋白质构象数量巨大、计算过程及其复杂,通过AI来对蛋白质结构进行预测一直存在精度不足的缺陷,故传统获取蛋白质空间结构的方法仍然以冷冻电镜等实验技术为主。单个蛋白质的观测成本高达数月以及几百万元。直至AlphaFold2的出现,才使得这一问题迎来了曙光。AlphaFold2 在国际蛋白质结构预测竞赛CASP14上实现了前所未有的结构预测精度。这一成就也被 Nature 誉为“前所未有的进步”。但是,AlphaFold2本身模型本身存在内存需求大,数据处理繁琐,控制编译复杂等特点,对基础 AI 框架存在着巨大挑战。故2021年9月昇思MindSpore联合高毅勤课题组(北京大学、深圳湾实验室)推出了分子制药研发套件MindSPONGE,该套件是第一个根植于AI框架的分子模拟工具,其采用模块化的设计思路,可以快速构建分子模拟流程。蛋白质结构预测工具依托昇思MindSpore,可对氨基酸序列长度2000+的蛋白质结构解析,能覆盖约99%以上的蛋白序列。该工具的模型部分与AlphaFold2相同,在多序列比对阶段,采用了MMseqs2 进行序列检索,相比原版算法端到端的速度有2-3倍提升。近期,昇思MindSpore,高毅勤课题组(北京大学、深圳湾实验室)联合团队使用该工具全面打通了AlphaFold2的训练。采用昇腾基础软硬件之后,通过软硬件协同优化大大提高了蛋白质预测的计算效率。在混合精度下,单步迭代时间由 20 秒缩短到 12 秒,性能提升超过 60%。依托昇思 MindSpore 内存复用能力, 训练序列长度由 384 提升至 512。MindSpore在CASP14验证集上TM-score得分87.2,超过了JAX(AlphaFold2的AI框架)的87.02除了在生命科学领域的蛋白质结构预测及折叠问题上有重大突破以外,昇思MindSpore电磁仿真套件MindSpore Elec也取得了重大突破。麦克斯韦提出了位移电流假说(变化的电场能够产生磁场),完善了电生磁的理论。并最终将电磁场理论以简洁、对称和完美的数学形式表示出来,即麦克斯韦方程组。随着计算机技术的发展,人们采用数值计算的方式去求解麦克斯韦方程组以模拟电磁场在空间中的分布。这样既节省了实验成本,又可以通过仿真设计出更加符合需求的电子设备。传统的电磁计算方法包括精确的全波方法和高频近似方法。虽然较好地辅助了电子产品的设计,但是该方法仍存在许多缺陷,如需要进行复杂的网格剖分、迭代计算,计算过程复杂、计算周期长。神经网络具有万能逼近和高效推理能力,这使得神经网络在求解微分方程时具有潜在的优势。为此,昇思MindSpore推出了AI电磁仿真套件MindSpore Elec。MindSpore Elec内置有前后处理工具(数据构建及转换、结果可视化)、AI电磁模型库(物理方程驱动和标签数据驱动)以及优化策略(数据压缩、动态自适应加权等),具体模块和功能如下:MindSpore Elec套件在AI电磁仿真上相比传统的电磁计算方法在性能上有了质的飞跃。MindSpore Elec在物理驱动的AI电磁仿真上比原始的PINNs方法,性能提升15倍以上;与Benchamrk(传统的数值方法)的相对误差在5%左右;在手机电磁仿真的场景中,仿真精度媲美传统科学计算软件,同时性能提升10倍。未来的十年将会是AI发展的黄金十年,而作为最为核心的AI技术之一,深度学习算法框架的发展牵动着业内每一个参与者的心。中国AI深度学习框架的发展必将迎来大爆发。昇思MindSpore必将扮演着重要的引领者角色,尤其是在AI+科学计算领域,昇思MindSpore可以充分发挥其大规模,多设备训练上的优势,不断完善科学计算套件,通过AI电磁仿真突破产品设计仿真性能瓶颈;通过实现药物分子预训练模型,加速分子生成,降低实验成本。这些科学计算套件必将助力各行业发展。————————————————原文链接:https://blog.csdn.net/u014534808/article/details/123879486
  • [openEuler] 浅谈openEuler OSV技术测评
    openEuler的影响力:自从openEuler捐献给开放原子开源基金会,越来越多的目光聚集到了国产操作系统之光-openEuler的身上。欧拉开源社区通过开放的社区形式与全球的开发者共同构建一个开放、多元和架构包容的软件生态体系,孵化支持多种 处理器架构、覆盖数字设施全场景,推动企业数字基础设施软硬件、应用生态繁荣发展。openEuler 作为一个操作系统发行版平台,每两年推出一个 LTS 版本。该版本为企业级用户提供了一个安全稳定可靠 的操作系统。 openEuler 也是一个技术孵化器。通过每半年发布一次的创新版,快速集成 openEuler 以及其他社区的最新技术成果, 将社区验证成熟的特性逐步汇合到发行版中。从2019年底 openEuler社区正式成立至今,历经多个LTS版本和创新版本之后,2022 年 3 月 30 日,基于统一的 5.10 内核,发布面向服务器、云计算、边缘计算、嵌入式的全场景 openEuler 22.03 LTS 版本,聚焦算力释放,持续提升资源利用率,打造全场景协同的数字基础设施操作系统。社区适时推出OSV技术测评:openEuler同时作为一款开源免费的操作系统,服务广大开发者和用户的同时,也致力于帮助OSV操作系统厂商开发和发布基于openEuler生态的操作系统商业发行版,为了检测商业发行版生态核心特性不丢失、基础路线一致性,欧拉开源社区适时推出OSV技术测评能力,联合OSV/ISV等社区伙伴,共同制定欧拉兼容性测评标准,欧拉生态创新中心根据该标准进行测试,测试通过后由欧拉开源社区颁发openEuler技术测评证书。• 首先看下测评标准https://gitee.com/openeuler/oecp/blob/master/doc/OECP%E5%B7%A5%E5%85%B7%E6%B5%8B%E8%AF%95%E6%A0%87%E5%87%86.md ,由测评标准可知,基础路线一致性要求了OSV商业发行版的核心包、软件包、内核ABI、系统配置、特性配置、仓库复用度等方面高度兼容、基础性能范围内浮动:测评维度检测项检测点描述测试标准可选工具检测核心包核心包一致性比例名称、小版本完全一致,核心包包括核心包内容一致性,内核、gcc、glibc、qemu、docker、openJDK、systemd、openssh、lvm2、busybox、initscripts核心模块一致性,JDK如果没有,则不会纳入比较项必选软件包L1/L2 软件包一致性比例L1 100%兼容,L2 95%以上兼容,参考社区等级清单定义(附上链接)https://gitee.com/openeuler/oec-application/blob/master/doc/compatibility_level.md 必选内核KABI接口OSV内核KABI接口白名单与openEuler内核KABI接口白名单一致性比例内核-KABI白名单 90%以上兼容可选用户态ABI接口OSV软件包ABI接口与openEuler软件包ABI一致性比例L1 100%兼容,L2 95%以上兼容,参考社区等级清单定义必选Service默认配置OSV软件包Service文件与openEuler软件包Service文件一致性比例全量默认配置一致性90%以上可选软件包默认配置OSV软件包配置文件与openEuler软件包配置文件一致性比例全量默认配置一致性90%以上,目前对于OSV厂商新增的配置,不会作为差异比较可选内核特性配置内核特性配置内核关键配置一致性,达90%以上必选平台验证仓库EPOL仓/软件所仓库在OSV版本上安装成功比例仓库复用度90%以上必选基本功能社区AT用例运行结果社区AT用例运行结果100%通过必选基础性能基础性能测试结果性能浮动5%以内必选运行时默认配置运行时默认配置全量运行时默认配置一致性90%以上可选• 其次以首个通过测评的OSV版本-超聚变FusionOS-22_22.0.1_x86-64为例,FusionOS对系统进行了深度增强,主要技术特性如下:• 高可靠:FusionOS 通过文件系统加固、高危操作控制、故障预测和隔离,故障分级自愈以及核心资源过载控制等特性,降低系统宕机风险,全方位保障操作系统的可靠性。• 高性能:FusionOS 采用软硬件分层垂直优化的方法,针对应用接口、系统服务和底层微架构进行了深度调优。调优内容包含 CPU 调度、IO 驱动、网络协议、文件系统、内存管理及基础软件库等,为客户业务带来出色性能体验。• 易运维:FusionOS 针对操作系统全生命周期的管理,面向部署、运维等场景,提供完整解决方案。支持一键收集关键日志、快速系统部署升级以及关键资源监控告警等特性,旨在提高用户在操作系统运维过程中的自动化和智能化水平,提升客户运维效率。FusionOS做了这些特性增强的同时依然延续了openEuler生态路线,它的测评结果依然满足了测评标准:故而最终顺利上线欧拉开源社区OSV技术测评列表:如何开展测评活动:那么如何开展测评活动呢?只需按照如下步骤一一申请https://www.openeuler.org/zh/approve/approve-step/ ,其中提交issue的时候填写ISO镜像下载地址,再留下您的联系方式,我们会持续与您沟通,并在约14个工作日内完成测评给予反馈。测评依托OECP工具:可能有人会问OSV技术测评是怎么做到的?OSV厂商是否能提前自验证?答案是测评标准里的所有检测点我们使用oecp工具https://gitee.com/openeuler/oecp 来完成,工具已开源发布到码云,所以OSV厂商完全可以提前下载oecp工具完成主要内容的自验证,如有使用问题也是通过issue处理。接下来简单介绍工具使用和报告解读:0. 主要功能1.检测2个ISO(基于RPM)的软件包,软件包内文件,库文件接口(C/C++),内核KABI的变化差异2.检测同一个软件(rpm包)在不同版本下的变化以及差异1. 运行环境1.1. oecp运行环境依赖组件组件组件描述可获得性python3python3.7.9及以上可先通过yum list命令查看,如果没有该版本需要下载安装sqlitev3.7.17 及以上版本系统自带2. oecp下载安装与部署install abidiff:yum install -y epel-release yum install -y libabigail(注意:openeuler需要配置openEuler-20.03-SP2以上版本everything仓库)install oecp:git clone https://gitee.com/openeuler/oecp.git  cd oecp pip3 install -r requirement3. oecp使用python3 cli.py [-h] [-n PARALLEL] [-w WORK_DIR] [-p PLAN_PATH] [-c CATEGORY_PATH] [-b PERF_BASELINE_FILE] [-a {x86_64,aarch64}] [-f OUTPUT_FORMAT] [-o OUTPUT_FILE] file1 file2• 位置参数(必选)o file 指定两个比较的iso文件,注意以file1作为基准• 可选参数o -n, --parallel 指定进程池并发数量,默认cpu核数o -w, --work-dir 指定工作路径,默认路径为/tmp/oecpo -p, --plan 指定比较计划,默认为oecp/conf/plan/all.jsono -c, --category 指定包级别信息,默认为oecp/conf/category/category.jsono -b, --baseline 指定基线文件,默认为oecp/conf/performance/openEuler-20.03-LTS-aarch64-dvd.iso.performance.jsono -f, --format 指定输出格式,默认为csvo -o, --output 指定输出结果路径,默认为/tmp/oecp• 举例o python3 cli.py /root/openEuler-20.03-LTS-aarch64-dvd.iso /root/openEuler-20.03-LTS-SP1-aarch64-dvd.iso• 比较计划说明o all.json 涵盖下面所有配置项的比较o config_file.json 比较rpm包中配置文件内容的差异,需依赖RPMExtractDumper(提取解压rpm的dumper类)o filelist.json 比较rpm包文件列表差异,可通过rpm -pql ${rpm_path}命令获取rpm文件列表o kconfig.json 比较内核配置文件,需依赖RPMExtractDumper(提取解压rpm的dumper类)o package_list.json 比较两个rpm集合包名称、版本、发行版本的差异o provides_requires.json 比较rpm的provides和requires差异,可通过rpm -pq --provides/requires ${rpm_path}查询python3 cli.py CentOS-6-8-x86_64-bin-DVD1.iso CentOS-7-x86_64-Everything-1810.iso,检测完成后下载报告到本地PC打开,报告目录结构如下:查看osv_data_summary.xlsx,该文件展示了与测评标准一致的测试项,工具检测内容需要全部是PASS查看all-rpm-report.csv,该文件汇总了iso里所有rpm包的扫描结果, compare_type选择rpm package name时compare_result列分成了1至5级,compare_type选择包括drive kabi、kabi、kconfig、rpm files、rpm provides等维度的时候,compare_result列分成了diff/same;另外osv_data_summary.xlsx里的“L1/L2软件包一致性比例”可以通过筛选category level=1&2来进一步分析。 比如筛选其中的diff内容,再详细查看具体差异,根据compare_detail列查看rpm_analyse/rpm-requires/libacl-2.2.49-6.el6.x86_64.rpm.csv
  • [技术干货] “我曾认为开源是有钱闲人的游戏,不要试图快速从中变现” | 对话《大教堂与集市》译者卫剑钒[转载]
    作者 | 宋林飞 责编 | 何苗受访嘉宾 | 卫剑钒出品 | CSDN(ID:CSDNnews)关注开源的人一定对《大教堂与集市》非常熟悉,随着这本书的中文版在国内发行,译者卫剑钒逐渐被更多的人熟知,而今,开源圈的朋友们亲切地称他卫Sir。书中,原作Eric S. Raymond用许多抽象概念为大家讲述了开源运动的理论与实际应用。这些“晦涩难懂”的英文也给卫剑钒的翻译工作带来诸多挑战,但他一直信奉的一句格言“麻烦的事中藏着珍宝”。历经无数个周末斟酌字句“较真”地翻译,他终于将《大教堂与集市》中文版完整、准确地展现给读者,使许多中国热爱开源的人跨越语言隔阂,领略到这本被称为开源运动“圣经”的风采。作为网络安全专家的卫剑钒因为工作性质并没有机会过多参与到开源项目中,但他化身为“卫Sir”在个人的博客和公众号上为大家用“人话”来解读诸多开源中抽象、“不明觉厉”的元素,例如开源理念,开源许可证,热点开源事件等等… 宛若一位世外高人。许多读者在看完他的文章后对开源有了更接地气的了解。古人云:“当局者迷,旁观者清”, 本期《开源访谈录》邀请到《大教堂与集市》译者、信息安全专家卫剑钒来分享他从一位“开源观察者”的角度对开源协议、开源安全性以及开源发展的见解。如何破解开源程序员的普遍困境:用开源获得收益与影响力?“麻烦的事中藏着珍宝”CSDN:你曾将开源著作《大教堂与集市》翻译成中文,也时常将晦涩难懂的开源协议解读给大家听,这两件事不是易事,从你个人的成长经历来看,为什么会坚持做这类事情?卫Sir:这两件事有它的相通之处,都有翻译的性质,而且都有难度。如果大家看过原版的《大教堂与集市》,就会知道它阅读和理解起来是比较困难的。开源许可证也有这个特点,如果对开源不了解、对IT没有了解、英文不好,直接阅读会觉得非常吃力。而我正好从事IT领域工作,对开源有一定了解,掌握的英文也足以用来翻译,因此决定做这件事。有一句格言我很喜欢,“麻烦的事中藏着珍宝”。一些简单的事情,可能大家已经有很多途径获得解决方法。但比较难、比较有价值的知识,就需要有一个通俗的媒介,使得人们可以相对容易地去接触、了解、掌握。如果我一个人费点功夫,可以让更多人受益,这是我理解的一种开源精神。CSDN:为什么会鼓励青少年和年轻的开发者去尝试开源?卫Sir:我主要基于两个判断。第一,这个世界终将走向数字化,大家应该能感受到这些年数字化趋势越来越明显,发展速度越来越快。这两年大火的元宇宙,就是人类对于未来生活在数字化世界中的一种设想。另外一方面,我认为未来的软件终将被开源吞噬,大多数都走向了开源。如果闭源软件和开源软件在功能相差无几,那么开源软件竞争力一定更强,因为大家会更倾向于源码开放的软件。因此年轻人参与编程,参与开源项目,也是尽早为进入未来社会做准备。这方面能力越强,在未来就越有竞争力。开源协议是一纸合同,也是创作者与使用者的默认契约CSDN:开源圈中大家都知道你擅长解读开源协议,为什么理解开源协议对我们如此重要?卫Sir:开源协议本质上是一纸合约,是开源项目的作者很认真、很郑重其事地把他对使用者的要求以书面形式展现出来,为了提醒使用者要注要按照他的要求来使用。比如要保留作者版权信息,使用导致的问题不要找作者等等。如果使用者不重视这些明文要求,在使用过程中违背了开源许可证,可能会给自己带来麻烦。轻则引发作者本人的愤怒,产生一些纠纷,重则惹上诉讼、官司,因此作为开源使用者一定要重视开源协议中的要求。CSDN:能否为开源新手介绍一下常用的几种开源协议和它们的特点,区别是什么?假如要开源一个项目,该如何在其中进行选择?卫Sir:最常用的开源协议包括BSD、MIT、Apache、GPL。简单地说,BSD和MIT是最简单、最宽松的协议,对使用者要求也是最少的。Apache许可证不像MIT和BSD那么简单,它包含了一条关于专利的描述,这是它比较创新的地方,风格也相对严谨,考虑的因素会更加全面。 GPL最主要的特点是它具有“传染性”,使用附带GPL协议的开源代码,其项目也必须要开源。使用者需要注意不同开源协议的特点,结合自己的情况挑选适合的协议。如果是自己写写玩票性质的小软件,用MIT、BSD就可以,不用那么讲究。如果是个有一定规模和考虑商业化的开源软件,可以考虑使用Apache协议,会比较周全,它会考虑专利的授权问题;如果比较崇尚自由软件的精神和理念,则可以用GPL系列的协议。我个人比较喜欢宽松的协议,比如MIT简单、随意,既然都选择了开源,不如开放得更彻底一些,有些东西放到公共空间(Public Domain)也很不错。CSDN:目前国内还没有以开源软件为主题的法律,开源软件的协议是否具有法律效应?它怎么约束开源作者和使用者?卫Sir:国内虽然没有直接和开源相关的法律,但开源协议可以看作是个合同,受《合同法》的保护。虽然创造者与使用者双方并没有在协议上面签字,但是作者在软件发布时是附带着“合同”一并发布的。开发者一旦使用作者发布的软件就默认接受了合同的规定,如果不接受就不要使用。此外,开源软件本身是有版权的,所以它也受《著作权法》保护。国内去年就有两起与GPL协议相关的著名案件,经法院审判后的判决书我们也能看到,我就此写了两篇文章,大家有兴趣可以看看。CSDN:最近地缘政治冲突已经蔓延到了开源世界,甚至像GitHub这种开源平台和一些开源社区,在美国政府要求或呼吁下已经向俄罗斯停止部分服务,这个举措是否意味着法律政策凌驾于一切开源协议之上?开源是否存在国界?卫Sir:开源协议只是一个合同,显然法律的效力大于开源协议,尤其是当开源协议与法律所规定的内容冲突时,法律的效力更高。GitHub的这次限制,是这么说的“在我们努力确保所有国家的开发者都能使用GitHub的同时,我们也在继续确保所有人都能获得免费的开源服务,包括俄罗斯的开发者。我们的法律团队对此类权限进行了彻底审查,而且我们正在遵守不断发展的出口管制和贸易法规。这包括实施严格的新出口管制,旨在严格限制俄罗斯获得其维持侵略性军事能力所需的技术和其他物品。”我们需要认识到的一点,GitHub是一家被微软收购的公司,它的所有行为仅仅代表这个美国公司的行为,而美国公司是受美国法律管控的。因此,我们可以说,开源程序、开源精神、开源社区是无国界的,但每一个开源开发者,每一家开源公司,都是有所属国家的。维护开源安全需要多方共同努力CSDN:一般企业使用开源软件会存在哪些风险?卫Sir:企业使用开源主要存在两大类风险。第一大类风险是能否用好开源。要想用好开源其实不太容易,一个企业的代码可能是自己开发的,或是从供应商购买的软件和代码。对企业来说,如果技术能力不强,即便成功部署了开源软件,出现安全漏洞时,可能还得等待社区出了补丁才能把漏洞补上。但如果社区短期内无法给与支持,企业自身是没有能力修复的(除非是一家有很强技术实力的IT企业),这对企业来说是一个风险。第二类是合规性问题,主要存在于在那些有输出能力的企业中。输出产品、代码都需要检查其是否违背开源许可证中要求的内容。假设代码中使用了含有GPL协议的开源代码,企业是否做到了将源码开放出去?如果没有就会出问题,这就是合规风险。CSDN:开源技术,因为它开放和不设门槛的特点,很容易受到黑客攻击。之前发生过多起开源技术漏洞导致的安全事故,你从网络安全专家的角度如何看待开源安全性?卫Sir:开源的安全性和任何软件的安全性没有本质区别,只要是人写的软件,都会有安全问题,和它是否开源关系不大。业界有个广泛流传的说法:“只要眼球多,bug容易捉”。由于开源天然的协作特性,开源的安全性应该更高,但事实上,很多安全漏洞隐藏得很深,不是眼球多就能看出来的,想要发现这种漏洞,独特的安全技术和安全专业能力是必不可少的。而且找功能bug和找安全bug的思路是完全不同的。开发人员的思维和安全人员的思维完全是反着来的。开发人员更在意实现功能和提升性能,而安全人员考虑的是如何用各种意想不到的手段获取数据和权限。如何理解这两种思维的差异?可以从最简单的用户名和密码的功能为例。传统测试只会测试不同长度、不同类型的字符输入是否会导致程序崩溃和异常;而安全测试人员会构造精巧的数据作为输入,比如构造SQL注入语句,或者导致缓冲区溢出执行恶意代码的数据,这是传统测试不会考虑的。安全人员更多是要用一种在开发人员开起来匪夷所思的角度和路径去找到那些隐藏很深的安全bug,这些不是常规的测试,这是安全性测试。当然,我们建议开发人员应当具备一定的安全思维和安全能力,但看上去困难重重,开发人员对安全往往是不太关心的。专业的培训会有一定帮助,再有就是在整个软件生命周期嵌入安全流程,比如DevSecOps等,让人们做出更安全的软件。要想防范甚至消灭开源软件的安全漏洞,除了提升开发者安全能力和加强流程管控外,还可以在更多技术领域发力,从CPU、硬件体系架构、操作系统、编程语言、安全工具等方面,都可以有更多的安全创新和改进。总的来说,经过20多年的发展,不论是安全法规、安全理念、安全意识,还是安全技术、安全产品、安全生态,整个环境比我刚接触这个领域时(2000年左右)要好得太多了。我想看到开源吞噬世界的那一天CSDN:如今国内的一些开源产品和开源文化的发展情况如何?是否存在瓶颈?卫Sir:我所了解到的国内比较出名的开源产品目前都发展得很好,但有更多无法脱颖而出的开源项目没有进入大家的视野。谈到开源文化,我能感受到如今大家对开源的态度比原来要友好很多。10年前左右,很多人对开源甚至会有一些错误的认识,认为开源是“坏”东西,是“别有用心”的,这在现在看来简直不可思议。现在大家逐渐以一种实用主义的眼光来看待开源,发现开源软件不仅可以解决自己的问题,还能获取源代码、甚至商业化。我认为只要不违反开源许可证,这些想法都是自然的、正常的,是理性思考的结果。另一进步是如今大家普遍意识到了开源可能带来的风险,和开源的合规问题。有经济实力的公司会购买商业版本的开源软件,并且会购买开源相关服务。一些IT企业也开始贡献上游,开源内部软件,促进开源生态发展,这些都值得赞赏。总的来说,我认为国内开源目前没有瓶颈,也无需突破。大家自由发展、自由竞争、自由使用,只要合规就好。CSDN:你曾专门撰文探讨 faker.js 和 colors.js 的项目作者毁库跑路的故事,这里着重探讨了开源程序员在“如何用开源获得收益”的困境,除此之外,您认为开源开发者还面临着哪些困境?卫Sir:在很长一段时间内(对于个人项目,现在我也这么认为),我都认为开源是有钱有闲的人玩的游戏,你可以将它作为一种兴趣或者乐趣。如果你还面临温饱问题,我建议还是先务实一点,找一份被雇佣、可以拿薪水的工作,不要试图快速从开源之中变现。玩开源可以为了乐趣,为了提高能力、获得名声,为了满足存在感,但不管怎样,现阶段个人玩开源,不要指望能直接赚到钱。开源本身更多是一种奉献精神,对个人来说,这是开源最主要的困境。此外,很多人搞创作还是希望得到他人的认同,发挥自己的价值,给社会带来一些有益的影响。但你开源的代码可能未必有人关注,也未必有人下载、使用它,也未必产生你预期的效果和影响力。创作者的普遍困境就是,当你的作品并没有人关注,没有人用的,一定会感到很失落,也很容易放弃。所以你做的东西,必须足够优秀,解决足够有趣、有价值的问题,你必须拥有足够的能力,甚至包括程序员所稀缺的营销能力,才能获得更多的关注和认可。CSDN:你曾经说“免费”、“搭便车”等话题已经失去了讨论的意义,那么开源圈内还有哪些问题是您长期比较最关心的?卫Sir:我比较关心的是,什么时候每个人都能用上开源的桌面操作系统、开源的office软件,甚至于人们使用的软件全都是开源的?也即开源何时能够真正地吞噬世界?这大概需要很长时间,甚至在有的领域永远不会实现,比如可以直接盈利的消费型软件一般都不会开源。不过,以后的世界真的很难想象,也许开源会以一种现在无法想象的方式,吞噬世界。此外,前面谈到一个程序员因为无法获得收入愤然删库跑路的例子,我们是否可以找到一种方式,让程序员进入一种自由编码的状态,不再需要考虑生计问题,且不用被雇佣,仅仅通过写代码,参与开源项目或是自创项目,就可以轻松获得回报?这也是我长期关心的问题。开源开发者因为赚不到钱而删库跑路不是个例,他们的代码使用量很大,但因为是免费的,没有任何经济回报的机制,开发者就无法因此致富。假如能有一种方式,只要代码被人使用了,产生价值了,就能得到收益,这对开源开发者而言就是非常理想的状态。目前看来web3似乎是一条比较可行的道路,但也有人觉得Web3并不靠谱。一切尚不明朗,不过我很期待。《开源访谈录》是一档聚焦开源发展的访谈类栏目,每周将邀请1位具代表性及影响力的开源专家,探讨大家广泛关注的开源话题,从不同角度还原开源圈真实面貌。————————————————版权声明:本文为CSDN博主「开源头条」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。原文链接:https://blog.csdn.net/csdnopensource/article/details/124726837链接:https://blog.csdn.net/csdnopensource/article/details/124726837?spm=1000.2115.3001.5927
  • [其他活动] KubeEdge同学会带你飞:已上线开源之夏2022KubeEdge社区第一批项目
    前言KubeEdge社区针对高校学生成立KubeEdge同学会微信群,鼓励和帮助社区中高校学生互帮互助,比如基于KubeEdge创建项目带队开发,开展研究发表论文,或参与社区开发贡献增加简历含金量。KubeEdge同学会今年第一项任务就是组织面向高校学生的开源之夏2022KubeEdge社区活动。开源之夏是开源软件供应链点亮计划系列的暑期活动。活动每年一度(当前已是第三期),持续拉动开源社区实习新风潮。参与学生通过远程线上协作方式,配有资深导师指导,参与到开源社区各组织项目开发中并收获奖金、礼品与证书。KubeEdge社区为本次开源之夏2022组委会推荐18项精选项目课题,覆盖边缘AI、云机器人、鸿蒙操作系统等边缘计算热门方向,包括应用与算法创新、系统研发与集成、易用性等各方面。KubeEdge社区正在组织相关宣讲,帮助同学们了解开源之夏2022活动、了解KubeEdge社区各领域项目、结识KubeEdge社区开源导师,以助力后续申请。在即将到来的开源之夏2022, KubeEdge社区期待学生的热情洋溢和灵光乍现,期待导师的编程绝技和薪火相传,期待大家的畅所欲言和灿烂笑颜,期待你与开源社区结缘的这个夏天!KubeEdge同学会成立KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目。KubeEdge在全球已拥有900+贡献者和70+贡献组织,在Github获得5.1k+Stars和1.4k+Forks。近年来,KubeEdge社区持续开拓创新,完成业界最大规模云原生边云协同高速公路项目(统一管理10万边缘节点/50万边缘应用)、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目,开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式。在开源之夏2022,KubeEdge期待和计算机领域新生力量一起,以代码开拓数字未来。边缘计算领域相关研发工作方兴未艾、前景非常广阔。KubeEdge社区面向高校学生,成立了KubeEdge同学会微信群。群里聚集了在社区里边基于KubeEdge开展工作的高校同学以及专家学者,方便大家结交在边缘计算领域志同道合的朋友。KubeEdge同学会鼓励互帮互助、薪火相传。不管是创立项目带队研发的专家、开展研究发表论文的学者、还是希望通过社区开发贡献增加简历含金量的同学,都可以加入。从开源之夏2022开始,KubeEdge同学会将组织一系列活动,比如由老师学长们宣讲、发布文章等方式分享经验,或者导师以开源之夏等方式带同学进行开源贡献。以期薪火相传,共同成长!扫描小助手二维码发送“KubeEdge同学会”加入KubeEdge高校同学交流群鼓励互帮互助,比如一起建项目,写论文,或通过社区开发贡献增加简历含金量宣讲活动KubeEdge同学会今年第一项任务就是面向高校同学组织开源之夏2022KubeEdge社区活动。今年开源之夏2022 KubeEdge项目包括云机器人、Re-ID、自动驾驶、工业质检等边缘计算创新应用场景及对应基准测试,边云协同终身学习、生成对抗式网络、VSLAM等前沿算法技术,以及结合Prometheus、Mindspore、Modelbox、OpenHarmony、Gazebo、ROS等知名开源项目的工作。特别地,KubeEdge云机器人场景项目包括基于KubeEdge实现RGBD定位和建图、机器人性能监控、移动抓取、多机器人协作仿真等边缘计算创新业务,SIG可提供仿真技术方案帮助同学们低成本完成项目,无需购置实体机器人。开源之夏2022项目学生可以在世界任何地方线上工作。KubeEdge相关项目结项需要在9月30日前以 PR 的形式提交到KubeEdge社区仓库中并完成合并。完成开源之夏项目课题,高校学生将有以下收获:    1、 在校提前获得企业资深开发者或开源大牛的专业指导;    2、 参与国际顶级开源项目开发的难得经历;    3、 获取国际开源社区结项证书;    4、 结项后获得与企业实习生相当的奖金,以及活动纪念品;    5、 出色完成项目更有机会获得优秀学生证书;这些收获,不仅仅是未来毕业简历上浓墨重彩的一笔,更是迈向顶尖开发者的闪亮起点,可以说非常值得一试。那么如何参与到开源之夏2022活动中,如何快速定位感兴趣项目,如何从众多同学中脱颖而出呢?本周,KubeEdge社区及KubeEdge SIG AI例会将手把手介绍学生参与流程、与导师的沟通内容与方法、高质量项目申请写作方法、快速定位感兴趣项目的方法、也包含答疑环节,欢迎届时参加。社区例会先行宣讲:    KubeEdge社区例会时间:2022.04.27 周三下午16:30    KubeEdge SIG AI例会时间:2022.04.28 周四下午16:30    KubeEdge社区各例会统一会议链接:https://zoom.us/my/kubeedge后续还有更多乃至更大规模项目宣讲在路上,敬请期待!首批项目一览KubeEdge社区,截至2021.04.19,已收到社区各导师项目提案36项,经过激烈评审和角逐,为本次开源之夏2022组委会推荐18项精选项目课题。其中首批10个项目见下。开源之夏2022 KubeEdge社区首批项目一览,后续批次项目介绍将陆续到来开源之夏2022KubeEdge社区项目课题覆盖边缘AI、云机器人、鸿蒙操作系统等边缘计算热门方向,项目包括应用及算法创新、系统研发与集成、易用性等各方面。KubeEdge社区正在寻找这些愿意贡献开源的高校学生开发者:1、具备K8s/Python/Golang/C++/shell等至少一种编程技能;2、在下列至少一个主题中有坚实背景:边缘AI或云机器人算法、边缘计算系统开发或测试、软件易用性或可视化、操作系统开发或测试;开源之夏2022 KubeEdge社区各项目课题将在5月21日开始接受学生参与项目申请,欢迎与各导师沟通并准备项目申请材料。开源之夏2022学生参与流程首批项目介绍下面按项目提交顺序介绍KubeEdge社区首批10个项目(后续还有更多项目陆续到来),欢迎各位联系导师或参加宣讲会了解项目详情。项目编号2298a0006面向边云协同终身检测的边缘智能基准测试难 度:进阶/Advanced项目社区导师:郑子木,导师联系方式:zimu.zheng@huawei.com项目编号2298a0007 基于KubeEdge-Sedna边云协同平台的行人Re-ID特性,开发算法性能自动化测试难 度:基础/Basic项目社区导师:王宇桐,导师联系方式:wangyutong_96@126.com项目编号2298a0011支持KubeEdge边缘节点运行在OpenHarmony难 度:进阶/Advanced项目社区导师:魏欢,导师联系方式:huan@harmonycloud.cn项目编号2298a0013 设计实现KubeEdge在边缘场景的测试用例覆盖难 度:基础/Basic项目社区导师:QeelinDarly,导师联系方式:1042581029@qq.com项目编号2298a0027构建基于Sedna和ModelBox的高频边云协同应用案例难 度:基础/Basic项目社区导师:黄基松,导师联系方式:huangjisong@huawei.com项目编号2298a0028基于Sedna终身学习复现未知任务识别算法难 度:进阶/Advanced项目社区导师:罗思奇,导师联系方式:luosiqi2@huawei.com项目编号2298a0029基于Prometheus实现KubeEdge-Sedna的可视化智能监控和日志管理难 度:基础/Basic项目社区导师:张俊,导师联系方式:zhangjun286@huawei.com项目编号2298a0031 Sedna边云协同终身学习运维UI开发难 度:进阶/Advanced项目社区导师:杨锦,导师联系方式:yangjin39@huawei.com项目编号2298a0032基于KubeEdge实现VSLAM算法难 度:基础/Basic项目社区导师:黄志炜,导师联系方式:huangzhiwei21@huawei.com项目编号2298a0033构建面向机器人的智能监控系统难 度:基础/Basic项目社区导师:陈文浩,导师联系方式:chenwenhao7@huawei.com有关开源之夏2022的更多介绍,请关注 https://summer-ospp.ac.cn/#/homepage 在即将到来的开源之夏2022, KubeEdge社区期待学生的热情洋溢和灵光乍现,期待导师的编程绝技和薪火相传,期待大家的畅所欲言和灿烂笑颜,期待你与开源社区结缘的这个夏天!扫描小助手二维码发送“KubeEdge同学会”加入KubeEdge高校同学交流群鼓励互帮互助,比如一起建项目,写论文,或通过社区开发贡献增加简历含金量发送“KubeEdge”“KubeEdge SIG AI”等加入各领域技术用户交流群获取技术干货,最新进展
  • [问题求助] 【华为开源镜像站】【鲲鹏软件包镜像】提供网站打不开,问题出现已经很久了
    【功能模块】https://mirrors.huaweicloud.com/home华为开源镜像站   求助求助!!!【操作步骤&问题现象】1、点击ARM类-选择底部的鲲鹏软件包,点击使用说明里的镜像地址。报504的错误,已经很久了。麻烦跟进处理下,这个网站很方便的对于鲲鹏搜索对应的适配软件包2、【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [问题求助] 申请mirror 企业级社区操作系统 Circle Linux
    项目名称与简介 (Project introduction)名称: CircleLinux介绍如下:Circle Linux 是国际化社区驱动的开源软件,使命在与努力专注于围绕 Linux 平台提供更强大的开源生态。提供企业级、生产环境就绪的 Linux 发行版。Global Community-driven Opensource software effort focus on delivering a robust open source ecosystem around a Linux platform.bring you Enterprise-grade, Production-ready Linux Distro.官网:www.cclinux.orgGitHub:https://github.com/circle-linux上游地址与镜像方法 (How to mirror)rsync -avh rsync://msync.cclinux.org/circle/pub/ . 镜像大小 (Mirror size)目前是400G,建议预留,随着全新版本的发布容量随之可能会到600G左右。备注 (Note)非常感谢你们提供的镜像服务,希望可以早日使用华为mirrors 提供的CircleLinux的Mirror 。Best Regards !以下是一些详细介绍和近期的进展:Circle Linux是扮演了昔日CentOS的角色。 CircleLinux企业级OS社区简况:社区官网 www.cclinux.orgGit仓库 git.cclinux.orgYUM源 mirror.cclinux.orgBuild系统 koji.cclinux.org社区论坛 talk.cclinux.orgwiki系统 wiki.cclinux.org国内mirrors:mirrors.tencent.com/circlemirrors.aliyun.com/circle国际mirrors:mirrors.xtom.de/circle网易163 mirrors 正在同步...您好 华为开源mirrors, 目前已有三家云厂商添加,辛苦华为云mirrors添加,非常感谢。
  • [公告] MindSpore社区成立易用性SIG,欢迎加入!
    2022年3月17日,MindSpore社区技术委员会(TSC)决议通过MindSpore易用性SIG的申请,正式成立MindSpore易用性SIG。SIG介绍见主页:https://gitee.com/msu-sig 打通开源软件使用的“最后一公里”打开软件安装指南,却发现不支持本机的操作系统;开始安装了,却提示需要手动预装N多三方依赖;API文档翻了好几遍,却找不到一段想要的示例代码;好不容易运行起来了,系统抛了个错误,提示信息却又看不懂了;想找找前人类似的经验,却发现怎么也找不到合适的案例……在许多开源软件的使用过程中,你是否也遭遇过类似的尴尬情况,从而被迫放弃使用?软件正在吞噬世界。在开源软件不断蓬勃发展的今天,能够真正赢得开发者青睐的开源软件却是寥寥,这提示我们,开源软件除了要把核心功能做稳定、关键竞争力做强之外,还需要在易用性上狠下功夫,不断提升开发者的使用体验,才能真正获得开发者的青睐。为此,MindSpore社区成立了易用性SIG(Usability SIG),来帮助各位开发者打通使用过程中的“最后一公里”。从今年起,易用性提升也会成为MindSpore的重点发力方向,随着API/算子/模型/套件快速补齐、文档信息结构优化、多平台安装陆续支持、以及报错解决地图的投入使用,相信今年会带给各位开发者一个易用性全面提升的AI框架,让“最后一公里”畅通无阻。 易用性SIG的愿景与目标作为和开发者进行连接的桥梁,易用性SIG的目标是和开发者共同打造易学易用、灵活高效的AI框架,持续提升MindSpore易用性,助力开发者成功。易用性SIG是一个倾听开发者声音的渠道,你可以在这里直接提出对MindSpore易用性的改进需求,需求将及时反馈给MindSpore社区进行评估。易用性SIG也是一个为开发者提供帮助的渠道,在你学习和使用MindSpore的过程中,对于文档信息体验、安装、API使用、语法/算子/模型支持、报错信息等方面有任何疑问,都可以在这里发问,SIG会通过社区互助的形式帮你答疑解惑。易用性SIG更是一个开发者共同交流和学习的平台,这里有丰富的技术活动,不仅有易用性相关特性讲解和演示,还有业界专家对AI工程方法和最佳实践进行分享,更有学术界大牛进行前沿技术分享,以及开发者现身说法,分享他们的故事与经验。我们还可以一起来开发知识问答机器人,让AI普惠每一位开发者,毕竟让开发者学好、用好MindSpore是我们最大的心愿。 在这里,你能够获得扩大自己在开源社区中的影响力:欢迎你为MindSpore易用性改进提供你的见解和建议,就有可能被社区采纳,也可以动手贡献出你的代码和技术总结,积累在开源项目中的开发经验,扩大自己在gitee指数排名第一的开源社区中的影响力;了解业界最佳实践和学术界前沿技术的机会:机器学习设计模式、动静态图统一、函数式编程、开发者体验研究……诸多话题等你来听;全栈系统化的学习资源:AI工程师知识地图、MindSpore实用技术资源集锦……助你从零基础入门AI开发,并逐步成长为资深AI工程师;丰富的实战机会:一起开发MindSpore知识问答机器人,一起动手学、动手开发各种实战案例,你也可以成长为AI开发大牛,并分享你的故事! 初始成员目前易用性SIG处在筹建阶段,已邀请到MindSpore社区内的数位专家和活跃开发者,共同作为初始成员参与SIG的运作。同时也欢迎各位开发者踊跃参与,不断壮大这个技术圈子。当前初始成员(及其gitee id)介绍如下:想飞就飞(@leon-wang2021),SIG发起人,MindSpore首席体验官Tong(@tong-zhang),SIGLead与组织者,MindSpore开发者体验专家阿青(@rudy_tan),SIG组织者,MindSpore信息体验专家aaa000(@ylfan96),SIG组织者与运营顾问,MindSpore信息体验专家Nan(@wangnan39),SIG组织者,MindSpore项目经理iambowen(@iambowen1984),SIG Contributor,MindSporeAI工程技术专家CQU弟中弟(@lvyufeng),SIGContributor,B站UP主CQU弟中弟,MindSpore资深算法工程师丁一超(@jeffDing890430),SIGContributor,华为云云享专家,昇腾优秀开发者,MindSpore资深开发者胡琦(@hu-qi),SIGContributor,华为云年度十佳博主,HUAWEI Developer Experts,MindSpore资深开发者张辉(@zhanghui_china),SIGContributor,MindSpore爱好者张小白,MindSpore资深开发者 加入易用性SIG方式扫码添加小助手的微信(vx: mindspore0328),(添加时请备注:易用性)小助手拉你进群哦!  欢迎加入,共同进步!
  • [问题求助] 开源镜像站Ascend仓库无法访问
    这里面的软件包仓库地址无法访问!
  • [优秀实践] 参与Remill复杂指令语义项目开发感受
           很高兴有机会参与华为Remill复杂指令开发的开源项目。开源在近十年来逐渐形成了一种趋势,有利于促进科研成果价值的体现。这次项目让我明白在项目实操过程中蕴藏的风险是多种多样的,人员的风险,离职率比较高,需要安排工作交接。技术的风险,如某些指令功能本身需要改造一下,就必须在与华为的负责团队充分沟通之在来修改,但是华为团队本身可能业务较多,需要协调资源。这块的工作就不少。需求理解的风险,开发和测试对BA给出的需求的理解可能出现偏差,需求没有很好地版本管理,所以有时出现BA改了需求文档,忘记通知开发和测试,或者只通知了开发,没有通知测试,或者只通知了测试,没有通知开发,各方对需求的理解不一致,导致项目后期各方扯皮。最后项目差点不能按时完成。所以我明白了在项目开发过程中应该注重各方协调,如果经常出现一些因为协调补充导致的问题,就会耗费了团队很多时间。这样会导致项目风险加深,同时给项目负责双方都带来压力       同时这次参加开源项目的机会也让我对开源项目有了更深的认识。目前国内对开源项目越来越重视,开源是创新科技的重要动力之一,但是由于国内高科技产业起步相较国外比较晚,即使我们已经拥有了这种各样的应用原件,但是我们的软件基础较为薄弱。华为作为国之重器,勇当历史使命,逐步加大基础软件领域的投入,相继开源了openEuler操作系统、openGauss数据库、MindSpore AI计算框架等重量级基础软件项目。作为专注科研的高校团队,我们团队也积极参与基础软件的开源构建生态之中,相继参与了REMILL指令语义开发、opengauss数学函数等众智开源协作项目中。  总的来说经历了项目实战,收获颇丰。既开拓了视野,也培养敢于接受挑战的勇气。同时也更清楚的认识到不断充实自身知识体系非常重要,不仅要深专专业知识,还需广泛涉猎。在实践中锻炼自己的动手能力,本着对工作严谨的态度,力求做到最好。最后感谢华为提供了鲲鹏众智平台提供了项目实践平台,在为鲲鹏生态系统做出微薄之力的同时,自身综合能力得到稳步提升。                                                                  北方工业大学--北方工业大学团队--陈征                                                                      指导教师:李阳老师
  • [优秀实践] remill语义开发项目实践心得
           开源在近十年来逐渐形成了一种趋势,开源让技术更迭更加快速,各种开源协议五花八门。开源不仅有利于继承性创新,还有利于促进科研成果价值的体现,同时开源社区的不断壮大也是大势所趋。华为作为一家以技术为根基的商业化公司,一直以来也在积极构建开源的商业模式。华为与国内的高校、机构,在课程开发、软件协作和相关的资源支持、社区学习和赛事认证方面,做出了积极的努力。很感谢华为提供鲲鹏众智这个平台,可以亲身参与到华为的开源生态建设中来。       目前国内各行各业站在开源软件的肩膀之上构建了一派繁荣的应用软件,虽然应用软件虽然非常丰富,但是基础软件却较为薄弱。华为作为国之重器,勇当历史使命,逐步加大基础软件领域的投入,相继开源了openEuler操作系统、openGauss数据库、MindSpore AI计算框架等重量级基础软件项目。作为专注科研的高校团队,我们团队也积极参与基础软件的开源构建生态之中,相继参与了REMILL指令语义开发、opengauss数学函数等众智开源协作项目中。       参与开源项目,为开源项目做贡献虽然不需要成为某个领域大牛,但需要你花费大量时间和精力去贡献,在这个过程中,你同样能够学到很多。如语义指令开发这个项目,我是先从官方文档开始了解remill项目的,并根据自己的了解,写一些博文,为项目写一些技术文档指导接下来的开发工作。通过本次项目实践,我收获了很多。首先对是对开源项目有了进一步认识,开源项目强调自主性、探索性、实践性和协助性,重在实施过程中发挥创新思维、创新实践,充分调动主观能动性,灵活运用相关知识,使自己得到锻炼和提高。回顾一年多来参加项目的经历,从开始对项目需求的理解到项目计划的讨论和确定,从对项目的整体把握到关键环节的分析,并制定详细的项目方案和进程以及后续的实施,整个过程不仅学到了我感兴趣的东西、觉得有用的东西,更重要的是自己思维能力、团队协作能力、实践能力都得到了提高,而且也学到了善于思考、积极总结的可贵精神。比如在代码效率优化方面,对于优化代码,有许多种渠道,对于不同的应用有不同的解决之道。通常情况下,同一种优化方式在不同的应用中达到的效果是不同的。对某一特定应用代码,运用多种优化方式结合使用,包括调整编译器选项、规范内存使用、合理运用循环体、profiler等优化工具使用、协处理器指令使用等,在不断的实验过程中达到最优。       项目的实施结果圆满达到预期效果,这也是我深感欣慰。在实践中,我看到了团队成员的共同进步,大家都认真完成项目进度的安排,对自己的工作负责到底,对没接触的知识,不动的技术也不畏惧,通过自己的努力克服技术壁垒,实现预定目标。虽然项目进展过程中也遇到了很多困难,但看到团队成员都以积极向上的心态去应对,正式一次次通过努力越过难关给我们带来了一段难忘的记忆。      开源项目有一个非常显著的特征,就是对社会的贡献和社会的价值。如果中国的开源生态能够基于利他和共赢的愿景之上繁荣发展,那么它一定会夯实中国软件的根基,同时在这个基础上更好地和全球的开源领域、和全球的软件开发者、和全球的公司实现合作共赢。期待后续参与华为更多开源项目,为中国开源软件贡献自己的一份力量。                                                    同济大学--认知与智能计算研发团队--徐彦军                                                                      指导教师:田春岐老师
  • [优秀实践] 基于openEuler平台下HyperMPI+毕昇编译器的HPC软件迁移项目实践心得
    HPC软件迁移openEuler项目主要是将WRF、CAMx、CESM、NEMO、ROMS、WAVEWATCH III、Bifrost,这7款软件使用鲲鹏社区发布的最新的毕昇编译器和HyperMPI来对进行相关迁移工作,其中包括编译、部署和测试等,同时对应用所涉及的周边功能组件和常见的错误,要给出相应的一些解决方法,在整个项目的实施过程中,我不仅在技术层面有大量的提升,同时对于团队协作、项目管理和对不熟悉领域的项目快速上手也有一些全新的认识。首先是在技术层面上。虽然本科期间学习过编译技术、Linux服务器等相关的专业课程,但是并没有进行一些实际的工业级项目的检验,借助这次项目的机会,在项目中实践了自己所学的东西,对Linux的命令和shell脚本更加熟悉,同时也学习了一些以前不会的命令,并且在对软件源码的编译过程中出现的一些错误,通过不断的查阅相关的资料,借助开源社区和华为那边的专家提供的一些资料,然后自己再去通过编写一些配置文件和脚本得以解决,极大地提高了自己在Linux上的编码能力。其次是在团队协作方面。本次项目中的几款软件都是气象相关的HPC开源软件,之前都没有怎么接触过。所以在项目实施之前,华为那边的技术专家,也是给我们进行了一个项目启动会和项目整体情况介绍,以及项目的实施规划。然后本次项目的指导老师刘勇,就对我们进行了一个项目分工。在整个项目的分工合作上,大家都积极地进行交流,对软件移植过程中遇到的一些问题,都会开会进行讨论,提出可行的解决方案,这样大大地避免了其他同学在移植的时候继续“踩坑”的情况,团队的成员也都集思广益,提高了在移植过程的效率,例如刚开始在移植HyperMPI的时候,大家都遇到编译报错的问题,后来通过大家一起讨论和查阅相关的文档,最终得以解决。我在想这也是当前国内一些软件所需要的,面对一些西方国家的制裁,越来越强调自主可控,华为虽然开源了自主的openEuler操作系统,但是在软件层面还需要国内很多的开发者进行协作努力,才能进一步的扩大生态,不能仅仅只靠华为等少数几个企业,在芯片和国产的桌面操作系统方面等也是如此,需要更多类似华为这样的众智项目。最后是对项目的快速上手方面。参与到本次项目中,一开始对这几款软件和华为毕昇编译器以及HyperMPI都不怎么了解,刚开始移植WRF的时候,遇到了很多错误,在排查错误的时候,一开始就是直接去找这个错误,发现很多都找不到,后面就改变方向,首先去软件的官网找这款软件的一些开发文档,然后是去GitHub找一些相关的源码,然后通过了解了这款软件的来龙去脉之后,再去一些开源论坛或者Google上结合一些编译日志来找解决方案,这对我在后续几款软件的移植上提供了非常大的帮助。例如在编译CESM的时候,安装CESM其他组件时候,一直提示github访问问题,后面切换到海外的云服务器就可以了。这对我以后上手一些其他的项目,积累了非常宝贵的解决问题的经验。最后,很荣幸感谢华为能够提供鲲鹏众智计划这样的机会,也非常感谢刘老师的指导,能够参加到本次的华为HPC软件迁移openEuler项目中,学习到了非常多的知识,同时还接触了华为那边非常优秀的工程师,并且对华为也有了一个全新的认识,在对自主知识产权的技术上,贡献了非常大的力量,包括华为鲲鹏系列的产品,和开源openEuler系统,以及建设相关的软件生态圈等等,希望以后自己也能为国产软件贡献更多的力量!                                                                                                                                                                                         重庆邮电大学-数据分析与智能决策创新团队-周召剑 指导老师-刘勇老师                                                
  • [交流吐槽] 技术带给我的思考
    1.大数据应用:分布式系统,处理海量数据,进行运算和存储技术要点:Storm、Spark、Hadoop(框架),MapReduce(负责计算),Hdfs(文件系统),Hive(数据仓库),Hbase(数据库),Zookeeper(中间件),Ambri(可视化,配置集群)2.安卓开发目前还出现了RxAndroid(响应式编程)、webFlux技术要点:开源框架,网络编程,json和xml解析,绘图原理,动画,事件机制,自定义View,数据存储,开源框架,四大组件原理,UI控件(RecycleView,TabLayout等),Material Designs3.web前端前端追求的是:页面表现,速度流畅,兼容性,用户体验等等。前端基础:js,html,css,jquery,bootstrap,node.js。jquery有点过时了。现在比较流行的前端三大框架: vue,angular,react4.web后端后端追求的是:三高(高并发,高可用,高性能),安全,存储,业务等等。python,java都可以做后端。也有少数公司用c/c++。大后端,目前很流行分布式、微服务、容器。python后端,一般用flask、django。5.PHP一般小公司刚起步,都会采用LAMP架构。也就Linux+Apache+Mysql/MariaDB+Perl/PHP/PythonPHP适合产品刚起步,快速开发,做出产品雏形,看能否适应市场。PHP 是一种创建动态交互性站点的强有力的服务器端脚本语言。6.云计算7.区块链8.人工智能9.游戏开发一般用c++。引擎有cocos2d,工具unity3d、openGL。
  • [技术干货] HarmonyOS(鸿蒙)介绍&学习资源大全
    一. 什么是HarmonyOS(鸿蒙)HarmonyOS(鸿蒙)是华为开发的一款面向未来的全场景分布式智慧操作系统,将逐步覆盖1+8+N全场景终端。对消费者而言,HarmonyOS用一个“统一的软件系统”从根本上解决消费者面对大量智能终端体验割裂的问题,为消费者带来统一、便利、安全的智慧化全场景体验。对开发者而言,HarmonyOS通过多种分布式技术,整合不同终端硬件能力,形成一个虚拟的“超级终端”。应用开发者可基于“超级终端”开发应用,聚焦上层业务逻辑,无需关注硬件差异。设备开发者可以按需调用其他终端能力,带来基于“超级终端”的创新服务体验。HarmonyOS作为一款面向未来的崭新分布式操作系统,在传统的单设备系统能力基础上,HarmonyOS提出了基于同一套系统能力、适配多种终端形态的分布式理念,能够支持手机、平板、智能穿戴、智慧屏、车机等多种终端设备,提供全场景(移动办公、运动健康、社交通信、媒体娱乐等)业务能力。必将在万物互联万物智能的全联接世界中发挥至关重要的作用。二. HarmonyOS(鸿蒙)三大系统特性1. 搭载该操作系统的设备在系统层面融为一体、形成超级终端,让设备的硬件能力可以弹性扩展,实现设备之间硬件互助,资源共享。对消费者而言,HarmonyOS能够将生活场景中的各类终端进行能力整合,实现不同终端设备之间的快速连接、能力互助、资源共享,匹配合适的设备、提供流畅的全场景体验。2. 面向开发者,实现一次开发,多端部署。对应用开发者而言,HarmonyOS采用了多种分布式技术,使应用开发与不同终端设备的形态差异无关,从而让开发者能够聚焦上层业务逻辑,更加便捷、高效地开发应用。3. 一套操作系统可以满足不同能力的设备需求,实现统一OS,弹性部署。对设备开发者而言,HarmonyOS采用了组件化的设计方案,可根据设备的资源能力和业务特征灵活裁剪,满足不同形态终端设备对操作系统的要求。HarmonyOS提供了支持多种开发语言的API,供开发者进行应用开发。支持的开发语言包括Java、XML(Extensible Markup Language)、C/C++ 、 JS(JavaScript)、CSS(Cascading Style Sheets)和HML(HarmonyOS Markup Language)。三. HarmonyOS(鸿蒙)精品资源总结1. 官网地址名称描述地址HarmonyOS官网地址官网链接地址HarmonyOS开发者官网地址开发资源官网链接地址OpenHarmony Gitee开源代码地址OpenHarmony是由开放原子开源基金会(OpenAtom Foundation)孵化及运营的开源项目,目标是面向全场景、全连接、全智能时代,搭建一个智能终端设备操作系统的框架和平台,促进万物互联产业的繁荣发展。链接地址HarmonyOS开发文档地址学习 HarmonyOS 系统能力、开发指导、API参考等,利用 HUAWEI DevEco Studio 开发工具,开发不同设备的应用,为用户带来全场景体验。链接地址示例代码这些代码也是链接到Gitee,但是做了详细的分类,比如Ability、UI、Common、AI、Data、Device、Media、Network、Security、Thread等等链接地址2.论坛地址名称描述地址华为开发者联盟论坛论坛的规模建设,需要大家一起努力去壮大链接地址CSDN HarmonyOS技术社区CSDN官方运营的HarmonyOS技术社区链接地址电子发烧友论坛电子发烧友论坛与HarmonyOS官方战略合作共建的技术社区链接地址51CTO51CTO与HarmonyOS官方战略合作共建的技术社区链接地址3. 视频地址名称描述地址HarmonyOS系统定位系统定位描述视频链接地址HarmonyOS系统架构系统架构简述视频链接地址华为开发者学堂华为开发者学堂涉及HMS、HarmonyOS、前沿技术、AGC研习社、考试认证、人才计划等模块,其中对HarmonyOS有丰富的教学视频链接地址什么是HarmonyOS介绍HarmonyOS定义及特点。链接地址HarmonyOS系统架构介绍HarmonyOS系统架构以及FA/PA原理。链接地址HarmonyOS应用开发系列课(基础篇)介绍HarmonyOS整体架构和理念,关键技术(分布式关键技术/安全和隐私/UX),应用程序框架,以及开放能力和工具平台。链接地址HarmonyOS应用开发系列课(进阶篇)介绍HarmonyOS应用程序框架,HarmonyOS分布式软总线、任务调度,分布式数据管理、安全和隐私设和UX体验设计等内容。链接地址HarmonyOS应用开发系列课(高级篇)HarmonyOS系列课程,快速上手HarmonyOS应用开发。链接地址HarmonyOS应用开发系列课(案例篇)HarmonyOS开发者实战经验和案例分享。链接地址HarmonyOS 鸿蒙,华为全场景发布会HarmonyOS 鸿蒙,华为全场景发布会链接地址华为鸿蒙系统取代不了安卓,两者根本不在一个赛道华为鸿蒙系统取代不了安卓,两者根本不在一个赛道链接地址4. API手册名称描述地址HarmonyOS Java API手册开发手册链接地址HarmonyOS Native(C语言) API手册开发手册链接地址HarmonyOS JS API手册开发手册链接地址5. 开发工具地址名称描述地址DevEco Studio开发工具链接地址6. 超强官方资料名称描述地址资料下载涉及HarmonyOS应用开发、HarmonyOS智能硬件开发、HMS Core5.0:Smart Device链接地址官方开发指南和资源索引官方开发指南和资源索引内容非常丰富,涉及新手指引、HMS Core、AppGallert Connect、Developer Tools和非常多的资源索引,华为开发者联盟依托华为终端设备、全球平台服务和产业链资源,为开发者提供应用开发、测试、推广、变现等全方位支持。链接地址来源:华为云社区博客版块文章链接:https://bbs.huaweicloud.com/blogs/304628文章作者:李子捌
  • [技术干货] 中文预训练语言模型回顾
    论文名称:Revisiting Pre-trained Models for Chinese Natural Language Processing论文作者:崔一鸣,车万翔,刘挺,秦兵,王士进,胡国平 原创作者:崔一鸣 论文链接:https://www.aclweb.org/anthology/2020.findings-emnlp.58 转载须标注出处:哈工大SCIR1. 简介以BERT为代表的预训练语言模型在众多自然语言处理任务中取得了显著性能提升,并且随后涌现出一批效果更优的预训练语言模型。在本文中,我们将经典的预训练语言模型应用在中文场景并使用相同的实验设置去验证它们在中文领域的性能表现。同时,我们创新地提出了一种基于文本纠错的预训练语言模型MacBERT,应用纠错型掩码语言模型(MLM as correction,Mac)解决了预训练模型中“预训练-精调”不一致的问题。为了验证实验效果,我们选择了8个经典的中文自然语言处理任务,包括阅读理解、单句文本分类、句对文本分类等。大量实验结果表明所提出的MacBERT能够在大多数任务上取得显著性能提升。我们已将所有本文涉及到的中文预训练资源进行开源,希望能够进一步促进中文信息处理的研究与发展。2. 构建中文预训练系列模型首先,我们提出了一整套的中文预训练系列模型,以构建较为完整的基线系统并为后续工作提供相对标准的参照数据。我们主要训练了以下几种预训练语言模型:BERT-wwm:我们在谷歌原版中文BERT-base[1]的基础上,将全词掩码技术(Whole Word Masking,wwm)应用在中文环境,即在掩码语言模型(Masked Language Model,MLM)中使用词粒度进行掩码。我们使用了LTP[2]作为中文分词工具。需要注意的是,虽然掩码粒度为词,但模型的输入仍然以字为粒度(使用WordPiece分词)进行切分,即与原版BERT并无差别。XLNet:Yang等人提出基于Transfromer-XL构建了XLNet模型[3],解决了BERT的“预训练-精调”不一致的问题,提出了Permutation Language Model。与BERT不同的是,XLNet采用了sentencepiece进行分词,因此分词粒度更大。RoBERTa-wwm:RoBERTa模型[4]由Liu等人提出,进一步挖掘了BERT的潜力。我们训练的RoBERTa-wwm与BERT-wwm类似,但从中删除了Next Sentence Prediction(NSP)预训练任务,并使用了全词掩码技术。需要注意的是,与英文RoBERTa不同,这里我们同样使用了WordPiece分词。通过后续实验发现WordPiece相比sentencepiece在中文预训练模型中更有效。ELECTRA:Clark等人提出一套全新的生成器-判别器架构的预训练模型ELECTRA[5],其中生成器是一个小型的MLM,用于替换输入文本。而判别器则是判断输入文本是否经过替换。由于判别器只需进行二分类,相比传统MLM来说效率更高。在下游任务精调中,我们只使用判别器。3. MacBERT为了解决预训练模型中的“预训练-精调”不一致的问题,我们巧妙地修改了掩码语言模型,并提出基于文本纠错的掩码语言模型(MLM as correction,Mac)。该方法不需要对现有结构进行任何改动,只需针对掩码方式进行改变,因此极大程度地保留了BERT的原始特性,并可以无缝迁移到任何使用BERT的下游任务精调代码中。 具体地,针对掩码语言模型任务,我们进行了如下修改:我们使用全词掩码技术以及N-gram掩码技术来选择待掩码的token,其中unigram至4-gram的概率分别为40%、30%、20%、10%。为了解决[MASK]标记在下游任务中不会出现的问题,我们提出使用相似词来替换[MASK]标记。我们使用Synonyms库[6]来获取待掩码单词的相似词。在N-gram掩码时,我们针对N-gram中的每个词均进行相似词替换。在少数情况下,当相似词不存在时,我们将使用词表中的随机词进行替换。与原版BERT类似,我们对输入序列总长度15%的token进行掩码,其中80%的情况下会替换为相似词,10%的情况下会替换为随机词,剩余10%则不进行任何替换(负样本)。下表给出了几种不同的掩码方式的对比示例。表1 不同掩码方式的对比除此之外,由于ALBERT模型[7]在众多自然语言处理任务上获得显著性能提升,我们采用了其中的Sentence Order Prediction(SOP)预训练任务来替换BERT中的Next Sentence Prediction(NSP)任务。在SOP任务中,正样本由相邻的两个片段构成,而负样本则是将两个片段的顺序进行倒置。4. 实验4.1. 预训练模型设置接下来简要介绍预训练模型的训练设置,详细内容请参考论文的4.1节。预训练数据:我们采用了中文维基百科数据(同时保留简体和繁体中文)以及额外爬取的中文数据(包括百科、问答、新闻等),总词数达到了5.4B。在模型中我们以ext标记采用扩展数据的BERT或RoBERTa模型。基本参数:我们对所有模型(除XLNet)采用了统一预训练词表,与原版中文BERT-base相同,包含21128个token。序列最大长度设置为512。训练设备:根据模型规模大小,我们采用了单个TPU v3或者TPU v3-32进行训练。4.2. 下游精调数据集我们选用了以下8个中文自然语言处理数据集:阅读理解:CMRC 2018[8],DRCD[9],CJRC[10] 单句文本分类:ChnSentiCorp[11],THUCNews[12] 句对文本分类:XNLI[13],LCQMC[14],BQ Corpus[15]为了保证结果的稳定性,对于每一组实验结果,我们均运行10次,并汇报其平均值和最大值。相关实验超参设置请参考论文的表2。4.3. 实验结果本文涉及的预训练模型的部分实验结果如下表所示(详细结果请参考论文4.3节)。可以看到MacBERT在多数任务上取得了显著性能提升,尤其在机器阅读理解的各项任务中的提升更为明显。表2 CMRC 2018中文阅读理解结果4.4. 消融实验为了进一步了解性能提升的来源,我们对MacBERT-large进行了消融实验。可以看到,整个模型中最重要的部分是纠错型掩码语言模型(Mac)和N-gram掩码语言模型(NM),而相对来说模型使用NSP还是SOP预训练任务并没有对模型性能造成很大影响,因此后续工作应进一步将重点放在掩码语言模型及其变种模型的设计上。表4 MacBERT模型上的消融实验结果5. 讨论前面提到MLM任务是这类预训练语言模型最重要的组成部分。MLM类任务包括两个方面:1)如何选择需要掩码的token;2)待掩码的token替换成什么。在前面的章节中,我们已经展示了不同的选择掩码token的方法,例如全词掩码、N-gram掩码等。现在我们将探索第二个方面,即探索“待掩码的token替换成什么”。我们在CMRC 2018和DRCD数据集上进行了验证。在15%的整体掩码比例下,其中的10%将保持不变(负样例),而剩余的90%将采取如下4类方案进行对比。MacBERT:80%的词替换成相似词,10%替换为随机词;随机替换:90%的词替换为随机词;部分MASK:(BERT原始MLM)80%替换为[MASK],10%替换为随机词;全部MASK:90%的词替换为[MASK]。实验结果如下图所示。可以看到依赖于替换成[MASK]的实验设置(例如部分MASK和全部MASK)下效果相对较差,说明“预训练-精调”不一致的确会为下游任务带来一定的性能下降。而简单地将所有待掩码的词替换为随机词后,其性能显著优于依赖[MASK]的MLM方法。最后,我们使用相似词进行进一步优化后,其性能还会得到显著提升,说明MacBERT设计是有效的。6. 结论在本文中,我们回顾了经典预训练语言模型在中文场景下的性能表现,以验证这些模型在非英文语种上的通用性。同时我们提出了一种基于文本纠错的预训练语言模型MacBERT,解决了预训练模型中的“预训练-精调”不一致的问题。大量实验结果表明所提出的MacBERT能够在多数任务上带来显著性能提升。我们已将所有与本文相关的中文预训练语言模型开源,并希望能够进一步促进中文信息处理的研究与发展。基于我们在文章最后的分析讨论,未来我们将探索一种有效调整掩码比例的方法以取代手工设置的方案,从而进一步提升预训练语言模型的性能表现。7. 参考文献[1] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. BERT: Pre-training of deep bidirectional transformers for language understanding. In NAACL 2019. [2] Wanxiang Che, Zhenghua Li, and Ting Liu. LTP: A chinese language technology platform. In COLING 2010. [3] Zhilin Yang, Zihang Dai, Yiming Yang, Jaime Carbonell, Ruslan Salakhutdinov, and Quoc V Le. Xlnet: Generalized autoregressive pretraining for language understanding. arXiv preprint arXiv:1906.08237. [4] Yinhan Liu, Myle Ott, Naman Goyal, Jingfei Du, Mandar Joshi, Danqi Chen, Omer Levy, Mike Lewis, Luke Zettlemoyer, and Veselin Stoyanov. Roberta: A robustly optimized bert pretraining approach. arXiv preprint arXiv:1907.11692. [5] Kevin Clark, Minh-Thang Luong, Quoc V. Le, and Christopher D. Manning. ELECTRA: Pretraining text encoders as discriminators rather than generators. In ICLR. [6] Zhenzhong Lan, Mingda Chen, Sebastian Goodman, Kevin Gimpel, Piyush Sharma, and Radu Soricut. Albert: A lite bert for self-supervised learning of language representations. arXiv preprint arXiv:1909.11942. [7] Hailiang Wang and Yingxi Hu. 2017. Synonyms. https://github.com/huyingxi/Synonyms [8] Yiming Cui, Ting Liu, Wanxiang Che, Li Xiao, Zhipeng Chen, Wentao Ma, Shijin Wang, and Guoping Hu. A Span-Extraction Dataset for Chinese Machine Reading Comprehension. In EMNLP 2019. [8] Chih Chieh Shao, Trois Liu, Yuting Lai, Yiying Tseng, and Sam Tsai. Drcd: a chinese machine reading comprehension dataset. arXiv preprint arXiv:1806.00920. [9] Xingyi Duan, Baoxin Wang, Ziyue Wang, Wentao Ma, Yiming Cui, Dayong Wu, Shijin Wang, Ting Liu, Tianxiang Huo, Zhen Hu. Cjrc: A reliable human-annotated benchmark dataset for chinese judicial reading comprehension. In CCL 2019. [10] Songbo Tan and Jin Zhang. 2008. An empirical study of sentiment analysis for chinese documents. Expert Systems with applications, 34(4):2622–2629. [11] Jingyang Li and Maosong Sun. Scalable term selection for text categorization. In EMNLP 2007. [12] Alexis Conneau, Ruty Rinott, Guillaume Lample, Adina Williams, Samuel R. Bowman, Holger Schwenk, and Veselin Stoyanov. Xnli: Evaluating crosslingual sentence representations. In EMNLP 2018. [13] Xin Liu, Qingcai Chen, Chong Deng, Huajun Zeng, Jing Chen, Dongfang Li, and Buzhou Tang. Lcqmc: A large-scale chinese question matching corpus. In COLING 2018. [14] Jing Chen, Qingcai Chen, Xin Liu, Haijun Yang, Daohe Lu, and Buzhou Tang. The BQ corpus: A large-scale domain-specific Chinese corpus for sentence semantic equivalence identification. In EMNLP 2018.
总条数:156 到第
上滑加载中