@VinsonGuo 首富和你人均一下能买的更多。

@szopen 在你描述的前提下，你这个 PR 的应用场景是？『如果只是为了冷启动的性能，那么这个方案与现有的文件缓存相比优势在何处』

@shm7 https://github.com/Lambda-3/Graphene 知识图谱相关的用 java 写的还是不少的。就算是 object detention，YOLO 也是拿 c 写的，python 也就在上面封一层。

感觉现在有些人做科研写 python 写多了，还能写出我就是无可取代的错觉，呵呵

@abersheeran hmm，实际上新建 RFC 是不需要的。任何人都可以向 internal 邮件组发邮件，说明自己想要提一个新的 RFC，并且简要说明你打算写什么相关的（一句话即可，说清楚就行，不需要证明合理、有用等等，反正我还没见过申请 wiki 账号被拒绝的），然后就会拥有一个 wiki 账号，就可以按照我在 3 楼发的链接自己去新建 RFC 并且完成
@CismonX 提到的一系列流程了。其中，只有投票这一步，是有资格要求的。
又或者，你对弄一个自己的 RFC 不感兴趣，只是想有事没事去吐槽一下别人的 RFC （参与讨论），那就更简单了，订阅 internal 的邮件列表就可以回邮件参与讨论了。

补一个邮件列表的链接： https://externals.io/message/111965

其次这个不算一个正式的 RFC，如果想写 RFC 请参考 https://wiki.php.net/rfc/howto

最后，我尝试总结并翻译一下邮件中其他人提到的疑问（因为这也好几天前的邮件了，我不记得当时有看到作者或者其他人给出强有力的解答）

『 OPCache 本身并没有保证实现的稳定性，换言之，某个版本编译出来的 opcode，在下一个版本（包括小版本），甚至对于 nightly 来说，某几个提交后，就不能够执行了。PHP 目前自己的做法是如果失效了就直接从源文件（.php ）生成一份新的 opcode 。但是对于你这个提交，因为没有源文件，那这个问题怎么解决？』

nikita 提出了关于应用场景的问题。因为如果是想尝试取代分发源文件的形式去部署应用，那意味着需要去保证 opcache 生成出来的 opcode （在不同版本间）的稳定性，这几乎是不可能的（工作量太大，没人想去做）。如果只是为了冷启动的性能，那么这个方案与现有的文件缓存相比优势在何处

如果是商业软件为了避免源码泄露采取这种方式，有人提到结合 docker 似乎可以（因为相当于把 php 解释器本身也固定下来了）←我个人并不认为这是一种值得尝试的做法。一来如果你真想这么做现在就可以了。二来更新使用的解释器版本更多的是为了避免潜在的 bug，因此用 docker 不代表就应该不更新版本了


To 楼主，如果你能够回复上面引号内的那个问题，并且说服我的话。我可以帮你去进行沟通 /创建 RFC 之类的

@ytll21 你打一下就知道了，这是人工智障聊天机器人的语音版。

大胆点，苹果要发布 time machine 了

@Huelse
> python 是计算集中型的，java 是 io 集中型的，所以两者领域不同，不存在谁干谁
> 我又没否认这些，python 能够调用这些库而不损失效率且不失优雅不正是他的特点之一吗？
如果真的不损失效率就可以用 python 直接实现了。正是因为 python 计算太慢所以才只能用 CPP 实现然后 python 去调用。

QQ 拼音不是早就被搜狗拼音合并了么。。。现在继续坚持 QQ 拼音的好处是啥？求教

杭州的啊，那是福报。
只要没死，哦不是，死了都没啥。『上千万城市的人口，出点稀奇古怪的情况死点人也是正常的。』

『分成比例可谈，9:1 、8:2 、7:3 等各种比例都有可能，渠道拿大头，因为流量是渠道免费给的，我们只需要按时收钱就可以。』

所以哪怕渠道拿走了 90%，对于开发商来说你觉得依然是赚的么？维护的成本呢？
其次，为何不能把苹果的流量都视为这一种流量？

@OnlySeePost 小学语文都不及格，19 年的新号就闭嘴吧