Akawa

ETY001的博客

发表于 更新于

新安装了centos6.2，要使用一个usb网卡，但是插上后没有反映，执行lsusb如下：
[root@pangu dm9601]# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 004: ID 0fe6:9700 Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter Bus 003 Device 003: ID 04b3:3025 IBM Corp. NetVista Full Width Keyboard Bus 005 Device 002: ID 1d57:0008 Xenta

阅读全文 »

发表于 更新于

转自：http://blog.csdn.net/xhu_eternalcc/article/details/13632643

今天用U盘装linux时候不小心将grub安装到了U盘上，导致每次启动系统都得插U盘，下面是解决办法，拷贝时忘了记下转载出处，实在不好意思。

装CentOS的时候用的是u盘安装，不小心把grub装在了u盘上，然后每次都要从u盘启动，当然不能容忍这样子，以下就是修复grub的过程：

阅读全文 »

发表于 更新于

转自：https://www.ibm.com/developerworks/cn/linux/l-cn-nohup/

我们经常会碰到这样的问题，用 telnet/ssh 登录了远程的 Linux 服务器，运行了一些耗时较长的任务， 结果却由于网络的不稳定导致任务中途失败。如何让命令提交后不受本地关闭终端窗口/网络断开连接的干扰呢？下面举了一些例子， 您可以针对不同的场景选择不同的方式来处理这个问题。

nohup/setsid/&

场景：

如果只是临时有一个命令需要长时间运行，什么方法能最简便的保证它在后台稳定运行呢？

hangup 名称的来由

在 Unix 的早期版本中，每个终端都会通过 modem 和系统通讯。当用户 logout 时，modem 就会挂断（hang up）电话。 同理，当 modem 断开连接时，就会给终端发送 hangup 信号来通知其关闭所有子进程。

阅读全文 »

发表于 更新于

在ubuntu下编译opencv程序后，执行报下面到错误：

error while loading shared libraries: libopencv_core.so.2.4: cannot open shared object file: No such file or directory

解决方法：找到libopencv_开头到库的目录，在/usr/local/lib下面，在/etc/ld.so.conf.d/下面新建一个opencv.conf，里面写入/usr/local/lib，最后执行下sudo ldconfig -v即可。

参考：http://stackoverflow.com/questions/12335848/opencv-program-compile-error-libopencv-core-so-2-4-cannot-open-shared-object-f

发表于 更新于

转自：http://blog.csdn.net/denghp83/article/details/16951437

源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
#include
#include
#include "opencv2/core/core.hpp"
#include "opencv2/features2d/features2d.hpp"
#include "opencv2/highgui/highgui.hpp"
#include <opencv2/opencv.hpp>
#include using namespace cv;
using namespace std;
int main()
{
Mat a;
return 1;
}

Makefile：

1
2
main: reg.cpp
g++ -o ${@} $< `pkg-config opencv --cflags --libs `

注意，g++语句一定要按照如上顺序来，pkg-config opencv –flags –libs(依赖文件) 一定要放在后面。（放在前面的话会出现莫名奇妙的错误）
pkg-config的解释见博文：PKG_CONFIG_PATH变量 与 ld.so.conf 文件

PKG_CONFIG_PATH变量 与 ld.so.conf 文件

文章来源：http://hi.baidu.com/dexinmeng/item/73768319cb45edf864eabf2c
一、编译和连接
一般来说，如果库的头文件不在 /usr/include 目录中，那么在编译的时候需要用 -I 参数指定其路径。由于同一个库在不同系统上可能位于不同的目录下，用户安装库的时候也可以将库安装在不同的目录下，所以即使使用同一个库，由于库的路径的不同，造成了用 -I 参数指定的头文件的路径也可能不同，其结果就是造成了编译命令界面的不统一。如果使用 -L 参数，也会造成连接界面的不统一。编译和连接界面不统一会为库的使用带来麻烦。
为了解决编译和连接界面不统一的问题，人们找到了一些解决办法。其基本思想就是：事先把库的位置信息等保存起来，需要的时候再通过特定的工具将其中有用的信息提取出来供编译和连接使用。这样，就可以做到编译和连接界面的一致性。其中，目前最为常用的库信息提取工具就是下面介绍的 pkg-config。
pkg-config 是通过库提供的一个 .pc 文件获得库的各种必要信息的，包括版本信息、编译和连接需要的参数等。这些信息可以通过 pkg-config 提供的参数单独提取出来直接供编译器和连接器使用。
The pkgconfig package contains tools for passing the include path and/or library paths to build tools during the make file execution.
pkg-config is a function that returns meta information for the specified library.
The default setting for PKG_CONFIG_PATH is /usr/lib/pkgconfig because of the prefix we use to install pkgconfig. You may add to PKG_CONFIG_PATH by exporting additional paths on your system where pkgconfig files are installed. Note that PKG_CONFIG_PATH is only needed when compiling packages, not during run-time.
在默认情况下，每个支持 pkg-config 的库对应的 .pc 文件在安装后都位于安装目录中的 lib/pkgconfig 目录下。例如，我们在上面已经将 Glib 安装在 /opt/gtk 目录下了，那么这个 Glib 库对应的 .pc 文件是 /opt/gtk/lib/pkgconfig 目录下一个叫 glib-2.0.pc 的文件：

prefix=/opt/gtk/
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

glib_genmarshal=glib-genmarshal
gobject_query=gobject-query
glib_mkenums=glib-mkenums

Name: GLib
Description: C Utility Library
Version: 2.12.13
Libs: -L${libdir} -lglib-2.0
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include

使用 pkg-config 的 –cflags 参数可以给出在编译时所需要的选项，而 –libs 参数可以给出连接时的选项。例如，假设一个 sample.c 的程序用到了 Glib 库，就可以这样编译：
$ gcc -c pkg-config --cflags glib-2.0 sample.c
然后这样连接：
$ gcc sample.o -o sample pkg-config --libs glib-2.0
或者上面两步也可以合并为以下一步：
$ gcc sample.c -o sample pkg-config --cflags --libs glib-2.0
可以看到：由于使用了 pkg-config 工具来获得库的选项，所以不论库安装在什么目录下，都可以使用相同的编译和连接命令，带来了编译和连接界面的统一。
使用 pkg-config 工具提取库的编译和连接参数有两个基本的前提：

库本身在安装的时候必须提供一个相应的 .pc 文件。不这样做的库说明不支持 pkg-config 工具的使用。
pkg-config 必须知道要到哪里去寻找此 .pc 文件。
GTK+ 及其依赖库支持使用 pkg-config 工具，所以剩下的问题就是如何告诉 pkg-config 到哪里去寻找库对应的 .pc 文件，这也是通过设置搜索路径来解决的。
对于支持 pkg-config 工具的 GTK+ 及其依赖库来说，库的头文件的搜索路径的设置变成了对 .pc 文件搜索路径的设置。.pc 文件的搜索路径是通过环境变量 PKG_CONFIG_PATH 来设置的，pkg-config 将按照设置路径的先后顺序进行搜索，直到找到指定的 .pc 文件为止。

安装完 Glib 后，在 bash 中应该进行如下设置：
$ export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
可以执行下面的命令检查是否 /opt/gtk/lib/pkgconfig 路径已经设置在 PKG_CONFIG_PATH 环境变量中：
$ echo $PKG_CONFIG_PATH
这样设置之后，使用 Glib 库的其它程序或库在编译的时候 pkg-config 就知道首先要到 /opt/gtk/lib/pkgconfig 这个目录中去寻找 glib-2.0.pc 了（GTK+ 和其它的依赖库的 .pc 文件也将拷贝到这里，也会首先到这里搜索它们对应的 .pc 文件）。之后，通过 pkg-config 就可以把其中库的编译和连接参数提取出来供程序在编译和连接时使用。
另外还需要注意的是：环境变量的设置只对当前的终端窗口有效。如果到了没有进行上述设置的终端窗口中，pkg-config 将找不到新安装的 glib-2.0.pc 文件、从而可能使后面进行的安装（如 Glib 之后的 Atk 的安装）无法进行。

在我们采用的安装方案中，由于是使用环境变量对 GTK+ 及其依赖库进行的设置，所以当系统重新启动、或者新开一个终端窗口之后，如果想使用新安装的 GTK+ 库，需要如上面那样重新设置 PKG_CONFIG_PATH 和 LD_LIBRARY_PATH 环境变量。
这种使用 GTK+ 的方法，在使用之前多了一个对库进行设置的过程。虽然显得稍微繁琐了一些，但却是一种最安全的使用 GTK+ 库的方式，不会对系统上已经存在的使用了 GTK+ 库的程序（比如 GNOME 桌面）带来任何冲击。
为了使库的设置变得简单一些，可以把下面的这两句设置保存到一个文件中（比如 set_gtk-2.10 文件）:

export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
之后，就可以用下面的方法进行库的设置了（其中的 source 命令也可以用 . 代替）：
$ source set_gtk-2.10
只有在用新版的 GTK+ 库开发应用程序、或者运行使用了新版 GTK+ 库的程序的时候，才有必要进行上述设置。

如果想避免使用 GTK+ 库之前上述设置的麻烦，可以把上面两个环境变量的设置在系统的配置文件中（如 /etc/profile）或者自己的用户配置文件中（如 /.bash_profile） ；库的搜索路径也可以设置在 /etc/ld.so.conf 文件中，等等。这种设置在系统启动时会生效，从而会导致使用 GTK+ 的程序使用新版的 GTK+ 运行库，这有可能会带来一些问题。当然，如果你发现用新版的 GTK+ 代替旧版没有什么问题的话，使用这种设置方式是比较方便的。加入到/.bashrc中，例如：
PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig
重启之后：
[root@localhost ~]# echo $PKG_CONFIG_PATH
/opt/gtk/lib/pkgconfig

二、运行时

库文件在连接（静态库和共享库）和运行（仅限于使用共享库的程序）时被使用，其搜索路径是在系统中进行设置的。一般 Linux 系统把 /lib 和 /usr/lib 两个目录作为默认的库搜索路径，所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：
在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
在 /etc/ld.so.conf 文件中添加库的搜索路径。
将自己可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择 ^_^
添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。例如：
/usr/X11R6/lib
/usr/local/lib
/opt/lib
需要注意的是：第二种搜索路径的设置方式对于程序连接时的库（包括共享库和静态库）的定位已经足够了，但是对于使用了共享库的程序的执行还是不够的。这是因为为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，所以是直接读取库列表文件 /etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是一个非文本的数据文件，不能直接编辑，它是根据 /etc/ld.so.conf 中设置的搜索路径由 /sbin/ldconfig 命令将这些搜索路径下的共享库文件集中在一起而生成的（ldconfig 命令要以 root 权限执行）。因此，为了保证程序执行时对库的定位，在 /etc/ld.so.conf 中进行了库搜索路径的设置之后，还必须要运行 /sbin/ldconfig 命令更新 /etc/ld.so.cache 文件之后才可以。ldconfig ,简单的说，它的作用就是将/etc/ld.so.conf列出的路径下的库文件 缓存到/etc/ld.so.cache 以供使用。因此当安装完一些库文件，(例如刚安装好glib)，或者修改ld.so.conf增加新的库路径后，需要运行一下 /sbin/ldconfig使所有的库文件都被缓存到ld.so.cache中，如果没做，即使库文件明明就在/usr/lib下的，也是不会被使用的，结果编译过程中抱错，缺少xxx库，去查看发现明明就在那放着，搞的想大骂computer蠢猪一个。 ^_^
在程序连接时，对于库文件（静态库和共享库）的搜索路径，除了上面的设置方式之外，还可以通过 -L 参数显式指定。因为用 -L 设置的路径将被优先搜索，所以在连接的时候通常都会以这种方式直接指定要连接的库的路径。

前面已经说明过了，库搜索路径的设置有两种方式：在环境变量 LD_LIBRARY_PATH 中设置以及在 /etc/ld.so.conf 文件中设置。其中，第二种设置方式需要 root 权限，以改变 /etc/ld.so.conf 文件并执行 /sbin/ldconfig 命令。而且，当系统重新启动后，所有的基于 GTK2 的程序在运行时都将使用新安装的 GTK+ 库。不幸的是，由于 GTK+ 版本的改变，这有时会给应用程序带来兼容性的问题，造成某些程序运行不正常。为了避免出现上面的这些情况，在 GTK+ 及其依赖库的安装过程中对于库的搜索路径的设置将采用第一种方式进行。这种设置方式不需要 root 权限，设置也简单：
$ export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
可以用下面的命令查看 LD_LIBRAY_PATH 的设置内容：
$ echo $LD_LIBRARY_PATH
至此，库的两种设置就完成了。

发表于 更新于

今天晚上大约10点左右，实验室的OA服务器莫名重启，然后mysql就一直是连不上的样子，经过各种尝试无果后，用搜索引擎找到了解决方法，其实也怨我不仔细，在用netstat查端口开放的时候，忽略了ipv6的端口，在my.ini的mysqld下面设置bind-address为0.0.0.0或者127.0.0.1即可解决问题了。睡觉。。。

ipv6-port

发表于 更新于

转自：http://blog.csdn.net/cy513/article/details/4285579

SIFT/SURF基于灰度图，

一、首先建立图像金字塔，形成三维的图像空间，通过Hessian矩阵获取每一层的局部极大值，然后进行在极值点周围26个点进行NMS，从而得到粗略的特征点，再使用二次插值法得到精确特征点所在的层（尺度），即完成了尺度不变。

二、在特征点选取一个与尺度相应的邻域，求出主方向，其中SIFT采用在一个正方形邻域内统计所有点的梯度方向，找到占80%以上的方向作为主方向；而SURF则选择圆形邻域，并且使用活动扇形的方法求出特征点主方向，以主方向对齐即完成旋转不变。

三、以主方向为轴可以在每个特征点建立坐标，SIFT在特征点选择一块大小与尺度相应的方形区域，分成16块，统计每一块沿着八个方向占的比例，于是特征点形成了128维特征向量，对图像进行归一化则完成强度不变；而SURF分成64块，统计每一块的dx，dy，|dx|，|dy|的累积和，同样形成128维向量，再进行归一化则完成了对比度不变与强度不变。

阅读全文 »

发表于 更新于

转载请注明：土人的国度 » SQL防注入:使用base64构建安全查询

SQL注入，主要是通过加入特殊字符，使用特殊编码将非法SQL语句注入到查询中，并得到返回数据

看到了一些防SQL注入的手段，自己也经过思考总结了一下，得到了一个流程：

1.查询前强制转换输入

对于提交的输入：

特定类型int, date等：进行强制类型转换，如intval, date_create；

字符串一律使用mysql_real_escape_string过滤

有格式的使用正则表达式进行验证

对于不需要模糊查询的字段，建议使用base64编码后再进一步处理并存入数据库，下文详述

阅读全文 »

发表于 更新于

在参加一个48小时的创客活动时，做了一个应用，用到了html5中的canvas，其中有一个步骤是读取9张图片画在canvas上，我遇到的难题就是onload函数的异步回调问题。最初的部分代码如下：

1
2
3
4
5
6
7
8
9
10
11
function fillJPG(ctx, el , width , height , i){
  var img;
  for(var i=0;i<MAX;i++){
    img = new Image();
    img.onload = function(){
      ctx.drawImage(img,width*i,0,width,height);
      /* console.log(i); */
    }
    img.src = el[i];
  }
}

这个代码中ctx是画布，el是图片url的数组，width和height分别是单张图片的宽和高，同时也可以用于计算坐标和图片大小压缩。
问题出现就是本来应该横向并排出现的9张图片一张都没有出现。把MAX调整为1后，发现，图片显示出来了，就一张，但是位置却出现在了第二张图片应该出现的问题，经过一晚上的调试，发现问题出现在回调函数。回调函数的执行时间是发生在图片载入结束，而循环体的执行是一直的，也就是i是一直在累加的，可以发现的就是i的累加速度快于图片载入的速度，所以，第一张图片载入完成的时候，i已经是1了（在MAX为1的情况下，其实也就是i为MAX了），也就是说图片是出现在了第MAX+1的位置上面了。

尝试过了一些方法，都避免不了这个异步，最终使用递归的方法来实现了这个功能，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
function fillJPG(ctx, el , width , height , i){
  var img = new Image();
  img.onload = function(){
    ctx.drawImage(img,width*i,0,width,height);
    i++;
    if(i<MAX){
      fillJPG(ctx,el,width,height,i);
    } else {
      return;
    }
  }
  img.src = el[i];
}
0%