参与者列表 Search 感谢 2020 ~ 2023.4 所有关注过 LitePress 的用户 此版已存档，详情参见 《推广名单》 《“ 参与者列表” 》 有 2,005 条评论 文派叶子 🍃 2021.07.14 目前 litepress.cn 上该功能的实现遇到了一个很难解决的问题。那就是通过爬虫爬取到的产品详情的文本是经过 wordpress.org 预处理过的，已经和 glotpress 里面的原文对应不上了…… 一个可能是解决方案是根据插件的 readme.txt 文件仿照 wordpress.org 的算法以生成原始 html 。 文派叶子 🍃 2021.07.14 有的云存储插件会替换附件在数据库中的链接。 参考这个帖子介绍的方法运行 SQL 替换之：https://litepress.cn/topic/20635 。 不凡 2021.07.14 然而两个小时过去了。。。 myelse 2021.07.13 没有没有，就是想研究一下，跟博客没有完全的关系。实际使用上来讲，redis 毕竟有商业化软件支持，更方便。没有问题了。 文派叶子 🍃 2021.07.13 这个没测试过。不过一个博客不需要在意这些吧……这俩的 key value 结构都是 O(1) 查询复杂度，已经快到几乎没时间损耗了，对这个难以理解可以去了解一下散列表这个数据结构。 他们测试的速度快慢可能是在大负载量下由两个软件的架构差异导致的 （这一部分是猜测） 。还有一种可能是做这个测试的人没控制好变量，使用了两种不同的插件来测试 memcached 和 redis，这样插件所缓存的数据范围不同，在浏览体验上就会存在差异。 myelse 2021.07.13 然而 memcached 的插件太难找了，redis 直接就 redis object cache 。 文派叶子 🍃 2021.07.13 支持多少数据类型不是判断是否落后的依据，这个是由业务场景决定的。对于 WordPress 的缓存场景，memcached 足够用了。 redis 除了用于缓存外还可以用于消息队列等复杂应用场景。 myelse 2021.07.13 我看有的地方说 memcached 的浏览体验比 redis 要快一些。 myelse 2021.07.13 哈哈，也是。 myelse 2021.07.13 好的，懂了。那就是 redis 随便用了。 memcached 是不是相比于 redis 落后了？redis 支持缓存的数据类型比 memcached 多一些？ 文派叶子 🍃 2021.07.13 总结一下就是放心的用就可以了，不用考虑单线程还是多线程。因为你博客不可能达到每秒几十万吞吐 文派叶子 🍃 2021.07.13 Redis 从 6.0 开始就支持多线程了。不过这些对个人用户完全没意义，因为单核性能已经非常过剩了。 文派叶子 🍃 2021.07.13 对不起，你是个好人 文派叶子 🍃 2021.07.13 我现在有个弯绕不开。这个译名似乎无论如何翻译都会和 「主题」 冲突。主题也是板式 or 样板 or 模板 or 样式吧……所以好纠结。 我目前有个想法是在其前面加一个主语：块板式 or 块样板 or 块模板 or 块样式。这样主题代表大范围的、整站的样式，而块 xx 则代表针对区块的小范围样式。 这样在 wordpress.org 的顶部条就是： 插件 | 主题 | 块 xx 而 Pattern 子站的标题则是：块 xx 目录 当然，目前还是个初步设想。因为这样的翻译明显和英文原文对不上了。在引入这一层讨论之后，块 xx 后面的 xx 是啥似乎不重要了，因为有了前面的主语就不会混淆和冲突了。 另外就是，主题用于指网站模板，这个说法似乎在国内是 WordPress 独创的，类似 Discuz 、织梦这些都是叫模板。于是对于从其他系统转来 WordPress 的人来说他们潜意识里会把主题和模板、样式、板式划等号。如果把 Pattern 翻译成模板、样式、板式的话估计他们会晕的，因为旧有的思维惯性被完全颠覆了。如果是块模板、块样板的话，至少能看出来是个新东西。 当然，就像前面说的，这只是一个初步想法。翻译这块我们是没你在行的，所以只是抛出一个话题探讨。 文派叶子 🍃 2021.07.13 如果没有什么特殊需求的话建议优先使用 InnoDB，InnoDB 同样是 MySQL 8.0 中的默认引擎。 InnoDB 与其他几个引擎的详细对比参见 MySQL 官方文档：https://dev.mysql.com/doc/refman/8.0/en/storage-engines.html（翻到页面底部，有个表格） lutofan 2021.07.13 并非只有这个插件会报错网站地图，其他插件的书写不规范也可能会导致这个问题； 还有就是主题 functions.php 文件开头有空行，也会导致这个问题； 建议把所有插件禁用后，逐个开启一一寻找问题插件。 smile 2021.07.13 之前 「WordPress 核心」 还有 「古藤宝插件」 都翻译为 「模式」，觉得不怎么恰当。 smile 2021.07.13 我觉得翻译成 「模板」 和 「样式」 容易造成混淆，「板式」 或者 「样板」 应该更加合适。 文派叶子 🍃 2021.07.13 似乎不太好。因为 「区块模式」 貌似不能传递出什么有价值的信息。如果是块模板、区块模板、区块样板、区块样式似乎好一点。突出的意思是这是用于古腾堡区块的样式模板，而用户则可以在此模板的基础上加上自己的内容。 我在这篇帖子里提到的 「区块目录」 的翻译似乎也不太好，因为完整的古腾堡区块应该是还附带有功能和添加按钮的。但这些 https://wordpress.org/patterns/中的内容就只单纯是 html 而已。似乎翻译成 「模板」 或者 「样式」 比较好。 smile 2021.07.13 你们觉得 「Block Pattern」 应该翻译为 「区块模式」 吗？ dgz 2021.07.12 辛苦了还一直记得这个帖子 文派叶子 🍃 2021.07.12 腾讯云的数据万象服务提供 Word 文档预览方案：https://cloud.tencent.com/product/ci 文派叶子 🍃 2021.07.12 万事的变化肯定是有人在推动的。我所说的 「天时」 及 「大环境」 是我所无法干预的东西。这些东西是由比我层次高许多倍的某个人或无数人在施加影响的。而作为我，只能对此顺应，而无法施加影响。举个例子：比如说新中国刚成立时的土地改革，这个推动者是中央，作为一个村里的地主老财除了早点把财产散掉或者出国远遁外，没有任何能力干预。 作为渺小的我，我只能干预我所可能干预的，比如说我从去年就开始到处寻求支持以筹划 WordPress 在中国的本土化工作，这些都是我所能干预的。但有些事情需要比我高无数个层次的人去干预才行，这里指的就是中国公民整体素质及消费习惯。 「小米让大家用上低价手机」 的这个例子，似乎欠妥当。因为让消费者用上更低价的手机是顺应人性的行为，并没有逆人性。既然没逆人性，那他有能力提供 1 块钱的手机，他自然可以搅动市场。 真正逆人性的应该是抬高价格来保证厂商研发投入。这一块从小米数字系列后续提价冲击高端的过程就可窥见其艰辛程度，早期著名的失败例子是小米 Note1 。小米最近一两年成功提价很大因素我觉得是国产手机整体售价都提升了。只有大家都低价，而小米自己抬价成功，才能算逆大势而为之。 所以总结一下，我会干预我所能干预的。但是中国公民整体素质和消费习惯是我所干预不了的。而我所干预不了的这个 「大环境」 或者叫 「天时」 决定了现阶段不可能让开发者愿意开源，如果强拉硬上的话，最后难免会和开发者们闹翻脸，那我们在国内存在的根基也就没了。 如果国内需要 「领头者」，也应该是某个开发者去领头，而不是我们作为平台方领头，可以是某个开发者用实际行动证明开源产品有更好的销量等等。我们如果领了这个头的话一定程度上就代表着有失公平，因为谈及 「领头」，肯定要对开源作者特殊对待，这样对闭源作者就有失公平。应该由市场去检验和筛选开发者，而不是平台，我们想活下去就必须保持中立。 sexloli 2021.07.12 你忽略了一点，这些事件的结果都是有人在推动的，有很多事就算没人去推动也会水到渠成，如果有人牵头推动至少可以让改观思维的进程加速，例如雷军当年不做低价的手机自然还有其他人做，但雷军就先做了，他至少让普通老百姓用低价提前了好几年使用到智能手机，同理如果你是那个先行者或许在国内互联网你能跟吴洪声一样成功，当然这只是臆想 文派叶子 🍃 2021.07.12 另外，补充一下。上文中所说的 「我国物质资源极大丰富，公民素质提高，人们更多的关注精神生活及数据、隐私安全」 。在不远的将来一定会实现的，国内开发者更多的拥抱开源未来也一定会随之实现，所以大可不必在现在为此忧心忡忡。天时不到，人的努力是没用的。 仔细看一看最近一百多年来中国对外状态的转变： 1840 年第一次鸦片战争 对比 1949 年紫石英号事件 1858 年瑷晖条约 对比 1969 年珍宝岛事件 1900 年八国联军侵华 对比 1950 年朝鲜战争 1950 年台海事件 对比 2016 年南海争端 中国正在以肉眼可见的速度发展，面包会有的，牛奶也会有的。 文派叶子 🍃 2021.07.12 核心是 「尊重人性」 。现阶段闭源对于一些开发者来讲是最优选择，那么就不可能通过外力干预让开发者放弃闭源 （这里直接是做不到，而不单纯是 「应不应该」 了） 。等开源对开发者来讲是最优解那天，同样也不需要谁干预，开发者会自动开源。 这一天到来的前提是：我国物质资源极大丰富，公民素质提高，人们更多的关注精神生活及数据、隐私安全。 应用市场目前的授权机制是提供对开源应用的支持的——只有激活的产品才能享受更新服务。提供更新和技术支持也是国外开源产品主流的营收策略。 另外后面会对开源应用打上开源标记，这样方便用户区分。 sexloli 2021.07.12 <!–more–> 你说的也是正确的，不应该强制开发者的行为，但是社区可以建议更好的授权策略。所以循序渐进的引导开发者和消费者的思想才是目前最好的解决方案，这不是能一步到位的，但可以起到从根本改观思维的效果，或许大多数开发者目前很难认同我的开看法，但在未来这必然是趋势，闭源项目也不是说肯定加密了，只是不能公开源码不购买不允许使用，我只是建议各位开发者大佬不要加密了，开源的项目仍然可以收费。这需要复制或借鉴国外的开源协议，需要有一个团体或机关制定并管控 （这是我个人的天真想法） 该有的版权绝对不能受到不公平待遇，但同时我也非常反对和强烈谴责滥用版权行为！ sexloli 2021.07.12 我就是想这样表达的，可能我说的不完全 文派叶子 🍃 2021.07.12 另外纠正下，这个标题有误导性。应该是 「不建议应用商店允许加密授权」 而不是” 使用加密授权”，整个 litepress.cn 及附属的所有代码、数据 (除用户隐私数据外) 都是 gpl v2 或 v3 开源的，不存在闭源情况。闭源的是应用市场中上架的商品，而不是市场本身。 文派叶子 🍃 2021.07.12 你说的这个观点，我个人其实是可以认同的。 WordPress 能发展起来很大原因是因为它基于 GPL 协议开源，这样对于用户来讲，如果使用 WordPress 及其生态设施来架设自己的平台的话，那么整个平台都将完全的 「自主可控」 并且无任何法律风险。这个优势是闭源软件所无法提供的。 而对于闭源软件来讲，尤其是由个人开发者维护的闭源软件，真正需要投入生产环境的话用户是会打怵的——因为这几乎等于是把自己企业的命脉交给别人握着，而自己则毫无办法亦无法进行任何干预，有一天维护者出事了，自己的业务也会跟着凉掉。也是基于同样的原因，litepress.cn 没有引用任何闭源及有法律争议的代码。 当然，这种重视 「自主可控」 的企业也不会从二道贩子、三道贩子手里买源码。 但，WordPress 的市场似乎没有这么简单。因为 WordPress 的用户不止有投入生产的企业，还有大量的小站长，他们对数据安全的敏感度其实并不高，于是盗版在这些人中就有了市场。 如果面向的用户群体刚好是小站长，而开发者又不闭源的话，那很有可能就真因盗版而饿死了。 于是从开发者的切身利益出发，得出这样一个结论： 开源适合面向企业 闭源适合面向个人用户 所以是否开源应该由开发者按照其面向的市场群体来自行决定最有利于自己的决策，我觉得应用市场不应该去强制限制。也就是说，任何制度都应该优先保证符合 「人性」，以大家的短期且切身的利益为出发点，不能为了某个长远的目标而要求大家短期放弃什么东西。这种 「存天理，灭人欲」 的操作，我觉得是不长久且无法推动的。 当然，严格说的话其实允许闭源应用上架的确是不道德的行为。因为这样做的话我们相当于都在吸 wordpress.org 社区的血。 但中国有中国的国情，我们的消费者群体知识付费意识最近几年虽然改观蛮大的，但还是不够。真的想让开发者开源，应该等用户的消费习惯养成了，用户会更多的因为安全性和可控性为开源产品付费时才是闭源产品应该消失的时候。到了那个时候，市场的自我调节能力会自然淘汰掉闭源应用，这也是未来的必然趋势。 所以闭源应用未来必然消亡，但这不是由谁去主动干预的，而是在用户付费意识和数据安全意识提升的前提下经市场自我调节而消亡。现阶段大环境还不成熟，不宜也不能去强行限制闭源应用，否则会影响生态积累。 ←较旧评论 1 … 19 20 21 22 23 … 67 较新评论→
《“ 参与者列表” 》 有 2,005 条评论
目前 litepress.cn 上该功能的实现遇到了一个很难解决的问题。那就是通过爬虫爬取到的产品详情的文本是经过 wordpress.org 预处理过的，已经和 glotpress 里面的原文对应不上了……
一个可能是解决方案是根据插件的 readme.txt 文件仿照 wordpress.org 的算法以生成原始 html 。
有的云存储插件会替换附件在数据库中的链接。
参考这个帖子介绍的方法运行 SQL 替换之：https://litepress.cn/topic/20635 。
然而两个小时过去了。。。
没有没有，就是想研究一下，跟博客没有完全的关系。实际使用上来讲，redis 毕竟有商业化软件支持，更方便。没有问题了。
这个没测试过。不过一个博客不需要在意这些吧……这俩的 key value 结构都是 O(1) 查询复杂度，已经快到几乎没时间损耗了，对这个难以理解可以去了解一下散列表这个数据结构。
他们测试的速度快慢可能是在大负载量下由两个软件的架构差异导致的 （这一部分是猜测） 。还有一种可能是做这个测试的人没控制好变量，使用了两种不同的插件来测试 memcached 和 redis，这样插件所缓存的数据范围不同，在浏览体验上就会存在差异。
然而 memcached 的插件太难找了，redis 直接就 redis object cache 。
支持多少数据类型不是判断是否落后的依据，这个是由业务场景决定的。对于 WordPress 的缓存场景，memcached 足够用了。 redis 除了用于缓存外还可以用于消息队列等复杂应用场景。
我看有的地方说 memcached 的浏览体验比 redis 要快一些。
哈哈，也是。
好的，懂了。那就是 redis 随便用了。
memcached 是不是相比于 redis 落后了？redis 支持缓存的数据类型比 memcached 多一些？
总结一下就是放心的用就可以了，不用考虑单线程还是多线程。因为你博客不可能达到每秒几十万吞吐
Redis 从 6.0 开始就支持多线程了。不过这些对个人用户完全没意义，因为单核性能已经非常过剩了。
对不起，你是个好人
我现在有个弯绕不开。这个译名似乎无论如何翻译都会和 「主题」 冲突。主题也是板式 or 样板 or 模板 or 样式吧……所以好纠结。
我目前有个想法是在其前面加一个主语：块板式 or 块样板 or 块模板 or 块样式。这样主题代表大范围的、整站的样式，而块 xx 则代表针对区块的小范围样式。
这样在 wordpress.org 的顶部条就是：
插件 | 主题 | 块 xx
而 Pattern 子站的标题则是：块 xx 目录
当然，目前还是个初步设想。因为这样的翻译明显和英文原文对不上了。在引入这一层讨论之后，块 xx 后面的 xx 是啥似乎不重要了，因为有了前面的主语就不会混淆和冲突了。
另外就是，主题用于指网站模板，这个说法似乎在国内是 WordPress 独创的，类似 Discuz 、织梦这些都是叫模板。于是对于从其他系统转来 WordPress 的人来说他们潜意识里会把主题和模板、样式、板式划等号。如果把 Pattern 翻译成模板、样式、板式的话估计他们会晕的，因为旧有的思维惯性被完全颠覆了。如果是块模板、块样板的话，至少能看出来是个新东西。
当然，就像前面说的，这只是一个初步想法。翻译这块我们是没你在行的，所以只是抛出一个话题探讨。
如果没有什么特殊需求的话建议优先使用 InnoDB，InnoDB 同样是 MySQL 8.0 中的默认引擎。
InnoDB 与其他几个引擎的详细对比参见 MySQL 官方文档：https://dev.mysql.com/doc/refman/8.0/en/storage-engines.html（翻到页面底部，有个表格）
并非只有这个插件会报错网站地图，其他插件的书写不规范也可能会导致这个问题；
还有就是主题 functions.php 文件开头有空行，也会导致这个问题；
建议把所有插件禁用后，逐个开启一一寻找问题插件。
之前 「WordPress 核心」 还有 「古藤宝插件」 都翻译为 「模式」，觉得不怎么恰当。
我觉得翻译成 「模板」 和 「样式」 容易造成混淆，「板式」 或者 「样板」 应该更加合适。
似乎不太好。因为 「区块模式」 貌似不能传递出什么有价值的信息。如果是块模板、区块模板、区块样板、区块样式似乎好一点。突出的意思是这是用于古腾堡区块的样式模板，而用户则可以在此模板的基础上加上自己的内容。
我在这篇帖子里提到的 「区块目录」 的翻译似乎也不太好，因为完整的古腾堡区块应该是还附带有功能和添加按钮的。但这些 https://wordpress.org/patterns/中的内容就只单纯是 html 而已。似乎翻译成 「模板」 或者 「样式」 比较好。
你们觉得 「Block Pattern」 应该翻译为 「区块模式」 吗？
辛苦了还一直记得这个帖子
腾讯云的数据万象服务提供 Word 文档预览方案：https://cloud.tencent.com/product/ci
万事的变化肯定是有人在推动的。我所说的 「天时」 及 「大环境」 是我所无法干预的东西。这些东西是由比我层次高许多倍的某个人或无数人在施加影响的。而作为我，只能对此顺应，而无法施加影响。举个例子：比如说新中国刚成立时的土地改革，这个推动者是中央，作为一个村里的地主老财除了早点把财产散掉或者出国远遁外，没有任何能力干预。
作为渺小的我，我只能干预我所可能干预的，比如说我从去年就开始到处寻求支持以筹划 WordPress 在中国的本土化工作，这些都是我所能干预的。但有些事情需要比我高无数个层次的人去干预才行，这里指的就是中国公民整体素质及消费习惯。
「小米让大家用上低价手机」 的这个例子，似乎欠妥当。因为让消费者用上更低价的手机是顺应人性的行为，并没有逆人性。既然没逆人性，那他有能力提供 1 块钱的手机，他自然可以搅动市场。
真正逆人性的应该是抬高价格来保证厂商研发投入。这一块从小米数字系列后续提价冲击高端的过程就可窥见其艰辛程度，早期著名的失败例子是小米 Note1 。小米最近一两年成功提价很大因素我觉得是国产手机整体售价都提升了。只有大家都低价，而小米自己抬价成功，才能算逆大势而为之。
所以总结一下，我会干预我所能干预的。但是中国公民整体素质和消费习惯是我所干预不了的。而我所干预不了的这个 「大环境」 或者叫 「天时」 决定了现阶段不可能让开发者愿意开源，如果强拉硬上的话，最后难免会和开发者们闹翻脸，那我们在国内存在的根基也就没了。
如果国内需要 「领头者」，也应该是某个开发者去领头，而不是我们作为平台方领头，可以是某个开发者用实际行动证明开源产品有更好的销量等等。我们如果领了这个头的话一定程度上就代表着有失公平，因为谈及 「领头」，肯定要对开源作者特殊对待，这样对闭源作者就有失公平。应该由市场去检验和筛选开发者，而不是平台，我们想活下去就必须保持中立。
你忽略了一点，这些事件的结果都是有人在推动的，有很多事就算没人去推动也会水到渠成，如果有人牵头推动至少可以让改观思维的进程加速，例如雷军当年不做低价的手机自然还有其他人做，但雷军就先做了，他至少让普通老百姓用低价提前了好几年使用到智能手机，同理如果你是那个先行者或许在国内互联网你能跟吴洪声一样成功，当然这只是臆想
另外，补充一下。上文中所说的 「我国物质资源极大丰富，公民素质提高，人们更多的关注精神生活及数据、隐私安全」 。在不远的将来一定会实现的，国内开发者更多的拥抱开源未来也一定会随之实现，所以大可不必在现在为此忧心忡忡。天时不到，人的努力是没用的。
仔细看一看最近一百多年来中国对外状态的转变：
中国正在以肉眼可见的速度发展，面包会有的，牛奶也会有的。
核心是 「尊重人性」 。现阶段闭源对于一些开发者来讲是最优选择，那么就不可能通过外力干预让开发者放弃闭源 （这里直接是做不到，而不单纯是 「应不应该」 了） 。等开源对开发者来讲是最优解那天，同样也不需要谁干预，开发者会自动开源。
这一天到来的前提是：我国物质资源极大丰富，公民素质提高，人们更多的关注精神生活及数据、隐私安全。
应用市场目前的授权机制是提供对开源应用的支持的——只有激活的产品才能享受更新服务。提供更新和技术支持也是国外开源产品主流的营收策略。
另外后面会对开源应用打上开源标记，这样方便用户区分。
<!–more–> 你说的也是正确的，不应该强制开发者的行为，但是社区可以建议更好的授权策略。所以循序渐进的引导开发者和消费者的思想才是目前最好的解决方案，这不是能一步到位的，但可以起到从根本改观思维的效果，或许大多数开发者目前很难认同我的开看法，但在未来这必然是趋势，闭源项目也不是说肯定加密了，只是不能公开源码不购买不允许使用，我只是建议各位开发者大佬不要加密了，开源的项目仍然可以收费。这需要复制或借鉴国外的开源协议，需要有一个团体或机关制定并管控 （这是我个人的天真想法） 该有的版权绝对不能受到不公平待遇，但同时我也非常反对和强烈谴责滥用版权行为！
我就是想这样表达的，可能我说的不完全
另外纠正下，这个标题有误导性。应该是 「不建议应用商店允许加密授权」 而不是” 使用加密授权”，整个 litepress.cn 及附属的所有代码、数据 (除用户隐私数据外) 都是 gpl v2 或 v3 开源的，不存在闭源情况。闭源的是应用市场中上架的商品，而不是市场本身。
你说的这个观点，我个人其实是可以认同的。
WordPress 能发展起来很大原因是因为它基于 GPL 协议开源，这样对于用户来讲，如果使用 WordPress 及其生态设施来架设自己的平台的话，那么整个平台都将完全的 「自主可控」 并且无任何法律风险。这个优势是闭源软件所无法提供的。
而对于闭源软件来讲，尤其是由个人开发者维护的闭源软件，真正需要投入生产环境的话用户是会打怵的——因为这几乎等于是把自己企业的命脉交给别人握着，而自己则毫无办法亦无法进行任何干预，有一天维护者出事了，自己的业务也会跟着凉掉。也是基于同样的原因，litepress.cn 没有引用任何闭源及有法律争议的代码。
当然，这种重视 「自主可控」 的企业也不会从二道贩子、三道贩子手里买源码。
但，WordPress 的市场似乎没有这么简单。因为 WordPress 的用户不止有投入生产的企业，还有大量的小站长，他们对数据安全的敏感度其实并不高，于是盗版在这些人中就有了市场。
如果面向的用户群体刚好是小站长，而开发者又不闭源的话，那很有可能就真因盗版而饿死了。
于是从开发者的切身利益出发，得出这样一个结论：
所以是否开源应该由开发者按照其面向的市场群体来自行决定最有利于自己的决策，我觉得应用市场不应该去强制限制。也就是说，任何制度都应该优先保证符合 「人性」，以大家的短期且切身的利益为出发点，不能为了某个长远的目标而要求大家短期放弃什么东西。这种 「存天理，灭人欲」 的操作，我觉得是不长久且无法推动的。
当然，严格说的话其实允许闭源应用上架的确是不道德的行为。因为这样做的话我们相当于都在吸 wordpress.org 社区的血。
但中国有中国的国情，我们的消费者群体知识付费意识最近几年虽然改观蛮大的，但还是不够。真的想让开发者开源，应该等用户的消费习惯养成了，用户会更多的因为安全性和可控性为开源产品付费时才是闭源产品应该消失的时候。到了那个时候，市场的自我调节能力会自然淘汰掉闭源应用，这也是未来的必然趋势。
所以闭源应用未来必然消亡，但这不是由谁去主动干预的，而是在用户付费意识和数据安全意识提升的前提下经市场自我调节而消亡。现阶段大环境还不成熟，不宜也不能去强行限制闭源应用，否则会影响生态积累。