大蕉 – 大蕉，一种有益的水果。不过本blog并不是介绍大蕉。哈哈

golang modules问题的理解与踩坑记

golang 在1.11版本开始增加modules的功能，解决包管理的问题，之前包管理方案废除了。这个方案感觉都几好，不过最近使用的时候。发觉都点问题，可能是我对它的理解不是很清晰。导致的出问题。

现在讲讲我遇到的问题。如果大家想跟着我的项目试验，请去

github下载并切换到这个commit。这里我列一下我项目的go.mod的主要部分

require (
github.com/deepch/av v0.0.0-20160612005306-c437a98c9300 // indirect
github.com/deepch/rtsp v0.0.0-20180827192050-70ae0abf31bd // indirect
github.com/deepch/sample_rtsp v0.0.0-20180827191708-90250a0f88be // indirect
github.com/gorilla/mux v1.7.1 // indirect
github.com/pion/webrtc/v2 v2.0.9 // indirect
)

目前项目有点问题，我需要升级下github.com/pion/webrtc/这个库的版本。升级这个库的版本有几个方面。

使用命令go get github.com/pion/webrtc/v2@v2.0.12
使用命令go get -u github.com/pion/webrtc/v2@v2.0.12
直接编辑go.mod文件，把版本号修改。

大家是否会觉得用以上三个方法结果都一样。我开始以为这个三个方法都一样的。不过后发觉他们直接还是有点不一样的。

方法1，go get github.com/pion/webrtc/v2@v2.0.12命令之后。go.mod文件只是修改了github.com/pion/webrtc/v2的版本号。go.sum增加了2.0.12依赖的包对应的新的版本库。

require (
	github.com/deepch/av v0.0.0-20160612005306-c437a98c9300 // indirect
	github.com/deepch/rtsp v0.0.0-20180827192050-70ae0abf31bd // indirect
	github.com/deepch/sample_rtsp v0.0.0-20180827191708-90250a0f88be // indirect
	github.com/gorilla/mux v1.7.1 // indirect
	github.com/pion/webrtc/v2 v2.0.12 // indirect
)

方法2. go get -u github.com/pion/webrtc/v2@v2.0.12命令后，go.mod文件多了很多依赖包。go.sum也出现了很多更新包。这些依赖包都是次级依赖的包的升级版本，可能是github.com/pion/webrtc库需要。都列在go.mod哪里了。

require (
	github.com/deepch/av v0.0.0-20160612005306-c437a98c9300 // indirect
	github.com/deepch/rtsp v0.0.0-20180827192050-70ae0abf31bd // indirect
	github.com/deepch/sample_rtsp v0.0.0-20180827191708-90250a0f88be // indirect
	github.com/golang/mock v1.3.0 // indirect
	github.com/gorilla/mux v1.7.1 // indirect
	github.com/lucas-clemente/quic-go v0.11.1 // indirect
	github.com/onsi/ginkgo v1.8.0 // indirect
	github.com/onsi/gomega v1.5.0 // indirect
	github.com/pion/datachannel v1.4.3 // indirect
	github.com/pion/dtls v1.3.4 // indirect
	github.com/pion/webrtc/v2 v2.0.12 // indirect
	github.com/stretchr/objx v0.2.0 // indirect
	golang.org/x/crypto v0.0.0-20190506204251-e1dfcc566284 // indirect
	golang.org/x/net v0.0.0-20190503192946-f4e77d36d62c // indirect
	golang.org/x/sys v0.0.0-20190508220229-2d0786266e9c // indirect
	golang.org/x/text v0.3.2 // indirect
	golang.org/x/tools v0.0.0-20190509014725-d996b19ee77c // indirect
	gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127 // indirect
	gopkg.in/yaml.v2 v2.2.2 // indirect
)

方法3。直接编辑go.mod，然后编译程序和或者运行，得到的结果是和方法1一样的。

现在来一条思考题：，如果命令是go get -u github.com/pion/webrtc/v2@v2.0.9版本号不变化。你会觉得go.mod会有变化么？

结果来了。

require (
	github.com/deepch/av v0.0.0-20160612005306-c437a98c9300 // indirect
	github.com/deepch/rtsp v0.0.0-20180827192050-70ae0abf31bd // indirect
	github.com/deepch/sample_rtsp v0.0.0-20180827191708-90250a0f88be // indirect
	github.com/golang/mock v1.3.0 // indirect
	github.com/gorilla/mux v1.7.1 // indirect
	github.com/lucas-clemente/quic-go v0.11.1 // indirect
	github.com/onsi/ginkgo v1.8.0 // indirect
	github.com/onsi/gomega v1.5.0 // indirect
	github.com/pion/datachannel v1.4.3 // indirect
	github.com/pion/dtls v1.3.4 // indirect
	github.com/pion/ice v0.2.6 // indirect
	github.com/pion/srtp v1.2.4 // indirect
	github.com/pion/webrtc/v2 v2.0.9 // indirect
	github.com/stretchr/objx v0.2.0 // indirect
	golang.org/x/crypto v0.0.0-20190506204251-e1dfcc566284 // indirect
	golang.org/x/net v0.0.0-20190503192946-f4e77d36d62c // indirect
	golang.org/x/sys v0.0.0-20190508220229-2d0786266e9c // indirect
	golang.org/x/text v0.3.2 // indirect
	golang.org/x/tools v0.0.0-20190509014725-d996b19ee77c // indirect
	gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127 // indirect
	gopkg.in/yaml.v2 v2.2.2 // indirect
)

二级依赖包都更新了。所以平时更新项目的依赖包要小心，最好别用go get -u来更新，只要用go get来更新具体某个依赖包就好了，带-u的会把次级的依赖都升价到新版本，不理会你直接引用的库是否有升级。这个问题不是很好的。因为有时候回归问题根源的时候，会把依赖包进行升级和降级处理进行查找一些问题。加了-u的选项，它把次级依赖包都升价了。不能很好地回归问题。
假设，你使用go get -u github.com/pion/webrtc/v2@v2.0.12升价了包，然后用go get github.com/pion/webrtc/v2@v2.0.9进行降级。其他依赖包也是被升价了。

所以大家以后升价依赖包，要不手动改文件。要不只用go get。千万别用go get -u了。要不然降级的时候就麻烦了。另外这个go的依赖包的升级是根据语义化版本来决定升级的。如果你原来是1.X.X的版本，不会知道升级到2.X.X的版本的。而且go现在的包的import语句引入2.X.X版本的时候需要跟一个v2的尾巴。这个超级不习惯。跟其他语言很大不同。

我目前使用的go的版本号：go version go1.12.4 darwin/amd64

菲律宾宿务墨宝潜水日志

这次墨宝的潜水期待已久，计划已久。这次终于来到了。墨宝这个地方比起pg细太多了。这里的沙丁鱼最出名了。

潜店就不介绍。之前的文章已经说过了。潜店是快艇的船，那条楼梯是那些不锈钢管。好在有钢管外包有防滑的胶垫。不喜欢这种楼梯。

配重：这次进购了自己的装备，就差wetsuit不是自己的。而且是第一次使用。买了件背飞XDeep Ghost，使用起来感觉不错。就是有一个问题，后翻落海。要水底要打个跟斗，开始不是很习惯。刚开始的时候配重4Kg。后来发觉水底经常要打气入BCD。后来几潜都要不停地减小配重，最后减到1kg，第一次使用1kg的时候还是感觉有点重，在较深的时候打了两下气入BCD。本来想试试不带配重的。不过后来感觉不带配重可能在3分钟停留的时候比较吃力。所以后来都是1kg下的。不过后来几潜，无论在深的时候还是在停留的时候，都没有大气或者放气。另外这次潜水并没有带spare air下水，因为店家不給充气。

wetsuit是2.5mm的，不知道是否比3mm薄了，所以配重减了这么多。还是因为背负的本身基本上没有正浮力的东西。水温，这次水温大多数是28度，偶尔看到是29度。不过28度給我感觉还是冷。后来发觉件wetsuit的拉链经常没有拉好，又可能拉好了，自己給滑下来了。这件wetsuit是前拉链的。感觉穿的时候也不方便穿。看来wetsuit还是要自购了。还有感觉墨宝的海水不是很咸。不知道是否这样又减少了我的配重尼。

中性：中性之前感觉自己还是可以的。但是这次感觉不是很好。感觉有时候会上上落落的。有可能开始的时候配重比较重导致的。想上升的时候单单用肺部控制感觉太缓慢了，不过后来感觉用踢腿控制一下上升还是不错的选择。还有一个问题这次潜水经常犯错的。就是深度控制，深度经常在潜导的下方1-2米左右。需要经常调整。

继续阅读“菲律宾宿务墨宝潜水日志”

菲律宾宿务墨宝潜店介绍

以往去潜水都不会事先找定潜店的，都是去到现场看，感觉那家好就找那家。这次例外，因为希望潜店帮忙安排车和住宿等。所以分别联系了潜水主义和Savedra。最后选择了Savedra，有一个比较大的原因是buddy看中了Savedra推荐的酒店，有无敌海景。加上这个这个酒店就在潜店旁边，非常方便。我个人也非常喜欢潜店就在酒店旁边。虽然这里不是很大，可能也就5分钟－10分钟的距离，有时候别看小这几分钟的距离。因为这了每一潜都上岸休息。这几分钟来来回来都比较麻烦的。

回来发觉我没有照潜店的外观和内在。只有一张在酒店观望潜店的照片。

潜店的规模都算大，不过你问我是否推荐这家潜店。我是不推荐的。原因有两个：

1 我带了一个spare air去，希望潜店帮忙充气，结果被店家的老板决绝了。原因我听不明白，只听明最后一句是，你不会用得上的。这个备用气源就是以防万一的。用不上当然最好。我之前在其他地方未试过被拒绝。

2 这了的潜水时间是早上7:30第一潜。这个时间真的要比翻工还要早起床。实在不明白为什么这么早。虽然它家网站说7:30 去看沙丁鱼会人比较少。但是不是每天第一潜都是去沙丁鱼的。虽然出发前就知道这家是这么早的，开始以为可以适应下，或者中午休息补补眠。不过中午休息时间补够补眠啊。

另外这个7：30是出发时间不是集合时间。起码提前15-20集合。加上这么早，吃早餐的地方都未开门，潜店附近就得一家开门。搞到那家的早餐吃了两天。第三天走远点，终于找到另外一家这么早开门的。

继续阅读“菲律宾宿务墨宝潜店介绍”

菲律宾宿务墨宝潜水住宿与美吃攻略

想去墨宝这个地方潜水很久了，这里有比较著名的沙丁鱼。在网络上看到很多沙丁鱼的图片都很震撼。上年10.1假期就想去这个地方，最后还是选择了pg是因为去墨宝的交通不是那么方便，而且网上找这里的潜水攻略也不是很多，说明也不是很详细。有很多不明白的地方。所以没有去，之后一路都有留意墨宝的资讯，总算搞明白了一些东西。这次是在8月18日星期六去到墨宝。

去一个地方旅游最重要的是机票和住宿。机票这个没有什么好说的，不同地区出发都有不同的方案，这个我也不想多说。这里说一说住宿吧。因为第一次想去的时候没有去成，有8成是住宿没有搞定。

首先这个半岛还是挺大的。在订房网站，或者google搜索，发觉整个岛周围都有酒店。究竟住那里是一个问题。那里才是我们这些背包客的集中地尼。大家请看下图，红色标记的岸边应该是背包客的集中地。其他地方估计是比较漂亮的酒店。因为这次我就在这个区域行走，其他地方没有去。不确定那些地方是否也一样旺，潜水坐船的时候看见也有不少的住宿，在白沙滩那里很多人在玩。住宿最后是找这个红色划线区域，不过这里的住宿大多都是比较廉价的住宿，青年旅馆的床位酒店也多。经常看到一些相对好些的酒店都是被订满了。我是提前一个月进行预定的。

继续阅读“菲律宾宿务墨宝潜水住宿与美吃攻略”

TensorFlow with CUDA安装在Ubuntu的踩坑记录

最近研究TensorFlow，需要开发环境，需要安装一个。我选择了在Ubuntu上使用docker来进行TensorFlow开发环境。因为使用docker是目前最方便搭建开发环境的工具。

安装步骤官方文档说明得比较详细。其实用docker安装环境没有什么可以说的，能会有问题么？如果你使用cpu版本基本不会有问题的。但是如果你使用的是GPU版本。那你还要安装CUDA环境和需要这些支持。我选择了使用CUDA9.1，安装教程在这。在CUDA9.1的下载安装我选择了从网络deb的方式。

不过安装后，运行测试程序(nvidia-smi)或在运行nvidia-docker失败。

 
Failed to initialize NVML: GPU access blocked by the operating system

nvidia-docker failed to initialize nvml: driver/library version mismatch

后来发觉这是驱动的安装问题。我使用的是这里的下载的驱动文件，你可以在www.nvidia.com/drivers按照你显卡型号选择驱动，我发觉最后下载的文件都一样的。下载的文件名称NVIDIA-Linux-x86_64-390.48.run。使用

sudo sh NVIDIA-Linux-x86_64-390.48.run

进行安装，途中会有些报错，不理会继续继续。但是安装出来后，cuda不能正常运行。查询google。最后发现原来官方说这个驱动在ubuntu上需要手动安装。不要直接运行run文件。

#这里先卸载之前安装的驱动。
sudo apt-get remove --purge nvidia-390 nvidia-modprobe nvidia-settings
#重新安装驱动，虽然安装过程中有报错，不过后来测试运行暂时没有发现问题。
sudo apt-get install nvidia-390 nvidia-modprobe nvidia-settings

经过这一卸载，再安装就成功了。幸福来得有点突然。哈哈哈。

还有一个地方需要注意的是，nvidia-docker的安装需要指定的docker版本，而且这个版本必须是精确的版本。不能高于或在一个小升级的版本。而且这个版本不是稳定版本来的。我这次需要的是Docker version 18.03.1-ce, build 9ee9f40版本。不过你的版本不对他是不会继续给你安装的。

下边给几个用于检查安装好的环境

cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  390.30  Wed Jan 31 22:08:49 PST 2018
GCC version:  gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)

ls -l /dev/nvidia*
crw-rw-rw- 1 root root 195, 254 May  3 10:00 /dev/nvidia-modeset
crw-rw-rw- 1 root root 243,   0 May  3 09:03 /dev/nvidia-uvm
crw-rw-rw- 1 root root 243,   1 May  3 10:00 /dev/nvidia-uvm-tools
crw-rw-rw- 1 root root 195,   0 May  3 10:00 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 May  3 09:03 /dev/nvidiactl
(我安装驱动失败的时候这里只有两个设备，/dev/nvidia-uvm和/dev/nvidiactl)

lspci | grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 730] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1)

cat /proc/driver/nvidia/gpus/0000:01:00.0/information
Model: 		 GeForce GT 730
IRQ:   		 34
GPU UUID: 	 GPU-????????-????-????-????-????????????
Video BIOS: 	 ??.??.??.??.??
Bus Type: 	 PCIe
DMA Size: 	 40 bits
DMA Mask: 	 0xffffffffff
Bus Location: 	 0000:01:00.0
Device Minor: 	 0

大家别笑我的GPU太差。真实使用的时候需要租用云服务器的GPU。

2017年国庆Puerto Galera潜水日记

这次是我第二次来到puerto galera了。上一次来的时候是2013年农历新年的时候，那时候的pg不是很多国人，虽然在中文潜店会很多国人。但是这次再来，发觉国人已经占据了这里，我在鬼佬潜店，也是大部分是国人。在餐厅，客人基本上都是说中文的。給我感觉是这里不能再来了。不过后来潜完水，觉得这里还是可以再来的。

这次的潜店也是我上次帮衬过的。blue:ribbon Dive resort 现在有中文名了，叫“蓝丝带”。不过现在的pg几乎所有潜店都会贴出中文店名的。Asia dive还有巨型中文海报。这家潜店給我的感觉没有上次好，虽然还是很不错的。设备比以前旧了。一些细节没有以前好了。例如上水后冲身的水，水压细了。还有冲洗池没有分冲洗bcd，wetsuit，相机。感觉不是很好。虽然影响不大。

这次选择了潜店，原因是上次在这里潜水体验还是不错的。特别是那条大木船。不过现在发觉很多潜店都改用大木船了。这次价格比上次贵了。1200php/潜，6潜以上是1100php/潜。不够不包装备，装备全套300php/潜。由于我有fins和mask，装备减50php/潜。

这次潜水感觉都比之前熟练了，在用气方面应该比之前好了很多，省气了。基本上水都在90bar左右，其他有些同行者都没有气了，要上水了，我有时候还有成100bar的气，

对付流方面可能有改进，又可能这次基本上没有遇到大流吧。因为没有对比很难说明问题。不过踢水感觉比以前有效率了。不过用力过猛的时候感觉有小小抽筋feel。而且在上船前，脱fin的时候试过脚子公抽筋。这个估计是我个人老问题了。筋骨硬。脱fin的时候特别小心。

继续阅读“2017年国庆Puerto Galera潜水日记”

coturn的用于webrtc的测试

coturn是一个开源的turn/stun的服务器，大家可以使用它进行webrtc的测试搭建。当然也可以用于生产环境。此文只是介绍其用于测试环境如何配置其用户于验证。这里可以配合apprtc-go的测试进行说明。

coturn服务器是包括了turn和stun这两个服务的。如果你只需要stun服务。按照下边的命令启动就可以。（假设turn服务器和apprtc-go服务器都运行在192.168.2.170上,另外，如果需要测试turn服务，需要把连接的两台机器分别放在不同的网段，相互之间不能访问，才能发挥turn的功效）

turnserver --no-auth --stun-only -v
参数说明：
--no-auth  不做用户认证，只有stun可以不用用户认证，
                turn服务，在iceServer中必须给出用户名认证等，
                要不然页面建立peerConnect的时候报错。
--stun-only  服务器制作stun服务，不做turn服务。
-v       打印log信息。请不要用-V,大V的信息量太多了。

apprtc-go的启动需要添加stun参数給，命令如下

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
                      -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key  \
                      -httpport=8080 -httpsport=8888 \
                      -stun=192.168.2.170:3478

iceServer返回json，只有stun服务器列表。

{"iceServers":[
{
   "urls": [
           "stun:192.168.2.170:3478"
           ]
}
]}

这样在浏览器就可以键入https://192.168.2.170:8080,就可以进行测试。建议使用两台机器，并连接到不同的的子路由器下进行测试。

测试turn服务，固定用户名，密码

turnserver -v  --user=daozhao:12345 --realm apprtc  --no-stun
参数说明：
--no-stun 不启动stun服务，所有stun的包都被忽略。
--user  用户名和密码 组合形式username:password
--realm  域标志，其实这个在这里随便写就可以。
             但是不能不写，要不然认证失败401

apprtc-go启动的时候添加turn服务器参数，使用静态用户名密码。

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
            -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key \
            -httpport=8080 -httpsport=8888 \
            -turn=192.168.2.170:3478 -turn-username=daozhao -turn-password=12345

iceServers返回，注意，如果使用turn服务列表，必须有username和credential。这里的用户名密码是静态的。

{"iceServers":[
{
    "urls": [
      "turn:192.168.2.170:3478?transport=udp"
    ],
    "username": "daozhao",
    "credential": "12345"
  }
]}

测试turn服务，动态验证用户名，密码：

turnserver -v  --user=daozhao  --realm apprtc --static-auth-secret=654321  --no-stun
参数说明：
--static-auth-secret  认证加密需要的key
--user   有static-auth-secret设置时候，这里只需要写用户名。
             不要写密码，要不然认证失败401

apprtc-go启动命令行。

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
            -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key \
            -httpport=8080 -httpsport=8888 \
            -turn=192.168.2.170:3478 -turn-username=daozhao -turn-static-auth-secret=654321

iceServers返回，注意这里是一个动态的用户名密码。这个用户名密码的计算方法：
用户名由两段组成 timestamp:username
credential的计算方式 base64(sha1_HMAC(timestamp:username,secret-key))
详细的参考这里，

{"iceServers":[
{
    "urls": [
      "turn:192.168.2.170:3478?transport=udp"
    ],
    "username": "1504596938:daozhao",
    "credential": "k/yZNM4Jfofkqqa7ygBP5yCstow="
  }
]}

下边是一个完全事例。

turnserver -v  --user=daozhao  --realm apprtc --static-auth-secret=654321

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
            -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key \
            -stun=192.168.2.170:3478 \
            -turn=192.168.2.170:3478 -turn-username=daozhao -turn-static-auth-secret=654321 \
            -httpport=8080 -httpsport=8888

iceServer返回：

{"iceServers":[
{
    "urls": [
      "stun:192.168.2.170:3478"
    ]
  }
,
{
    "urls": [
      "turn:192.168.2.170:3478?transport=udp"
    ],
	"username": "1504598153:daozhao",
	"credential": "+pUWOR9wKKgBRXQoLJ7tl2PlFSA="
  }
]}

参考链接：

http://www.cnblogs.com/lingdhox/p/4209659.html

http://www.cnblogs.com/kakawater/p/7112925.html

https://stackoverflow.com/questions/30745153/turn-server-for-webrtc-with-rest-api-authentication?noredirect=1&lq=1

在chrome上调试webrtc踩坑记

最近又再次用chrome测试webrtc的demo(https://appr.tc/)。为了有更多的控制性，和测试两个客户端不同的网络环境的情况是否可以通讯。此网站是google提供的测试网站并且提供了网站的全部源代码（https://github.com/webrtc/apprtc）。可以自行部署在自己的机器上。部署webrtc的服务器，如果想访问摄像头的功能必须部署https。或者你只能通过localhost来访问。apprtc提供的代码是需要部署 Google App Engine SDK for Python的。或者使用使用这个docker(piasy/webrtc-build)，使用说明。不过存在一个问题，就是它们都不支持https的访问，如果用chrome来调试，就只能本机访问。或者你在做一个https和wss的转发代理。

上述的方法我并没有采用，我是用golang重写了一次这个demo的python部分。代码请去https://github.com/daozhao/apprtc-go。为什么重写这个，当然有原因，这里就不说了。

先说说我的发现的bug。我发现在windows的chrome经常建立不了呼叫和应答，出不了视频图像。有时候可以有时候不可以。搞不懂。使用的官方的appr.tc的网站测试和自己搭建的测试环境都一样。但是我在mac OS X上的chrome肯定是可以的。实在搞不懂。

测试了很久，终于发现规律了。就是我如果是通过Mac OS X 上的Microsoft Remote Desktop去登陆windows进行操作，进行测试是没有任何问题的。但是如果我是直接在windows的主机上操作就是老出不到图像。或者，先remote过windows，chrome进行过呼叫，并出过图像，然后再在windows主机操作，这样也是可以的。这个真的令我奇怪不已。

不过找其他同事的windows机器测试并没有此问题。真的傻了，chrome升级了一遍又一遍，卸载重装。问题依旧。后来细心思考了一会儿，估计出问题是截屏问题，因为我的windows是台式机，并没有摄像头。呼叫或者应答的时候是输出桌面的截屏视频的。后来我在主机接上了一个usb摄像头。并在chrome的设置使用该摄像头。发觉问题解决了。这个问题搞了我2天。真的TMD。

在这个bug解决后，我继续思考。chrome的桌面输出是需要在启动的时候添加参数才可以。我由第一次使用chrome测试webrtc就没有打开过这个参数，就可以输出桌面的。我开始并不以为然。以为网上的资料有错，由或者我之前打开了chrome的测试模式。现在看来这个桌面输出并不是chrome自带的。而且我安装了一个第三方的截屏输出的驱动。而chrome把它也当作一个摄像头。我查询了一下这个截屏输出是screen-capture-recorder。原来这个东西和chrome有点不合。不过我在别的同事也安装了这个插件的机器上，并没有我的问题。看来是版本的原因。

交叉编译Android平台glib库和其他一些库

最近有需要把glib库编译上Android上。网上搜索了一下，发觉有人已经写了详细的编译步骤出来了。

编译可在Android上运行的依赖库（一）：glib库
 交叉编译Android平台glib库

但是按照其方法还是有不少问题。我也不想在这里说明了。因为我估计这些问题可能和你的编译环境等有关系。每个人的机器环境可能都有小小区别。虽然文章也給了具体编译环境的说明，和编译的软件的版本信息。理论上应该没有太多问题。但是我实质上还是遇到问题。现在提供一个docker来统一编译环境，这样就可以减少问题的存在。而且还提供了编译脚本。其实我已经在建立docker的时候也顺便把编译的工作做了。节省时间。你只要把

docker pull daozhao/glib-android-build-docker

下来，就可以直接使用了。使用的编译方式与文中有点区别，使用standalone的方式编译。我觉得这样的方式比较方便，特别需要对C++的支持。

编译了glib库及依赖包列表：
1) iconv (1.14) https://www.gnu.org/software/libiconv/
2) gettext (0.19.8) https://www.gnu.org/software/gettext/
3) pcre (8.40) http://www.pcre.org/
4) libffi (3.2.1) https://sourceware.org/libffi/
5) glib (2.44.1) https://developer.gnome.org/glib/stable/

其他一下库的包列表
6) jansson (2.10) http://www.digip.org/jansson/
7) gengetopt (2.22.6) https://www.gnu.org/software/gengetopt/gengetopt.html
8) libsrtp (2.0.0) https://github.com/cisco/libsrtp
9) gmp (6.1.2) https://gmplib.org/
10) nettle (3.1) https://www.lysator.liu.se/~nisse/nettle/
11) gnutls (3.5.13) http://www.gnutls.org/
12) libnice (0.1.14) https://nice.freedesktop.org/wiki/
13) libmicrohttpd (0.9.54) https://www.gnu.org/software/libmicrohttpd/

使用方法

docker run -it daozhao/glib-android-build-docker bash

修复mac OS X的Docker: No Space Left on Device

mac os x的docker现在比较好用，虽然macOS都是POSIX系统。但是多少都和linux系统有点不一样。所以我实验一些新软件系统的时候很多时候还是需要linux系统，以前多数使用虚拟机进行。现在喜欢用docker了。虽然mac上的docker也是运行在虚拟机上的。但是运行效果和在linux上没有什么区别。但有一个问题困扰了我很久。就是经常出现No Space Left on Device。明明我的磁盘还有很多空间。就是老出现这句提示。原来的处理方式，是删除一些不需要的image。最近由于剩下的images都是需要的，删无可删了。

只能上网找解决方法。发现这个问题还是不好处理的。最后虽然成功处理了。大家发觉处理的方式和网上说的有点不一样，所以记录下来。不能说别人的方法错误，只能说明我更加黑仔。

首先，这个不够磁盘空间的问题产生有几种情况的。

1 虚拟机的虚拟磁盘空间不够了。

2 是虚拟机的磁盘分区导致空间不够。（估计大部分人都是这个问题，我就是这个问题导致的。）都不知道为什么docker这么傻逼，生成一个虚拟磁盘是64G的。但是在这个磁盘上在分配一个18G的分区进行使用，超过18G就不能用了。超级傻逼。

现在讲处理方法。

继续阅读“修复mac OS X的Docker: No Space Left on Device”