哈哈，我要举报楼主抄袭我的凡体文。也许这里可以看出 react 生态远比 vue 生态强势的地方，目前看到的包括楼主的在内的三个 macos 和一个 ubuntu 都是 react 写的，感觉以后如果要学习的话都是不错的参考资料。另外捉个虫，我默认状态打开之后，如果开启 safari，并点击全屏按钮后样式会变得奇怪。

@sky96111 我实测就是 virtualbox 会黑屏，新建虚拟机不能操作，无法挂载镜像

@8e47e42 没看懂，他说 vmware 会使用 whp，也没见说哪里要经过特别设置才能用

算法的话，个人想法是，首先将每个等式标准化，然后依次搜索出现频率最低的变量，将其消去，最后求解。循环直到所有变量都解明

@oppoic 也许是看中了插件的权限？这种已经有一定存量的如果被拿去做灰产，破坏性很大的吧

大概本质还是因为前端程序员的水平差距像海一样深吧。。es6 之后，在良好的编码规范和良好的注释下其实可以达到 ts 相同效果（由于没到语言级别规范，IDE 补全方面会有缺失，不过总体而言堪用）。但实际项目中很难要求前端程序员严格遵守这些规则，由此产生了屎山。

这个问题可以分为几个方面。单纯表现上，pypy 在主流编程语言的 jit 解释器里基本排在最后一名或者倒数第二名，不过客观上讲这不是由于 pypy 技术落后，单纯是因为 python 本身是一门非常动态的语言，这给 jit 带来了很多难题，即使使用了 partial evaluation 等技术，同样难以优化到 java jit 的水平线。

不过 pypy 项目的存在本身也是开发效率即解释效率的一个例子，很多人坚持否认的，认为高效开发无用，实际上 pypy 已经出来这么多年而 cpython 的 jit 仍然在难产足以说明问题。可以想见的是如果 python 的一些现代特性被早一些加入的话，各应用领域（比如 web ）当中的市场份额可能会有大翻转，这也体现出互联网项目推广中的时也运也的一面。

具体坑的层面的话，一个共识是 python 一直以来的运行生态，从不依赖于 jit，可以看得出来 guido 从设计层面认为 ffi 扩展相比于始终不理想的 jit 是更好的解决方案，这也造成了目前的 py 生态。而 pypy 的 cffi 效率和兼容性差几乎成为制约其发展的主流因素，这也是为什么 pyston 这种提升很少性能，但具有完整嵌入支持的项目，即使仍在闭源状态，许多人仍然更看好它的因素。

python 优化的另一个方向可能是最近的 mypyc 项目，我觉得这个方向是对的，一如当初 cython 在 py 中引入类型后效率直接起飞一样，虽然这套方案在今天已经有更好的选择。很多事情如果程序员能低成本地实现，那么不要交给程序，程序处理起来反而会很复杂。

@IgniteWhite 我不是完全从头做的意思，我的意思大体上是希望使用通用材料进行组装，而不是专门为航模设计的产品进行组装，比如具体到芯片的话，我希望使用通用的开发版之类的，而不是专门设计出来的一个由别人做好，卖给航模爱好者的类似黑盒的东西

@billlee 风筝的话，小时候做过，印象中应该是有卖的蒙皮和骨架，只需要自己缝上之后拉到广场上就能飞了。我如果叫我现在做个风筝的话，我感觉主要问题可能是把龙骨烧成指定的形状最困难，具体形状方面我觉得照猫画虎应该不至于偏差太大，蒙皮方面应该是能买现成的，我觉得这些技术不太能跟航模对应的类比。因为我设想里外壳是通过 3D 打印出来的，如果叫我用木条和蒙皮组装一个空心骨架的话，我觉得难度一下会高很多

@learningman 这个贴主要是这个意思，起码单纯针对壳的话我是想从头做一个，建模我不熟，但是我有流体仿真模拟的设计经验，因为是打算当做长期爱好的，所以我觉得如果可行的话欠缺的部分可以慢慢学。不可行的例子，比如如果 3D 打印目前没有合适的材料，无论如何没法达到类似效果，那么就说明这个想法不可行，帖子里主要是想讨论这个，倒不是轻视其他学科，重看帖子可能确实会让其他专业的朋友感觉不愉快，有种他们做的工作廉价化的感觉，我本人没有这个意思，抱歉。

@abersheeran 手机打字有些问题，我那句话本来想打的是 io 复用对于本身运行效率低的 python 意义重大，打错字了手机没发现，意思变得很奇怪。我觉得跑分这个事吧，毕竟 io 的大头还是在系统调用，跑分有不同结果也正常，但毕竟单线程下 io 复用在工业界广泛应用是大家用脚投票投出来的。

flask 本身是个很优雅的框架，那它也就要承受优雅的反作用，你只能无奈说现在大家不是很接受这个

@mnssbe 操作系统做过玩具级，可以烧到虚拟机跑的那种的，我对航模的完成度期望不比这个高。如果你很清楚两者，你可以帮我详细对比一下他们在难度上有何异同

@billlee 买来风筝组装过，我没有自己烧龙骨的打算，这个帖不是这个意思

@longear 既然是可行性讨论，假设必然是大胆的，具体哪里做不到欢迎提出问题，而不是抖这种无意义的机灵。
@learningman 我觉得单人实现工业体系的说法不准确，毕竟电机之类的是要买的，不可能自己攒。我的理解中这个只是编程控制开关的问题，就像使用 gpio 控制电灯一样，当然我的理解可能很跑偏。外壳的话，不知道现在 3d 打印这么火有没有合适的材料

@greyli 不是很清楚开源项目的维护者本身如何产生利益相关，不过 io 复用为本身运行效率低下的 io 解决了大问题，本身大势所趋，fastapi 全是其中一个比较圆的轮子，且营销较好。我觉得你既然还在维护旧框架，本身是逆潮流而行，各方面不被理解也是正常的

h5 肯定不是核心问题，你浏览 V2EX 完全不会卡，那么假设你在 app 里浏览同样的内容也就理应不会卡，js 在桌面级复杂 gui 工程上也有大规模应用，卡肯定是由于这部分以外的原因导致

有一说一，主题说的倒是没错，不过辨析的意义是什么呢，又一个 python 版的回字四种写法吗

@learningman 我发这个贴确实就是想讨论你说的这些可行性的问题。外壳的话软件工程的范围内，也许我能搞出一个建模文件，也许更进一步能进行一些模拟的流体测试，判断模型飞不飞得起来，不过我不知道模型文件有没有用，有多大用。飞控算法同理，软件工程范围内的问题我能解决，剩下的问题我不懂。电机的部分不太懂，不过应有一些成熟协议。如果只是淘宝买东西然后组装，为什么不直接买成品呢，在我看来两者区别不大，且商业产品肯定是更酷一些的。

@IndexOutOfBounds 有没有意义倒可以讨论一下，我感觉应该还是有，sl 除了多核心下高效利用时间片以外，单核心中也可以避免挂起的系统调用开销啊