针对国产编程语言“木兰”被质疑“换皮Python”一事，中科院计算所编译实验室员工、“木兰”语言研发团队负责人刘雷1月18日在科学网上发布情况说明，承认其在接受记者采访中存在夸大成分，对“在网络上造成的不良影响”表示“郑重道歉”。
1月15日，刘雷在接受媒体记者采访时称，“木兰”是面向智能物联应用的编程语言，由我国科研人员自主设计、开发和实现，与之配套的编译器与集成开发工具，也由科研团队自主实现。今天的情况说明则提到，这一说法有“夸大”——“木兰语言在8位单片机上的编译器是本团队开发的，在32位单片机上的编译器是基于Python开源编译器进行的二次开发，但在接受采访中将木兰编程语言和编译器夸大为完全自主开发。” 刘雷关于“木兰”编程语言的情况说明：本人系中科院计算所编译实验室员工。基于我在编译技术上的科研积累创办了中科智芯（北京）科技有限公司，该公司围绕青少年编程教育，设计开发编程语言、编译器和集成开发环境等产品。 为了更好地在中小学中普及计算思维，本人带领团队开发了一种称为“木兰“的编程语言。它包含三个组成部分：一、在语言规范上借鉴了Lua语言的特性并进行了扩展，增加数据表达方法等新的特性；二、开发了支持少儿编程教育的可视化编程环境；三、针对8位AVR单片机，实现了相应的编译器和运行时系统，开发了能模拟多任务执行的虚拟机。以上产品已经在数百所中小学中，开展了10万人次的编程科普活动。 针对STM32单片机，我们是基于Python开源编译器进行的二次开发，也就是先将木兰语言的源程序转换为Python的中间表示（AST），再在Python虚拟机上运行。这就是在开发和运行环境中会包含Python系统的原因。 对于此次在网络上造成的不良影响，本人郑重道歉，对给中科院、中科院计算所带来的不良后果表示诚挚的歉意。本人感谢大家的监督与批评，并深刻反省，保证不再出现类似问题。更多消息，大家可以关注本次专辑…… sourceforge 社区团队最近发表了一篇文章《Open Source Is Growing, But Not How It Should》，如文章标题所言，内容表达了 sourceforge 对于开源近来发展的一些见解与担忧。
文章开门见山：开源已经发生了令人不快的事情，并且近年来变得越来越明显。从 AI 到云，开源驱动着各个领域，并且在飞速发展，但是尽管表面上似乎一切进展顺利，但实际上只有少数开发人员在做所有工作。 长期以来人们一直认为使用开源代码的流行会导致或等同于增加编写开源代码的人数，但事实并非如此，并且这种情况在最近几年变得越来越明显。根据 Stack Overflow 的最新调查，仅有 12.4％ 的受访者表示他们每月至少一次或更频繁地为开源做贡献，而 23.1％ 的受访者说他们每年进行一次以上的贡献，其余的受访者则表示，他们每年在开源上的贡献少于一次，甚至根本没有。 为什么会出现这样的情况呢？sourceforge 认为答案在于开源项目本身，其从两个方面解释了这种情况：根据技术主管 Mathew Lodge 的说法，许多开源项目可能会非常不受欢迎，尤其是对于临时开源贡献者来说，他们为了使项目维护者相信自己的价值，必须投入大量的工作，但是很多时候，贡献者不愿意或者根本无法花时间和精力来向项目维护者证明他们自己的能力。 另一方面，项目维护者的确有合理的理由要警惕临时贡献者，因为其中许多贡献可能需要花费时间来审查，导致复杂的问题或 bug，也需要文档与合并等。现在的情况是在开源贡献上提供高质量代码的人越来越稀有。 找时间做贡献：大多数贡献者都没有从编写开源软件中获得报酬，而往往开源贡献需要花费时间，并且参与贡献还需要自证价值，为样使得现在越来越多的开发者无法参与开源。sourceforge 认为采用“交易形式”可以解决这样的问题，同时这样的机制也不会造成对项目的贡献标准的降低。更多消息，请大家关注本次专辑…… 上周 Linus Torvalds 在某个论坛上讨论关于内核的相关问题时，提到了 ZFS on Linux，他表明了自己的态度，在 Oracle 对 ZFS 的代码进行重新授权以使其能更友好地被引入到 Linux 内核主线之前，他不会推荐使用 ZFS，同时，即便抛开许可证的原因，Linus 也觉得 ZFS 的综合性能并不特别强。
本周，FOSS 作者 Jim Salter 针对 Linus 影响广泛的言论进行了回应，他觉得 Linus 对于 ZFS on Linux 不了解，表示“Linus 应当避免对自己不熟悉的项目发表权威性的言论”。 关于 ZFS on Linux 许可证方面的问题，要追溯到 2019 年 1 月，当时内核开发人员 Greg Kroah-Hartman 决定禁止将某些内核符号导出到非 GPL 可加载内核模块，这直接限制了 ZFS（一度引起 ZFS On Linux 在 Linux Kernel 5.0 上陷入困境）。 内核符号导出将有关内核状态的内部信息公开给可加载的内核模块，比如_kernel_fpu_跟踪处理器浮点单元的状态，无法访问该符号，ZFS 直接访问 FPU 的外部内核模块就必须实现自己的状态保存代码。具体来讲，拒绝继续导出_kernel_fpu_符号的技术影响不是防止模块直接访问 FPU，而是阻止模块使用内核的状态管理工具来保存和恢复状态。 因此，要删除对该符号的访问，就需要模块开发人员分别重新创建自己的状态保存代码，这会增加内核本身发生灾难性错误的可能性，因为恢复状态不正确可能会导致之后的内核操作崩溃。 另一方面，通常，在包括 BSD 在内的任何平台上，ZFS 都使用 SSE/AVX SIMD 矢量优化来加速某些操作，由于无法访问该_kernel_fpu_符号，ZFS 开发人员最初被迫完全禁用 SIMD 优化，这导致了相当大的性能下降。更多内容，请关注吧本次专辑…… |
