Posts tagged 软件工程

新的革命:自由网络 vs. 安全网络

我起了一个巨大的标题。我本不该的。我希望用这样的标题党引起更多人注意这个问题,共同来解决这个世界性的世纪难题。 这篇bo的内容起始于我关于网络实名制的一些想法。但是不成熟,所以没有抛出来。很快就遇到的CSDN以及其他诸多著名网站密码流出事件,更是证明了网络安全问题其实是长久以来悬而未决的难题。后来美国又发起了SOAP的论战,当时俺兴趣不在这个上,也没有仔细去读新闻。过年回来后知后觉地追踪了下时下火热的方韩大战的新闻旧闻,说来这故事跟网络自由和安全其实有些相关性,那就是拷问网络言论究竟应不应该受到责任约束的问题。今天上午在公司无事,反过头来详细阅读了译言翻译的上许多对SOAP和PIPA的详细分析和报道。再反思以前一直思考着的,互联网未来发展的趋势;该不该实名制;用什么方式帮助大家公平地排队买火车票;怎样有效地分发和贩售知识,这种新世纪的财富;怎样有效地让人们在互联网上能够公平自由地发表言论,同时又能切实地为自己的言论负责;怎样保证信息流动性的同时还保证他的可靠性。因为一直思考着这些,发现这些问题其实源于同宗,于是就有了今天这个标题。 经过半个世纪的发展,互联网正走向新世纪,新革命。互联网极大便利人们的同时,也极大地改变,甚至可以说是,毁灭着人类。因为他的便利性地下藏着的是巨大的漏洞,无尽的陷阱。互联网最初的设计来自于学校,而目的是用于军事。也就是说,最早的互联网使用者,是科研机构和政府部门,是用于组织内部,是互相信任的不同机构的通讯网。互联网,从其设计之初的基础来看,就是一个信任网络。互联网是一个明码通信网络。当然,VPN,SSL等技术从不同层次改进了网络的安全性,但VPN并不是互联网的一部分,只是一个局域安全网,而SSL则会遇到密钥分发这个密码学永远要面对的难题,中间人攻击仍然是他的软肋。目前网络常用的用户名-密码验证机制,有着他的巨大漏洞。这绝不是说网站增强自己数据库的安全性就能解决的问题。举例而言,假如我是黑客,我完全可以建立一个用明码存储用户名密码的网站,然后用吸引眼球的东西引诱大家来注册。例如说糟糕图床,例如说二次元漫画,例如说盗版游戏下载,例如说灵异事件讨论和照片分享,等等。你会说我不沾游戏不看盗版电影不上糟糕站,那你会不会订打折机票,会不会团购旅游?恭喜你,你又中招了。黑客世界除了能逆向工程软件和系统,还有逆向社会工程学。你会说我每个网站都用不同的用户名不同的密码。但是这个世界有几个你这样的聪明人,十几亿网民中有千分之一的密码泄漏,就够养活一个师的黑客大军了。 强调绝对的网络自由的后果就是,网络不存在任何安全性可言。那就会陷入无政府主义的痛苦深渊。每个上网的人都必须是黑客,否则就是黑客押镖保护下的惊慌旅客,再不然就是待宰羔羊。网站安全要靠站长自身素质、纪律和技术支持;上网安全要靠网民自身武艺高超。那将会是一个骗子横行的世界。例如我可以开发一个720软件,密码存我这,包你上网无忧。结果实际我是地下黑客组织的大后台,我一边大肆兜售安全软件,一边就把所有人的私人信息插标出售。那你还敢信银行专用防火墙吗?那你还敢信全自动保安系统吗?那你还敢信网上银行吗?自动操盘bot?天哪没有网络安全的世界是不可想象的。 那么,反其道而行之呢?建立强有效的安全网络?问题是如何去做,问题是技术水平是否足够,问题是国际政治环境是否允许,问题是新的政策新的法律新的技术将如何影响现有的利益集团。 实名制:毫无疑问,实名制会给网络减少不少乐趣。用一个名字拉风的马甲胡吹海泡的时代一去不复返了。但是好处呢?每个人都要为自己说的话负责;或者仍然允许匿名,但是如果你用的是匿名,则你说的话根本没人搭理。谩骂、水军、造谣、煽动、这些毫无营养的网络垃圾终于可以省省了。更多的空间让给建设性的建议和评审,让给知识的有效流动。同时,实名制的信息签名制度使得一个人说的话在被复制和传播的时候他的签名被同时传播,于是制止了匿名转载,保证了CC实现。另外如果有一个强有力的独立部门承担网络ID的认证工作,则任何其他网站都不需要保存用户的密码了,于是再也没有密码泄漏问题。当然前提是那个独立认证部门必须切切实实的强有力,值得信赖。 技术难度:签名的不可复制性需要密码学的严谨论证;公民的网络ID将成为他的新一代身份证,同时也是他全部虚拟财产的钥匙,需要强有力的安全部门保证这个帐号的安全。 默认加密:现代互联网仍然是默认明文的。使用一些简易设施,任何人都能截取局域网或者wifi中传递的私人信息。加密应该在网络的底层实现,而不是依赖应用程序提供者的道德约束。问题是想要从底层修改网络协议,影响面太广,不是一日可完成的任务。并且这要求世界各国的网站齐心合力一同做到。新的IPV6协议中包含更多的安全部件,但仍然是可选项。强制安全的网络协议是未来人类的必然选择。 技术难度:向后兼容 异构云系统:这是我的独立发明。未来互联网就是云系统。但是现在的云系统都是同构的,同一个系统内部的无数并行运算组件其实是运行在同一个机房几乎完全相同硬件上的完全相同的软件。这也就是说,无论你的安全机制多么严密,只要黑客攻克了你那么一点点,那么所有的机器,所有的组件,全都被攻克了。我认为真正安全的系统必须是异构复合的。同样是处理邮件,同一个服务,在云端由不同的并行组件,就可能由成千上万种完全不同的方式处理掉(当然结果是相同的,异曲同工嘛)。这在自然界,就是称作“物种多样性”的杰作。这样黑客就算创造出一种病毒,也仅仅能摧毁某种特定类型的细胞,而其他的细胞完全不受影响。那种特定类型的细胞灭绝之后,这种病毒也就跟着一起灭绝了。要如何实现异构复合的云计算系统?毫无疑问要依赖遗传编程。啊伟大的人工智能,创造奇迹吧,改变软件工程的历史性大手笔! 技术难度:遗传编程的工程应用。于此相比,更大的难度在于安全性对于服务提供商而言是附加题,他们不会在没有利益驱动的前提下自动花大笔的精力去做。因此此事的推动需要等待互联网的进一步进步。 我写了好多,但还是太少了。但是很明显的,再多写也没有意义。推动网络革命需要的技术进步,远远比不上他所需要的社会进步那么急切。如果互联网不能进一步前进,进一步暴露他的问题,给各利益方以驱动,则即使技术摆在那里,也没有人想要去用。结果又变成了,技术拯救人类和技术毁灭人类的死亡竞速。 因此纸尽言犹,先就此收笔,静候网络发展的佳音吧。

又是命名法

命名法是个我不想再纠结的东西,不过最近又遇上了… 碰巧过完年,脑子锈掉了,居然读不懂自己年前写的代码了。我向来奉行“代码即注释”原则,也就是说…几乎不写注释…完全依靠函数和变量命名的含义来表达代码的意图和思路,除非真有复杂到需要注释的地方,例如莫名其妙的需要多线程同步的地方之外,其余一律不写注释。不过反作用就是,年前那阵子贪玩,没认真好好写代码,导致命名有点糟糕,过了年回来再读就有点绕人了… 一边改那些变量的名字,一边就遇到这个命名法的问题。我还在用匈牙利前缀,整数用n,浮点数用f,字符串用sz。现在需要自己增加几个自己的规则。 iterator类型,我原先用it做前缀,打出的代码看上去非常丑陋,例如: for(std::vector<Phone>::iterator itPhone = phoneList.begin(), itPhoneEnd = phoneList.end(); itPhone != itPhoneEnd; ++itPhone) { //… } 单纯就觉得这两个字母放在前面不搭,不美…现在我用小写t做前缀,好看多了。 for(std::vector<Phone>::iterator tPhone = phoneList.begin(), tPhoneEnd = phoneList.end(); tPhone != tPhoneEnd; ++tPhone) { //… } 当然了,这是古董代码了,有了foreach,这样的代码已经可以进垃圾堆了。不过难免用到iterator的时候俺就该记得用这个t前缀。还有就是项目里的代码我不想霰弹枪一起动,先这样放着比乱改安全很多… 受这个启发,typedef出来的变量类型用大写T前缀,例如 typedef std::vector<Phone> TPhoneList; for(TPhoneList::iterator tPhone = phoneList.begin(), tPhoneEnd = phoneList.end(); tPhone != tPhoneEnd; ++tPhone) { //… } 我喜欢typedef出几个项目中常用的容器类型。仅仅到容器类型,而iterator类型直接使用Type::iterator引用,而不进一步typedef。这样恰好保持代码的简洁程度适中,容易理解。 std::string类型用str前缀,而raw string类型(0结尾的字节序列)用sz类型,从而区分两者。这一点通常不重要,但是当你使用printf的时候: […]

Monkey Test 遐思

给公司做了个Symbian Monkey Test工具,结果跑monkey test的任务就一起承担下来。 Monkey Test其实就是个随机输入序列。我想知道这个输入序列长度同发现bug的概率的关系。 现在,一个bug的引发需要一个输入序列串。当这个输入串长度是1的时候,就是说,任意一个随机输入都可能导致bug。这样的软件其实根本不需要测试,直接砍掉重练就好了。因此需要用到monkey测试的程序,一般来说他的bug都是隐藏较深的。假如引发一个bug的输入序列长度是L。则问题就是,一个随机生成的输入序列Input(monkey),它的长度Lm,与引发一个bug所需要的输入序列Input(bug)的长度Lb的关系。 这又涉及到一个问题,就是可能的输入集合。现在我们只考虑手机触屏的话,一台640*320屏幕的手机,触屏输入集合是18万之多。但是考虑到一般的软件都使用控件,而控件一般不会太小而导致用户点击困难,可以用最小能够点击的控件大小作为单位,把屏幕切分开来,每个单元作为一个可能的输入。这就大大减小了输入集合。我们以32*32作为单元的话,一个屏幕会有200个单元格。为照顾一般性,我们设输入集合拥有a个元素。则一个长度为Lm的随机输入串,其可能的组合有aLm之多。 现在我们要考虑的是,这样一个长串中,恰好包含了输入串Input(bug)的可能性。这是一个数列求和。 第一项是Input(monkey)的第0个输入开始恰好匹配Input(bug)的概率。 第二项是从第1个输入开始匹配的概率。但还需减去与第一项重叠的部分。也就是从第0个输入开始,和从第1个输入开始,同时匹配的概率。 第三项是从第2个输入开始匹配的概率。还需减去与第一项重叠的部分以及与第二项重叠的部分。然后再补偿第一、第二、第三项同时匹配的概率。 这样的求和非常复杂,并且是否可能出现匹配的情况,其实是受Input(bug)本身的影响。这里我们作为估算,忽略掉重叠带来的误差,最后会得到一个偏乐观的结果。 于是Input(monkey)恰好包含Input(bug)的概率 p < (Lm-Lb)*a-Lb 当Lm远大于Lb时,我们可近似认为Lm与发现bug的概率成正比。于是Lm增长一倍,则p增大一倍。 由于是简单的线性关系,在Lb不变的情况下,只需简单的增大monkey test的测试序列长度,就能尽可能多地发现bug。因此我们可以预期,当Lm足够大的时候,几乎可以把所有Lb < Llimit的bug都找出来。而这个时候,进一步增长monkey test的长度就变得无效了,因为如果找完了Lb < Llimit的bug,想找到新的bug,一定都是Lb > Llimit的,换句话说,就会导致Lb的增大,而正如我们所见Lb是处于公式的指数上的。增大Lm仅能线性增大找到bug的概率,而增大Lb却导致概率指数级下降,最终导致的结果就是进一步增大Lm却很难找到新的bug了。 既然知道这个道理,我想计算出monkey test大概合适的测试长度。得到最大化的利益。我们根据上述讨论,设a = 200。根据经验bug通常有一个Lb <= 3。则如果我们希望发现一个特定bug的概率超过90%,则有 0.9 < p < (Lm – 3)*200-3 则我们的Lm需要7.2M。假如按照我们常用的设置,一秒钟执行两次操作的话,需要跑超过41天。 这个绝望的估计结果主要原因是200个的输入集合太过巨大了。假如我们仅考虑手机键盘操作的12个键的话,我们可以测试到Lb <= 5,其需要测试的步数大概是220K,按照1秒两个操作需要测试约30个小时,这就在可行范围之内了。 [编辑]这里我仅讨论了想要发现一个特定bug的情况。这是由于我们不知道软件究竟有多少个bug,为保守起见,就按照最悲观的方案来。如果想讨论多个bug的情况,例如10个,则我们仅需令10个bug都找不到的概率降低到0.1以下,则发现每个bug的概率约为0.2。注意到这里其实是对数关系,面对指数级数,这个关系不会对Lm的长度有显著贡献。 0.2 < p < (Lm-3)*200-3 将Lm缩短3.5倍,也无非是从41天降低到九天,仍然是不可接受的长度。当然你会说可以增加同时执行测试的手机数量。但是一旦Lb步长增加1,则立刻就会发现这点缩短其实无意义。[/编辑] 由此也可见,monkey test对于过于复杂以及bug隐藏过深的程序几乎不起作用,如需稳定性测试需要另求他途。

论资源抢占的系统设计

怎么会想到这个问题,出发点是来自提出一个更通用的多线程架构的问题。其实这个问题我现在讨论有点过早,因为至今还没仔细研究过go和erlang,不了解多线程编程的现状。但总归在这个blog的小小圈子里,随便抒发几句应该是问题不大。 其实我的想法是很简单的,就是想增加一个 “任务” 的概念。这个必然很多语言很多系统已经提供了,我为什么还要提。我主要是感觉,现在的多线程编程,还有网络编程,每个程序都自己定义一套多线程管理、进程池、线程池、网络连接池、数据库连接池等等概念。虽然有库函数,不必每次从头造轮子,但每个程序一份几乎完全雷同的管理机制,绝对是有问题的。 况且,现在的操作系统,除了CPU占用这一点实现了“抢占”之外,其他的系统资源仍然是依赖程序间的谦让协作的。我前几天发的帖子,就是因为adb的一个bug,导致占用了过多的系统连接,导致其他程序无法使用网络。同样的例子,臭名昭著的迅雷,因为过量占用连接数导致你根本无法上网。虽然最近迅雷提供了种种功能,他会检测你有没有使用浏览器,他会检测某些著名的端口(对应各大著名网游),确定你是不是在打游戏,等等,来谦让地给你腾出一些网络带宽。但问题是,这样看来,是不是太委屈迅雷大哥了。虽然霸占过多网络资源是他的不对,但是研究到底应该使用多少资源,并不是一个应用程序能够做到的事情(迅雷也只是经验性的猜测,你自己写的网游、小众的网络服务,他一定是无法猜测到的)。 参考CPU抢占的系统设计,其实资源抢占完全也是可以做到的。还可以参考虚拟内存的方式,给每个应用程序足够巨大的虚拟资源空间,并使用工作集、缺页调度等机制,调度所有的资源。这样擅自开辟了大量网络连接的服务(如adb),也不会导致系统无法打开更多的网络连接,霸占了大量资源的迅雷,也无法阻止其他程序连接网络(因为有工作集的限制)。操作系统可以根据资源使用的活跃程度等因素调度资源,例如当其他程序都不使用网络时,就可以让例如迅雷这样开辟了过多连接的程序拥有更大的工作集,保证系统资源的最大化利用。 好吧,话说到这里已经扯开去了。前面提到的多线程管理的机制,其实跟这个资源抢占的机制没有任何关系。只是因为思路飘忽扯到这里来了。说回那个多线程管理的问题,也是一样的,我希望提供一种机制说明任务的并发逻辑(可能要使用新的语言,至少C语言无法表达并发逻辑这种概念),然后要使用什么样的并发度,这个决定让系统来做。因为系统有多少内存资源,有多少CPU资源,这些事情本不该是应用程序该知道、该负责的事情。尤其是,跟本身的应用程序一起,系统里还有哪些其他的程序在跑,他们对内存和CPU的消耗如何,更加不是应用程序的职责范围能知道的。但是决定一个任务的并发度,必须从系统级思考问题。因此把并发逻辑列清楚之后,让系统去决策如何并发,才是最良好的策略。我不知道go语言或者erlang这些传说有着高度并发支持的语言是否已经做到这样,如果是这样的话,我就再次后知后觉了;不过作为一个思考练习,也是挺好的~(热烈欢迎评论拍砖=) 好吧,把资源抢占和这个多线程管理机制综合到一起,就变成了更系统更完善的系统管理机制。因为并发度不仅要考虑内存CPU,也要考虑硬盘、网络、设备等等等等。把所有的资源使用频率整合统筹调度,就能得到最优化的系统,当然这个多维度的最优问题,也将成为一个巨大的算法难点。也正是因为想到这里,我才感到格外兴奋。 说实话,即使用十年时间去开发出来这样一个系统也不会太迟。但要做到一点,就是对市场现有产品的兼容性。如果能运行java虚拟机,或者能兼容linux系统调用(也就是说新系统在linux的基础上修改得到,说实话我觉得这是一个靠谱的打算),或者至少旧有的程序代码通过编译能够运行在新的系统上,并且仍能体现系统的优越性,那么新东西做出来就不会没有市场没有价值。 不过我真的要跳这么个大坑么。。还是仅仅满足于YY然后坐看系统更替风云变幻?说实话,自己感觉暂时能力有限不足以完成伟任呢,或者说过于浮躁也有可能。暂时先记录一下吧,也许明天就会自否命题了呢囧||| 有时间先去研究下go和erlang哈哈:) PS. 还有一个关于通用缓冲区设计的思考练习,目前正在开发和实验中,有结果了一定写bo!

自动编程 – 语言的级别

先说一个悖论吧。 程序员的任务是让机器帮助人类做工作。 程序员的唯一工作就是开发代码。 程序员喜欢手动hack开发代码。 这就是我今天想要讨论的。 今天读到了阮一峰翻译的为什么Lisp语言如此先进?感触很深。原文Revenge of the Nerds 正如我开头说明的一样,之所以软件工程这个领域这么奇怪,有什么人月神话;有各种其他工程都完全不可能遇见的奇怪问题;即使开发得非常熟悉的类型的项目,再去开发仍然无法准确估计工期和成本;最讨厌的代码就是别人的代码,要知道别的工程领域流水线都是最重要的提高效率的方案,也就是在其他人做了某个步骤的产品基础之上在做一个步骤;即使软件工程理论已经存在和发展了几十年,软件项目的可测性和可控性都完全没有提高;被业界高呼了二十年的面向对象被骂为骗局;等等等等。。。 之所以这一切问题存在,是因为软件工程根本就是一个悖论。当别的工程领域早就摆脱了手工作坊生产,早就工业化自动化了的时候,软件工程还在手动hack代码。就像摆着高大的吊车和推土机不用,软件工程师们想要徒手建造长城,一次又一次的非要从地基开始重新建起。 这里再附上之前在代码交叉拷贝悖论中同ownwaterloo的讨论吧,在读到上述那篇文章之前,其实我们已经走到某一个角落了,其实已经离这个真理只差一步之遥了。(好吧。。虽然我说的也不见得就是啥“真理”啦。。) OwnWaterloo at 10/11/2010 18:12 不知道是不是想要这样的效果? 伪代码大致是这样: for image in [ thumb, caption, buttom /* 这里还可以更多 */ ] : image.offset(height) image.rotation(270) hawk at 10/11/2010 23:58 呜!这段代码很漂亮! 可惜c++效仿起来有难度。。 OwnWaterloo at 10/12/2010 10:36 其实那代码是一个暗示…… 做GUI这种效率不吃紧的东西, 能不用C++, 就别用C++…… 如果我早点学python, 并且发现OpenCV其实有python的绑定…… 不知道可以节省多少时间…… 陪gf玩玩什么的…… hawk at 10/12/2010 16:25 那时候因为是在winCE上做widget,没有.NET,所以只能用C++了。。 […]

Chrome同步…桌面同步

大学时期有过一个同步桌面的想法,就是说他能做到同步桌面主题,你安装的程序,你的文档,等等,反正就是做到你用两台不同的机器,只要装有一个客户端,他就帮你把两台机器搞成同样的软件环境。当然啦,那个时候只是想法。毕竟尤其是应用程序这一步,很难做到同步,正版软件获得不到权限当然是最主要的问题,除此之外一方面是存储和传输的成本,另一方面则是安装和配置的复杂度。(例如数据库之类,很难做到自动安装配置) 然而今天才看到chrome的同步已经远远超出书签的范围,包含了扩展、配置信息、主题,全部。我才明白这个桌面同步的想法,在本地操作系统时代无法解决,在云系统阶段,就迎刃而解了。想想看chrome就是一个操作系统,那么扩展就是应用程序,书签就是文档,主题、配置信息不一而足。有了这些轻量化的信息,两个系统就可以变成完全相同的设置。甚至可以做到,同一部硬件,谁登录就变成什么样子。两个不同的帐号使用看上去完全不同。 未来果然还是值得期待啊。

协作开发和二进制管理

因为经济的原因,协作开发一直是仅做源代码管理,由开发者checkout代码后自行编译。 但在有大笔资源的情况下,时效应该是更为重要的东西,为什么不考虑二进制管理? 在公司,一个项目编译出来需要3到5个小时。。(会跑来这里写东西的原因也说出来了。。)。。反正提交代码之前每个人都必须做build, 做测试,然后才能提交的,为啥不一开始就把大家build的结果保留下来,需要用的人自取呢? 这正好可以跟系统每天的daily-build和test-suite结合起来,一起完成。 开发过程还是一样,checkout, update,之后提交。但这个时候提交的内容不要直接进main branch. 先在他checkout的版本基础上,patch上他的update,之后做buddy-build和test-suite。如不通过,打回重练。这个过程可以以天或者以周为单位。以天为例吧。每天晚上12点,系统尝试将通过测试的patch进行合并。如果合并失败的话,就把导致合并失败的patch拿掉,直至合并成功为止。如果成功合并,进main branch, 并且做daily-build和test-suite。假如合并之后导致新的bug或build break产生,应该知道这些问题是协作造成的,将受影响的文件或模块相关的patch除去,重新build-test。直至没有bug产生为止。次日早晨发邮件给没进main branch的patch的owner们,让他们解决问题。 关键在于编译。在编译脚本里面可以加上新的机制,允许从服务器下载跟本地版本相符的obj,lib,dll,exe等内容。即编译器需要和源代码管理器协作,确定即将编译的一段代码是否被edit过。如果没有被edit过,检查目前版本的代码在服务器上是否有相应的二进制目标文件。如果有就可以直接下载,如果没有才考虑自己编译。这个过程跟编译顺序相反,是自顶向下,从最终目标开始比较,尽可能下载整个的lib,dll之类,这样就可以避免下载很多可能本地根本用不到的obj文件。 当然,由于二进制文件没有有效的增量备份算法,在服务器上不可能保存所有版本的二进制文件。但至少可以保存最近几天或几周的版本的,还有历史上的几个milestone版本的。 当然在这种机制下必须要求所有人都在最新版本下工作,否则必须新开branch。每天的patch都只能接受从当天版本号基础上checkin。如果有旧版本的patch提交,可以有两种选择,一种是要求开发者更新到最新,然后重新提交patch,另一种是要求开发者开新branch, 并在新branch上做开发。具体选择哪一种看具体需求以及开branch的成本了。 毕竟当项目变大,每个人要处理的模块都是很小的一部分,其余的部分只需要lib,dll就可以了,没有必要自己编译。并且,如果不需要编译,其实开发人员的机器配置就没有必要那么高,节省的成本可以做更好的服务器机器。其实这种策略也更符合所谓“云计算”。当然更加有趣的是,可以让编译本来就发生在由所有客户机结成的计算网格上面。并且所有的二进制文件也都分布式存储在这些分散的机器上面。服务器仅仅是一台或几台管理信号的中转路由。这样做可能可以进一步降低成本,并且对于每个计算网格而言,本地编译某个模块,然后二进制文件就存储在本地,也没有太多网络开销。当然具体算法如何实现,这个恐怕要仔细研究了。(研究生课题?:)