地点在恒春的后壁湖，岸潜4次，船潜12次。岸潜地点在核电站出水口左侧右侧和软珊瑚区域（潜点就叫这个名字，俗吧）。深度都不怎么深，但是越过一堆礁石比较困难。有鞋子保护好歹脚不痛，但是这双鞋子防滑性能一般，我差点在岸边溜冰。 船潜地点在外侧的几个礁石，深度都比较大。独立礁（瞧瞧这名字起的）悬崖部分深度超过30。我有几支用了EAN32，下不了32米的深度。至于其他人，他们基本都没有DD的证，本来就不能下去。 在垦丁附近潜水，最大的风险来自于低温和大流。我本来还和潜导说我就水母衣下吧，反正水温都在29-30左右。潜导说你碰到斜温层就知道厉害。垦丁这里有很多斜温层，底层温度会骤降5度左右，我记录的最低温度是22度，3mm的湿衣冻成狗。比我在PG外岛碰到的斜温层强大的多。最大的流在3节左右。负浮力下水后还没动作抓绳，先被大流压到了梯子上。比我在泰国碰到的流还猛。比较值得欣慰的是，基本都是横流，很少有垂直流或洗衣机。不过同时也有个坏消息。垦丁这边有很多的浮潜，水上摩托和香蕉船。这几个活动的危险性就先不去说了，水上船只频繁运动的情况下，是很容易撞到的——尤其是没有SMB的情况下。 垦丁的能见度不高，一般只有5-10左右。但有趣的是，在斜温层下方，能见度反而更好。往往有10米以上。肉眼可见的原因是因为斜温层的温度有利于浮游生物的生长。不过这也造成一个问题。在垦丁水下拍照，是一定要补光的。因为上方自然光都被表层海水吸收了，底层虽然能见度不错，但光线不足。 物种多样性来说，还不错，经常能看到蓝点鳐，厚唇石鲈。我还看到了龙虾，海蛇和海龟。有看到一只豆丁海马，不知道照没照清楚。出水口左侧的软珊瑚区里，有一堆海胆正在搬家。在核电出水口附近，照道理说，水温会比较高，可能引起珊瑚白化。但实际上珊瑚还不错，偶尔见到白化。 上次在垦丁浮潜，有严重的水下垃圾问题。这次无论是船潜还是岸潜都没有看到特别严重的垃圾问题。有见过几张纸，一次见到塑料袋。比起其他国家来说没有明显糟糕。后来我考虑了一下，水下垃圾估计是因为沉没在水下的部分无法在净滩中清理。浮潜和深潜业者当然有动力去清理他们看到的垃圾（毕竟关系到他们的饭碗），但是这并不能覆盖全部海滩。因此这次我的活动范围可能被清理过，而上次的活动范围则是问题比较大的部分。 在潜水间隔和船长聊过，他们其实是渔船，属于娱乐渔业。每次出海的时候，是要有海政属的人来点人头的。这也间接造成了船的大小很大，每次出海成本很高。我这次是一条船出海一次潜两支，1000NTD。上面往往就三五个人，很多时候教练都比客人多。其他国家经常是一条小船就出去，船上也是三五个人。这样的成本差异接近数倍。 最后说说交通和生活基础设施。恒春没有通铁路，只能通过垦丁快线（巴士）来返。从恒春到左营大约是两小时左右。但是去的时候最近一班车没票，回的时候正常车都没票，最后在等加班车。可见总体运力并不是很足。住宿方面，恒春老城里有很多民宿，可选择空间很大。我很喜欢乡村鸭肉冬粉家的卤味（不是他家冬粉），和对面的洋葱冰淇淋（是的，洋葱冰激凌，恒春产洋葱）。基本来说，你可以认为，这里除了可以讲中文外，基本和你去的其他潜点没什么区别（主力语言还不是普通话，而是闽南语，大部分人聊天的时候，我感觉和东南亚没啥区别）。

引子 在加密系列里突然出这么一个问题，确实有点怪。我犹豫了一下，还是先写了再说。 这个问题的提起，是公司老大kay提出一个问题。在反转链表的时候，如果有环怎么办。然后我们就现场写各种解环算法。这个问题本身不难，我们先看一下原始问题和解，还有带环反转。 Scheme反转链表 想了想，还是先写Scheme版本。这个版本实现简单概念清晰，个人觉得非常典型。而且对后面理解Python版本很有帮助。如果看不懂的话，可以直接去看Python版本。Python版本看不懂了再回本章来，去看Scheme入门教材。 Scheme的正解版本只有一个，就是带复制TCO版本。 (define (reverse-tco ll rslt) (if (eq? ll '()) rslt (reverse-tco (cdr ll) (cons (car ll) rslt)))) 这个版本体现了Scheme的几个特点。 递归比迭代好使。 强制要求TCO。 cons操作起来非常方便。 Python递归反转链表 def reverse_tco(ll, rslt): if not ll: return rslt return reverse_tco(ll[1], [ll[0], rslt]) 这是链表最简单的问题，也是递归论最基本的问题。注意这里采用list来模拟了lisp中的cons，不用tuple主要是后面还有环，需要修改数据。如果你不明白，可以先看Scheme版本的代码。 递归转迭代 写到这个水平，其实有一半的被面人就挂了(好水)。但是这个水平其实也就是入门水平。最低限度，也要知道上面这个递归是可转写为迭代的。更进一步的，要知道这个递归是个尾递归。下面我们把这个代码转写为迭代形态。 def reverse_iterate(ll): rslt = None while ll: rslt, ll = [ll[0], rslt], ll[1] return rslt 或者非生成节点版本。 def reverse_iterate(ll): rslt = None while ll: rslt, ll[1], ll = ll, rslt, ll[1] return rslt 这里的区别，其实是SICP第24页所说的“递归计算过程”和“递归过程”的区别。具体请直接参考原书，我就不打字摘抄了。

鸣谢和前言 首先感谢Ivan Ristić。本篇很多内容可以从他的这本书里读到。大家如果有钱，可以买来支持一下。没钱但是英文好的话，也可以直接读一下(这本书在网上是公开的)。本文没有直接复制，引用，或是完全写成读书笔记。所以原则上是不受书的版权限制的。不过如果作者有异议的话，我愿意下线这篇文章。 First of all, I wanna say thank you to Ivan Ristić. I got a lot of help from this book. You can buy one if you want, or read it personally (it’s public). This is really a good book. In this article (I mean the one you are reading currently), I don’t copy or reference directly from that book. So as far as I know, it shouldn’t have any copyright problem.

openssl的基本检查 使用以下命令检测版本，-a可以提供完整数据。 openssl version openssl version -a speed test speed测试是openssl为你跑一下不同算法在你机器上的实际执行速度，这项测试在openssl中是一项非常有指导意义的测试。一方面，他给出了你选择算法的依据，通过实际数据告诉你每个算法能跑多快。另一方面，他可以用来评估不同硬件对算法的加速能力。如果仅仅是给出了选择算法的能力，我们一般都可以得到一个一般性结论，例如chacha20比AES快。但实际上很多CPU带有AESNI指令集，这种情况下AES的执行速度反而会更高。所以运行性能是和执行平台紧密相关的。关于这部分，可以参考Intel对OpenSSL的性能优化。 具体的测试方法是 openssl speed 后面可以跟算法，只测试特定的算法集。 我这里跑了一遍全集，挑几个重点算法说一下性能吧。 hash算法 sha256，标杆性hash算法，64字节小数据140M/s，8k大数据353M/s。sha512，170/470。hash算法的内部状态越长，在连续计算时的速度越快。 sha1，251/768。 md5，243/575。(你没看错，md5比sha1还慢) rmd160比sha256还慢，whirlpool比sha256慢。最快的是ghash，小数据4222/9732。但是见鬼的是，我查不着这是TMD什么算法(openssl list -digest-algorithms的输出里没有)。 最合适的算法，应该就是sha-512/256了吧。很安全，速度比sha256快，长度也不算太长，还能防御LEA(Length extension attack)。 对称算法 aes-128-cbc，标杆算法，120/125(M/s)。aes-192，93/103。aes-256，86/88。aes的内部状态越长，在连续计算时的速度越慢。这点和hash正好相反。 camellia128，138/167。camellia192，110/128。camellia256，109/124。这是一种大批量数据计算非常优越的算法，AES在计算大批量时性能上升并不快。 des比aes慢的多，只有66M/s。3DES更慢，只有25M/s。 没有chacha20。 不考虑chacha20的情况下，最好的算法应该是camellia128。当然，工业标杆是aes-128-cbc。 非对称算法 rsa 1024/2048/3072/4096的sign效率分别是8698/1351/453/206(个/s)，verify效率分别是131847/46297/22970/13415。rsa也是随着内部状态上升效率下降的，而且下降非常快。而且verify效率远高于sign。 dsa 1024/2048的sign效率分别是9836/3280，verify的效率分别是10584/3616。 ecdsa 192/224/256/384的sign效率分别是12696/12672/21016/4383，verify效率分别是3200/5630/9994/1019。能很明显看出来，sign效率比verify高。256位的时候由于某种效应性能达峰，后续直接断崖下跌。 ecdh 192/224/256/384的效率为3642/8339/15094/1183。同样能看出这种效应。 rsa和ecc不具有互换性。rsa参数选择建议2048，ecc参数选择建议256。 对称加解密 openssl支持多种对称加密算法，可以直接对文件加解密。在使用前，我们首先列出系统上支持的算法。 openssl enc -ciphers 输出很复杂，不列举。我们直接讲我的机器上分析后的结果。 第一段是密码算法。在我这里，支持以下算法：aes, bf, blowfish, camellia, cast, chacha20, des, des3, desx, id(ea), rc2, rc4, seed。 最后一段有可能是模式。在我这里，支持以下模式：ECB，CBC，CFB，OFB，CNT。其中CFB，OFB和CTR(CNT)是可流式的，其余都是块式的。关于加密模式，可以看这篇。 在enc的manpages里明确说了，enc不支持CCM或是GCM这类的authenticated encryption。推荐是使用CMS。 例如我们使用比较流行的chacha20来加密一个文件src，里面可以随便写一句话。

Digest 摘要为一个函数H。对任意数据d，有h=H(s)。同时至少满足下面特性1。其余特性为额外要求。 对相同的数据d1=d2，计算得到h1=H(d1)和h2=H(d2)，必然有h1=h2。但不要求h1=h2的情况下，必然有d1=d2。 根据h计算任意一个可能的d极其困难。（安全性） d服从随机分布的情况下，h的分布足够随机。（均匀性） hash系列函数 hash系列中最著名的即MD5，其后继者为SHA1，SHA2，SHA3等。但实际上这几个都是密码学hash函数。非密码hash常用于快速计算均匀散列值（例如hashtable），代表有CRC （实际上CRC主要的目地是校验，而不是散列）, FNV，Murmur。这几个非密码hash函数的对比可以看这里。 hash函数需要注意长度。一般来说，长度越长越安全（越难被找到一个碰撞值）。但是过于长的值会在保存和使用上产生困难。 Rainbow table Rainbow table是一种通过预先计算来碰撞的手段。 从粗略的角度来说，你可以认为这就是一个巨大的反向hash表，保存了所有计算过的hash和对应的碰撞数据。但是通过计算可知，这样的反向表会占用巨大的存储空间。彩虹表采用巧妙的算法缩减了空间消耗。 其基础思想是，对某个碰撞数据，计算其hash，随后通过某个算法R，将这个目标hash再映射到另一个碰撞数据上去。通过这种方式，一个碰撞数据可以持续的计算出一串不同的hash。假设这个长度为n，我们最后保留最终一个hash和最初一个碰撞数据。 在检索某个hash的原始碰撞数据时，我们可以利用R将其映射为碰撞数据(但不是我们需要的那个碰撞数据)，进而计算hash串并检测是否在反向表里。如果表里存在这个hash的碰撞数据，那么在生成n步的hash串的过程中，必然能在反向表里发现命中。而当发现命中后，就可以通过原始碰撞数据算出整个碰撞链，从而找到该hash的对应碰撞数据。 从算法分析的角度来说，这是一个空间换时间和时间换空间同时存在的巧妙算法。利用反向表计算原始碰撞是用空间换时间，用hash串来压缩空间消耗是用时间换空间。 另一个细节是hash链的碰撞。当hash链在某个节点相同，后续链条必然完全相同。这大大降低了hash串的效率。因此彩虹表采取了一个变形。算法R在n步中每一步都各不相同(实际一般是将n当作参数)，这样使得hash碰撞只发生在一个点上。由于算法在每个步骤上各自不一，因而得名彩虹表。 KDF 密钥生成算法( KDF )是一类算法的统称，用于将一个密码/密钥变换成另一个(或多个)密码/密钥。在这个过程中，会提供很多额外特性。例如符合特定格式，防御暴力穷举攻击，保存后难于破解原始密码，等。 KDF的最知名场景，就是密码保存问题。用户的密码不应直接保存，这样在万一数据库泄漏时就会泄漏原始密码。而单纯hash会导致用户密码遭受彩虹表攻击。一般解决这个问题的方法是对密码加盐。但是盐是加在前面还是后面呢？以我个人的分析来看，似乎是没有区别的。即s+salt和salt+s都能保证安全。当然，更好的方法是用scrypt或bcrypt。他本身就有专门的函数保证密码安全保存，这可比加盐好使多了。 最佳实践 现在已经2018年了，我相信大部分读者都应该知道MD5和SHA1不安全的事了吧。这两者虽然还能完成摘要的用途，但是并没有安全保证了。如果你需要一个安全的hash算法，我推荐sha2。sha3目前并没有进入主流系统，而且执行速度还是略慢。 另外，如果有的选择的话，在sha2算法族里我推荐SHA-512/256或SHA-512/224。这两个算法有助于避免长度扩展攻击。 Encryption and Decryption 对称加密解密为一对函数，加密为E，解密为D。对任意数据d和密钥p，满足下面要求1和2。 加密为e=E(d, p)，解密为d=D(e, p)。 攻击者得知E，D，e的情况下，无法反推d和p。 在条件2的基础上，攻击者能得知d和对应e的情况下，无法反推p。（已知明文攻击） 在条件2的基础上，攻击者能构造d并得知对应e的情况下，无法反推p。（选择明文攻击） 对称加密有几种可能的变形情况，例如E和D为同样的函数，一次加密第二次解密。或者由生成算法构造出密钥p和解密密钥p’。在其中密钥p可以推算变换为解密密钥p’。但这其实仍然符合上面的描述。因为解密时可以使用d=D(e, p')，而p'=G(p)，因此d=D(e, G(p))，即可认为d=D'(e, p)。对于密钥p无法推算出解密密钥p’的情况，请参考下面的“非对称加密”。 DES/AES加密解密算法 加密算法中最有名的是DES和AES。关于这两个，我们不赘述。 密码模式 加解密算法一般都是以块模式运作的。即每个加密算法都有一个特定的长度，他只能处理这个长度的数据。块密码模式算法将基于某个特定的块算法，将其应用于流上。 最简单的用法是重复进行加密。取明文的前N字节加密，得到N字节密文。重复直到得到最后一块数据，数据的长度必然大于0小于N。对尾部的数据补足0。最后将所有密文联合起来，得到最终密文。这种模式叫做ECB模式。 ECB模式的好处是简单，但是ECB并不能防御内容替换攻击。攻击者可以通过某种方式获得一个数据的加密形式（选择明文）B’，然后将某个加密后的块B’替换原始块B。以此，虽然攻击者并不知道原始内容，但是可以替换其中的部分内容。 人们对ECB做了一点改进，使用上一个块的加密结果，对下一个块做干扰（具体使用XOR）。如此一来，对任意一个块的变更会导致后续块全部都无法解密。第一个块没有上一个块，也就没有加密结果。所以CBC需要一个初始向量IV来初始化干扰。而先加密上一个块的结果，再和当前数据XOR的算法，被称为CFB。CFB和CBC仅仅顺序上有区别，但是CFB可以用于流式加密，而CBC不行。因为CBC必须得到一个完整块，才能计算加密。而CFB预先算出mask，用XOR获得结果。 CFB再略变化一点，就可以构成OFB。OFB取的是XOR前的结果，因此加密序列并不受明文的影响，只受IV和key的影响。你可以想像，OFB是一个由IV和key已经决定好的，无限长的mask，逐步XOR到明文上。 但是CFB和OFB都有一些缺陷，例如明文和密文的异或对应性。在确定模式为CFB或OFB的前提下，对某些特定位置遍历所有可能空间，就能在不了解解密结果的前提下遍历所有明文可能性。这个问题被用于ss的主动探测上。 密码模式具体可以看这里。 Salsa20 Salsa20原来叫Chacha20，是一种经过特别设计的密码系统，在未经优化的CPU上拥有非常快的执行速度。 最佳实践 可能和大家想像的相反，一般没事不推荐直接使用加密函数本身，而是推荐使用AEAD算法。这里有一份2015年密码学最佳实践，按照推荐，是使用AES-GCM或Chacha20-Poly1305最好。这两种都是AEAD，具体下面有介绍。 如果一定要用加密算法，而非AEAD的话。推荐使用NaCl。它的加密算法默认选择是XSalsa20/20(Salsa20的一个变形)。 Message authentication code 消息验真，不同于摘要，要求的是拦截者无法伪造。其前提条件是发送者和验证者有一个共同的秘密p。本质上看，这个就是签署(sign)。但是一般我们讲sign都是指非对称的sign，MAC是对称式的。对称签署为两个函数，签署为S，校验为V。对任意数据d和密钥p。 对于签署获得的v=S(d, p)，可以用V(d, v, p)来检验d和v是否成对。 攻击者在得知S，V，v，d的情况下，无法反推p。 签署算法经常和摘要算法合用，即对数据d先使用摘要H得到摘要，再计算签署。即v=S(H(d), p)。验证时使用V(H(d), v, p)来验证。

大致情况介绍 Similan archipelago，在Thailand，Phuket西北方一点的位置。要从Phuket坐一个多小时车，到一个叫做Khao Lak的地方。然后再坐船出海，走大概两三小时。地图上看，在Thailand的外海，离海岸50公里以上。（这应当是公海了吧） 潜店和船 我们是让朋友报的船，到了才知道，潜店是这家Khaolak Scuba Adventures，船是三天三夜的一艘Manta Queen 5。船宽5米长26米，推荐容纳20人，实际容纳22人。推荐船员5人，实际7人。推荐潜导5人，实际7人（含manager）。 这艘船，怎么说呢，家吉一看就觉得很坑爹，我觉得还好吧，毕竟这个价格。船舱里面是上下铺的床，都是软垫铺一层床单，加一个枕头和被子。床很小，大约60-80公分宽，2米长。趟下去顶天立地，横向只够翻身，高度不够坐起。船舱里有空调，但是只有晚上打开。平时只有头上的一个风扇。幸好电倒是24小时提供，足以充手机和相机。然而这一路上都没有信号。 这也不难理解。Similan离最近的陆地超过50km，而普通手机信号只能传播20km左右。再加上按照地球弧度，50km造成的高度差会高达200m左右（6700*(1-math.cos(50⁄20000.0*math.pi))*1000，不知道我有没有算错），信号塔不在山上的话，无线信号会直接被海水阻挡住。所以整个船宿过程是没有信号的。 我们说回船。一层前半部是8个船舱，中间是三个浴室兼厕所，后部是潜水装备间。二层前半部是船长室和4个船舱，后部是公共空间，一般在这里做brief或者吃饭。三层是Sun deck，带一个顶棚。我们经常在潜水间隔跑去Sun deck那里晒太阳。冬天Similan的水还是有点冷（28左右吧），晒晒太阳有助于蒸发水分补充热能减少寒冷。 这里要说说厕所。船上的厕所都是直排的，你的排泄物会直接冲到海里。所以如果有什么可能导致问题的东西（例如，纸巾），必须丢到垃圾桶里。有一次某个客人的纸巾丟到马桶里了，结果一个厕所就无法使用了。我们还只有三个厕所，每个都是厕所/浴室/面盆的合体（地方也不是一般的小）。一旦碰到早上起床，潜水前后。厕所前排长队是意料之中。所以那次厕所出问题后，基本每次高峰时刻，厕所前面都会排上一个小时左右的队。 航程 我们是晚上9点左右上船的，经过一个简短的brief就开船了。Manager是一个俄罗斯妹子，声音比较沙哑。晚上经过两个多小时的晃悠，我们到了Similan群岛附近的一个地方停泊。 睡过一晚上后，早上6点起床做brief，下水check dive，吃早饭。休息一小时顺便换个地方，再下一支，起来吃午饭再休息一小时。下午下一支，起来休息两小时再吃个晚饭。晚饭后大家聊聊天，再下一次夜潜，第一天结束。 第一天我碰到了剧烈的头痛，推测是在第二或第三潜的时候上浮过快导致。一旦产生气泡，要消解起来就要好几小时的排氮。所以夜潜的时候都在头痛，直到夜宵结束后才逐步减轻。所以大家要小心上浮速度问题，非但不要超过18m/min，最好控制在9m/min以内，甚至短距离内也不要放松。 这次潜水我全程使用高氧，一支大概要150THB，合30CNY。全程总计300CNY，我觉得挺便宜。原则上说，这让我全程舒服很多。至于头痛，只能说大概我控制的还不够好。 潜点我就不一一列举了，反正你们也没得选。大致来说，1.1左右Similan水温28左右，不需要湿衣。天气晴，偶尔有小雨。海浪一般。大部分时候是没什么感觉的，只有一次例外。当然，开船的时候晃动还是比较猛烈的。 第二天就是晕船。早上起来，船长泊在一个面向波浪，靠近岛礁的地方休息，等待等会潜水。（海浪也是有传递方向的，一般船长会选择泊在岛背面，减少波浪）结果海浪加岸边的波浪反弹把我晃晕了。早上一支结束后，难受的生不如死，就吃了一颗晕船药，放弃一支潜水，躺在船舱里睡觉。他们上来后，船长就开始换地方，我继续睡觉。等突然就有船员很开心的敲门，Dolphin！我大概也好的差不多了，跑到Sun deck那就开始观望海豚。一群海豚追逐着我们和隔壁一艘潜水船，不断盘旋和跳出水面，大概跟了半个多小时。船长还特意偏出部分航线来追海豚。可惜跑的太快了，忘记把相机拿出来，结果没照片，只能等同船的人发给我（如果他们还记得的话）。 至于晕船，我了解到一点。不是我不会晕，只是海浪还不够大。后来我就聪明了。凡是这种有晕船可能性的情况，统统先吃再说。 第三天去北边的Koh Bon那。我们早上第一支下去的时候，有个团友就看到了Manta，但是他没有叮叮。潜到一半的时候，潜导把我们集体敲起来看Manta。我们集体连气泡都不敢吐，就看着一只巨大的Manta从我们头顶飞过。旁边还有几条大鱼（当然，和Manta本身大小比起来是大大不如）。上水之后，把同船的人羡慕坏了，我们Team直接变成了Manta Team。不过第二支的时候，我们在一个山脊侧面遇到1-2节的对向流。潜导看我们踢的很辛苦，就斜切避开了。后面几个Team就直接顶流，最后Drift。所以他们上水的位置比较靠外，我们是在Bay里面上水的。他们上水的时候又看到了Manta。 好吧，这样也是蛮公平的。 另外就是回程路上，我们最后一支是在回程一半的地方，Wreck Dive。尼马Wreck我见多了，但是这么多鱼的我还是头一次见到。能见度不高，只有10左右。但是整个行程基本都是在鱼类瀑布里面游动。就看到无数鱼围着你转圈圈。上来之后我们在那里吐槽，为啥海洋中间能见度那么差？那TM都是鱼类的粪便。 上陆地后事情就乏善可陈了。在Phuket住了一晚，早上坐L家的车到了Samui，晚上在Samui吃了点东西（下船的时候正好大雨，等我们住下，雨停了）。再一个早上坐另一艘船到了Koh tao。 Koh Tao Koh Tao算得上是我和家吉的老地盘了，这次还是到Crystal。他们的宿舍修好了，就在学校隔壁。很近不说，还有空调，1000THB一天。 这次去Crystal，是考Deep Dive。这次搞明白了一个问题。在AOW的时候，我们不是有五个专长么？其实在AOW的时候，我们并不是修完了5个专长，而是每个专长只上了一节课。所以AOW修完，我们是没有专长证的。但是在AOW时附修的EAN，是专门的两支，所以有专门的证。AOW的这五节课只给了我们两个好处： 部分的专长能力。例如深潜，AOW必修课，给我们30米深度许可。 在考对应专长的时候，能少上一次课。 所以，这次的深潜专长，经过三次大深度潜水（至少一次30米以上），和一次额外辅助减压（抱气瓶），许可我潜到40米深度。但是不得不吐槽一下，在仔细查过之后，我发现这个证并不是特别有用。因为： 很多保险并不支持40米深度。例如美亚，要求你在证件许可下，30米深度内活动。所以30米以下深度潜水是无保险的（而且可能会连累你之后的潜水全都没有保险）。 40米深度并不是谁都能去的。如果你的潜导，全组潜伴并不是都有这个证，你就下不去。 EAN下40米深度的配套很不友好。EAN32的最大深度是32-33米，要下40米深度，需要用EAN28。但是EAN的标准是32或36（左右），很多地方并没有28，例如Crystal。这导致这种大深度潜水反而必须使用空气，其实非常消耗No Dec。老潜水员知道，大部分高强度潜水的时候，No Dec才是瓶颈。 30-40米深度可见生物更少。这个深度生物体积更大，出现几率变少，基本都是博人品的重复潜水。 所以，如果考专长的话。你们可以考虑一下Deep Dive是不是值得考。以下是我觉得还不错的几个证，有机会可能会考： Wreck。绑线进去的那种，汗。要求15以上，AOW。 Sidemount。15岁以上，OW。 Dry Suit。10岁以上，OW。这个在潜冷水的时候是必需品。 Rebreather。18岁以上，OW，EAN，最低25潜。这个要求挺复杂，但是主证到不用AOW（实话说EAN+25logs其实是超过AOW的）。CCR在大深度还是比较管用的，而且下去不会有气泡惊到鱼群。 其中，Sidemount，Drysuit，Rebreather都是需要考虑是不是能在潜店租到装备的。也欢迎考过上述几个证的朋友给予意见，是不是值得。起码EAN是非常值得的一个证。 另外两个非专长的课，我有计划去上的。 Rescue。要先考出EFR来。但是我挺不喜欢中红会。 GUE Fundamentals。俗称馒头课。从我看到的数据来说，PG就可以上。 最后说一下这次考证的几个细节。

目标很简单。云存储上很多文件都挺私人的，直接放着很吓人。虽说云存储采用各种方法来保证你的安全，但是世界上没有绝对的安全。万一密码泄漏，或者更糟糕，云存储泄漏。此时你的各种文件就在网络上裸奔了。 最简单的解决方法是什么？在底层存储上套一层加密呗。不过由于是云存储，所以基于块设备的加密方案不能用，例如LUKS。否则你同步到云上的就是一个超级巨大的块文件，然后每次修改，云存储客户端都要找到差别上传。这太蛋疼了。正解是每个文件分别加密上传。但即便如此，对于超大文件进行加密后依然会影响上传效率，请提前考虑一下这个问题。 同时又要注意，云存储用的加密文件系统和普通的加密文件系统还有点差别。很多加密文件系统的daemon会认为自己是唯一一个会访问加密内容的进程，而云存储可能随时接收来自远程的修改。所以这会造成一些问题。 备选方案 我对比了四种方案，EncFS，CryFS，GoCryptFS，eCryptFS。对比的方法是用这四种分别建立一个加密目录，然后用不同的方法做写入测试，看他的各种参数。顺便说一句，如果你要看的话，其实看这份表格就好。我只是在自己的机器上复现了一下，顺便了解一下各家特点。 测试语句： time dd if=/dev/zero of=test bs=1048576 count=1024 time dd if=/dev/zero of=test bs=1024 count=1048576 time tar xf linux-4.13.12.tar.xz 其中，在裸盘上直接解压内核源码耗时7.568s，空间使用870M。 数据对比 +---------+-------+-----+-------+-----+-------+-----+--------------+ | |time1 |size1|time2 |size2|time3 |size3|comment | +---------+-------+-----+-------+-----+-------+-----+--------------+ |EncFS |13.210s|1.1G |39.039s|1.1G |26.496s|894M | | +---------+-------+-----+-------+-----+-------+-----+--------------+ |CryFS |9.327s |1.1G |21.230s|1.1G |42.918s|2.5G |删除耗时2.804s| +---------+-------+-----+-------+-----+-------+-----+--------------+ |GoCryptFS|3.515s |1.1G |28.180s|1.1G |19.874s|918M | | +---------+-------+-----+-------+-----+-------+-----+--------------+ |eCryptFS |3.132s |1.1G |10.218s|1.1G |9.448s |1.4G | | +---------+-------+-----+-------+-----+-------+-----+--------------+ 解读 首先说怎么解读。time1是连续写入性能，time2是离散写入性能，time3是小文件写入性能，size3是大量小文件膨胀系统。size1和size2没啥用。 下面先看性能。从性能上看，最优秀的是eCryptFS。这是理所当然，因为这是唯一一个内核态而且和内核整合的系统。GoCryptFS次之。EncFS要慢上好多。至于CryFS，一开始写小文件就原型毕露了。何况这是唯一一个删除大文件时间超过1s的，达到2.8s。你看我其他系统测试里都没写。 然后是膨胀率。EncFS膨胀2.75%，CryFS膨胀近三倍，GoCryptFS膨胀5.52%，eCryptFS膨胀65%。相比起来，EncFS膨胀率最小，GoCryptFS次之，CryFS最糟糕。 安全性 下面是同一个人出的三份审计报告：

细节不说太多了，京都毕竟是一个挺现代化的城市了，又不是什么荒郊野外。我只说几个特别的建议吧。 京都公交一日卡非常便宜，只要500JPY。如果单独坐车，一次230JPY，所以三次回本。但是公交日卡和铁路日卡是分开的，一起买1200JPY。公交日卡地铁站就有卖，铁路日卡铁路那里没得卖，你最好趁早在京都站搞定。公交日卡不需要写日期，头次用会塞到机器里打印一个日期，第二次起直接给司机看就行。啊，对了，这些卡都有使用范围限制，具体查一下。 大部分公交都是后门上前门下，下车付费，不设找零(但是1000JPY以下有自动兑换机)。部分车上车的地方有个刷卡机，那就可以分段计费了。但除非是照顾对象，请不要坐优先席。 强烈推荐Hot Pepper这个应用。可以指定一个区域，搜索平均费用在什么区间的一个什么类型的饭店。我用这个找到了几个不错的店。不是说特别好吃，京都的店都不差，就算街上随便碰也都不错。而是说没有这个应用我找不到店，或者店不合适。例如仁和寺门口，有个挺便宜的小店，叫篝・喫茶，旁边还有个咖喱店。但是这要走两步。如果你没看到，直接进了门口的佐近，那就走的远了。我相信东西会好吃很多，可是价钱也会贵一些。 机场的商品种类不多，而且价格不一定便宜。有的便宜了，有的反而贵。最简单的办法是在市内的免税店把东西都买好，过机场的时候把免税单一交就行。 不要担心语言问题。只要有钱，你不说话都行。不过想省钱，还是把日语学学好。

大致情况介绍 Boracay，菲律宾长滩岛。关于菲律宾的基础信息不介绍了，这篇里面都有。我们就说一点当地的东西吧。 我们主要在西边活动，东边没怎么去，据说不太平。Boracay西边有个贼长无比的海滩，一条繁华的海滩商业街就沿着那里展开。初此外还有一条主路。基本你就沿着这两条路走，一定能找到你要去的地方。海滩商业街上有很多店，基本都是餐饮，按摩，小商品，潜水，辫子，纹身。我们所说的大部分店，都在海滩边上。如果不在，我会特别指出。 潜店 Boracay的潜店一大堆，我随便走走都能看到10多家。但是在padi上注册过的并不多。我这里看到的idc有Calypso Diving School International和Sea World Dive Center。从padi上看，watercolors也是idc。但是他的注册位置和实际位置不大一样。其他的都不是idc，或者没有在padi上注册过。 Sea World我路过去看过。当时打着中文广告，我还以为是中国人开的，结果是韩国人开的。广告很NB，岛上唯一一家五星IDC。岛上究竟几家上面我都列出来了。不过不说别的，他们的位置和店面都很不错。而且店员会中文，这点对很多人很有用。 Boracay的价格基本都稳定下来了，FD标价都在1800PHP左右，偶尔能见到1900，比较贵。我选的一家是朋友推荐的，老板是韩国人（很帅的欧巴哦）。标价都是1800，去了才发现地方略偏，但是有好处的。除了两潜外，潜导都是1对1服务。不过最后一天我才发现，两个潜导一个SSI一个CMAS。幸好我有一支和老板一起下水了，所以让老板给我签个PADI的，好规避review问题。 最后说一点，DSD。岛上的DSD才是最大的潜种，而不像有些地方，基本都是FD。这很好理解，Boracay是一个休闲旅游岛，而不是一个专门潜水的岛。在我选的这家店里，有次我看到十多个人在那里做DSD培训(店里有人会中文)，出去的时候还要加十个左右的instructor(有负责照相的)。30个人浩浩荡荡两条船跑出去。 做DSD的(虽然我估计DSD不大可能来我的blog，会来的不是程序员就是老潜水员)请千万注意几个问题。DSD最主要的安全问题是什么？潜导不足潜导违规。只要配够instructor按规定操作，DSD几乎没有风险。说几乎是因为，就算平地走路都可能被雷劈死，跳到海里去潜水不会更加安全的。因此体验潜水一个强制要求是，instructor和潜水员比例不得超过1:2。 这两天闲聊的时候，我听到的范围里，所有潜店都坚持了这个比例配置。但是如果坚持这个比例，你就可以算出来，做DSD好像还没有FD赚啊(1:1的这种FD不谈)。所以很多DSD有一定的玩花样的成分。例如水下配个AOW下去给你照相，回头卖你相片。还有气不给打足，20多分钟就可以上来了。当然，万幸的是，好歹大家节操还比较足，不会出现耳压培训不做就踢下水，然后等你受不了升水的情况(三亚名产)。 潜点 Boracay通常流都不大，因为大部分情况下洋流都是东西向的，而岛是南北向的。因此在西面大部分时候都没有流，或者小流。在岛的最南和最北有大洋流，所以去的人很少。西面大部分时候都是南向北或者北向南的一节流。人类活动较多，水下能见度一般。 照片在这里。 Camia Wreck 11° 57.115’ N, 121° 54.523’ E Max: 28.4, Avg: 19.5, Vis: 10+, Current: 1 海滩正对面的一个沉船，没啥好多说的。有几条非常大的鱼，品种搞不清楚。中间船舱有个地方能沉下去，然后穿过大约3-5米的封闭船舱(警告：这是潜水违规操作)，右转上升出舱。中间距离非常大，对脚法没有要求。这个点有种非常大的鱼，谁知道是什么？ Angol Point 11° 56.828’ N, 121° 55.2’ E Max: 14.3, Avg: 7.9, Vis: 10+, Current: 0 海滩对面的浅点，非常容易。基本就在里面玩了一阵而已，没啥难度。照到了三个海兔排排坐。另外，下去之前我的reg的O-ring爆裂了。 Friday Rock 11° 58.083’ N, 121° 54.263’ E Max: 17.4, Avg: 12.8, Vis: 10+, Current: 0

我本来以为是个挺简单的问题，结果实践一下发现还是挺多人不明白的。所以我写一下。 安装 挺简单的。你在golang.org下载一个合适的安装包，回来之后找个地方解开——例如~/usr/share/go这个目录。 而后你需要调整两个变量，GOROOT和PATH。PATH是必须调整的，GOROOT原则上可以不管。当你使用了正确的go程序后，GOROOT会自动设定。但是我习惯先设定GOROOT，然后计算出PATH。像下面这样(注意环境变量里要用绝对路径，不要用~)。 export GOROOT=/home/user/usr/share/go export PATH=$GOROOT/bin:$PATH 一般我会将这个设定设在bashrc里，变成我私有的设定。这样不会对系统产生干扰。在经过这个设定后，你需要让所有bash载入这个设定。最快的是重启，不喜欢动静太大的可以source ~/.bashrc。载入完成后，你可以试试go version，看看是否生效，版本是否正确。 配置环境 golang的编译环境配置只需要配置一个变量，GOPATH。例如我将GOPATH设定到~/usr/，在bashrc中加入export GOPATH=/home/user/usr，那么源码路径就是~/usr/src。将来下载的所有包，都会根据这个位置自动计算路径。例如http2的包，名字叫做golang.org/x/net/http2，下载时的路径就会是~/usr/src/golang.org/x/net/http2。你可以用go get golang.org/x/net/http2来自动下载这个包。 如果你自己开了一个项目，那么你需要搞一个url，例如github。然后把你的项目放到对应路径——例如~/usr/src/github.com/username/project。然后在这个路径下做所有操作。最后你可以使用go build package编译它，非常容易。 install golang除了源码之外，还有很多的编译结果。例如go项目自己的源码在~/usr/share/go/src/下面，可执行文件在~/usr/share/go/bin/下面。而你和你下载的各种项目的编译结果就在~/usr/bin/下面——是不是觉得和linux的文件管理方式非常像？ 所以上面的bashrc配置还需要做一点调整，以便让你除了能用go做编译外，还能直接使用go编译出来的项目。 export GOROOT=/home/user/usr/share/go/ export GOPATH=/home/user/usr/ export PATH=$GOROOT/bin:$GOPATH/bin:$PATH