|
锁定老帖子 主题：项目事故和安全语言
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-09-28
jack 写道 有个从表面上看起来很奇怪的事实是：司机戴安全带比不带安全带时发生的行车事故要多。不带安全带时，司机死亡率比较高，但是带了安全带时，司机死亡率是降低了，但是行人死亡率却提高了。
不带安全带时，司机需要谨慎缓慢的开车，带了安全带，司机却会 更快，更放肆地开车。 这个方面的资料 可以看下 Automobile Safety Regulation and the Incentive to Drive Recklessly:Evidence from NASCAR 和Automobile Safety Regulation 编程语言，从一种不安全语言(比如c/c++)发展到一种相对安全语言(比如C#)时,语言上安全程度提高，并不因此能够大量的减少项目事故，只能减少对开发人员威胁程度而已。而对于客户平均威胁程度却是提高了。 安全性高的语言，就像司机有了安全带一样，使得原本那些担心做不好而使得自己饭碗不保地不合格开发人员更加-------放肆了。 同样的项目 用c/c++开发，开发人员知道c/c++极易出错，开发速度故而缓慢，谨慎。尽量避免在开始就出错。项目运行时，初期出错。小错误还好，如果是系统崩溃之类的错误，有麻烦的是开发人员。 用C#开发，则因为C#和.net平台有各种各样的保证机制。相对不容易出错，比如c/c++中最麻烦的内存，资源回收和指针问题。项目运行初期也很难发现.等运行一段时间之后，出错了很有可能就需要重新设计了。 开发语言虽安全，请各位"新人司机"缓慢，谨慎驾驶。 整个的推理逻辑就有问题,你不能由交通的例子就直接套到软件开发上来 |
| 返回顶楼 | |
|
发表时间：2006-09-28
charon 写道 bigpanda 写道 robbin 写道 如果你知道一个房子里面只有一个人，然后另外一个人进去了，等他出来以后，手里拿着把血淋淋的刀，屋子里面的人已经死了。你会怎么想？你会说死无对证，屋子里面的人根本就不是那个拿刀的人杀的吗？
房间里面有鬼，是鬼杀的。 
你们再这么争论下去，也争论不出什么来。开始学习学习怎么配置Linux Kernel Debugger吧。 这个是典型的密室杀人案，最后一个离开的嫌疑最大。但是按照套路，通常结果会让人大吃一惊 突然有个问题，那个php4.4是编译成32位应用跑在64位平台上，还是直接编译成了64位的应用. 还有一个问题，只要进程还活着，它占用的内存(不管是不是泄漏了)，都会被内核跟踪到(系统并不管这个指针是不是已经是free了这个应用级别的问题)，所以要确认是不是进程惹的祸，肯定要在进程级别的内存信息才行,如果所有相关进程都不能显示出来分占了消失的3G的一部分，只能说内核的嫌疑更多一些。但如果是内核的问题，除了架LKD没有别的办法可以确认。 至于内核的成熟度，应用的越广自然越成熟，但是n多unix操作系统都在隔三差五的打补丁(不仅仅是安全补丁)，尽管其装机数巨大，也说明其还存在bug. 当然是直接编译为64位应用了。 我解释不了这个现象，我个人认为不是kernel的问题。 |
| 返回顶楼 | |
|
发表时间：2006-09-28
jack 写道 有个从表面上看起来很奇怪的事实是：司机戴安全带比不带安全带时发生的行车事故要多。不带安全带时，司机死亡率比较高，但是带了安全带时，司机死亡率是降低了，但是行人死亡率却提高了。
不带安全带时，司机需要谨慎缓慢的开车，带了安全带，司机却会 更快，更放肆地开车。 这个方面的资料 可以看下 Automobile Safety Regulation and the Incentive to Drive Recklessly:Evidence from NASCAR 和Automobile Safety Regulation 编程语言，从一种不安全语言(比如c/c++)发展到一种相对安全语言(比如C#)时,语言上安全程度提高，并不因此能够大量的减少项目事故，只能减少对开发人员威胁程度而已。而对于客户平均威胁程度却是提高了。 安全性高的语言，就像司机有了安全带一样，使得原本那些担心做不好而使得自己饭碗不保地不合格开发人员更加-------放肆了。 同样的项目 用c/c++开发，开发人员知道c/c++极易出错，开发速度故而缓慢，谨慎。尽量避免在开始就出错。项目运行时，初期出错。小错误还好，如果是系统崩溃之类的错误，有麻烦的是开发人员。 用C#开发，则因为C#和.net平台有各种各样的保证机制。相对不容易出错，比如c/c++中最麻烦的内存，资源回收和指针问题。项目运行初期也很难发现.等运行一段时间之后，出错了很有可能就需要重新设计了。 开发语言虽安全，请各位"新人司机"缓慢，谨慎驾驶。 这让我想起接下来的故事，话说在美国上个世纪电气时代，随着汽车普及事故死亡率不断上升（那边主要是汽车和汽车撞，撞人的比较少见）。专家研究说了：一要加强安全意识教育，二要提高路面质量。大家觉得很有道理，照做。但是事故死亡率还是不断上升，原来对司机个体来说事故死亡率下降了，但是汽车总体数量快速增加，所以事故总量越来越多。还有什么办法？终于有人研究出安全气囊这个东西，加强了被动保护。 所以回到主题靠‘谨慎驾驶’减少撞死行人的愿望是好的，但是够不够呢？是不是需要‘车外安全气囊’呢？ |
| 返回顶楼 | |
|
发表时间：2006-09-29
jack 写道 ddd 写道 robbin 写道 但是C/C++就不一样，这些东西一旦内存泄漏，就根本找不回来了，不重起整个操作系统，根本就没有戏，可以说危害极大。 你说的这个用c/c++做的系统包含操作系统么? 如果不包括的话,应用程序内存泄露是无所谓的,用不着重起操作系统. 呵呵 俺做的c/c++程序都是24*7的那种，或者努力实现24*7的,内存泄露，内存碎片啥的，头痛的要死 什么时候会遇到内存碎片？ |
| 返回顶楼 | |
|
发表时间：2006-09-29
fustic 写道 什么时候会遇到内存碎片？
内存碎片和硬盘碎片原理差不多。 举个例子，程序刚开始运行的时候，连续五次向Heap申请内存，每次1k，然后释放了第二个，第四个，然后再申请4k内存，这4k内存不是连续的，而是分成了三片，在原来的第二块，第四块和第五块后面。这样在这4k里面读写数据就会在内存里跳来跳去，影响性能。 上面这段有错误。 举个例子，程序刚开始运行的时候，连续五次向Heap申请内存，每次1k，然后释放了第二个，第四个，然后再申请4k内存，这4k内存只能放在原来的第五块后面。如果将来申请的内存都大于1k，中间的第二块，第四块就成碎片。 http://en.wikipedia.org/wiki/Fragmentation_%28computer%29 推荐几本书， Programming Applications for Microsoft Windows, 4th Edition, by Jeffrey Richter 这本书对Win32 API讲的非常好，process, thread, job, virtual memory, heap, thread stack都讲的很清楚，概括了操作系统的很大一部分，结合API讲，比较实际，比光讲理论的操作系统教科书好理解。操作系统教科书里面谈到Windows NT/2k/XP都推荐这本书。 Memory Management: Algorithms and Implementations In C/C++，Bill Blunden,结合处理器讲，有些东西别的书里都没写，比如操作系统如何实现Atomic操作，semaphore是怎么实现的。 IA-32 Intel® Architecture Software Developer's Manual Volume 3A: System Programming Guide, Part 1，可下载： http://www.intel.com/design/Pentium4/manuals/253668.htm 操作系统是和处理器紧密结合的，唇齿相依，把这本书翻一遍可以大大加深理解，要能精通就是大牛了，可以在Linux，BSD内核里折腾了。
|
| 返回顶楼 | |
|
发表时间：2006-09-29
bigpanda 写道 要能精通就是大牛了，可以在Linux，BSD内核里折腾了。 原理很重要，不过linux内核还有个问题就是复杂性，代码互相依存，结构复杂。知道原理估计还不行，还得有驾驭这种复杂性的功力。 如果是结合linux源码讲可能真的精通后就能折腾了。 |
| 返回顶楼 | |
|
发表时间：2006-09-29
虽然是个跑题帖，但很有深度，受教不少！
我觉得的要弄清这个内存泄漏问题，除了你们提到的 Linux Kernel , 驱动程序, PHP 引擎之外，还要考虑到编译器和 CPU（内存和硬盘应该可以排除）。或许可能是 PHP 应用代码引发，说不定是特定 PHP 应用代码引发了 PHP 引擎的特定 BUG，导致一个特定的缓冲区溢出而不小心闯进了 Linux Kernel，而这一切又离不开编译器和 CPU 的某个特定 BUG，哈哈:) 问一下 robbin，同样环境下运行别 PHP 应用会有同样的内存泄漏吗？ |
| 返回顶楼 | |
|
发表时间：2006-09-29
ddd 写道 原理很重要，不过linux内核还有个问题就是复杂性，代码互相依存，结构复杂。知道原理估计还不行，还得有驾驭这种复杂性的功力。
Linux内核的代码说的好听是结构复杂，说的不好听是结构混乱，所以我现在投身到BSD去了。
|
| 返回顶楼 | |
|
发表时间：2006-09-29
bsd估计也不会简单到哪里去。
操作系统并且是功能效率都很高的操作系统这个级别的复杂度简直太大了。 |
| 返回顶楼 | |
|
发表时间：2006-10-03
jack 写道 有个从表面上看起来很奇怪的事实是：司机戴安全带比不带安全带时发生的行车事故要多。不带安全带时，司机死亡率比较高，但是带了安全带时，司机死亡率是降低了，但是行人死亡率却提高了。
不带安全带时，司机需要谨慎缓慢的开车，带了安全带，司机却会 更快，更放肆地开车。 这个方面的资料 可以看下 Automobile Safety Regulation and the Incentive to Drive Recklessly:Evidence from NASCAR 和Automobile Safety Regulation 编程语言，从一种不安全语言(比如c/c++)发展到一种相对安全语言(比如C#)时,语言上安全程度提高，并不因此能够大量的减少项目事故，只能减少对开发人员威胁程度而已。而对于客户平均威胁程度却是提高了。 安全性高的语言，就像司机有了安全带一样，使得原本那些担心做不好而使得自己饭碗不保地不合格开发人员更加-------放肆了。 同样的项目 用c/c++开发，开发人员知道c/c++极易出错，开发速度故而缓慢，谨慎。尽量避免在开始就出错。项目运行时，初期出错。小错误还好，如果是系统崩溃之类的错误，有麻烦的是开发人员。 用C#开发，则因为C#和.net平台有各种各样的保证机制。相对不容易出错，比如c/c++中最麻烦的内存，资源回收和指针问题。项目运行初期也很难发现.等运行一段时间之后，出错了很有可能就需要重新设计了。 开发语言虽安全，请各位"新人司机"缓慢，谨慎驾驶。 且不说这个交通的案例是否有权威性。这个分析也让人忍俊不禁。 司机带上安全带，就不怕死了？金钟罩护身是不是？有这样的司机啊？ 据我所知，编程经验差不多的群体中，c++程序员出错的几率远大于java程序员。仅仅是在我身边发现的例子就很多。 c++的内存问题，可不止内存泄漏一种方式。还有对内存的非法引用，会让程序直接挂掉，连处理错误的机会都没有。比如去访问一个空的指针，对同一块内存释放两次。 是的，老手的确不容易犯错误。可是不可能所有的开发人员都是老手。即使是老手，也不能完全避免犯错误。 老手如果用了好的工具，错误会更少。 |
| 返回顶楼 | |
