deepin 然后关于乱发issues的问题，这很好理解，你不能用开源社区的思路思考遥遥领先
鸿蒙作为全球第一款完全不支持侧载，任何应用必须在商店下载的操作系统（这tm倒确实遥遥领先），你想支持鸿蒙不是编译好了就行，是要上商店给某为分成的
说白了，分成利益的驱动而已，挣钱嘛，不寒碜，仅此而已，还能有啥别的理由吗
苹果不也是要上商店吗？还得每年交保护费，不知道你单独拎华为出来是要引战还是要干什么，这就是deepin生态骨干的想法吗🤔？
deepin 苹果不也是要上商店吗？还得每年交保护费，不知道你单独拎华为出来是要引战还是要干什么，这就是deepin生态骨干的想法吗🤔？
苹果更恶心，不仅每年个人开发账户的费用，连应用内购也抽成。
deepin 能把V2ex的尸米搬上来你也是一个天才，这出了名的风中必反，逢花必反的地，能有什么好心人
v2ex只是一个中转或者说转发而已，真正的在说的是github和nas论坛的行为，你这都拎不清？不在v2ex,在别的地方也会见到有人吐槽，v2ex只是一个平台媒介而已。
deepin v2ex只是一个中转或者说转发而已，真正的在说的是github和nas论坛的行为，你这都拎不清？不在v2ex,在别的地方也会见到有人吐槽，v2ex只是一个平台媒介而已。
问题是存在，但是V2ex你这套就是典型的“技术无罪论”，没多大实际意义。
Popular Events
More
中文 
原帖：https://v2ex.com/t/1131883
在path-to-regexp项目的测试结果写“基于OpenHarmony系统，我们对dayjs的原生库测试用例进行了单元测试。”
关于这段话的翻译：
关于我们在初始提案中提到的“OpenHarmony支持”声明，确实存在不准确之处。实际上，由于OpenHarmony支持Node.js，path-to-regexp库可以直接在OpenHarmony环境中运行，无需任何额外的代码适配工作。
由于OpenHarmony采用了新的软件中心仓库OHPM，我们JS项目的构建/打包过程与传统的NPM方法有所不同。之前，我们计划将相关的打包脚本提交给path-to-regexp社区。然而，正如大家所指出的，将这些配置放在GitHub Actions中可能更为合适。我们完全理解，这一操作可能会给path-to-regexp项目带来额外的维护负担。
基于以上考虑，我们提出一个更轻量级的合作方案：我们将使用我们自己的自动化构建平台定期构建path-to-regexp，并将构建产物发布到OHPM。在此过程中，我们将明确标注path-to-regexp为上游项目。同时，我们也希望path-to-regexp社区能在项目的README中添加一个指向OHPM平台上的库的链接，以便更多开发者了解其在OpenHarmony生态系统中的应用。
↓还有更搞笑的，评论区说这个项目都是第一个适配支持开源鸿蒙的开源项目，居然还在提issue说要适配鸿蒙，这说明了什么？
不过我点进去这个issue已经删除了。发现网页时光机有记录：
评论区说连飞牛都没逃得过：
大家也可以在bing里面搜索以下关键词，可能会有更多有意思的东西。
Proposal for OpenHarmony Adaptation of
这些人到底是机器人，还是魔怔了？还是利益相关的人？