卫星通信

@arnofeng 够狠，敢直接打基站的主意。这玩意说严重了，是干扰、破坏通信设备，可以直接上刑法了。

这个取决于运营商，例如电信、联通或者移动等。我想您的VOIP运营商肯定和这些大佬（至少是某些地方运营商）是有协议的。

从技术上讲，比如采用软交换里常用的SIP协议，协议本身可以传递您的主叫号码（实际上可以指定任何主叫号码），关键在于运营商是否对主叫号码进行鉴权。如果不鉴权，直接放进网内，就是lz说的情况。这种情况下，您就是传110过去都没问题。

其他小伙伴说的欺诈电话问题，实际上是电信运营商管理松懈导致的。估计这些地方运营商只管和VOIP运营商进行中继对接，按话务收费，至于里面传什么号码或者呼叫，他们是不管的。

根据现有法律，实际上VOIP运营是被禁止的，属非法运营（是否合理那是另外一说）。现在网上那一堆堆的VOIP运营商，究其原因还是各地的电信、联通、移动等出于自身业绩考虑及其他利益考虑，睁只眼闭只眼而已。

@1dian01 不怕爆啊

rmbp13高配

@seiwev 我觉得ssd也是用过就回不去的东西。话说我体验时，简直就被吓到了。

@bearzx 13寸有16G高配么？顺电店员说8G是高配了，默认是4G。

@l142857 我不太清楚具体细化下去的流程，不过还是非常感谢您的说明啊。

重定向stderr后，发现问题与这个没关系。以前不知道哪位哥们在类初始化（__init__）时，调用了python logging，打开了一个log文件，但是在实例释放时居然没有关闭，因此系统运行一段时间后，无可用文件句柄，导致创建实例失败。SHIT！

话说回来，感觉logging设计也值得商榷啊。既然python本身是支持自动回收的，那设计log文件对象，完全可以在回收的时候自动关闭文件，这样就不会有问题了。

不可能吧？不受这个gov监控，也会受另一个gov监控吧。

@l142857 我看了一下2.7.6的代码，这两函数都最终调用PyEval_CallObjectWithKeywords来实例化对象。不同的是：PyInstance_New会先对类的__init__处理做一些判断。

最后，创建了一个cStringIO重定向stderr，看最终是什么结果。

有没有SSD的移动硬盘？

如果是C/C++的话，windows平台用source insight，linux平台用qt creator。

没更新。。。还是3。。都这么多年了。。

把扩展程序禁止掉一些试试。chrome自身还是相当稳定的。

@pythonee python同样适合大规模软件，比如现在比较热的openstack等。

我也认为行数不是关键，但是“可维护性”这个东西就得再考虑一下。作为一个随便弄一下的系统，您觉得会有太多的考虑么？我认为不会考虑太多。系统变大后，如果不重写某些部分甚至调整架构，哪怕单纯出于系统兼容性考虑，也只能沿用原来的处理方式，这也就是为什么会越来越糟的原因之一。

这也就是为什么我认为作者的这个项目，如果反过来，先用java随便弄一下，系统大了之后，再用python去重构，估计会有同样的结论。

所以我觉得作者这个问题，其实无关语言，换谁都这样。这更多反应的是软件工程问题，是大规模软件V1版本和V2版本演进重构的问题。比如我们自己的软件，以前全部用C/C++，后来重构了业务模块，将业务逻辑独立出来用python实现，整个系统可维护性、扩展性等各方面都更好了，但我就不能因此得出结论：python比c/c++的可维护性方面强很多，对吧？

我觉得作者弄错了。初始系统是当初随便弄一下的，必然很多东西会欠考虑。后续扩展中，也只能缝缝补补，代码自然会越来越糟。重构一个系统，一来已经对整个系统比较了解，二来会更合理地通盘考虑和设计，自然效果会好很多。这和使用什么语言没什么关系。

翻过来说，如果一开始用JAVA随便去弄，后期用PYTHON重构，估计效果也会是这样。

烧秸秆都烧了上百年了吧？不至于把半个中国都罩进去。

@meta 倒不是纠结在数字。而是如果应用到生产环境的话，毕竟还希望有稳定的工具链。如果版本变换太快，未必是件好事。

好像不久前才1.1，这个golang难道也像chrome一样会成为版本帝么？