感谢LiGHt童鞋的辛勤劳动，在实习中抽出难得的业余时间为Geek For Us制作主题，几乎是高保真地将我的设计图转换成了代码。由于我对CSS什么的缺少了解，设计图中有很多东西都是直接用CSS难以实现的，给LiGHt带来了不少的麻烦，这里再次感谢LiGht的劳动！
当然，现在的主题还存在一些问题，请大家一起帮忙反馈，并且在本文后的留言中指出Bug之所在。另外，对于需要截图才能说明白的，也欢迎给我发送电子邮件：coolcfan # gmail.com（去掉空格并把#换成@）。
这是WooDragon同学看到一篇“伪科学”文章后自己查资料写出的回应，本来只是想写成一篇科普文，后来在推特上讨论时，我建议从破坏电梯、恐怖袭击的角度入手，WooDragon欣然采纳，于是就有了这样一篇文章。原文在此。
——coolcfan
前天的时候看了这篇文章：http://ta.md/1010/ 标题是《电梯突然断电下坠时，一定要这么做》。作者的观点虽然不能说错，但是文中对这种事件的发生条件和概率毫无论证和考据，极易误导读者使其产生“电梯只要断电就会下坠”这样的错觉，说不定会造就不少人的“电梯恐惧症”……所以我决定用类似方法YY一下弄死一电梯的人需要什么条件来验证这个说法。
文首注：下面的实验对象全部指的是正常维护的、整套系统正常运转、所有装置都能顺利准确动作的电梯。
再注：没耐心的直接看末尾。
准备阶段，我首先研究了电梯行动机构的安全体系，该部分资料来源：中国电梯信息港
防超越行程的保护
为防止电梯由于控制方面的故障，轿厢超越顶层或底层端站继续运行，必须设置保护装置以防止发生严重的后果和结构损坏。
防止越程的保护装置一般是由设在井道内上下端站附近的强迫换速开关、限位开关和极限开关组成。防止越程的保护装置只能防止在运行中控制故障造成的越程，若是由于曳引绳打滑、制动器失效或制动力不足造成轿厢越程，该保护装置无能为力。
防电梯超速和断绳的保护
电梯由于控制失灵、曳引力不足、制动器失灵或制动力不足以及超载拖动绳断裂等原因都会造成轿厢超速和坠落，因此，必须有可靠的保护措施。
防超速和断绳的保护装置是安全钳－限速器系统。安全钳是一种使轿厢（或对重）停止向下运动的机械装置，凡是由钢丝绳或链条悬挂的电梯轿厢均应设置安全钳。当底坑下有人能进入的空间时，对重也可设安全钳。安全钳一般都安装在轿架的底梁上，成对地同时作用在导轨上。
限速器是限制电梯运行速度的装置，一般安装在机房。当轿厢上行或下行超速时，通过电气触电使电梯停止运行，当下行超速电气触点动作仍不能使电梯停止，速度达到一定值后，限速器机械动作，拉动安全钳夹住导轨将轿厢制停；当断绳造成轿厢（或对重）坠落时，也由限速器的机械动作拉动安全钳，使轿厢制停在导轨上。安全钳和限速器动作后，必须将轿厢（或对重）提起，并经专业人员调整后方可恢复使用。
缓冲装置
电梯由于控制失灵、曳引力不足或制动失灵等发生轿厢或对重蹲底时，缓冲器将吸收轿厢或对重的动能，提供最后的保护，以保证人员和电梯结构的安全。
将缓冲器无效化：
由保护原理来看，缓冲装置所起到的作用在高层坠落时微乎其微，所以我进行破坏时必须确保电梯下坠时正处于8层或更高，这样一来底坑的缓冲器铁定跟着电梯轿厢一块儿打地基了。
先算算多高掉下去能把人弄死，电梯轿厢（非高速）自重通常在1000-1300kg，这里我取最小值以确保致死冗余高度。
地球上重力加速度为9.8N/kg，为了计算方便，将轿厢质量换算成牛顿，为9800N-12740N，后面仅计算最小轿厢重量（空载）情况下最小致死高度，同样为确保致死冗余高度（因为质量越大惯性越大）。
普通写字楼楼层高度3.5米，假设从8楼坠落，估算坠落时间h=1/2gt^2。坠落时间t约等于2.39s
最大瞬间速度估算。v=gt，v约为23.422m/s
为了计算方便，忽略轿厢触底反弹以及缓冲器卸走的力，仅计算完全不反弹的极限情况，MV=F*t。
原本我将t值估算为0.1s，但是在frank lin指出了t的取值问题，随后我又请教了 @xufan6 ，他认为t值的计算会较为复杂，故而我决定放弃t值的确认，继续维持估算，此外他也给出了大致符合真实情况的t值，将其确定设为1。
由此得平均冲击力F估算为229535.6牛顿，等于23422kg，等于23.422吨（一开始的值为234吨，差距很大，看起来撞击持续时间对结果会产生很大的影响）
鉴于这属于瞬间过载，美国航空航天局的SP-3006文档显示不考虑晕厥，人所能承受的最大正向瞬间过载为35G（一秒以内）。
电梯坠落触地时瞬间静止，而电梯自重1吨，承受的冲击为23.422吨，所以电梯整体承受的过载为23.422G，理论上人与轿厢以同样的速度触地，所受过载理应也相同，23.422G即便单纯只是过载也能使人失去知觉很长一段时间，更何况需要承受23.422个人体重量的剧烈冲击，和跳楼没什么区别，必死无疑。（飞行员高G机动的时候不需要同时拿9倍于体重的东西往身上砸吧—_—并且速度变化也没有那么剧烈）
缓冲器我没有找到很详细的资料，不过通常认为缓冲器的承受能力在0.5-20吨之间，轿厢下方的底坑通常配备两只缓冲器（非可信源，请求来源），简单的相加能够承受40吨的冲击力，同样也是泻完就挂的份，另外40吨的意思是缓冲装置能承受40G的冲击而不挂掉，不是能够让40吨的冲击力化为粪土……
也就是说如果要保证高度可靠的乘客死亡率，高层坠落是前提。
将钢缆相关的安全装置无效化：
与钢缆有关的主要安全装置有制动器以及减速箱，要引发下级安全装置动作必须破坏或者无效化这两者，而由于整套电梯安全系统均为电气控制，其中任何一个环节故障都将触发电梯停止运行，所以非同时的破坏或者无效化安全系统是不可行的，即不能先破坏制动器和减速箱再破坏最终安全装置（限速器-安全钳系统）来引发坠毁。
其次断电导致电梯坠落也是不现实的，一来制动器在非正常断电时能自动制停曳引机，二来最终安全装置（限速器-安全钳系统）同样能够在断电条件下动作制停电梯。所以在突然断电时电梯不会下坠而是立刻停止在原位置。假如发生断电坠落，那么可以肯定的是该部电梯安全装置已经失灵，即便备电启动电梯恢复正常，那么不需要动手，未来必然发生事故。
在这里电梯曳引机断电抱死的资料来源于 @coolcfan 的某工程师亲属，感谢。
参考常规曳引式电梯结构图：
综合考虑之下目前想到可行办法有三：
方案1需要对各型制动及减速系统结构及原理有充分的理解，需要先悄无声息的无效化最终安全装置，再使减速及制动系统失效，然后电梯随后就会失控并冲顶或坠落。
方案2是较为方便的，同时破坏所有可能的安全机制和曳引装置，直接使其迅速下落，但是由于对重装置的存在，所以会存在一个较长的加速时间，故而在更高的楼层实行该方案比较合适，如果楼层较低，没有足够的加速距离，底坑缓冲器也许能使电梯保持完整结构的着陆，也就是无法确保乘客死亡的必然性。
方案3是相对最可靠的方案，因为可以忽略制动器、减速箱等作用于钢缆及曳引机的安全装置（事实上，电梯在正常运行中就是主要依靠的这二重安全机制），只需要考虑最终安全装置的解除，查看该类安全装置（安全钳-限速器系统）结构后发现，不触发自动切断回路的情况下较好的破坏该系统的方法是在电梯停止运行的情况下切断限速器钢丝并将末端捆绑于电梯上，这样可导致限速器正常工作，但遭遇急速下降触发极限开关时安全钳无法被下坠动能提起制动从而确保坠落过程顺利。
公称直径10mm的八股钢丝抗拉强度标准为1770N/mm2，理论单根抗拉强度17700N，约为1806.1kg，约为1.8吨。常用客运电梯钢丝绳数量4-8根，按6根计算电梯钢丝绳荷载10点8吨。同时标准规定最小破断载荷44kN，6根的话简单相加计算为26.9吨（来源：GB 8903-1988）
由此可以发现维护良好的钢缆荷载远大于电梯标称荷载，故而通过载重弄断所有钢丝的可能性非常低，同时搜索发现全球电梯因为超重而坠落的例子极少（via 维基百科）
故而弄断钢丝绳较为可行的方法有剪切和爆破，但是实际上要考虑到绷紧的钢缆被剪切时带有巨大应力的抽击，人下井作业的话有极高的可能性被钢丝绳甩到从而死无全尸，并且同时需要担负极高的被当场抓获风险，实为不智之举。
爆破的话就安全了，爆破物设在顶部连接部、钢丝绳上（位置要靠近轿厢，否则容易被盘机绞进去误触）、轿厢连接部都行，使用遥控或者定时引爆，装药量不需大（无法估计所需装药量，无钢缆紧绷状态下的横向极限受力数据），对于绷紧的钢缆来说，被施加纵向破坏力从而断裂的难度远大于施加横向破坏力从而断裂的难度。
将最终安全装置无效化：
最终安全装置就是限速器——安全钳系统
该系统有无电力均可完全动作，所以停电下坠是很不靠谱的说法，但是该系统为电梯的最终保障装置（请无视缓冲器），普通的断电并不会触发安全钳的动作，这里延续上面说下大概原理，限速器在机房由一根钢索连接到轿厢侧面或者底部的安全钳，当电梯运行速度过快，触发强制换速开关无效、制动器无效的情况下，持续加速到触发极限开关，那么限速器机械动作，切断电梯回路并且使主系统失电，限速器抱死，这时电梯仍在下落，下坠的动能导致缩进的钢索提起安全钳并且死死卡在钢轨上开始强制制动，下坠速度越快，制动力越大。
安全钳动作过后并不能自动复位，所以除非极限情况，并不会导致安全钳的动作。异常断电时动作的是位于曳引电机连接部的制动器，它会在断电时自动抱死电机使钢丝绳停止运动从而制停下降。
故而破坏限速器和安全钳，连接钢丝都能使安全钳无法顺利动作，事实上这一步同样可以按照上一部分中破坏承重钢丝绳一样做法，但是连接钢丝较细，不方便直接爆破，将爆炸物置于限速器下方或者直接爆破限速器是不错的做法，总之解开限速器和安全钳的连接即为成功。
总结
从上文可以看出，在无人为干预的情况下，电梯发生无制动下坠的可能性极小，即便发生，也应追究责任人，同时进电梯时注意检查电梯安全规范铭牌，否则则为私设电梯，是无安全保障的。
http://zh.wikipedia.org/zh-cn/%E5%8D%87%E9%99%8D%E6%9C%BA#.E6.84.8F.E5.A4.96
从这里可以看出，作为一种运载工具来看，按照客运量排序的话电梯应当是最为安全、事故几率极低的，并且绝大多数事故均是人为操作不当导致，面对一部定期检查、结构完善、动作正常的现代电梯，完全不需要有任何不安的心态，需知假如电梯发生急速下坠的事故而无安全装置动作，那么一切姿势皆为徒劳，如此巨大质量物体从高层下坠触地产生的瞬间过载足以让里面的人成为一堆肉饼——你不会有什么痛苦产生，一下子就过去了~而只要有一处安全装置顺利动作，那基本上就性命无忧了。
在frank lin的提示下，在此补充一点，通常情况下有保险装置动作的电梯下坠时，使用正确的肢体动作是可以最大程度保护自己免于或尽量减少受伤的（文中所述极端的必死情况几乎不可能出现），因为只要有安全装置动作，那么一般情况下冲击力只要使用正确的抗冲击动作就不足以致命，站立是必须的，由前文可得撞击持续时间越长，最终冲击力就会极大的降低了，而从站立到瘫倒的重心转移过程可以极大延长撞击持续时间，同时在下坠发生时迅速站到角落位置，这常见于地震防护常识，建筑物角落部位的强度是最高的，不容易变形。
流言止于智者，我们应该抱着怀疑的态度去看待每一则没有出处和科学依据的内容，不被伪科学误导。
本文不供学习不供参考，一切内容皆未经过实验检验，请勿付诸实践，如有人进行此类实验导致的一切后果请自行承担。
最后，coolcfan还是要插一句，安全钳是1853年发明的，使用电力的升降机则是在那之后才发明出来的……
夏天的威力果然无穷，一个北方海滨城市的气温都达到了30多度。在没有空调的房间里，在一台掌托温度足有40度的笔记本电脑上，稀饭继续为您推荐软件，这是什么精神！
天气如此的热，写起文章来自然也很难集中精神。除了打开电扇让风带走些许温度，也许还需要一个没有打扰的写作环境——它们应该将一切可能分散你精力的事物都遮挡在界面之后，让你可以专心于你写出的文字。这就是“非主流编辑器”第二集的主题——全屏文本编辑器（Fullscreen Text Editors）。
系列前言
在做毕业设计的过程中，需要经常编写Ruby on Rails代码。Rails工程的目录结构比较复杂，需要修改的文件分布在多个目录中，尽管手头已有VIM，但并没有为Rails开发进行专门的配置，编写起代码来就比较麻烦。某些人相信VIM能做任何开发用编辑器能做的事——只要你花足够多的时间和精力去配置，可我总觉得，花时间用VIM“山寨”一个TextMate或者其他什么编辑器，是一件无比蛋疼的事，所以，我希望找一个“适合”Ruby on Rails的编辑器，来完成这项工作。
在这个过程中，我试用了数款编辑器，它们各有各的特色，其中有一些，真的是相当有创意。而且，我还意识到，有很多特色各异的编辑器（并不限于代码编辑）并不为大众所知。因此，Geek 4 Us推出“非主流编辑器”这个专题，希望通过我们的介绍，让大家认识它们。
Geek4Us所用的主题Theme G33k的第一版设计稿完成后，WPG论坛的Keelii同学自告奋勇地承接了将其转化为WP主题的任务。完成的主题使用到现在，出现了一些问题——包括编码上的，以及设计上的。
于是，在1个多月前，我就开始修改Theme G33k的设计稿，这期间由于忙于毕业设计而搁置了很久，现在终于有空，来完成第二版的设计了。这次的修改目标是“简洁”，着重简化了导航、侧栏、文章列表等区域的设计，同时将主题整体调亮来避免第一版可能存在的压抑感。
现在，设计稿还没有完成，但我希望提前征集在Coding方面有造诣的人士来帮忙。有意者，请在文后留言，我会联系您的。
我很喜欢逛Acfun，因为这个网站上有很多好玩的视频，还有无数围观者的吐槽；我会把某些喜欢的视频下载回来，然后用播放器循环洗脑（比如……上老师的作品）。在以前，我会用AcfunDowner来完成这一工作。它本来是一款好软件，但由于我的懒惰本性，这个需要我手动打开软件、把视频网页的地址复制进去再点击“下载”的软件还是免不了被我束之高阁的命运——尤其是在，我的同学给我VDigger之后。
VDigger是来自DLUT计算机系某教研室的一款流媒体下载软件，也就是说，软件的开发者们，是我的老师、学长和同学。如果不是因为这一点，我可能并不会知道这个软件——它实在是完全没有任何名气，也没有做任何宣传；今天我在这里写这篇文章，也完全是出于这一点。废话少说，下面大家就随我一起看看，VDigger究竟不一样在哪里。
本文是 Tabbles 系列的第 2 部分。 之前的Tabbles初体验，不但得到了小众软件的链接，还发表在《电脑爱好者》杂志上。但那只是一篇体验文，很多同学看了之后还是不明白Tabbles到底能干什么。今天为大家带来的，是horan同学自己使用Tabbles整理电影的心得，大家一起来看一看，Tabbles在实际使用中的效果吧～
[ 原文链接 | 转载有修改 ]
大概一个多月之前便听说了 Tabbles，安装在机子上这么久，也就用过当初那么一次。
大约是因为那时候骆驼还并不是太了解，Tabbles 或者 WinFS 到底能够提供怎样的便利，对于它们也仅仅停留在字面意义上的理解。就算是使用了 Tabbles，也未觉察出它与 Windows 自带的资源管理器有何显著分别。
事情的转变总在突然之间。这天我正在将一部蓝光片子，从负责下载的机子转移到负责保存的硬盘。时间比较久，我便开始进一步整理保存视频的硬盘。我是属于非常强调整理的人，各式的文件都保存得井井有条（这也许是强迫症的一种，却也能让我感到精神上的愉悦）。特别是视频文件，就算是详细归类之后，文件夹也必须一丝不苟地标注成规范格式。这个习惯大约是从以前大学时代，流连于各类FTP站点时便养成的。格式统一，标注清晰的文件夹，能在第一时间给予访问者各种所需信息。
当然，一开始定下的文件标注格式不可能十全十美，骆驼当年便是基本上按照0Day视频发布的格式来标注文件夹，尔后逐步变换成为符合自己意愿的格式。
就目前而言，一个视频文件夹的标注格式如下：
[中文名][英文名][类型][年代][格式][画面][音频][团队]
其实在过去这么长时间里，标注格式的变换主要是各个细节之前前后顺序的调整（我试图将自己更为关心的细节调整至靠前位置），本质上并没有太大变化。就在我按照新的标注格式整理硬盘中的文件夹时，我突然意识到，是不是可以利用 Tabbles 来优化这一点呢？
本文版权归属[Geek4.us]
写在开头的话：
这是我写完BooguNote全解之后不久就定下的一篇文章，结果变成了一个坑，直到现在。
这是一篇比较硬的文章，因为涉及到与编程语言有关的话题。在本文中，我将根据BooguNote作者公布的Boo文件格式，结合著名XML开发工具Altova XMLSpy的Schema生成功能，对其进行简单的说明，并且简单地演示如何使用这种格式。
我的编程水平比较低，给的例子非常简单，请各位多担待。
本文是 Tabbles 系列的第 1 部分。 本文版权归属[Geek4us]，转载请保留此行
前言
很久很久以前，微软提出WinFS的概念——通过数据库的支持，为用户提供基于属性和关系的文件管理体验。只是，Windows Vista的开发周期被拖得太长太长，使得微软不得不将WinFS从Vista的功能列表中删除，只保留了基于索引服务的“虚拟文件夹”（可是有多少人会不受那些优化教程的挑拨而保留索引服务呢）；直到Windows 7的发布，才让人们从它崭新的“库（Library）”功能里看到了WinFS的一丝影子。
有了虚拟文件夹，我们将搜索结果保存为视图留待将来使用，而“库”，则提供了在有限范围内利用标签（而不是目录树）来分类文件的功能，但是它们看起来离WinFS描述的愿景仍然遥远。不过现在我们有了新的选择：Tabbles，一个可以让我们与WinFS更加接近的软件。
P.S. 本文并不是一篇教程，而只是一篇介绍。
【来自 子仲 的投稿】
更新：子仲在GTDSTUDY上的原创文章：我为什么使用OneNote
微软最近推出的Onenote2010增加了许多吸引人，并具革命性的新功能，比如Wiki、比如靠边收集。正好最近我的知识管理系统遇到了一些问题，想更换一下新的知识管理工具，就马上下载安装了Onenote2010。
很久以前就有试用过Onenote2007，不过是很初浅的那种试用，现在重拾起来，想用好就得多花点功夫。一方面自己把菜单功能一个个试过去，另一方面找了一些网上的资料学习，以便使自己的知识管理更加流畅。如果你也想学习Onenote和知识管理的话，推荐以下三个地方：
我在豆瓣的PKM>D小组里面，看到了LeoZ发的帖子。他提出了一个问题， 要是OneNote可以使用大纲视图，那OneNote对他来说就是一个完美的软件。（以下为引用：由于我喜欢阅读和保存比较长的文档及网页，用Onenote没有大纲导航栏的话，对文章结构就很难做到一目了然的把握，还要上下拉动去看去总结，简单就是灾难。——Leoz）
