大概一个半月之前，入手了一个 HG255D用来刷OpenWRT，主要是有两个目的：一是本来宿舍的交换机没了想买个来替代交换机，二是买个通用机型来熟悉一下OpenWRt的编译流程。基本上两个目的都达到了，这里撰文记录一下为HG255D编译OpenWRT的流程，以及遇到的一些问题，还有一些OpenWRT的基本的概念。还有就是想给使用HG255D的同学一些刷机的指导。

1. 硬件。HG255D 是华为的一款路由器，支持 USB，而且有4个LAN口，最主要的是便宜-> 20包邮，而且它的折腾教程是相当的丰富。从OpenWRT官网的数据可以知道它的硬件信息大概如下

• CPU Ralink RT3052 MIPS 24K @384 MHz
• RAM 32 MiB
• Flash S29GL128P 128(sectors)X128(Kbytes)=16Mbytes
• Wireless Ralink APSoC RT2860 b/g/n 2T2R (integrated)
• Switch Integrated 6 Port Fast Ethernet Switch
• USB Yes (1 Port)
• Serial Yes
• JTAG Yes
  当然还有拆解的帖子在这里

Dockerfile 的编写。我们可以使用 docker build 来创建一个新的镜像。为此，首先需要创建一个 Dockerfile，包含一些如何创建镜像的指令。Dockerfile里面的每一条指令创建镜像的一层，只是有的层有tag而有的层是没有的。

1. Dockerfile 的基本语法

• 使用 # 来注释
• 基础镜像信息，FROM 指令告诉 Docker 使用哪个镜像作为基础镜像。
• 维护者的信息，基本格式是MAINTAINER docker_user [email protected]
• 镜像操作指令，类似RUN之类的指令将对镜像执行跟随的命令。每运行一条RUN 指令，镜像添加新的一层，并提交。
• 容器启动时的执行指令，类似CMD 指令，来指定运行容器时的操作命令。
  编写完成 Dockerfile 后可以使用 docker build 来生成镜像可以看到 build 进程在执行操作。它要做的第一件事情就是上传这个 Dockerfile 内容， 因为所有的操作都要依据 Dockerfile 来进行。然后，Dockfile中的指令被一条一条的执行。每一步都创建了一个新的容器，在容器中执行指令并提交修改（就跟之前介绍过的docker commit一样）。当所有的指令都执行完毕之后，返回了最终的镜像id。所有的中间步骤所产生的容器都被删除和清理了。

很久之前就说要学Docker，但是一直断断续续的学了一点，这个暑假终于腾出点时间把Docker过一下。主要是阅读 《Docker-从入门到实践》这本书，然后看了一下希云的视频，留此文章用于备忘。

1. Docker简述

2. Docker 项目的目标是实现轻量级的操作系统虚拟化解决方案。Docker 的基础是Linux 容器 (LXC) 等技术。

3. Docker 和传统虚拟化方式的不同之处:容器是在操作系统层面上实现虚拟化，直接复用本地主机的操作系统，而传统方式则是在硬件层面实现。

4. Docker 容器的启动可以在秒级实现,容器除了运行其中应用外， 基本不消耗额外的系统资源，使得应用的性能很高，同时系统的开销尽量小。

在大概一个月之前，重邮的LUG团购了一波日本的AU HOME SPOT CUBE，大概一个人12块左右，自己买了一个，同时帮同学买了一个。自己在校园网环境下面使用了大概一个月，除了覆盖范围小了点外，感觉还是很不错的，但是在使用的过程中还是踩过不少的坑，遂撰文记录之，以给后来的学弟学妹一点人生的经验。

事情的起因是这样的，在我皇家邮电大学即将举办CCTF之际，有个哥跑到大重邮的Linux的协会群放了一个精彩图片合集.chm的文件。并能够看到点击该文件的群里同学的桌面而且还有访问摄像头的功能。群里一篇慌乱，使得释放木马的哥开心的合不拢嘴。很多同学表示无能为力，我也点了一下那个文件，然后电脑卡了几秒之后然后就看到了那个文件里面并没有什么内容。这个时候我也慌了，从来没有感觉到原来安全这么的重要，于是我决心破解那个木马，并努力学习安全防御。

这是一篇翻译的文章，原文链接,当然这个链接的内容也是来自这里。在此之前你可能需要了解一些Scene Graph的知识，你可以参照：

• Scene graph
• Scene Management - Scene Graph
• 不朽的SceneGraph
• 既方便又强大的QML Scene Graph
• 场景渲染(Scene Graph)
• Qt新渲染底层Scene Graph研究

and then 开始翻译

Qt 中的场景图

在 Qt Quick 2 中使用了基于OpenGL ES 2.0或OpenGL 2.0的场景图来进行渲染。使用场景图进行绘图而不是传统的绘图机制（QPainter类似的）意味着渲染的场景可以在帧间保留，并且将要渲染的完整的一组基本元素在渲染开始之前就已经知道了。这就允许一系列的优化，比如分批渲染来尽可能的减小状态的改变和丢弃被覆盖的元素。

由于BananaPro在使用MQ-2传感器的时候要采集模拟电压，所以必须使用AD转换模块。这个过程也是异常艰辛，大概花了3-4天才解决这个问题故记录之。首先，由于这边的AD芯片奇缺，TI又不让申请，不给申请也就算了还给我打广告，真是醉了。后面学弟给了一块ADS1286，然后在调试过程中拿不到数据，后面发现貌似是由于ADS用的是5v供电，然后BananaPro的GPIO的拉高的电压是3.3V，相比5V的80%还是不够高。再者就是由于PCB绘制过程中使用的RGB_LED的共阴和共阳弄反了，因此干脆就直接重新换了一块ADS1118。下面就主要讲在BananaPro中使用ADS1118的一些人生的经验。

我们知道像raspberry、BananaPro之类的开发板与普通linux电脑的很大的区别就是它可以将GPIO口引出方便大家连接各种模块，因此，对GPIO口的了解就显得尤为重要。对于Lemaker的BananaPro官方的wiki其实已经写得很详细，之所以拿出来单独写一是想在自己的博客上面留个笔记，二是遇到一些很奇葩的问题需要特别引起注意。

GPIO口的操作根据使用的语言和方式的不同也可以使用不同的库，一个是使用C语言的WiringLMK,官方的说明在这里，还有就是使用Python的LMK.GPIO官方的说明在这里，再有就是使用web进行控制的webio-lemaker。本人了解的目前就只有这三种方式。由于在实际使用中只用过wiringPi的库所以接下来只会介绍这个库，后面如果用到其他的库会在本文一并加上。

继上面给BananaPro编译好GPU的驱动后，已经迫不及待地要把Qt移植到开发板上看看效果。但是过程并不省心，主要还是一些概念没有弄清楚，导致了各种奇葩的错误。所以在做一件事情之前一定要阅读大量的文档，尤其是官方的文档，这样不仅能够减少走的弯路，更是最快的捷径。在这里是通过交叉编译的方式移植最新版的Qt5.6.0到BananaPro，这也是继Qt4.8之后的Qt5的首个LTS版。

上承我们刚刚构建最小文件系统，下承即将要编译Qt，在这里我们编译一下BananaPro的GPU驱动。在官方的linux中并没有将GPU驱动编译进内核，不过可以在官方wiki->BananaPro/Pi:GPU)中编译用户空间的驱动，然后在开机的时候加载就好了，编译过程也很简单，基本上就是按照wiki的步骤一步步来就ok。不过在此之前，我们很有必要搞清楚一些概念性的东西(大部分来自各个百科)。