文章摘自：看雪学院1998年2月，陈盈豪编写出了破坏性极大的Windows恶性病毒CIH-1.2版，并定于每年的4月26日发作破坏，然后，悄悄地潜伏在网上的一些供人下载的软件中。1998年8月26日，CIH-1.4病毒首先发作，中国内地部分地区遭到袭击，但损害面积不大。事后，为了必免更大灾害，中国公安部发出了通缉三种CIH病毒的通告。可是，使用正版杀毒软件的意识不被一些用户重视，又不经常保持升级杀毒软件，CIH-1.2病毒又经过一年的传播，已传遍全世界，世界性的巨大杀机潜伏下来，1999年4月26日，信息大劫难终于暴发。反病毒厂商一时打破以久沉寂，大大红火了一把。　　刹那间，全世界防、查、杀CIH病毒的呼声昏天黑地......CIH（英语又称为Chernobyl或Spacefiller）其名称源自它的作者，当时仍然是台湾大同工学院学生陈盈豪的名字拼音（Chen Ing-hau）缩写。它被认为是最有害的广泛传播的病毒之一，会破坏用户系统上的全部信息，在某些情况下，会重写系统的BIOS。因为CIH病毒的1.2和1.3版发作日期为4月26日（第一版病毒创造出来的时间），正好是前苏联（位于今日乌克兰）核电厂灾害“切尔诺贝利核事故”的纪念日，故曾被认为病毒作者撰写动机和切尔诺贝利事件有关，因此CIH病毒也被称作切尔诺贝利（Chernobyl）病毒。看雪论坛的版主zmworm 在2013年的时候有幸采访到CIH，这里在这个特殊的日子，让我们一起再与新的小伙伴分享一下CIH当年的风采！PS：大家不要担心，只要正确地使用杀毒软件、及时升级病毒库、全面彻底地对电脑杀毒，就可轻松度过4.26这一天。这次去HITCON有幸遇到CIH的作者陈盈豪，中国第一代黑客 coolfire。还是收获不少的。这是CIH在HITCON2013的演讲，花了两个晚上整理的，并由CIH亲自校对。现经CIH同意，放在看雪论坛上。CIH说这些东西对大家有帮助就好，另外专门准备了他和看雪的合照:)======================================================================= HITCON  演讲稿兴趣执着和专注力让我与众不同By CIH我在高中一年级，开始学习BASIC和C语言。那时候我一点都不懂，我的电脑启蒙是从电脑游戏开始的。那时候玩游戏时，过到下一关卡，就会提示插第二片，第二片插进去玩到结束，再把第二片拔出来，插入第三片。所以我的电脑兴趣是从游戏开始。那时候我告诉自己，这一辈子我要变成游戏的设计者。 那时候，我只想成为这样的人。所以从高一开始写程式，到考大学的时候，我觉的我写的程式不完美。我就想学高职的资讯系。当时我妈很头大，然后他们和我说你到大学一样可以去考咨讯系。所以我才去考大学，因为当时电脑对于我来说就是一切。 现在讲一下CIH病毒。高一的时候第一次碰到电脑病毒，那时候资讯不像现在这么发达。那时候看到病毒感觉好恐怖。当时我第一个反映就是“啊，会不会被传染。”。真是这样的。 第一次碰电脑，是去同学他们家去换游戏，那是25年前第一次碰电脑。然后后来，大概是高二时开始写游戏。大一的时候开始碰Windows 3.1。然后Windows 95才开始出现。当Win 95出现时，兴趣开始有转移，当时最大的兴趣就是组合语言，每天都要写。因为他可以控制所有要控制的东西。在DOS时代，只能寻址1MB，而在Window世界他可以寻址4GB。所以那时候我写的组合语言不并是很简单，我用组合语言写了一个简单的作业系统，他不是真正的作业系统，他只是在处理作业系统中的虚拟机部分。 大二的时候开始研究Windows的Kernel，怎么去处理虚拟机，怎么处理Exception，这些都是Win95机制。后来开始虚拟化的文章，特别是候捷，他的著作对系统理解非常深。 大二自己每天都在做一件事，挂上系统进行DEBUG，那时使用的调试器是SoftICE。每天都按下一步，下一步。有些人问我学DEBUG有什么技巧。其实就是遵循一个逻辑，按“下一步”，然后用眼睛看，没什么技巧。但是要一直这样按，要按24小时，因为一但你睡觉，隔天就会忘记昨天你追到哪里了。在大二我一直都在做这样事情。 最后，你会发现Win95跟本就是个大垃圾。对！微软是个垃圾！从头到尾Win95他根本就不是个作业系统，在我的定义里。 Win 95他是个有大BUG的系统。所以呢，他的BUG会很多。Windows 95 宣称是32 bit作业系统，他底层很多事实上很多的Kernel会使用16 bit作业系统。甚至有些东西会呼叫DOS的API。所以Win 95 有三个作业系统：32bit作业系统、16bit作业系统，再加上16bit DOS作业系统。 有人说我怎么厉害入侵一个Win95的Kernel，让自己从User Mode 取得 Kernel Mode。CIH怎么那么厉害。 错！因为从头到尾就一两个字节就做到了。因为大门就这么大，一进去就到了Kernel Mode。在Win95，你只要通过一行C的程式就可以让你的系统Crash掉。因为一行C的程式就可以毁掉中断向量表。他没有做检查。因为Win95要向兼容16 bit Windows和DOS。所以才有这个奇怪的现象。而当时真正稳定的系统就是NT--另外系列的作业系统，真正的32bit OS。 后来我在大四，我看到一些病毒，还听说病毒绝对是不可以毁掉BIOS。我在想真的不可以毁掉吗？那时很多人很难想象BIOS会被毁掉，而事实上是可以毁掉的。 为什么？ 因为那时候有可以用工具去升级BIOS，既然工具可以把BIOS升级，那么病毒也可以把BIOS升级。升级完之后，屏幕打开黑黑的看不到。软体可以做到的，病毒都可以做到。那当然了，你会发现这些病毒在爆掉世界之前，我的电脑先暴了。所以我会买两颗BIOS，这颗坏掉后，再烧另外一颗。当时我对烧BIOS不熟，BIOS虽然只有几百K，但把他变成组合指令还是很难追的。最后我以一种极土的方式。就是每天一直按下一步，然后找到可疑的地方停下，看他在什么地方更新BIOS。 如果没有更新，下一次就再多按几下，最终会有一次，一旦执行这个Function就会擦除BIOS为空。然后跟进这个function继续追，没日没夜的测，靠的就是坚强的毅力。 当时从User mode 取得Kernel mode时，我就想就可以为所欲为了。不过我喜欢做一个技术高超的程式员。所以那个时候，我的病毒感染之后，执行文件一个Byte都不会变大，因为我去找执行档里面破碎的空间。所以感染之后的病毒体被切成几块，分开到不同的破碎的地方，然后病毒在执行的时候，再像变形金刚组合起来，就是从执行档里找这几个不同的破碎地方组合起来变为一个病毒。就是因为这样的技术，执行档感染起来后，完全不会增加一个Byte。而同时用一些技巧，去减小function的大小。当时我在测试的时候，每找一个地方我就改一个。优化这个东西，是因为我从高中的时候，我就喜欢玩酷的东西。后来就越玩越火，居然我花6成到7成的时间，每天在做什么事情呢?一个Byte一个Byte的减，能少一个Byte就少一个Byte，检查每一个组合指令能否用更短的方式去替代。对我来说这也是个成就感。这样我的病毒不到1024Byte，就可以做到所有功能。 接下来，因为全班的同学都知道我在写这个病毒。那时候又要毕业了，就开始有人找我要这东西了。 主持人：“我问一句，因为我很好奇，你的同学你怎么找到你写病毒？” 很我兴奋呀，我就告诉全班，这东西写出来可以做的到现有的技术，包括防火墙，杀毒软件完全都看不到他。 主持人：“如果当时有HITCON大会你会否发表？” 如果当时会。 回到之前那里，因为有些老师太压榨学长，所以等学长们毕业后，CIH就会爆了。当时没想那么多。我在写的时候，所有的同学都知道我在写。因为实验室是跟宿舍相连的。所以后来的结果是超出我想像，传播到了全世界，因为那是一年以后。当时看到相关资讯后，我在想。“哇，我捅了大事情了！”一个月之后各大杀毒软件发布的清除程式，然后我想应该没有问题了。想不到一年后又爆炸了。这个事情是无意中发生的事情。 主持人：“我问一下，如果有学生正想写virus你有什么建议？” 如果有人对这块极度感兴趣，我的建议就是除了一直debug外，你还是要把底子打好呀。如果你确定要写BIOS，在Kernel Mode做事情，那就乖乖的花很多时间去写程式，我写了很多年，每天一直在写，研究Windows Kernel 的东西。只有对他很了解，才会知道哪些地方有问题，这些都是基本功。如果你确定真的要写这方面的东西，你要想一想，你可能去创造一个之前没有的东西，但是东西写完之后，同时必须提供相对应的方式去把问题Fix掉。然后写文章纯粹发表技术，这样对资讯安全有更大的贡献。 后来因为CIH，我一直和国安局，资讯局都还有交流。一说交流，就是被叫过去喝茶。那时候真的以为自己这辈子完蛋了。后来呢，如果某些小朋友在这方面出了的问题，他们会问一下我的想法。不过有一次，他们打电话给我：“CIH恭喜你呀，因为你的关系，立法院通过资讯相关犯罪条例！”。我当时想，小弟终于有贡献了。所以呢，站在我的立场，我们可以研究一些攻击方法，但是必须把这些技术或是咨讯安全的问题转换成对科技的贡献。 主持人：“因为我发现你从高中开始，从完全不会电脑，只花了五六年时间，就做出了CIH病毒。这一点让我蛮佩服的。我认识的许多高手，绝大部分是从小学开始。我想问的是说，你究竟花了多少时间，你有在睡觉吗？” 有睡觉。这里问到一点，为什么同样的时间，结果却不同。因为我只做一件事情，就是focus，专注于一件事情。事实上我只会按“下一步”。因为我只专注研究Kernel，其他的我完全不会，写网站不会， Java不会。如果你确定有兴趣，就把所有的时间就投入到这块。所以我和别人不一样，别人总是东碰西碰，而我没有。我每天总是在写组合指令，而且没觉的很烦。有时写累了，就换点做其他的，休息完再继续写。你看到台上的人技术力很强，其实背后花的时间，是你想象不到的。所以兴趣，执着和专注力才能把事情做好。 其中有一点，造就我在Kernel这块与众不同。因为我高中和大学英文成绩不好。怎么样不好？那时候英文全班倒数第一。强迫去参加一个特殊的英文发音课程，而我大二大三就强迫就被抓去过上这个班。因为这样，你会说有这么多技术，是不是从社区或者网上的技术文献看到的。因为我英文不好，所以不可能从这方面获得。我是接触到SoftICE这个32bit Debuger，我每天一直按，才知道作业系统是怎么做的，虚拟机是怎么做的。我知道大部分黑客是混社群的，而我是比较特别，就是关起门来，自己学，每天和SoftICE相处，看到的都是汇编指令。

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/E51lKQOojsvhHvACIyXwhw 作者：黄文佳常见错误的分类对于用户在访问页面时发生的错误，主要包括以下几个类型：1、js运行时错误JavaScript代码在用户浏览器中执行时，由于一些边界情况、本地环境的不可控等因素，可能会存在js运行时错误。而依赖客户端的某些方法，由于兼容性或者网络等问题，也有概率会出现运行时错误。e.g: 下图是当使用了未定义的变量"foo"，导致产生js运行时错误时的上报数据：2、资源加载错误这里的静态资源包括js、css以及image等。现在的web项目，往往依赖了大量的静态资源，而且一般也会有cdn存在。如果某个节点出现问题导致某个静态资源无法访问，就需要能够捕获这种异常并进行上报，方便第一时间解决问题。e.g: 下图是图片资源不存在时的上报数据：3、未处理的promise错误未使用catch捕获的promise错误，往往都会存在比较大的风险。而编码时有可能覆盖的不够全面，因此有必要监控未处理的promise错误并进行上报。e.g: 下图是promise请求接口发生错误后，未进行catch时的上报数据：4、异步请求错误（fetch与xhr）异步错误的捕获分为两个部分：一个是传统的XMLHttpRequest，另一个是使用fetch api。像axios和jQuery等库就是在xhr上的封装，而有些情况也可能会使用原生的fetch，因此对这两种情况都要进行捕获。e.g: 下图是xhr请求接口返回400时捕获后的上报数据：各个类型错误的捕获方式1、window.onerror与window.addEventListener('error')捕获js运行时错误使用window.onerror和window.addEventListener('error')都能捕获，但是window.onerror含有详细的error堆栈信息，存在error.stack中，所以我们选择使用onerror的方式对js运行时错误进行捕获。window.onerror = function (msg, url, lineNo, columnNo, error) { // 处理错误信息 } // demo msg: Uncaught TypeError: Uncaught ReferenceError: a is not defined error.statck: TypeError: ReferenceError: a is not defined at http://xxxx.js:1:13 window.addEventListener('error', event => (){ // 处理错误信息 }, false); // true代表在捕获阶段调用，false代表在冒泡阶段捕获。使用true或false都可以，默认为false2、资源加载错误使用addEventListener去监听error事件捕获实现原理：当一项资源（如<img>或<script>）加载失败，加载资源的元素会触发一个Event接口的error事件，并执行该元素上的onerror()处理函数。这些error事件不会向上冒泡到window，不过能被window.addEventListener在捕获阶段捕获。但这里需要注意，由于上面提到了addEventListener也能够捕获js错误，因此需要过滤避免重复上报，判断为资源错误的时候才进行上报。window.addEventListener('error', event => (){ // 过滤js error let target = event.target || event.srcElement; let isElementTarget = target instanceof HTMLScriptElement || target instanceof HTMLLinkElement || target instanceof HTMLImageElement; if (!isElementTarget) return false; // 上报资源地址 let url = target.src || target.href; console.log(url); }, true);3、未处理的promise错误处理方式实现原理：当promise被reject并且错误信息没有被处理的时候，会抛出一个unhandledrejection。这个错误不会被window.onerror以及window.addEventListener('error')捕获，但是有专门的window.addEventListener('unhandledrejection')方法进行捕获处理。window.addEventListener('rejectionhandled', event => { // 错误的详细信息在reason字段 // demo:settimeout error console.log(event.reason); });4、fetch与xhr错误的捕获对于fetch和xhr，我们需要通过改写它们的原生方法，在触发错误时进行自动化的捕获和上报。改写fetch方法：// fetch的处理 function _errorFetchInit () { if(!window.fetch) return; let _oldFetch = window.fetch; window.fetch = function () { return _oldFetch.apply(this, arguments) .then(res => { if (!res.ok) { // 当status不为2XX的时候，上报错误 } return res; }) // 当fetch方法错误时上报 .catch(error => { // error.message, // error.stack // 抛出错误并且上报 throw error; }) } }对于XMLHttpRequest的重写：xhr改写 // xhr的处理 function _errorAjaxInit () { let protocol = window.location.protocol; if (protocol === 'file:') return; // 处理XMLHttpRequest if (!window.XMLHttpRequest) { return; } let xmlhttp = window.XMLHttpRequest; // 保存原生send方法 let _oldSend = xmlhttp.prototype.send; let _handleEvent = function (event) { try { if (event && event.currentTarget && event.currentTarget.status !== 200) { // event.currentTarget 即为构建的xhr实例 // event.currentTarget.response // event.currentTarget.responseURL || event.currentTarget.ajaxUrl // event.currentTarget.status // event.currentTarget.statusText }); } } catch (e) {va console.log('Tool\'s error: ' + e); } } xmlhttp.prototype.send = function () { this.addEventListener('error', _handleEvent); // 失败 this.addEventListener('load', _handleEvent); // 完成 this.addEventListener('abort', _handleEvent); // 取消 return _oldSend.apply(this, arguments); } }关于responseURL 的说明需要特别注意的是，当请求完全无法执行的时候，XMLHttpRequest会收到status=0 和 statusText=null的返回，此时responseURL也为空string。另外在安卓4.4及以下版本的webview中，xhr对象也不存在responseURL属性。因此我们需要额外的改写xhr的open方法，将传入的url记录下来，方便上报时带上。var _oldOpen = xmlhttp.prototype.open; // 重写open方法,记录请求的url xmlhttp.prototype.open = function (method, url) { _oldOpen.apply(this, arguments); this.ajaxUrl = url; };其他问题1、其他框架，例如vue项目的错误捕获vue内部发生的错误会被Vue拦截，因此vue提供方法给我们处理vue组件内部发生的错误。Vue.config.errorHandler = function (err, vm, info) {  // handle error  // `info` 是 Vue 特定的错误信息，比如错误所在的生命周期钩子  // 只在 2.2.0+ 可用}2、script error的解决方式"script error.”有时也被称为跨域错误。当网站请求并执行一个托管在第三方域名下的脚本时，就可能遇到该错误。最常见的情形是使用 CDN 托管 JS 资源。其实这并不是一个 JavaScript Bug。出于安全考虑，浏览器会刻意隐藏其他域的 JS 文件抛出的具体错误信息，这样做可以有效避免敏感信息无意中被不受控制的第三方脚本捕获。因此，浏览器只允许同域下的脚本捕获具体错误信息，而其他脚本只知道发生了一个错误，但无法获知错误的具体内容。解决方案1：（推荐）添加 crossorigin="anonymous" 属性。<script src="http://another-domain.com/app.js" crossorigin="anonymous"></script>此步骤的作用是告知浏览器以匿名方式获取目标脚本。这意味着请求脚本时不会向服务端发送潜在的用户身份信息（例如 Cookies、HTTP 证书等）。添加跨域 HTTP 响应头：Access-Control-Allow-Origin: *或者 Access-Control-Allow-Origin: http://test.com注意：大部分主流 CDN 默认添加了 Access-Control-Allow-Origin 属性。完成上述两步之后，即可通过 window.onerror 捕获跨域脚本的报错信息。解决方案2难以在 HTTP 请求响应头中添加跨域属性时，还可以考虑 try catch 这个备选方案。在如下示例 HTML 页面中加入 try catch：<!doctype html> <html> <head> <title>Test page in http://test.com</title> </head> <body> <script src="http://another-domain.com/app.js"></script> // app.js里面有一个foo方法，调用了不存在的bar方法 <script> window.onerror = function (message, url, line, column, error) { console.log(message, url, line, column, error); } try { foo(); } catch (e) { console.log(e); throw e; } </script> </body> </html> // 运行输出结果如下： => ReferenceError: bar is not defined at foo (http://another-domain.com/app.js:2:3) at http://test.com/:15:3 => "Script error.", "", 0, 0, undefined可见 try catch 中的 Console 语句输出了完整的信息，但 window.onerror 中只能捕获“Script error”。根据这个特点，可以在 catch 语句中手动上报捕获的异常。总结上述的错误捕获基本覆盖了前端监控所需的错误场景，但是第三部分指出的两个其他问题，目前解决的方式都不太完美。对于有使用框架的项目：一是需要有额外的处理流程，比如示例中就需要单独为vue项目进行初始化；二是对于其他框架，都需要单独处理，例如react项目的话，则需要使用官方提供的componentDidCatch方法来做错误捕获。而对于跨域js捕获的问题：我们并不能保证所有的跨域静态资源都添加跨域 HTTP 响应头；而通过第二种包裹try-catch的方式进行上报，则需要考虑的场景繁多并且无法保证没有遗漏。虽然存在这两点不足，但前端错误捕获这部分还是和项目的使用场景密切相关的。我们可以在了解这些方式以后，选择最适合自己项目的方案，为自己的监控工具服务。—— —— 参考文档 —— ——1.Using XMLHttpRequest： https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest2.script error 产生的原因和解决办法： https://www.alibabacloud.com/help/zh/faq-detail/88579.htm3.JavaScript执行错误： https://docs.fundebug.com/notifier/javascript/type/javascript.html4.betterjs的script error： https://github.com/BetterJS/badjs-report/issues/35.Vuejs的errorHandler： https://cn.vuejs.org/v2/api/index.html#errorHandler6.React的componentDidCatch： https://reactjs.org/blog/2017/07/26/error-handling-in-react-16.html

原文转自：微杂志机场是个很有意思的地方，它是出发地与目的地之间悬浮着的一座孤岛，一个欲言又止的逗号，千万种人生在此汇合，有一些从此变了方向，更多的人短暂相遇又彼此错过。这是个容易让人产生幻觉的地方，你会觉得自己因为这趟旅程或多或少都会有那么点不同。飞机像集装箱一样把乘客投递到他乡的时候，身后托带着的那串纷纷扰扰的无线电信号遮蔽着肉眼可见的天空。你并不真的知道那些信号搭载的信息，就像你无法获知机舱里别人酣睡时做着的梦。这些未知在遭遇恶劣天气的时候会迅速孵化焦虑，喷洒在狭促的机舱内，迄今为止很少有人能对此完全免疫。可怕的是等待，比等待更可怕的是无故浪费的时间以及由此引发的一连串的计划更改、延误。那种广泛散布的不安足以使一个温和的人怒从心头起，一个刚烈的人恶向胆边生。它是所有人，所有焦虑的叠加，或者说等量复制，这些积聚的情绪庞大到机舱都无法隔离，最后都结结实实砸在机长头上，除了不确定的天气，身体的疲累，一个机长的沉稳和酷劲都从这些焦虑中提炼而来。这算是炼金术的一种么？今天推荐的这篇文章几乎算得上一篇成色很好的小说（其实它是作者真正的经历），作者本人是国内某航空公司飞行员，在今年5月经历了职业生涯里历时最长的延误，虽然不是电影里那种惊险的飞行事故，但行文中到处弥散的紧张，时时刻刻的坚持和抉择都让这个故事的张力保持得非常好，飞行员当时比天气还恶劣的情绪如今仍然新鲜。关键是，那些你不知道的戏剧性的情节，那些拥挤的信号搭载的信息，在这篇文章里都有明白的解释，而文明的进步何尝不是对人类普遍经验的清醒认识？==============================================================================延误in北京地服问：“机长咱们没事吧？能不能上客？”管制员给副驾驶的答复是：“准备好才能申请，大约等30分钟。”所以我给地服的答复是：“抓紧！”【19:00】这是我们真正准备好的时间，15分钟前我们向管制员报告了准备好。提前谎报的理由无它：不求占便宜，只求不让我航班上的旅客太吃亏。在我之前已经有数架飞机连续报告了准备好，他们也许已经关好了舱门，也许与我一样报告的同时还在上客，当然还可能是刚刚落地滑入机位⋯⋯一时间扑朔迷离，这注定是一场脑力与运气的竞逐。你永远不知道对方的底牌，唯有妥协去适应当前的局面。【19:30】30分钟后我们并未等到任何消息，频率里异常繁杂，更多的飞机向管制员报告了准备好。管制员不断地回答着：“时间已抄收，等通知！”只要管制员接话稍有停顿，飞行员便会呼叫第二遍、第三遍，生怕管制员遗漏掉自己被别的飞机抢了先，直到传来管制员解释：“准备好已经收到了，刚喝了口水。”从他的声音里不难听出后半口水甚至还没来得及咽下。尽管知道管制员不容易，但在他喝第二口水前，我们还是找了个间歇残忍的插进播道询问了当前状况，答复如下：“排在第十架左右，由于雷雨天气放飞间隔加大，时间预计要两个小时。”听到这个信息后，驾驶舱内三个人的动作很一致：扶额。作为机长，我比他们还多了“掐”这个动作。“排在第十架”这句话本身并不可怕，如果天气好和机场不繁忙的时候30分钟内就能起飞。但是加上“雷雨天气放飞间隔加大”这句话就大大的不妙了：本来每2分钟就能放一架飞机，现在间隔大到5分钟、10分钟都有可能，所以再后面的的“预计两个小时”就只能是一个参考时间。同时两个小时又是一个很尴尬的时间点：如果组织旅客离机，那么呆上1小时就要重新登机，来回折腾不说，到时候有一两名旅客失踪找不回来报警的心都有！由于飞机已经是延误状态，从道义上你还不太好意思减客，凭什么只能你迟到我不能迟到啊？如果不下客就让旅客在飞机上等呢？那你就祈祷这个时间准确吧！不准的话你再祈祷旅客都是好脾气，赶上差脾气旅客再祈祷当前的状况一定是个梦⋯⋯总之，雷雨天气变幻莫测，有可能雷雨云团中突然露出一道缝隙，管制员找准机会连续放出四五架，你的时间就提前了；也有可能雷雨把机场封得越来越牢使得间隔进一步加大，你的噩梦就到来了！我向乘务长大致说明了延误情况，建议她在地面上发餐。乘务长明显有些顾虑，说飞机上100多名旅客，发餐到收餐需要将近1个小时。我向她展现了一个阳光般的笑容说：“1个小时吗？小意思，不用担心！大胆去发吧！”乘务长愣了一下，离开驾驶舱的时候眼神中充满着幽怨。无法预知未来的我还是老老实实做了第一次常规的机长广播：我们抱歉抱歉抱歉……大家辛苦辛苦辛苦……天有不测风云，有具体起飞时间一定通知大家！让我们在守候中期待惊喜！（本来想通过最后一句展示一下我的文学素养，但是现在回想起来，这一句确实不应该说……）【20:00】再次询问管制员，回答：“还需要等待两个小时。”等一下下！！之前半小时白等了吗？管制员这次解释得很详细也很耐心：南下的飞机只有一道缝隙可以穿过雷雨（注：我们的航班由北京飞往杭州，属于“南下”），但往西边去的飞机由于绕不过去也只得飞来一起挤这道缝，所以放飞十分缓慢。滑行道上还压着7、8架无法起飞。担心的事终于发生，最可恨的依旧是“两个小时”这不长不短的时间……这是延误以来第一次需要好好考虑做决策的时候，到底需要不需要全部下客？如果以结果论来反推的话，这一刻让旅客全部离机无疑是最轻松的选择。请注意：我的用词是“最轻松”而不是“最正确”。机组是轻松了，但同为民航一线的地服人员接手了这份“甜蜜的负担”之后，他们的应对情况从微博反映来看并不如想象中的理想。正所谓：楚人失之楚人得之！从旅客角度来说，有些喜欢下机去吸支烟歇歇腿，有些愿意在机上小憩懒得再动。无论哪种选择都不会让所有人满意，我决定赌上一把再等等这两个小时。当然，任何决策都不代表你能忽略旅客的意愿！我要求副驾驶通过现场频率叫来地服人员靠上廊桥，开始第二次的机长广播：“目前雷雨天气的发展很不乐观，预计还要等待很长时间，目前估算为两小时左右！（闭着眼不去想象旅客听到后惊呼失望的样子）这里提醒大家如果有终止旅程的旅客，请提前告知乘务人员。一旦我们有了推出时间，您再提出终止旅程很可能会使我们错过时间，为了大多数旅客的利益，那个时候我也许会拒绝您的下机要求，希望得到您的谅解。”广播之后，陆续有旅客联系了乘务长与地服办理了终止旅程的手续。我也借此机会通知油车再次补进500kg的油量以备后续的等待。这里顺便说明一下：我们的飞机是今年才从德国接回的，空调设备优良。地面空调由辅助动力提供（APU），每小时大约消耗100kg航油。而滑行道上那些启动好发动机等待的飞机每小时至少消耗800kg，想想都心疼。所以那些持有类似“航空公司明知道起飞不了，故意将飞机滑出去等着，然后等很久滑回来欺骗我们。”这种阴谋论的网友，你们可以省省心编点别的内容了。【21:00】由于一直没有起飞时间，飞机始终保持在靠桥状态，地服也偶尔会登上飞机询问当前状况，我糟糕的脸色终于令他放弃问出那句“没事吧？”转而问道：“旅客情绪还好吧？还得等多久？”我答道：“旅客情绪还好，不愿意等的旅客大都办理了终止，机上旅客应该都是迫切想飞往杭州的。只是现在放飞十分缓慢，天气情况仍然不够明朗。”询问管制员，我们的次序已排入了前五。看到一段时间内再没有旅客离机，我们通知了配载部门按照新的旅客数量及油量重新制作舱单，计算配平重心。这样做使得我们的飞机仍然保持着手续齐全随时可以推出的状态，这种状态在延误排续中算得上一种优势，而我有信心把这种优势再维持一个小时。（注：建议旅客们在飞机起飞前不要随意坐到空的座位，特别是前后排数跨度很大的空座位。 尽管现代飞机具有增稳装置和自动配平功能，但这种自动化只限于空中。在起飞前配载部门只能根据旅客的座位来计算起飞重心，飞行员通过人工调整配平轮来保证起飞时的杆量适中。倘若旅客自行更改座位造成重心差异较大，飞行员在操纵飞机抬头的瞬间有可能发生带不动飞机，或者杆量太轻造成仰角过大擦机尾。所以特别是飞机后排比较空的时候，非要换还是等到巡航吧。）此时，整个北京机场开始第一波大面积取消航班：这次取消航班主要由于一些机组上午已经执行过其它航班，由于执勤时间的限制无法继续执行后续航班。这时候如果这家航空公司在北京有驻地，有机组可换的话便会换上新的机组继续坚守等待；如果航空公司没人可换，航班就只剩下取消一途。【22:00】频率里的排队的飞机已达到了恐怖的40架以上，北京这次的雷雨连绵不绝地影响了机场近4个小时仍未消散，持续时间之久远远超出了预期。这真的应了前面机长广播里所说的SURPRISE！更加让人吐血的是：向南起飞的航班停放了！开车的人都知道，高架桥上20-30迈的速度往前移动和开不动停下来完全不是一个概念，假如你车后面还坐着一群领导，你该如何淡定？我继续询问管制员停放状态要持续多长时间？管制员也很无奈地表示要看中低空那边的管制员什么时候能把飞机调开了。我相信管制员所言不虚，这片雷雨不单压住了无数起飞的飞机，而且对落地的飞机影响更甚。在签派频率就能听到空中一些航班的飞行员正在和签派员们商讨着备降事宜。我的后续航班也发生了变化，最后一段“杭-京”由于我延误过多无法回杭，于是公司从杭州调配了其他机组和飞机来执行。遗憾的是他们在杭州苦等了两个小时终于得以推出滑行，但仅仅滑行了3分钟就接到了“北京不再接收飞机”的指令而不得不滑回取消。各个航空公司开始第二波大面积取消航班：这次取消是因为有些航班的目的地机场有关闭时间，例如上海虹桥机场会在24:00前关闭，那么飞机即便现在起飞到目的地也无法落地。倒不如早早取消明早补班！取消得越早，明早补班就能越早！（注：机组需满足《运行手册》的规定休息时间，新闻中所说的航班延误是因为“机长没睡好”专业点的说法应该是“机长还不符合休息时间的规定”。）而我也打算按照原计划开始祈祷旅客好脾气了……此时此刻的我终于有些感觉力不从心，让人忧心的不再是糟糕的天气、也不是自己的精力，而完完全全是旅客的情绪。这次让旅客在飞机上等待这么长的时间在我近些年的飞行经历中绝无仅有，几年前我曾在微博上发过一篇小文《延误时机长会做些什么》，那个时候还没有CDM放行，几乎每班都是在载客中等待，无论是旅客和机组都苦不堪言，即便如此等上3小时至少也能有明确的起飞时间。我曾说如果等待三个小时还没有时间，自己一定去找管制员要个说法！可今天说法就在眼前，我却没把握它能令旅客信服。我怀着无比愧疚地心情准备通知全部旅客离机的时候，突然传来一条消息——西边的雷雨开始消散了。【22:30】频率里再次繁忙起来！管制员们开始尝试能否让南下的飞机从西边离港，他们不停地询问着排队靠前的飞机：“如果起飞后先飞向郑州再回转，油量是否满足？”飞行员们此时也犹如打了一剂强心剂般的计算着、权衡着……我在这个时候拿起话筒做了第三次机长广播：“女士们先生们，我是本次航班机长，我猜可能大家已经厌烦了这个声音，毕竟前两次的广播都没有给大家带来好的消息。在飞机上等待三个小时确实不太容易，大家急躁的心情我们机组非常理解，我把目前的状况向大家交代一下：我们的飞机现在已经排到了前五架，如果正常情况下我们随时可能推出飞机。但是由于南面的雷雨天气持久不散，这个方向近一段时间都没有飞机起飞。北京机场已有很多航班陆续取消，有些因为机组的执勤时间面临超时，有些由于目的地机场将要关闭。我们机组目前没有超时的问题，精力充沛请大家放心，杭州机场拥有双跑道也将保证24小时的开放。我们机组现在所能做的就是陪大家一起等待，等待天气转好后安全的将大家送至杭州。据空中飞行员反应，天气目前已经开始好转，请大家能再坚持一下，我们的乘务员将尽所能为您服务，希望我们的工作能得到您的理解和配合。”广播之后，乘务长说后面有些旅客让她转达理解和谢意。然而，这并没有让我的心情变得轻松。如果我站在乘机人的位置，恐怕更多的心思是郁闷与无奈，随着时间的不断延后，留给理解的空间也将越来越小。西边的雷雨散了，可我依旧不知道那南边的还会久吗？【23:30】就在我们与管制员沟通时，乘务长要求进入驾驶舱。她说：“后面有一名稍胖的旅客说他身体不好，血压高，需要休息，明早7点还要服药。”也许是等得时间太久了脑子僵硬，我一下子没得出要领，“所以？”“所以他说自己需要好好地休息！”乘务长又强调了一遍。“他的气色如何？意思是需要下机休息？”我继续问道。“看他气色正常，安全员也这样问他是否需要下机？那人说安全员这样问是在威胁他。”“你再好好打听一下他的目的，耐心询问一下他的需求，我这边再问下管制员有没有具体时间。”该来的事情迟早会到来，宣泄口一旦找到全部下客清舱就成为了必然，只是我的时间来得及吗？我们再次询问管制员的放飞状况，管制员回答说我们的排序是在前面，但是之前有5架滑行道上的飞机陆续地滑回补油，这5架如果都同意走西线继续执行航班的话，我们必须排在他们后面。这样的安排无可厚非，倘若再把滑回飞机的位置排到队伍后面，显然对他们机上的机组和旅客是不公平的。与此同时我们联系了现场频率，询问了是否能提供医生上机量血压？现场告知可以，不过需要当事人自费，大约200-300元。我急忙将这一信息反馈给乘务长，并通知地服协助我们协调工作。乘务长再次进入驾驶舱时的心情比之前要急迫得多：“机长，您能不能再广播一下。那名旅客带头要求赔偿，很多乘客赞同，闹得很凶！”我无奈地开始做了第四次广播：“虽然南边的雷雨还没有完全退去，但西边已经逐渐晴朗。管制员们已经为我们从西边绕飞努力做着准备，目前我们可以先飞向郑州再转回杭州，尚需等待管制员的指令。有很多旅客询问赔偿问题，毕竟延误了这么久，作为机组我本人也很希望能得到一份赔偿，航空公司有专门的人员负责这件事，我在这里可以把我所知道的向大家介绍一下：针对我们公司的规定，如果由于天气原因造成航班延误并不在赔偿范畴；如果是非天气原因，延误达到4个小时可以进行相关的赔偿。也许有的旅客觉得这并不公平，您有权利和地服人员去交涉，只是这恐怕要花费相当长的时间和精力，也可能为此耽误我们的行程。如果可以，我希望您能够到达杭州后再做此项工作，以免影响目前渴望休息和尽早飞回杭州的旅客。我们机组从下午一点多开始执行航班，从晚上七点一直陪伴大家等到了现在。按照规定，我们的执勤时间最晚可以等到凌晨4点钟起飞，在4点钟前我们都会咬紧牙关等下去。乘务长反应已经有个别旅客出现了身体不适，如您需要下机休息或就医请务必告知我们，如果您可以同我们再坚持一下的话，我一定在半小时内对离场时间给大家一个回馈。对于其它疑问，相信我们的乘务人员也会尽所能去回答让大家满意，谢谢。”我无力地放下话筒，乘务长进来报告：那位客人已经不闹了，说再给我们半个小时的时间。副驾驶问我：“半小时我们能有时间吗？”我回答：“如果没有，就只能下客了。不知道这是否是他们想要的结果。”【24:00】管制员回答滑回的5架飞机均要求从西线离港，所以我们预计至少还要一个小时。这在意料之中又在意料之外，意料之中是5架飞机的决绝，都回来补油了还能不走吗？意料之外的是怎么还要等这么久啊！我意识到“大势已去”，通知了现场人员组织下客，那一刻我的心情低落到了谷底。而此时地服走了进来对我说：“机长，您看能不能不下客？签派说正在帮忙协调马上能走！”我一腔邪火正无处可发，大声地对地服叫嚷着：“之前公司让我赶着回杭州继续执行下一个航班的时候，我请求他们协调，他们答应了却没有任何回应；后来等啊等，我的休息时间快赶不及明天下午航班的时候，我请求他们去协调，他们答应了又没有回应；现在我要求下客了，他们主动要求去协调了？我怀疑他们是否有这个能力！前面五架飞机都补完油滑出了，你告诉我他们怎么协调能把我调到前面去？你转告他们尽快去协调吧，我先下客了，如果协调下来时间我马上把旅客接回来成吗？”地服没再说什么，转身而去。望着她同样劳累的背影，我为自己之前的脾气感到有些后悔，超长延误的重压我们机组已经尽力扛起得够多够多，请谅解吧。在旅客离机之前，我做了最后一次广播：“很抱歉的通知大家，由于具体起飞时间无法敲定，我们还是组织大家离机，希望大家能在候机楼好好休息。后续航班是继续执行或是取消我们要等待签派的通知，但我们的承诺依然存在，只要有希望我们一定会尽力申请保留航班飞回杭州。非常感谢与大家共同度过的这段时间，大家的配合令我们感动，谢谢。”放下电话，我终于长舒了一口气，副驾驶问我：“终于轻松了？”话音未落，乘务长开门进来说：“机长，有7个人不走！”“哦？如果愿意留在飞机上就留着吧，不用过于勉强。”我不以为然。“不走的就是刚才那个‘胖子’和一起闹的几个人啊！”我已苦中带笑：“那你去问问他们有什么要求没有？”一会，乘务员回馈说：“他们担心下了飞机航班就会取消，没地方再去要说法所以不肯走。现在几个人闭眼睡觉了！”“是该好好休息了。”我答到。旅客休息的这段时间，我们机组并未停歇！我先询问了签派对航班的建议，并要求尽量保留航班，我深知这班若取消对旅客意味着什么：一旦这个航班取消，即便按照最短的休息时间去休息，补班也要制定在明天中午左右。由于今晚取消的航班太多，明早补班与正版交织一线势必再次延误，如果本机旅客无法顺利改签的话也许会足足耽误一天。那我到目前所等的5个多小时就变得有违初衷全无意义可言了。另一方面我通知了油车再次补油，这次干脆直接补进5吨油！任你滑行道上再排队等候、任你起飞之后往西绕飞多远，往北往东绕我都不怕了！望着副驾驶略有疲惫的面容，我要过了操纵权：“这么晚了，这个起落还是我来吧，下次换你！”我脑中一遍遍地过着还会有什么因素影响着我飞回杭州，一旦旅客重新登机，那时任何的疏忽与闪失都将造成航班取消。【01:00】同公司最后一架飞往杭州的航班由于排序过于靠后终于也不得不宣布取消，至此唯有我们还在坚守。【01:15】旅客重新登机，不仅人数没少而且还多了很多伙伴（其它被取消航班的旅客改签至此），飞机几近满客。【02:10】等待了7小时后，我们终于冲上云霄。我知趣地没再做机长广播以免更加让人生厌。【04:10】飞机安全于杭州落地。这一天我们飞两段，执勤了14个小时。最后一段的飞行我没有感到任何疲倦，因为我知道机组的使命并未完成。虽然夜色已深，但这一路并不孤独:频率里的每个声音都能让我感受到空中的管制员从容淡定；夜空中的每一点闪烁都令我仿佛看到另一间驾驶舱内飞行员的严谨沉着；飞机脱离跑到后一眼便能望见引导车的守候；到位停稳时客梯车、摆渡车接驳依然准时无误；以及送我们回公寓的机组车师傅脸上还有着真诚的笑容。这大概就是熟睡的旅客所无法得见属于民航世界的另一番景象吧。【05:00】我躺在公寓的床上，透过窗帘的缝隙望着夜色里逐渐透露出的鱼肚白。尽管没有经过第三次的祈祷，我也感到之前所经历的一切宛如梦幻。延误时，在机上与旅客共处5个小时。在此之前对于我来说这是无法想象的且坚信不可完成的任务！而对于自己没有在等待之初就采取下客措施，对此我并不感到后悔与自责。在飞机上等待，我可以在旅客迷惘时第一时间向他们通报最新情况，可以在他们疲惫时递过一杯咖啡或盖上一条毛毯，可以在时间到来的第一刻带着他们冲上云霄。这些都是候机楼里等待所无法实现的。与此同时，我感受着旅客的焦虑，了解着他们的苦衷，这使我对相互理解又有着更深刻的认识和体会。这个时刻，飞早班的机组想必已经开始起床准备了，不知道今天又有哪些经历与故事等待着他们。记录下这一切，也许只愿换回旅客的一份信任吧。

0.999... = 1 吗？此问题在国内外大大小小的网络社区里出现了无数多次，每次都能引来上百人激烈的争论，可谓是最经久不衰的老问题了。其实，在学术界里，这个问题也是出了名的争论热点。让我们来看看，数学家们都是怎么来看待这个问题的。 最简单的“证明” 最简单的证明是这样的：1/3 = 0.333...，两边同时乘以 3，1 = 0.999... 。1998 年，弗雷德·里奇曼（Fred Richman）在《数学杂志》（Mathematics Magazine）上的文章《0.999... 等于 1 吗？》中说到：“这个证明之所以如此具有说服力，要得益于人们想当然地认为第一步是对的，因为第一步的等式从小就是这么教的。”大卫·托（David Tall）教授也从调查中发现，不少学生看了这个证明之后都会转而开始怀疑第一个等式的正确性。仔细想想你会发现，“1/3 等于 0.333…” 与 “1 等于 0.999…” 其实别无二致，它们同样令人难以接受。正如很多人会认为 “0.999… 只能越来越接近 1 而并不能精确地等于 1” 一样，“0.333… 无限接近但并不等于 1/3” 的争议依旧存在。问题并没有解决。 另一个充满争议的证明 大卫·福斯特·华莱士（David Foster Wallace）在他的 《Everything and More》一书中介绍了另外一个著名的证明： 令 x = 0.999... 所以 10x = 9.999... 两式相减得 9x = 9 所以 x = 1 威廉·拜尔斯（William Byers）在《How Mathematicians Think》中评价这个证明：“0.999... 既可以代表把无限个分数加起来的过程，也可以代表这个过程的结果。许多学生仅仅把 0.999... 看作一个过程，但是 1 是一个数，过程怎么会等于一个数呢？这就是数学中的二义性⋯⋯他们并没有发现其实这个无限的过程可以理解成一个数。看了上面这个证明而相信等式成立的学生，可能还没有真正懂得无限小数的含义，更不用说理解这个等式的意义了。” 逐渐靠谱的证明 等比级数具有这么一个性质：如果 |r| 那么我们就又有了一个快速的证明： 这个证明最早出现在 1770 年大数学家欧拉（Leonhard Euler）的《代数的要素》（Elements of Algebra）中，不过当时他证明的是 10＝9.999... 。 之后的数学课本中渐渐出现了更为形式化的极限证明： 1846 年，美国教科书《大学算术》（The University Arithmetic）里这么说：在 0.999... 里，每增加一个 9，它都离 1 更近。1895 年的另一本教科书《学校算术》（Arithmetic for School）则说：如果有非常多的 9，那么它和 1 就相差无几了。意外的是，这些“形象的说法”却适得其反，学生们常常以为 0.999... 本身其实是比 1 小的。 随着人们对实数更加深入的理解，0.999... = 1 有了一些更深刻的证明。1982 年，巴图（Robert. G. Bartle）和谢波特（D. R. Sherbert）在《实分析引论》（Introduction to Real Analysis）中给出了一个区间套的证明：给定一组区间套，则数轴上恰有一点包含在所有这些区间中；0.999... 对应于区间套[0, 1]、[0.9, 1]、[0.99, 1]、[0.999, 1] ... ，而所有这些区间的唯一交点就是 1，所以 0.999... = 1。 弗雷德·里奇曼的文章《0.999... 等于 1 吗？》里则用戴德金分割给出了一个证明：所有比 0.999... 小的有理数都比 1 小，而可以证明所有小于 1 的有理数总会在小数点后某处异于 0.999... （因而小于 0.999... ），这说明 0.999... 和 1 的戴德金分割是一模一样的集合，从而说明 0.999... = 1 。 格里菲思（H. B. Griffiths）和希尔顿（P. J. Hilton）在 1970 年出版的《A Comprehensive Textbook of Classical Mathematics: A Contemporary Interpretation》中，用柯西序列给出了另一个证明。 从未停止过的讨论 尽管证明越来越完备，学生们的疑惑却从来没有因此减少。在品托（Pinto）和大卫·托教授的一份调查报告中写到，当学生们用高等方法证明了这个等式之后，会大吃一惊地说，这不对呀，0.999… 显然应该比 1 小呀。 在互联网上，这个等式的魅力也依然不减。辩论 0.999… 是否等于 1 被讨论组 sci.math 评为“最受欢迎的运动”，各类问答网站中也总是会有网友激烈的讨论。 诺贝尔奖获者费曼（Richard Feynman）也用这个等式开过一句玩笑。有一次他说到：“如果让我背圆周率，那我背到小数点后 762 位，然后就说 99999 等等等，就不背了。”这句话背后有一个很奇怪的笑点：从 π 的小数点后 762 位开始，出现了连续的 6 个 9，偏偏在这里来一个“等等等”，就会给人感觉好像后面全是 9，这相当于把 π 变成了一个有限小数。此后，π 的小数点后 762 位就被戏称为了费曼点（Feynman Point）。作者：pondering 链接：https://www.guokr.com/article/19218/来源：果壳

原文转自：量子学派1 墨菲定律  一旦你担心考试遇到自己没复习的知识点，考题就总会考到，这就是高考“墨菲定律”。2波函数坍缩一名考场上的监考老师永远处于看你/不看你的叠加态，当你观察时，他会马上确定他是看你还是不看你。这就叫监考者的“波函数坍缩效应”。3波粒二象性选任意一个考生，他同时处于会/不会两种状态，你没有办法确定他具体状态，除非他开始答题。这叫考生的“会/不会二象性”。4测不准原理考试分数出来后，预期分数总与最终分数不符。这就是著名的分数“测不准原理”。5边际效应递减规律其他条件不变的情况下，随着刷题次数的递增，学生从每一遍刷题中所获得的有效知识越来越少。这被称为复习者的“边际效用递减规律”。6帕累托定律对于一名考生来说，决定80%高考成绩的是20%的拉分知识点。这就叫分数的“帕累托定律”。7混沌理论在上百万高考大军中，只要提高1分，就可以干掉几千甚至几万考生。这种1分微小变化带来存亡根本差别的反应，叫作考场系统里的“分数混沌”。8爱因斯坦相对论进考场前，感觉时间慢得难耐；进考场后，感觉时间飞快流逝。这被称为“考场时间相对论”。9马太效应一个学霸，往往认为老师布置的作业简单、题量很少；反之，一个学渣则总是抱怨功课题量太大、难度太高。这种现象在校园里常有，叫作“学习的马太效应”。10凡勃伦效应一个录取分数越高的学校，越是受到考生的喜爱。这种考试现象叫“考勃伦效应”。11斯德哥尔摩综合症高考越残酷，考生指望高考改变命运的感情就越强。这就是著名的“斯德哥尔摩高考综合症”。12领头羊效应一个优秀的学霸通常能带动周围的同学认真学习，一个学渣只能加强别的学渣。这是高考的“领头羊效应”。13熵增定律高考时，学渣将试卷从第一题翻看到最后一题，越看大脑越混乱。这就是“学渣熵增定律”。14黑洞无毛定理高考考生的世界只剩下分数、志愿、高校，其他的一切都消失了。这就是“考生无毛定理”。15达克效应高考结束后，88%的学生会认为自己的考试成绩高于平均水平。这就是著名的“成绩达克效应”。16玻色—爱因斯坦统计&费米——狄拉克统计每一个分数都可以容纳很多考生，这是“玻色—爱因斯坦统计”；但每一个考生只能拥有一个高考分数，这是“费米—狄拉克统计”。17潘洛斯阶梯四年后你会发现，高考的分数其实并不重要，重要的是你能明白人生走过的路并无高低，这就是高考的“潘洛斯阶梯”。

2019年5月14日，Microsoft在最新的安全更新公告中披露了一则RDP远程代码执行漏洞。通过此漏洞，攻击者无需经过身份验证，只需要使用RDP连接到目标系统并发送特制请求，就可以触发漏洞，实现在目标系统上远程执行代码。漏洞名称：Remote Desktop Protocol漏洞 威胁等级：严重 影响范围：Windows XP、Windows 7 、 Windows Server 2003、Windows Server 2008、Windows Server 2008 R2 漏洞类型：任意代码执行漏洞 一、Remote Desktop Protocol组件介绍 Remote Desktop Protocol(远程桌面协议，RDP)是微软公司创建的专有协议。它允许系统用户通过图形用户界面连接到远程系统。在默认情况下，该协议的客户端代理内置在微软的操作系统中，也可以安装在非微软操作系统中。RDP的服务器端安装在微软操作系统中，从客户端代理接收请求，显示发布应用程序的图形界面或者远程访问系统本身。默认情况下，系统在3389端口来监听来自客户端的通过RDP的连接请求。 通常情况下，在企业中，RDP或者终端服务会话被配置在需要分布式客户端机器来连接的服务器上。它可以用于管理、远程访问或者发布用于中央使用的应用程序。该协议还常被桌面管理员来远程访问用户系统，以协助排除故障。如果RDP没有正确配置或存在漏洞，这种特定功能将会给企业带来威胁，因为未授权访问者将可以访问关键企业系统。 二、漏洞描述 CVE-2019-0708，属于远程代码执行漏洞，当未经身份验证的攻击者使用RDP连接到目标系统并发送特制请求时，即可触发该漏洞。无需用户交互，成功利用此漏洞的攻击者可以安装应用程序，查看、更改、删除数据或创建具有完全用户权限的新账户。 此外，恶意攻击者还很有可能利用该漏洞专门编写恶意代码到定制的恶意软件，攻击易受感染的主机并进行病毒传播。  三、漏洞分析 1.漏洞原理 远程桌面协议（RDP）支持客户端和服务器之间的连接，并且以虚拟信道的形式定义了它们之间通信的数据。虚拟信道是双向数据管道，可以针对RDP实现扩展。 Windows Server 2000使用RDP 5.1定义了32个静态虚拟信道（Static Virtual Channel, SVC），由于信道数量的限制，进一步定义了动态虚拟信道（Dynamic Virtual Channel, DVC），这些信道包含在专用SVC中。 SVC在会话开始时创建并保持到会话终止，而DVC将会根据是否需要确定是否创建和抛弃。 此次微软补丁termdd.sys中的_IcaBindVirtualChannels和_IcaRebindVirtualChannels函数用于对这32个SVC进行绑定相关操作。 如下图所示，RDP连接序列在信道安全属性设置之前就进行了连接和设置，这为CVE-2019-0708的创建和传播提供了条件。 2.漏洞流量分析 “MS_T120”这个SVC名称在RDP协议的GCC Conference初始化序列时被绑定为数字31的参考信道。此信道名称由Microsoft内部使用，在客户端没有明显的、合法的使用以“MS_T120”命名的SVC来发起请求进行连接的用例。 下图展示了一个标准GCC Conference初始化序列的信息。 然而，在GCC Conference初始化期间，攻击者可以在31之外的信道上设置另一个名为”MS_T120”的SVC，这种行为将会导致堆内存破坏，最终可以实现远程代码执行。下图展示了GCC Conference初始化序列期间的异常信道请求： 3.漏洞补丁函数分析 下图中显示了MS_T120信道管理中涉及的相关组件。rdpwsx.dll和rdpwp.sys会为MS_T120信道分配堆内存。在31之外的信道索引的上下文中对MS_T120信道进行处理时，会发生堆内存损坏，损坏位置位于termdd.sys中。 通过对微软更新的CVE-2019-0708补丁的分析，可以发现该补丁修复了RDP驱动程序termdd.sys中的_IcaBindVirtualChannels和_IcaRebindVirtualChannels函数。  下图补丁函数分析所示，Microsoft补丁针对使用了信道名称“MS_T120”的情况下，添加了对客户端连接请求的检查，并确保它在termdd.sys中的_IcaBindVirtualChannels和_IcaRebindVirtualChannels函数中仅绑定到通道31（1Fh）。 四、影响范围 1.暴露资产情况  到目前为止，在全球范围内对互联网开放RDP的资产数量已经多达1250万，其中美国地区对外开放的RDP数量排名第一，为341万台。排名第二与第三的分别是中国和德国，其中中国数量远远超过德国的数量。 由以上数据统计看来，国内RDP的使用基数很高，用户相当广泛。其中RDP使用量最高的三个省市是北京，浙江以及广东。北京的使用量最高，数量达864982台，浙江省的使用量也达57万以上，广东省的使用量达27万。因此，针对此次RDP的漏洞防范尤为重要。 2.目前受影响Windows版本 Microsoft Windows XP  Microsoft Windows Server 2008 R2 for x64-based Systems SP1 Microsoft Windows Server 2008 R2 for Itanium-based Systems SP1 Microsoft Windows Server 2008 for x64-based Systems SP2 Microsoft Windows Server 2008 for Itanium-based Systems SP2 Microsoft Windows Server 2008 for 32-bit Systems SP2 Microsoft Windows Server 2003  Microsoft Windows 7 for x64-based Systems SP1 Microsoft Windows 7 for 32-bit Systems SP1 五、解决方案 修复建议如下：  （1）及时安装微软发布的安全更新补丁：   Microsoft官方已经在 2019年5月14日修复了该漏洞，用户可以通过安装微软的安全更新来给系统打上安全补丁，下载地址为：https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708  同时针对已不受微软更新支持的系统Windows Server 2003和Windows XP提供的安全更新，下载地址: https://support.microsoft.com/zh-cn/help/4500705/customer-guidance-for-cve-2019-0708  （2）缓解措施（在无法及时安装微软安全更新的情况下作为临时性解决方案）：   若用户不需要用到远程桌面服务，建议禁用该服务。             开启网络级别身份验证（NLA），此方案适用于Windows 7, Windows Server 2008, Windows Server 2008 R2。   暂时性修改RDP的连接端口，默认端口为3389。                   使用ACL对RDP的访问来源进行限制。                   使用RDP网关，网关的功能是安全的将流量从远程客户端传递到本地设备。 使用RDP网关可以防止或最小化远程用户访问，并使组织能够更好的控制用户角色，访问权限和身份验证需求。  以上缓解措施只能暂时性针对该漏洞对系统进行部分缓解，强烈建议在条件允许的情况下及时安装微软安全更新。 六、参考链接 [1].https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708  [2].https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/  [3].https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/5073f4ed-1e93-45e1-b039-6e30c385867c

       原文转自：http://game.zol.com.cn/213/2138869.html 文：姚舜禹　　不要告诉我成熟是什么，我在最灿烂的瞬间毁灭，　　不要告诉我永恒是什么，我在刚开始的瞬间结束。　                           　——郑智化·《别哭，我最爱的人》　　这一切还得从《仙剑奇侠传四》说起。　　2007年8月，《仙剑奇侠传四》在北京举行首发仪式，制作人张毅君(工长君)、张孝全(笑犬)等人到场签售，现场出现了由玩家排起的长长的购买游戏的队伍，这种情形一般只有在日本，每逢《最终幻想》、《勇者斗恶龙》这种大作发售时才能看到。　　现场有几幕颇令人感动。其中有一位玩家表示愿意出钱捐助上海软星，支持《仙剑》的研发，被婉拒后，他购买了好几套游戏才肯离开。还有一位从广西特地乘飞机赶来的15岁女玩家，在得到了张毅君的祝福之后，她激动地哭了。在上海《仙剑四》豪华版首发现场，有一位玩家在上海大剧院门口等待了13个小时，只为购得一套限量梦璃版。　　《仙剑四》一周内销量达20万套。这在如今日渐萎缩的单机游戏市场中已经算是一个了不起的数字。然而，就在此后不久，网上就传出张毅军、张孝全辞职的消息，紧接着，上海软星就正式宣布解散，一连串的变故来的都是如此突然，令人错愕。　　无数疑问摆在我们面前——《仙剑四》卖得好好的，怎么上软就解散了？二张的离职到底又所为何故？《仙剑》系列又将何去何从？带着这些疑问，笔者经过多方走访取材撰写了本文，希望能解答各位心中的疑问。　　一、事出有因　　俗话说，冰冻三尺，非一日之寒。上海软星能走到今天这一步，其实和母公司大宇的经营策略难脱干系。　　北京软星是台湾大宇公司在内地设立的全资子公司，代表作有《大富翁》；上海软星是北京软星的分公司，主要负责开发《仙剑奇侠传》系列，同时也有《阿猫阿狗》这样优秀的原创作品。上海软星既受到母公司大宇的财务管制，又要听从北京软星的指挥。在这个三角关系中，上海软星的自主权最小。　　当初成立上海软星，是北京软星的总负责人——“仙剑之父”姚壮宪的主意，他将《仙剑奇侠传》系列交给张毅君、王世颖等主力干将，而自己则专心开发《大富翁》。　　姚壮宪当初离开台湾到北京，其实多少带有赌气的成分。因为他尽管是大宇的王牌制作人，但前前后后这几年过得并不算开心。这其中有大宇内部的问题，也有他自己的问题。　　大宇公司的管理模式和其他游戏公司不太一样，比如在开发一款游戏时，会招进很多完全没有游戏开发经验的人，员工只要有好的创意都可以提出来，并且很容易被接纳。但是那个时候单机游戏市场很兴旺，游戏种类和数量并不多，因此只要做出游戏都会有人买，因此掩盖了这种管理模式很多弊端。随着市场越来越成熟，玩家的口味越来越高，钱也就越来越难赚。姚壮宪所经历的第一个游戏黄金时代——个人英雄时代结束了。　　与此同时，个人电脑也正在从Dos平台全面转向Windows平台，单凭一个人或几个人的小打小闹是不足以做出叫好又叫座的商业游戏。姚壮宪以往已经习惯了独来独往的制作风格，面临如今的技术和理念的双重转型，他面临许多矛盾和困惑。但除此之外，还有一件事让他一直耿耿于怀，那就是尽管他制作了最赚钱的两个系列《大富翁》和《仙剑奇侠传》，但大宇给他的待遇却只是一个中级别的项目主管。在大宇上市前，曾公开让员工认购原始股，但并没有给他更多的份额，这让他觉得非常不公平，于是当其他组的主管帮组员提升认购额度时，他却采取了置之不理的态度，导致他的组员应得的利益受到了很大损失，这引起了很多人对他的不满。　　大宇上市后，内部管理模式发生了一系列的改变，原先一批骨干开发人员纷纷走上管理岗位，其中也包括姚壮宪。由于管理经验的缺乏，小组制度的弊端也在转型后逐渐显现，小组间缺乏交流、各自为战的情况比较明显。姚壮宪的精力更多地放在项目规划和人事安排等方面，同时也暴露出他性格的很多缺点。为了避免别人插手《大富翁》和《仙剑奇侠传》的开发，他对小组成员加以过多的限制和保护。当时大宇决定向世嘉土星(SS)移植《仙剑奇侠传》，并确定由“狂徒创作群”的林嘉裕负责时，便引起了姚壮宪的不快。此后，当林和他的小组的几位美工走比较近时，他便警告林“不要打他组员的主意”，并且每次在林嘉裕索要《仙剑奇侠传》DOS版程序源代码时，姚壮宪总是以“硬盘坏了”等理由拒绝提供，林和组员只能从游戏中提取程序，并重新编写，无形中浪费了很多时间和资源。在完成SS版的移植后，林嘉裕愤而退出狂徒创作群。　　而姚壮宪与狂徒另一核心人物——谢崇辉的关系也不甚理想。谢崇辉是《仙剑》一代的主企划，为游戏同样倾注了大量心血，但他的名气却远不及“仙剑之父”的姚壮宪。在构思《仙剑二》时，姚谢二人的制作理念产生了重大分歧——姚壮宪坚持认为《仙剑二》应该讲述一个全新的故事，而谢崇辉则认为《仙剑二》应该延续一代的故事，两人争执不下，最终谢崇辉无奈只得转去开发新作《霹雳奇侠传》。而姚壮宪为了让游戏达到《FF7》、《铁拳3》的品质，不断修改剧本、推翻策划案，不仅开发人员叫苦不迭，让本就人手不足的开发组进度更是步履维艰，最后《仙剑二》的开发终于搁浅。　　2000年8月，大宇在北京注册了软星科技有限公司，姚壮宪觉得这是自己一次发展的机会，可以脱离总部的种种束缚，于是他仅带着张毅君一个人来到了北京。经过初期的艰苦奋斗，北京软星初具规模，不仅招募到很多游戏开发人才，还制作了《仙剑客栈》这部创意性的小品游戏，一切看起来都很顺利。但就在《仙剑客栈》发售不久，也就是北京软星刚刚成立一年之际，姚壮宪做出了一个令人有些意外的决定，让张毅君带队，与张孝全、王世颖等主力开发人员赶奔上海，成立了北京软星的分公司——上海软星。　　其实游戏做好最重要，露不露脸根本不重要。研发人员应该让游戏中的人物变成明星，而不是自己。　　——摘自张毅君BLOG 二、重任在肩　　上海软星的情况比较特殊，虽说是分公司，但真正的性质却只是一个子团队。姚壮宪曾要求张毅君只能开发《仙剑奇侠传》系列的游戏，并且一定要做好。这是有原因的，当初姚壮宪提出由上软负责开发《仙剑》续作时，就遭到了大宇总部的否定，总部认为张毅君之前一直没有独立负责过大型项目，他的能力和经验都不足以胜任《仙剑》这样重量级的产品，另外对大陆研发人员的技术是否能做出高水准的游戏也表示怀疑。在姚壮宪的极力保证下，总部才勉为其难的放行。而姚壮宪之所以执意要将《仙剑二》拿到上软去做，主要就是避免总部方面的过多干涉，面对这份信任和期待，张毅君深感自己的责任之重。　　很快，让姚壮宪和张毅君担心的事情发生了。谢崇辉的《仙剑二》提案通过了总部的批准，这让姚壮宪愤怒不已，他认为总部的做法实在有些欠妥，他必须采取一定的措施。因此他一面敦促张毅君尽快将《仙剑二》的提案上交，一面积极与总部联络，表达自己不满的情绪，但最终大宇还是将《仙剑二》的开发权交给了谢崇辉，而上软所提供的《仙剑二》则变成了《仙剑三》。　　由于总部对上软并不抱太大的期望，初期启动资金仅给了65万美金(约合540万人民币)。这样的规模做一款三流游戏可能还算够用，但制作像《仙剑三》这样的大作就显得有些捉襟见肘。更不要说张毅君一直在开发的RTS游戏《汉朝与罗马》也进入到了吃钱的阶段，更加速了资金的消耗。　　就在局势并不十分明朗之时，大宇总部突然传来谢崇辉的开发小组集体离职的消息，留下了烂尾的《仙剑二》。为了不让“仙剑”之名受损，姚壮宪不得不回到台湾，与其他几位制作人一起收拾烂摊子。可此时离制作档期结束只有不到一年，游戏的完成度却并不高，就算姚壮宪的能力再强，也无法在这样短的时间内把一个支离破碎的游戏变成经典之作，于是《仙剑二》在未能完善的情况下仓促推出，自然引起了玩家的强烈不满，一时间恶评如潮。　　《仙剑二》的失利带给张毅君更多的压力，《仙剑三》有可能会因为玩家产生的逆反心理影响到销量，一旦《仙剑三》也失败，后果就非常严重，不仅《仙剑》初代多年来累积的口碑可能会消失殆尽，上软也可能会随之关门大吉，就算运气好没有倒闭，但今后也会和《仙剑》绝缘。可以说，《仙剑三》还未出世，就注定是一款只许成功、不许失败的作品。　　张毅君和开发人员更加清楚这个后果的严重性，因此在制作《仙剑三》的过程中，几乎每个人都在不计报酬、不辞劳苦的加班，张毅君每天的工作时间更是超过15个小时，他们在尽可能地利用有限的资金条件，做出最好的效果。　　但是有些事情却不是仅靠拼命加班就能解决的。《仙剑三》项目进入到后期，65万美金基本已所剩无几，总部拒绝再追加投资的决定让上软陷入了经济危机。最严重的时候连办公用品都买不起，张毅君只得自掏腰包，勉强维持公司的运转，但凭他个人的财力又能支持多长时间呢？那个时候张毅君特别绝望，他想到过求助姚壮宪，但自尊心让他没有这么做。好在天无绝人之路，与寰宇之星的签约金成了一笔救命钱，靠着它项目终于得以完成。　　2003年7月，仅隔了半年时间的《仙剑三》正式发售，游戏的素质大幅度的超过了预期，征服了包括内地、港澳台在内的所有玩家。游戏限量版一度被炒到12000元人民币，一扫之前《仙剑二》失败的阴霾，成为玩家心目中真正的《仙剑》续作，甚至还有很多从来不知“仙剑”为何物的玩家也被《仙三》独特的中国文化底蕴与良好的游戏性所吸引，成为该系列的忠实拥趸。　　据统计，《仙剑三》共卖出50多万套(盗版约为300万套)，总销售额达到了6000多万元人民币，这在当时的中国游戏市场绝对是一个奇迹(如果没有盗版更加会是一个奇迹)。《仙剑三》的佳绩不仅让姚壮宪扬眉吐气，同时也让大宇总部打消了所有疑虑，将《仙剑奇侠传》的独立开发权留在了上软。　　小野人与菱纱、梦璃、紫英、勇气等等人物的互动，有很多其实都是研发人员平日给我的感受。我很庆幸认识这批同事，因为大家都保有一颗爱玩但又执著的心，工作辛苦但还是很快乐。　　——摘自张毅君BLOG 三、步履蹒跚　　尽管《仙剑三》的成功让许多人都松了一口气，但实际上并没有给上软带来多少切实的利益。因为上海软星没有独立的财权，大宇规定上软只能拿到内地销售的纯利润，而台湾、港澳的销售利润都归总部所有。这样算下来，能够留在上软的资金只有500万～600万，这点钱填补完公司的缺口以后也就所剩无几了。但用钱的地方还多着呢，上软要发展、《仙剑》要开发新作，这都要进行资金储备。最重要的是，《仙三》开发组拼死拼活忙了三年，迫切地需要奖金来慰藉一下。张毅君权衡了一下，决定还是以公司发展为重，并没有发放太多的项目奖金，这个做法引起了不少员工的不理解，他们觉得自己的劳动成果创造了巨大的经济价值，却没有得到应有的报酬，心里很不舒服，于是纷纷提出辞职。很快，一批骨干开发人员离开上软，张毅君尽管心痛，却也无力挽留。　　众所周知，2003年后，伴随着上海的房地产行业的爆发，人力物力的成本也开始飞升。三年后的500多万，实际作用可能连三年前的一半都不到，而上软员工的薪资待遇也和2001年时没什么区别。《仙剑三》的成功只是让上软声名远播，而开发资金的规模反而却不如三年前了，这是让张毅君和上软人感到的最不公平之处。只能靠一些低成本的项目(比如《仙剑三》 资料片“问情篇”)来创盈收，为《仙剑四》的开发积累资金。　　实际上，台湾大宇公司的待遇之差是业界一直所公认。通常是靠着知名系列和制作人招进员工，但开发完一个项目后，这些人就会觉得付出和获得不成比例而选择离开，所以也有人讽刺大宇是“培训基地”。从大宇出去的研发人员水平都不错，普遍要求却都不高，因为他们在大宇享受的是业界最低等级的待遇。　　这个习惯也延续到了北软和上软，相对来说北软要好一些，而上软则有点像“后妈的孩子”，就算做出再大的成绩，总部也不会因此而放宽政策，始终是冷冰冰的态度，未免让人感觉有点心寒。张毅君只能动用有限的资金，在不影响《仙剑》续作开发的前提下，做一些自己喜欢的游戏，其中《阿猫阿狗2》就是一部非常有创意的作品，各方面的评价都很高，但因为单机市场环境恶化的影响，最后也只能叫好而不叫座。随着《仙剑三外传：问情篇》的完成，又有一批老员工难以忍受高强度的工作和低廉的薪资待遇而离开上软，其中甚至包括《仙剑三》主力策划王世颖。这次离职后，上软的元老所剩无几。看着昔日的战友一个个离去，张毅君也想到了过一走了之，但对《仙剑》的感情让他迟迟无法下定决心，就这样一直挨到了《仙剑四》的项目的开始，他决心再奋力拼搏一次。　　那么，大宇总部为何始终对上软的管理策略如此冷漠呢？这主要是由于2003年后，单机游戏市场的日益衰落，开发公司纷纷解散或倒闭。随着盛大公司掘到的第一桶金的诱惑，更多的单机开发商转向网络游戏开发，大宇也是其中之一。但初次的几次试水均告失败，产生了巨额的亏损，加之单机市场的萎缩，对大宇的财务状况更是雪上加霜。连续几年亏损对上市公司打击是非常致命的，对于现在的大宇来说，迫切需要利润来填补亏空，而《仙剑三》创造的利润正好解了燃眉之急。　　尽管在网络游戏市场屡次失利，但大宇并没有动摇转型的决心，并不断加大投入。对单机游戏研发的预算则不断削减，从《轩辕剑五》的素质中即可看出端倪。姚壮宪的想法也比较类似，他在不断扩展新的产品思路，积极着手研发网络游戏。于是，上软的《仙剑四》就是在这种孤立无援的情况下开始了研发工作。　　大宇工作八年，看过太多沧桑，又小又穷的上软照顾仙剑六年，虽然辛苦，虽然不能做得更好，但是无惧无悔！　　——摘自张毅君BLOG　　四、壮士断腕　　拿着极其有限的资金，却承载着无数玩家的期望，不允许有半点敷衍和粗心；付出超过常人几倍的劳动，却拿着低于行业标准的薪水；用心制作的游戏，却换来那些使用盗版的玩家无端的指责和唾骂，这就是上软员工一直以来都在承受的压力。　　在《仙剑四》的很多人物对话，都强烈地透露着一种沧桑和辛酸，这难保不是制作人员的心声。在游戏一处隐藏地点中，《仙剑四》开发人员化身为一个个小妖怪，向玩家诉说心中的理想和委屈。看了这些，让人觉得心中不是滋味，仿佛这个结局早已注定，只是时间问题而已，。难怪有不少玩家在玩过后感慨地说，《仙剑四》的故事其实就是上软自己的故事。　　在《仙剑四》正版说明书中，张毅君写下了一段耐人寻味的前言。其中道出了上软这七年来的辛酸历程，以及不足为外人道的烦心事。“或许离开的大家都有各自的原因，但最为可惜的便是某些受不了玩家辱骂而心灰离开的战友。他们超量工作仍能怡然自得！看着销售量好像很高但利润很低的成绩还能继续奋斗！一边玩着欧美大作一边看着资金限制下自己的作品还能保持希望！但是每当面对恶意的批评，却往往不支倒地。”　　看到这里，不知那些等游戏出了，就在网上四处打听“有下载吗”，然后只玩了个开头就跑到论坛上大骂“垃圾”、“和FF、DQ完全没可比性”的所谓“玩家”，现在又作何感想？当你们随心所欲地践踏别人劳动成果时，又可曾想过，今天你们可以痛骂仙剑，而明天你们连骂的对象没有的时候，难道就可以心安理得地去玩那些国外大作了？　　张毅君在前言中还写到，“百年之后，仙剑本身并不重要，赚的多少也不重要，付出多寡也不重要，因为一切终将归于尘土……重要的是游戏乃人性所躯，不懂得经营、把握与坚持，便是等着他国文化洗脑，年青一代将不负记取何谓传统文化，岂不为国人悲哀？”　　可见，张毅君并不是仅仅把《仙剑》当作一款游戏在做，他希望《仙剑》成为中国传统文化的载体，将浩瀚五千年的中华文明渗入到每一位玩家的心中。尽管《仙剑四》各方面都不如那些国外的大作，但这种文化底蕴却是它们所无法具备的，因为《仙剑》是我们中国人开发的游戏，如果有朝一日《仙剑》、《轩辕剑》都不复存在，或是名存实亡，那么对于中国玩家来说绝对是一个悲哀至极的事。　　但是，盗版的冲击和玩家的恶意中伤还打不倒坚强的张毅君，让他已下定决心离开的是对于总部的积怨。《仙剑四》在中国内地的利润约有1000万人民币，这部分资金本应该为发展上软、开发《仙剑五》而准备，大部分都要挪用到其他项目上，留给张毅君的还是只有600万人民币，这和七年前开发《仙剑三》、三年前开发《仙剑四》的资金规模相同，但不同的是，如今的人力物力的成本是多少？如今游戏开发规模的又是多少？很多人喜欢拿《仙剑四》和《最终幻想》或《勇者斗恶龙》比——好，那我来告诉各位，《最终幻想7》的纯开发费用为4500万美元，按当时的汇率折合人民币为3亿6000万，那些整天批判《仙剑四》不如国外大作的人不妨算算，这个数字大约是上软开发资金的多少倍？　　那么，你现在知道为什么《仙剑四》的CG动画又少又难看，画面有些过时，人物动作有些呆板了吧？好，如果你明白了，我也不希望你说什么，做什么，明白就好。　　《仙剑4》的诞生多少带有一些悲剧色彩。本来是好好的游戏，却被Star Force加密软件弄得频繁卡机；正版验证也无可厚非，但偏偏就因为服务器太少造成拥堵而无法认证；台湾出精装版也是好事，但就是因为质量低劣打击了玩家收藏正版的热情。不明真相的玩家痛骂《仙剑四》，痛骂上软，看着这些无理的漫骂，回想大宇这么多年来对上海软星的冷遇，未来又要面对《仙剑五》这个“不可能完成的任务”，张毅君真的觉得有些倦了。　　2007年9月，张毅君、张孝全辞职，上海软星宣布解散，剩余工作将由北京软星接手。至笔者截稿日前，上海软星的员工无一人加入北京软星。 结束语：　　得知上软解散的消息，很多玩家痛哭失声。他们为什么要哭？因为他们知道，他们失去的不仅仅是一家制作公司，而是一个充满灵性、血性、个性的团队，一个深谙中国传统文化，坚持独立风格的优秀的游戏制作人。未来也许会有《仙剑》，但必定不会是那个工长君的《仙剑》了，必定不会是那个有些沧桑、有些自嘲，但骨子里却透出一股桀骜不驯、一股中国人的尊严的《仙剑》了，必定不会是那个能让玩家落泪的《仙剑》了。我始终认为，一个游戏的形式可以被照搬，但其中的灵魂却是无论如何也拿不走的。　　最后，请允许笔者引用一段《仙剑四》结尾中的一段话来结束这篇伤感的文章，希望离开上海软星的有志之士都能找到理想的职位，继续自己的梦想。　　“不管仙剑四最终的评价好坏；　　不管以后是否还有缘相聚在一起；　　在仙剑十四年的风雨是非之中；　　大家又在一起共同刻画了一次人生的烙印。　　——大宇最小团队 上海软星感言”　　注：本文部分内容参考了《狂徒传说》(作者：历史の道标)与《软星七年》(作者：大狗)，特此表示感谢。　　注2：谨以此文献给成立仅六年的上海软星公司，并向所有《仙剑奇侠传四》的开发人员致敬。

*本文转载自公众号SME科技故事只需输入作者名，电脑就能帮你生成一篇“SCI级别”的计算机论文。摘要、背景介绍、实验结果、图表、讨论以及结论等都一应俱全。世上就是有这等美事。只要你想，一口气就能搞个几百篇计算机论文。尽管SCIgen只是一个网页程序，但它产出的论文格式可能比一些本科论文还要规范。上图是本人用SCIgen自动生成的论文，SCIgen官方网站为https://pdos.csail.mit.edu/archive/scigen/感兴趣的可以自己一试。 不过也别高兴得太早，到目前为止AI还无法取代人类完成科研任务。别看这些生成的论文有模有样，但根本没有地球人能看得懂。不是因为太高深，内容纯属是“一本正经地胡说八道”。但这并不要紧，因为在学术界总是会有人上当。将这些计算机论文，投稿到一些国际学术期刊还会被录用，极具讽刺意味。         学术出版界也是个江湖，同样鱼龙混杂。并不是所有人，都奔着证明自己或是发现真正有价值的东西而来。而SCIgen这个程序的诞生，就是为了戏耍学术界的那些“野鸡期刊”。这些只以盈利为目的的野鸡期刊也叫掠夺性期刊（Predatory journals），学术质量与信誉都很低。他们的日常就是疯狂地给科研人员发送垃圾邮件，以“征集论文”之名吸引那些没有发表经验的学者上当。一般来说在论文发表前，学术刊物主编会邀请专业领域内有一定造诣的同行学者，评议论文的质量。这也叫同行评议，刊物会按评议结果决定是否发表。但掠夺性期刊，只要钱到位他们都能安排论文的发表，连审都不用审。因为日常不堪骚扰，麻省理工学院（MIT）计算机科学与人工智能实验的几个学生就看不过去了。2005年，Dan Aguayo、Max Krohn和Jeremy Stribling三人，决定向这种”水”得不行的期刊和会议宣战。从左到右分别为Dan Aguayo、Max Krohn和Jeremy Stribling那时已临近学期末，但这MIT三剑客还是花了一两星期去开发这个小程序。SCIgen的原理很简单，有些类似于填词游戏。学术论文的格式是非常相似的，它本身就充满了专业词汇和固定的句式。而SCIgen则能够从固定的词库中，随机抽取出这类计算机领域内的专业术语，以符合语法的方式生成文本。再加上一些漂亮的图表和详细的参考文献等，就能骗过不少外行。但这个软件真没多厉害，内行人一看就知道全文是在“胡说八道”。要怪，就怪一些期刊和会议灌水得太过分了。不出所料，他们第一篇自动生成的论文就攻破了WMSCI（World Multiconference on Systemics, Cybernetics and Informatics）会议的防线。这篇论文名为《Rooter：处理接入点与冗余的典型合一方法》，看似高大上其实内容根本不知所云。而WMSCI会议，不但接受了这篇假论文，还邀请作者出席会议作报告。这下可高兴坏了MIT三剑客。毕竟在这之前，他们就听说WMSCI会议以接受水货著称，但没真想到他们居然这么水。于是，他们便把SCIgen攻陷WMSCI的事情经过发到网上。一波嘲讽下来，这在科研圈立马引起了广泛的关注。毕竟大家早就看不惯这些掠夺性期刊和会议。这下WMSCI会议是颜面扫地，立马撤回了对他们团队的邀请。不过，失去报告资格，这三剑客反倒来了兴致。利用在网络上众筹来的2500美金，他们决定将恶作剧升级，搞一波大的。这三人，长途跋涉地在同一天赶往了会议所在的佛罗里达州奥兰多市。就在大会举办的同一地点，他们租了一块场地，用“假身份”开了一场属于自己的“分会场”。想要伪装一场学术会议并不难，和论文灌水一样只要有钱就够了。而报告内容用SCIgen就能无限生成，这种垃圾想要多少就有多少。除此之外，他们还置办了一批假的宣传海报、假名片、假胡子和假发等。反正，这场学术会议的一切都是假的。但这并不妨碍有人上当，当时来听他们装模作样演讲的人还不少。如果不明真相，或许这些人到现在都仍以为自己是在听WMSCI的报告。 但这场闹剧，并没有随着这场假学术会议的结束而收场。刚开始，只是IEEE撤销了对WMSCI会议的资助。到后来，越来越多人开始使用SCIgen产出的“钓鱼文”在其他学术期刊“试水”。现阶段，这三位SCIgen元老已步入职场，深藏功与名。而他们留下的这款软件，则将学术界搅得天翻地覆。        例如，德国的学生利用这款神器，就攻下了2008年和2009年在中国武汉举办的两个IEEE国际会议。当时，Schlangemann教授就被当成知名学者，还被邀请作为会议的主持人出席。但Schlangemann教授并非真有其人，他只是一个由这位学生创造的虚拟角色。而这个名字，则源于一部名为Der Schlangemann的德国电影。 Schlangemann教授还有虚拟的个人网站，感兴趣可以自行搜索Der Schlangemann的形象，比想象中还要讽刺现在SCIgen的访问量依然惊人。每年的浏览量仍超过60万次，无数钓鱼文在源源不断地产出。这导致了这个页面，隔几个月就要崩溃一回。2013年，法国格勒诺布尔大学的研究员Cyril Labbé就透露了一个令人不安的事实。他在IEEE和Springer出版公司旗下的期刊中，就发现了超过120篇SCIgen生成的诈文。对于自己是否已彻底排查出所有乱入的伪论文，Labbé自己心里也没底。因为他本人也无法从有限的订阅源内下载所有的论文。这也是学术出版商常常遭到诟病的一点。想在期刊上发论文需要收取高昂的版面费，但想在上面下载论文则又要付另外一笔费用。就算是作者本人在学术期刊上发表的论文，想要下载都不能例外，一律收费。而除了期刊的审核不严格，Labbé还揭示了另一个漏洞。那就是，利用SCIgen这类垃圾论文软件，竟可以给自己狂刷h指数（H index)。一名科研人员的h指数，是指他至少有h篇论文被引用了至少h次。这是评价个人学术成就的一个新方法。例如，某人的h指数是20，这表示他已发表的论文中，每篇被引用了至少20次的论文总共有20篇。但所谓的H指数，在SCIgen的捣乱下就无法起效了。当时，Labbé就以“IKE ANTKARE”作为作者名（注意，IKE ANTKARE这人并不存在），用SCIgen生成了102篇垃圾论文。这让IKE ANTKARE在谷歌学术中的h指数，一下子飙升到了94。他还一度挤进了计算机科学领域科学家中h指数排名的前六。当然，为了让h指数变高，他也用了一点小技巧。这100篇假论文中，每篇都会对所有作者名为IKE ANTKARE的假论文进行引用。而为了让谷歌学术能够对这100篇论文进行索引，Labbé还在参考文献中加入了唯一一篇真实的，已被谷歌学术索引的论文。“我自己引用自己”，就这样IKE ANTKARE凭一己之力就成了学术界冉冉升起的新星。这一虚拟人物的h指数，甚至比爱因斯坦还要高。当然，IKE ANTKARE这颗学术新星陨落得也很快。因为Labbé已经将自己的一系列骚操作写成论文，对世人公开了IKE ANTKARE的虚拟身份。随后谷歌学术，就对IKE ANTKARE进行了封杀并删除了他的论文。因为一些知名学术期刊，会对这些计算机生成的诈文照单全收。那么，我们就有理由相信一些作者会把SCIgen当作赚钱的工具。于是，为了揪出这些混入科学期刊的诈文，Labbé就与Springer合作特意开发了一款针对SCIgen的软件——SciDetect。这款开源软件，能够自动检测出哪些是由SCIgen生成的假论文。但在这之后，SCIgen的创始人之一Stribling是这样评价此事的。“他们开发了一个新程序，而不是制定更好的政策让所有被接受的论文有更好的评审过程，这事本身就挺搞笑的”。事实上，SciDetect的作用并不大，想要绕开这个程序的检测并不难。Stribling表示，如果这是一场军备竞赛，他敢打赌再次骗过SciDetect只是时间的问题。事实上，学术钓鱼从上个世纪就已经存在了。早在1996年，量子物理学家艾伦·索卡尔(Alan Sokal)撰写的一篇科学诈文，就引起了一场“科学大战”。他将一篇充满了常识性错误的论文，投稿至著名的文化研究杂志《社会文本》。标题为《超越界限：走向量子引力的超形式的解释学》。结果《社会文本》的五位主编，都没有发现这是一篇诈文，还一致通过将文章发表。东窗事发，这立即触发了一场席卷全球的科学大论战，世界众多著名的媒体都参与其中。相比SCIgen，艾伦·索卡尔还是比较有诚意的。尽管内容还是一本正经地胡说八道，但论文毕竟还是他自己亲手炮制的。他将量子物理学中的术语、后现代主义领军人物的术语，还有他自己捏造词句糅合在了一起。于是便得到了一篇毫无学术内涵，但又充满“后现代”风格的诈文。而作为学术钓鱼的鼻祖，之后的学术钓鱼事件都被称为“索卡尔的平方”。那么学术钓鱼，何时能消失？很简单，只有鱼儿不上钩，钓鱼就会自动失去意义。*参考资料Adam Conner-Simons.How three MIT students fooled the world of scientific journals.MIT News.2015Jerrusalem.“三傻”大闹科研坞：我们怎么钓出了那些水货？.果壳网专访.2015李慧翔.给我一篇假论文，我能骗倒半个地球.南方周末.2013John Bohannon.Hoax-detecting software spots fake papers.Science.2015CYRIL LABBÉ.One of the great stars in the scientific firmament. ISSI NEWSLETTER.201

资源名称：Stulz C5000 空调说明文档 资源类型：PDF 资源Hash： File: D:\Desktop\C5000.pdf Size: 816335 bytes Modified: 2019年4月16日, 12:20:46 MD5: B2DE785881081831CA8D1D288C6B8849 SHA1: 50C4E040EABD0C273278E66274FFB7B8778C18E2 CRC32: D8D273D4 预览：下载地址：本地下载   分流下载

    原文摘自：http://www.rupeng.com/forum/thread-1215-1-1.html     编者注：这已经是许多年前的一篇文章，但里面的一些看法仍然很实际，值得推荐一看    我始终认为，对一个初学者来说，IT界的技术风潮是不可以追赶的，而且也没有能力去追赶。我时常看见自己的DDMM们把课本扔了，去卖些价格不菲的诸如C#, VB.Net 这样的大部头，这让我感到非常痛心。而许多搞不清指针是咋回事的BBS站友眉飞色舞的讨论C#里面可以不用指针等等则让我觉得好笑。C#就象当年的ASP一样，“忽如一夜春风来，千树万树梨花开”，结果许多学校的信息学院成了“Web 学院”。不少大学生都去做Web 了。当然我没有任何歧视某一行业的意识。我只是觉得如果他们把追赶这些时髦技术的时间多花一点在基础的课程上应该是可以走得更远的。  几个误区  　      初学者对C#风潮的追赶其实也只是学习过程中经常遇到的几个误区之一。我将用一些实际的例子来说明这些现象，你可以按部就班的看看自己是不是属于其中的一种或者几种：  认为计算机技术等于编程技术:      有些人即使没有这个想法，在潜意识中也有这样的冲动。让我奇怪的是，许多信息学院的学生也有这样的念头。认为计算机专业就是编程专业，与编程无关的，或者不太相关的课程他统统都不管，极端的学生只要书上没带“编程”两个字他就不看。      其实编程只是计算机技术应用过程中一种复杂性最低的劳动，这就是为什么IT业最底层的人是程序员（CODER）。计算机技术包括了多媒体，计算机网络，人工智能，模式识别，管理信息系统等等这些方面。编程工作只是在这些具体技术在理论研究或者工程实践的过程中表达算法的过程。编程的人不一定对计算机技术的了解就一定很高。而一个有趣的现象是，不少大师级的计算机技术研究者是不懂编程的。网上的炒作和现实中良好的工作待遇把编程这种劳动神秘化了。其实每一个程序员心里都明白，自己这些东西，学的时候并不比其它专业难，所以自然也不会高档到哪里去。  咬文嚼字的孔已己作风:      我见过一本女生的《计算机网络原理》教材，这个女生像小学生一样在书上划满了横杠杠，笔记做得满满的，打印出来一定比教材还厚。我不明白的是，像计算机网络原理这样的课程有必要做笔记？我们的应试教育的确害了不少学生，在上《原理》这一类课程的时候许多学生像学《马列原理》一样逐字背诵记忆。这乃是我见过的最愚蠢的行为。所谓《原理》，即是需要掌握它为什么这样做，学习why，而不是how（怎样做）。极端认真的学生背下以太网的网线最大长度，数据帧的长度，每个字段的意义，IP报头的格式等等，但是忘了路由的原则，忘了TCP/IP协议设计的宗旨。总之许多人花了大量的时间把书背得滚瓜烂熟却等于什么也没学。      在学习编程的时候这些学生也是这样，他们确切的记得C++语法的各个细节。看完了C++教程后看《Thinking in C++》（确实是好书），《Inside C++》，《C++ reference》，this C++, that C++……，然后是网上各种各样的关于C++语法的奇闻逸事，然后发现自己又忘了C++的一些语法，最后回头继续恶补…。有个师弟就跟我说：“C++ 太难了，学了这里忘了那里，学了继承忘了模板。”我的回答道：“你不去学就容易了”。我并没有教坏他，只是告诉他，死抠C++的语法就和孔已己炫耀茴香豆的茴字有几种写法一样毫无意义。你根本不需要对的C++语法太关心，动手编程就是了，有不记得的地方一查MSDN就立马搞定。我有个结论就是，实际的开发过程中对程序语法的了解是最微不足道的知识。这是为什么我在为同学用Basic（我以前从没有学过它）写一个小程序的时候，只花了半个小时看了看语法，然后再用半个小时完成了程序，而一个小时后我又完全忘记了Basic 的所有关键字。  不顾基础，盲目追赶时髦技术：      终于点到题目上来了。大多数的人都希望自己的东西能够马上跑起来，变成钱。这种想法对一个已经进入职业领域的程序员或者项目经理来说是合理的，而且IT技术进步是如此的快，不跟进就是失业。但是对于初学者来说（尤其是时间充裕的大中专在校生），这种想法是另人费解的。一个并未进入到行业竞争中来的初学者最大的资本便是他有足够的时间沉下心来学习基础性的东西，学习why 而不是how。时髦的技术往往容易掌握，而且越来越容易掌握，这是商业利益的驱使，为了最大化的降低软件开发的成本。但在IT领域内的现实就是这样，越容易掌握的东西，学习的人越多，而且淘汰得越快。每一次新的技术出来，都有许多初学者跟进，这些初学者由于缺乏必要的基础而使得自己在跟进的过程中花费大量的时间，而等他学会了，这种技术也快淘汰了。基础的课程，比方数据结构，操作系统原理等等虽然不能让你立马就实现一个linux（这是许多人嘲笑理论课程无用的原因），但它们能够显著的减少你在学习新技术时学习曲线的坡度。而且对于许多关键的技术（比方Win32 SDK 程序的设计，DDK的编程）来说甚至是不可或缺的。      一个活生生的例子是我和我的一个同学，在大一时我还找不到开机按纽，他已经会写些简单的汇编程序了。我把大二的所有时间花在了汇编，计算机体系结构，数据结构，操作系统原理等等这些课程的学习上，而他则开始学习HTML和VB，并追赶ASP的潮流。大三的时候我开始学习Windows 操作系统原理，学习SDK编程，时间是漫长的，这时我才能够用VC开发出象模象样的应用程序。我曾一度因为同学的程序已经能够运行而自己还在学习如何创建对话框而懊恼不已，但临到毕业才发现自己的选择是何等的正确。和我谈判的公司开出的薪水是他的两倍还多。下面有一个不很恰当的比方：假设学习VB编程需要4个月，学习基础课程和VC的程序设计需要1年。那么如果你先学VB，再来学习后者，时间不会减少，还是1年，而反过来，如果先学习后者，再来学VB，也许你只需要1个星期就能学得非常熟练。  几个重要的基础课程  　      如果你是学生，或者如果你有充足的时间。我建议你仔细的掌握下面的知识。我的建议是针对那些希望在IT技术上有所成就的初学者。同时我还列出了一些书目，这些书应该都还可以在书店买到。说实在的，我在读其他人的文章时最大的心愿就是希望作者列出一个书单。  大学英语－不要觉得好笑。我极力推荐这门课程是因为没有专业文档的阅读能力是不可想象的。中文的翻译往往在猴年马月才会出来，而现在的许多出版社干脆就直接把E文印刷上去。学习的方法是强迫自己看原版的教材，开始会看不懂，用多了自然熟练。吃得苦下得狠心绝对是任何行业都需要的品质。  计算机体系结构和汇编语言－关于体系结构的书遍地都是，而且也大同小异，倒是汇编有一本非常好的书《80x86汇编语言程序设计教程》（清华大学出版社，黑色封面，杨季文著）。你需要着重学习386后保护模式的程序设计。否则你在学习现代操作系统底层的一些东西的时候会觉得是在看天书。  计算机操作系统原理－我们的开发总是在特定的操作系统上进行，如果不是，只有一种可能：你在自己实现一个操作系统。无论如何，操作系统原理是必读的。这就象我们为一个芯片制作外围设备时，芯片基本的工作时序是必需了解的。这一类书也很多，我没有发现哪一本书非常出众。只是觉得在看完了这些书后如果有空就应该看看《Inside Windows 2000》(微软出版社，我看的是E文版的，中文的书名想必是Windows 2000 技术内幕之类吧)。关于学习它的必要性，ZDNET上的另一篇文章已经有过论述。  数据结构和算法－这门课程能够决定一个人程序设计水平的高低，是一门核心课程。我首选的是清华版的（朱战立，刘天时）。很多人喜欢买C++版的，但我觉得没有必要。C++的语法让算法实现过程变得复杂多了，而且许多老师喜欢用模块这一东西让算法变得更复杂。倒是在学完了C版的书以后再来浏览一下C++的版的书是最好的。  软件工程－这门课程是越到后来就越发现它的重要，虽然刚开始看时就象看马哲一样不知所云。我的建议是看《实用软件工程》（黄色，清华）。不要花太多的时间去记条条框框，看不懂就跳过去。在每次自己完成了一个软件设计任务（不管是练习还是工作）以后再来回顾回顾，每次都会有收获。  Windows 程序设计－《北京大学出版社，Petzold著》我建议任何企图设计Windows 程序的人在学习VC以前仔细的学完它。而且前面的那本《Inside Windows 2000》也最好放到这本书的后面读。在这本书中，没有C++，没有GUI，没有控件。有的就是如何用原始的C语言来完成Windows 程序设计。在学完了它以后，你才会发现VC其实是很容易学的。千万不要在没有看完这本书以前提前学习VC，你最好碰都不要碰。我知道的许多名校甚至都已经用它作为教材进行授课。可见其重要。  上面的几门课程我认为是必学的重要课程（如果你想做Windows 程序员）。      对于其它的课程有这样简单的选择方法：如果你是计算机系的，请学好你所有的专业基础课。如果不是，请参照计算机系的课程表。如果你发现自己看一本书时无法看下去了，请翻到书的最后，看看它的参考文献，找到它们并学习它们，再回头看这本书。如果一本书的书名中带有“原理”两个字，你一定不要去记忆它其中的细节，你应该以一天至少50页的速度掌握其要领。尽可能多的在计算机上实践一种理论或者算法。      你还可以在CSDN上阅读到许多书评。这些书评能够帮助你决定读什么样的书。  日三省乎己　　　　      每天读的书太多，容易让人迷失方向。一定要在每天晚上想想自己学了些什么，还有些什么相关的东西需要掌握，自己对什么最感兴趣，在一本书上花的时间太长还是不够等等。同时也应该多想想未来最有可能出现的应用，这样能够让你不是追赶技术潮流而是引领技术潮流。同时，努力使用现在已经掌握的技术和理论去制作具有一定新意的东西。坚持这样做能够让你真正成为一个软件“研发者”而不仅仅是一个CODER。  把最多的时间花在学习上      这是对初学者最后的忠告。把每个星期玩CS或者CS的时间压缩到最少，不玩它们是最好的。同时，如果你的ASP技术已经能够来钱，甚至有公司请你兼职的话，这就证明你的天分能够保证你在努力的学习之后取得更好的收益，你应该去做更复杂的东西。眼光放长远一些，这无论是对谁都是适用的。      相信你已经能够决定是否学习C＃或者什么时候去学它了。